JPEG to PNG image corruption about sharp HOT 8 CLOSED

Hi Luís, I'm able to reproduce this problem via sharp as well as directly via vipsthumbnail, so this may be related to an upstream feature/problem (in either libvips or libpng).

vipsthumbnail firefox.jpg -s 256 -o firefox.png[interlace]

Let me look at the vipspng code to see if I can work out what's causing this.

from sharp.

I've just spotted that Github has converted your original "firefox.jpg" image to be PNG format.

$ identify firefox.jpg 
firefox.jpg PNG 256x256 256x256+0+0 8-bit sRGB 48.3KB 0.000u 0:00.000

Are you able to publish this image elsewhere as the original JPEG?

from sharp.

That was not GitHub's fault but mine, I made an error in my workflow and I swapped the filenames somewhere.

or you can download from the website: firefox.jpg

The problem still happens with different JPG (truly jpg =P) images.

I don't know if it's relevant, probably not, but the previous image was obtained from the alrra/browser-logos and then converted to JPG with image magick:

convert -alpha remove -background "#FFFFFF" firefox_256x256.png firefox.jpg

from sharp.

Thanks Luís, I've been able to reproduce this problem on a Mac via vipsthmbnail v7.38.5 for other JPEG images.

The problem occurs only when generating interlaced output PNGs from any input format accessed via sequential read (vipsthumbnail uses sequential read by default). The best quick fix for now is to avoid sequential read and accept the increased memory usage this brings.

I'm going to try the libvips master branch on a Linux box to generate as much debug info as possible before reporting this upstream.

from sharp.

Worry not and take your time.
Thanks for the support and awesome package :)

from sharp.

Hi @Couto are you able to test the fix for this bug, now available in master.

npm install lovell/sharp

This change has the added benefit of almost halving the time taken to generate interlaced PNG output.

from sharp.

I'm not getting corrupted images anymore :)
I'm not measuring performance for now, so I can't comment about that, but that's great news too!

Thanks a lot for this.

from sharp.

The fix for this bug is included in v0.5.2 now available via npm. Thank you for reporting this.

from sharp.