Resizing image results in larger file

[Clo]

Hello !

- Resizing with "Lanczos" provides a better look, it's obvious. But there is an odd issue when resizing, example :
• An original PNG-24BPP is 5.63 KB - 618*73
• Resized by ~ 50% (heigh / width) it becomes 8.30 KB
• Plus "Sharpen" (30%), it becomes 9.4 KB
- I noticed and reported this a long while ago… Except when you are bound to get a smaller size -h/w- (i.e. on a HTML page), resizing gives no benefit at size there (KB) , this seems illogical.
- Any explanation, please?

Best regards,
Claude
Clo

[xnview]

• An original PNG-24BPP is 5.63 KB - 618*73
• Resized by ~ 50% (heigh / width) it becomes 8.30 KB
• Plus "Sharpen" (30%), it becomes 9.4 KB
- I noticed and reported this a long while ago… Except when you are bound to get a smaller size (i.e. on a HTML page), resizing gives no benefit at size there , this seems illogical.
- Any explanation, please?

With same compression level?

[Clo]

Hi Pierre!
- The same file; the original has been made in XnView (conversion from BMP). I use always the maximal compression ratio for PNG (9)

- The same with a big GIF :
- original 1061*882 - 8 BPP = 23.2KB
- resized 530*441 - 8 BPP = 32.1 KB

- With a BMP - 24 BPP, the size is alright divided by 4, since the surface is divided by 4… This is logical.
?

Best regards,
Claude
Clo

[xnview]

- The same with a big GIF :
- original 1061*882 - 8 BPP = 23.2KB
- resized 530*441 - 8 BPP = 32.1 KB

Yes, it's funny. Compression can perhaps work better on your big picture

[helmut]

- The same with a big GIF :
- original 1061*882 - 8 BPP = 23.2KB
- resized 530*441 - 8 BPP = 32.1 KB

Yes, it's funny. Compression can perhaps work better on your big picture

Depending on the contents and origin of the image, I don't think that this result is too surprising:

O Imagine a white, empty image with just one three pixel strong, pitch black horizonzal line in it. This image would perfectly compress with Run Length Encoding and 1 pixel colour depth.
Now, you resize this image to let's say 75%. What will happen is that the horizontal line is resized to 2.25 pixel in width. Since there's no such thing as a quarter pixel, there will be two black pixel and two light grey pixel, due to the anti-aliasing. Now when saving this image, the whole image does not compress that well anymore, since more colours are used. So the image might become even larger in (file) size, although the image is smaller in dimensions.

O When sharpening an image, algorithms like JPG do not work that well anymore, since there's more details/dynamic in the image.

O Also, the PNG format allows lossy compression, this means that your original PNG might have been compressed using lossy compression, already. So the things written for JPG files in topic Smaller image has same file size may also apply.

I'm not deep in imaging and image compression, but I think my sample show how simple things may have impact on compression and file size.

[Guest]

.png's are lossless!

[lawndart]

.png's are lossless!

And with the compression ratio similar to Zip according to:
niveau de compression PNG

[helmut]

.png's are lossless!

Right, PNGs are always lossless. The compression level for the PNG format only sets the level of ZIP compression, which will affect file size & compression speed, but not change the image data.

[DOS386]

OK ... thread is 4 years old nevertheless, didn't contain much clarification so far, not even corpus delicti was attached, so finally answering

[img]optbig.png[/img]

This image gets 3 times BIGGER when resized down by factor 2

Code: Select all

************************************************************

Lanczos resize paradox (smaller bitmap, bigger file) :

************************************************************

04A10BD8B75E4EA1E6DE4B685CCCF545 
OPTBIG.PNG 17'892

F4338B9E08E97160148E3927A1816703 
OPTSMALL.PNG 40'620

************************************************************

Truecolor 3x8bpp BMP :

BIG.BMP      720'054  1'338 colors 600x400
SMALL.BMP    180'054    707 colors 300x200

Obviously, the "small" BMP must be 4 times smaller 
than the "big" one, except the 54 bytes of BMP header.

Saving as PNG using NCONVERT 5.00 (XNVIEW must give the
very same result since both contain the very same LIBPNG) :

BIG.PNG      23'028  
SMALL.PNG    69'613  More than 3 times BIGGER !!!!! 

Maximum lossless PNG optimization using PNGOUT and
DEFLOPT (OPTIPNG irrelevant here, lost against PNGOUT) :

OPTBIG.PNG   17'892  
OPTSMALL.PNG 40'620  Still 2.27 times BIGGER !!!

Additionally we can see than an optimized PNG can be 
1.7 times smaller than "standard" PNG.

************************************************************

Download: lanczos.zip

Why does the file size grow ? Because the image has "special" content, the FreeDOS fish at the top has >> 256 colours, while the ASM stuff below just 2, resizing rises the amount of colours below to 256 (all grey), so the lower part will compress badly and grow massively in size, while the negligibly small fish can't save too much

This is a special case however, and I deliberately brewed the image as-is to maximize the shock , OTOH resizing down and saving as PNG using PNG optimizers is still the best way to reduce image size, resizing by factor 2 should reduce the file size by factor 4 in average.

> the PNG format allows lossy

NO, as already found out.

> And with the compression ratio similar to Zip according

Better than ZIP, because of the filters.

resizing gives no benefit at size there (KB) , this seems illogical.
- Any explanation, please

Maybe LibPNG of XNView was not very good at that time promoting the evil effect ... retest with PNGOUT is the first thing to do next time