Rotate increases PNG size x10 !

On Thu, Jun 24, 2010 at 6:16 AM, Philip Rhoades <phil@pricom.com.au> wrote:
> Confirmation of what is going on from the gurus would be appreciated!

It was as I guessed - the scans are in grayscale mode but the contents
are essentially a 1-bit image.

Open a scan, do image->mode->bitmap, choose 1-bit palette. Then
rotate and save - the file size will be comparable to the original.

Your image has that fine dot pattern all over the place - that's what
(I think) is causing the huge size blowup when rotated. Open a scan,
zoom to 100% or greater and look at the character of those small dots.
If you rotate the image in grayscale mode, look at the dots again at
100% or greater - they are now quite blurry. Where each dot was n
pixels of solid black, now each dot is something like n+5 pixels of
shades of gray, which makes the image harder to compress efficiently.

On the file increase when just saving - see here:
$ identify TestScanningDoc.png
TestScanningDoc.png PNG 2552x3523 2552x3523+0+0 PseudoClass 2c 8-bit
230.383kb 0.740u 0:02

$ identify TestScanningDoc_nochange.png
TestScanningDoc_nochange.png PNG 2552x3523 2552x3523+0+0 PseudoClass
256c 8-bit 366.076kb 0.870u 0:02

It appears the original has a 2-color palette, while the unchanged,
saved image has a 256-color palette.

HTH,
Chris

Chris,


On 2010-06-25 02:54, Chris Mohler wrote:
> On Thu, Jun 24, 2010 at 6:16 AM, Philip Rhoades<phil@pricom.com.au> wrote:
>> Confirmation of what is going on from the gurus would be appreciated!
>
> It was as I guessed - the scans are in grayscale mode but the contents
> are essentially a 1-bit image.
>
> Open a scan, do image->mode->bitmap, choose 1-bit palette. Then
> rotate and save - the file size will be comparable to the original.
>
> Your image has that fine dot pattern all over the place - that's what
> (I think) is causing the huge size blowup when rotated. Open a scan,
> zoom to 100% or greater and look at the character of those small dots.
> If you rotate the image in grayscale mode, look at the dots again at
> 100% or greater - they are now quite blurry. Where each dot was n
> pixels of solid black, now each dot is something like n+5 pixels of
> shades of gray, which makes the image harder to compress efficiently.
>
> On the file increase when just saving - see here:
> $ identify TestScanningDoc.png
> TestScanningDoc.png PNG 2552x3523 2552x3523+0+0 PseudoClass 2c 8-bit
> 230.383kb 0.740u 0:02
>
> $ identify TestScanningDoc_nochange.png
> TestScanningDoc_nochange.png PNG 2552x3523 2552x3523+0+0 PseudoClass
> 256c 8-bit 366.076kb 0.870u 0:02
>
> It appears the original has a 2-color palette, while the unchanged,
> saved image has a 256-color palette.


I resent my second mail (without the attachment) before reading your
response - sorry about that . .

Many thanks for the explanations - I appreciate it.

Regards,

Phil.

Chris,


On 2010-06-25 02:54, Chris Mohler wrote:
> On Thu, Jun 24, 2010 at 6:16 AM, Philip Rhoades<phil@pricom.com.au> wrote:
>> Confirmation of what is going on from the gurus would be appreciated!
>
> It was as I guessed - the scans are in grayscale mode but the contents
> are essentially a 1-bit image.
>
> Open a scan, do image->mode->bitmap, choose 1-bit palette.


I had to do:

image->mode->indexed->1bit


> Then
> rotate and save - the file size will be comparable to the original.


OK, so now the next question is: If the original is recognised by
"identify" as a 1 bit per pixel image, why doesn't Gimp keep it that way
when opening the file? At 300dpi there is no real issue with "jaggy"
edges - is it just a judgement call that a conversion to grey scale is
likely to give the best result for most situations and the file size is
a secondary consideration?

Thanks,

Phil.

On Fri, Jun 25, 2010 at 4:45 PM, Philip Rhoades <phil@pricom.com.au> wrote:
> OK, so now the next question is:  If the original is recognised by
> "identify" as a 1 bit per pixel image, why doesn't Gimp keep it that way
> when opening the file?  At 300dpi there is no real issue with "jaggy"
> edges - is it just a judgement call that a conversion to grey scale is
> likely to give the best result for most situations and the file size is
> a secondary consideration?

If the image was produced as 1bpp to begin with, I don't think
converting to Greyscale will help a lot. Maybe with rotation, but
otherwise, there should be little advantage.

Branko,


On 2010-06-26 00:54, Branko Vukelic wrote:
> On Fri, Jun 25, 2010 at 4:45 PM, Philip Rhoades<phil@pricom.com.au> wrote:
>> OK, so now the next question is: If the original is recognised by
>> "identify" as a 1 bit per pixel image, why doesn't Gimp keep it that way
>> when opening the file? At 300dpi there is no real issue with "jaggy"
>> edges - is it just a judgement call that a conversion to grey scale is
>> likely to give the best result for most situations and the file size is
>> a secondary consideration?
>
> If the image was produced as 1bpp to begin with, I don't think
> converting to Greyscale will help a lot. Maybe with rotation, but
> otherwise, there should be little advantage.


The question was - why does Gimp make the change automatically? - it
shouldn't in my view.

Thanks,

Phil.

People,

I used:

xsane-0.997-3.fc12.x86_64

to scan an A4 page at 300dpi in LineArt mode and got a file of:

325,668 t_xsane.png

I then edited it using:

gimp-2.6.8-1.fc12.x86_64

rotating the image by -0.7 and cropping slightly - the resulting image
was 10 times the size!:

3,368,891 t_xsane_-0.7.png

As another test I simply opened the original file and saved it with a
new name - this gave about a 33% increase in size:

478,305 t_xsane_nochange.png

What is going on with these size increases?

Thanks,

Phil.

On Wed, Jun 23, 2010 at 8:07 PM, Philip Rhoades <phil@pricom.com.au> wrote:
> What is going on with these size increases?

It may be that after rotation, pixels that were otherwise the same
color got anti-aliased and were slightly different color. This would
increase the image size. Can you show us the original scan?

Regards,

On Thu, 24 Jun 2010 06:04:57 am Branko Vukelic wrote:
> On Wed, Jun 23, Philip Rhoades wrote:
>> What is going on with these size increases?

> It may be that after rotation, pixels that were
> otherwise the same color got anti-aliased and were
> slightly different color. This would increase the
> image size.

Branco, that may account for the increased size of a
_rotated_ image, but Phil also increased the size simply
during a re-save of an unchanged image.

Phil, I suspect that when re-saving that image, you may
wish to check the Advanced Settings popup to ensure that
the PNG compression ratio is set to maximum at the time.

WRT the rotated image, it wouldn't so much be anti-
aliasing as that the rotation is unlikely to be precisely
right-angled, so pixels along edges would be partially
coloured, which would make the PNG compression process
less efficient.

If the image is text or something else essentially
monochrome, Phil might try desaturating, then (regardless
of desat) Auto/Stretch Contrast. This should minimise
colour-gradient effects somewhat, so provide for more
effective compression.

If minute details are not so important, saving as JPeG
will reduce the size massively without serious loss of
visual quality. Loss of quality can be adjusted to a
reasonable compromise level within the JPeG settings
during SaveAs.

Cheers; Leon

On Wed, Jun 23, 2010 at 5:30 PM, Leon Brooks
<leon-gimp@cyberknights.com.au> wrote:
> If the image is text or something else essentially
> monochrome

Or image->mode, bitmap, 1-bit palette should drastically reduce the
file size. I suspect that the 'line art' setting in xsane is
producing a grayscale image but with each pixel either solid black or
solid white, which would make the resulting PNG easy to compress.
Rotating likely causes many pixels to become shades of gray along the
edges and increasing the file size.

My scanner is dead or I'd test this out myself.

Not sure on the increase when saving the image as-is - are all of the
'Save Comment', 'Save Creation', etc. boxes unchecked in the PNG save
dialog?

Chris

Chris Mohler wrote:
> On Wed, Jun 23, 2010 at 5:30 PM, Leon Brooks
> <leon-gimp@cyberknights.com.au> wrote:
>
>> If the image is text or something else essentially
>> monochrome
>>
>
> Or image->mode, bitmap, 1-bit palette should drastically reduce the
> file size. I suspect that the 'line art' setting in xsane is
> producing a grayscale image but with each pixel either solid black or
> solid white, which would make the resulting PNG easy to compress.

The downside would be that the text is jaggy. If it's just black or gray
text on a white background, I would convert the image to indexed,
with, say 32 colors. For text, this should be enough. My guess is that
the large file is in RGB--thus the big file size.

Claus

P.S.: Is it true that future Gimp versions won't have an indexed
mode anymore?

People,

I am resending this - the firsts attempt with the attachment didn't make
it apparently . . I can provide it if anyone is interested . .


On 2010-06-24 10:08, Chris Mohler wrote:
> On Wed, Jun 23, 2010 at 5:30 PM, Leon Brooks
> <leon-gimp@cyberknights.com.au> wrote:
>> If the image is text or something else essentially
>> monochrome
>
> Or image->mode, bitmap, 1-bit palette should drastically reduce the
> file size. I suspect that the 'line art' setting in xsane is
> producing a grayscale image but with each pixel either solid black or
> solid white, which would make the resulting PNG easy to compress.
> Rotating likely causes many pixels to become shades of gray along the
> edges and increasing the file size.
>
> My scanner is dead or I'd test this out myself.
>
> Not sure on the increase when saving the image as-is - are all of the
> 'Save Comment', 'Save Creation', etc. boxes unchecked in the PNG save
> dialog?


I produced a test PNG which resembles my actual pages and confirm my
previous results - original file attached (it was deliberately scanned
not square):

235,913 TestScanningDoc.png
3,184,862 TestScanningDoc_-1.0Rotate.png
374,903 TestScanningDoc_NoChange.png

I used the Gimp defaults when saving the files - compression was set at
the max of 9.

Confirmation of what is going on from the gurus would be appreciated!

BTW, I got around the real world problem by rescanning my actual pages
(which were themselves photocopies and NOT squarely produced) by
manually rotating the pages on the scanner so the pictures ended up
being square in my PNG and not needing rotation in Gimp (although other,
minor editing was still necessary).

Regards,

Phil.