vipsthumbnail generates corrupt images about libvips HOT 17 CLOSED

Oh dear, that's bad.

What version are you using? I tried in 7.30.4 and git master and it worked OK there.

from libvips.

try

vipsthumbnail --vips-version

to see the version of the libvips library you are using.

from libvips.

I tried on a win7 machine using the current version of libvips on Windows (7.30.3) and it worked OK for me.

http://www.vips.ecs.soton.ac.uk/supported/7.30/win32/vips-dev-7.30.3.zip

Are you running an old version?

from libvips.

I'm running libvips 7.30.3-Mon Oct 1 14:38:45 BST 2012

Its not a specific image that has the problem and its not consistent. Here are 3 consecutive runs of the program and it worked the 2nd time. I wonder if its significant the number of "read warnings" are different?

C:>vipsthumbnail.exe --size=2404 --verbose -n 42-35276890-MEDHI_IPTC.jpg --output=tn_%s.jpg:70
thumbnailing 42-35276890-MEDHI_IPTC.jpg
detected format as jpeg
using fast jpeg shrink, factor 1
thumbnailing 42-35276890-MEDHI_IPTC.jpg as tn_42-35276890-MEDHI_IPTC.jpg:70
integer shrink by 2
residual scale by 0.870384
bilinear interpolation
vips warning: VipsJpeg: read gave 88 warnings
vips warning: VipsJpeg: Application transferred too many scanlines

C:>vipsthumbnail.exe" --size=2404 --verbose -n 42-35276890-MEDHI_IPTC.jpg --output=tn_%s.jpg:70
thumbnailing 42-35276890-MEDHI_IPTC.jpg
detected format as jpeg
using fast jpeg shrink, factor 1
thumbnailing 42-35276890-MEDHI_IPTC.jpg as tn_42-35276890-MEDHI_IPTC.jpg:70
integer shrink by 2
residual scale by 0.870384
bilinear interpolation

C:>vipsthumbnail.exe" --size=2404 --verbose -n 42-35276890-MEDHI_IPTC.jpg --output=tn_%s.jpg:70
thumbnailing 42-35276890-MEDHI_IPTC.jpg
detected format as jpeg
using fast jpeg shrink, factor 1
thumbnailing 42-35276890-MEDHI_IPTC.jpg as tn_42-35276890-MEDHI_IPTC.jpg:70
integer shrink by 2
residual scale by 0.870384
bilinear interpolation
vips warning: VipsJpeg: read gave 80 warnings
vips warning: VipsJpeg: Application transferred too many scanlines

from libvips.

Hi again, I've been able to test on a win machine and I see this problem too. I don't get it on linux, which is strange.

I'll investigate. It looks like a race condition caused by differences in the threading systems between the two operating systems.

Thanks for the report ferryfax.

from libvips.

Hi again, I think I've found the problem, it was on linux as well, just not quite as often.

libvips caches a few scanlines behind the read point when loading jpeg images for sequential processing. The number of lines cached was set to exactly what should be needed and had no room for "slop". When running with many threads some can get ahead or behind by small amounts. The cache needs to have a bit of spare room to allow for this.

I've raised the linecache size by 50% and this seems to have stopped the problem. With this change:

jcupitt@b03d48e

I was able to run your vipsthumbnail command 100 times with no problems.

I'm making a new windows binary now, I'll test there too.

from libvips.

That's great!

Thanks very much for the quick response. Now if I could only get it to maintain the APP0 and Exif resolution settings from the original that would be awesome.

from libvips.

Here's a test windows binary with this fix:

http://www.vips.ecs.soton.ac.uk/development/vips-dev-7.30.4.zip

Would you be able to test it? I should be able to test as well tomorrow.

from libvips.

Oh, it's supposed to keep the exif and app0 resolution settings, are they getting lost?

Here's what I see on linux:

$ header -a img_0075.jpg | grep -i res
memory: high-water mark 0 bytes
xres: 7.086614
yres: 7.086614
exif-Compression: 6 (JPEG compression, Short, 1 components, 2 bytes)
exif-X-Resolution: 180 (180, Rational, 1 components, 8 bytes)
exif-Y-Resolution: 180 (180, Rational, 1 components, 8 bytes)
exif-Resolution Unit: 2 (Inch, Short, 1 components, 2 bytes)
exif-Compressed Bits per Pixel: 2 ( 2, Rational, 1 components, 8 bytes)
exif-Focal Plane X-Resolution: 7766.9902912621355 (7766.990, Rational, 1 components, 8 bytes)
exif-Focal Plane Y-Resolution: 7741.9354838709678 (7741.935, Rational, 1 components, 8 bytes)
exif-Focal Plane Resolution Unit: 2 (Inch, Short, 1 components, 2 bytes)
resolution-unit: in
$ vipsthumbnail img_0075.jpg
$ header -a tn_img_0075.jpg | grep -i res
memory: high-water mark 0 bytes
xres: 7.086614
yres: 7.086614
exif-Compression: 6 (JPEG compression, Short, 1 components, 2 bytes)
exif-X-Resolution: 180 (180.00000000, Rational, 1 components, 8 bytes)
exif-Y-Resolution: 180 (180.00000000, Rational, 1 components, 8 bytes)
exif-Resolution Unit: 2 (Inch, Short, 1 components, 2 bytes)
exif-Compressed Bits per Pixel: 2 (2.0000000000, Rational, 1 components, 8 bytes)
exif-Focal Plane X-Resolution: 7766.9902907178612 (7766.990291, Rational, 1 components, 8 bytes)
exif-Focal Plane Y-Resolution: 7741.9354827080242 (7741.935483, Rational, 1 components, 8 bytes)
exif-Focal Plane Resolution Unit: 2 (Inch, Short, 1 components, 2 bytes)
resolution-unit: in

exif overrides app0, I think.

from libvips.

That version works great thanks.

As for the resolution here is what JPEGsnoop shows for the original 5500x5524 and for a thumbnail created at 2404x2414. As you can see it changes the APP0 JFIF resolution to be an aspect ration instead of dpi and it messes with the Exif. It even changes the embbeded exif IFD1 thumbnail resolution for good measure.

*** Marker: APP0 (xFFE0) ***
OFFSET: 0x00000002
length = 16
identifier = [JFIF]
version = [1.2]
density = 300 x 300 DPI (dots per inch)
thumbnail = 0 x 0

*** Marker: APP1 (xFFE1) ***
OFFSET: 0x00000320
length = 15820
Identifier = [Exif]
Identifier TIFF = 0x[4D4D002A 00000008]
Endian = Motorola (big)
TAG Mark x002A = 0x002A

EXIF IFD0 @ Absolute 0x00000332
Dir Length = 0x000D
[ImageDescription ] = "SQA Caption 1"
[Orientation ] = Row 0: top, Col 0: left
[XResolution ] = 3000000/10000
[YResolution ] = 3000000/10000
[ResolutionUnit ] = Inch
[Software ] = "Adobe Photoshop Elements 5.0 (20060914.r.77) Windows"
[DateTime ] = "2007:08:03 11:08:23"
[Artist ] = "SQA Author 1"
[Copyright ] = ".. SQA Copyright 1"
[ExifOffset ] = @ 0x0940
[XPComment ] = "SQA Description 1"
[XPSubject ] = "SQA Description 1"
[IFD0.0xEA1C ] = 0x[1CEA0000 00080000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000...]
Offset to Next IFD = 0x00001200

EXIF IFD1 @ Absolute 0x0000152A
Dir Length = 0x0006
[Compression ] = JPEG
[XResolution ] = 1/96
[YResolution ] = 1/96
[ResolutionUnit ] = Inch
[JpegIFOffset ] = @ +0x125E = @ 0x1588
[JpegIFByteCount ] = 11109
Offset to Next IFD = 0x00000000

EXIF SubIFD @ Absolute 0x00000C6A
Dir Length = 0x0005
[UserComment ] = "S"
[ColorSpace ] = sRGB
[ExifImageWidth ] = 5500
[ExifImageHeight ] = 5524
[SubIFD.0xEA1C ] = 0x[1CEA0000 00080000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000...]

After vipsthumbnail:-

*** Marker: APP0 (xFFE0) ***
OFFSET: 0x00000002
length = 16
identifier = [JFIF]
version = [1.1]
density = 1 x 1 (aspect ratio)
thumbnail = 0 x 0

*** Marker: APP1 (xFFE1) ***
OFFSET: 0x00000014
length = 15843
Identifier = [Exif]
Identifier TIFF = 0x[4D4D002A 00000008]
Endian = Motorola (big)
TAG Mark x002A = 0x002A

EXIF IFD0 @ Absolute 0x00000026
Dir Length = 0x000D
[ImageDescription ] = "SQA Caption 1"
[Orientation ] = Row 0: top, Col 0: left
[XResolution ] = -1096/28633108
[YResolution ] = -1096/28633108
[ResolutionUnit ] = Inch
[Software ] = "Adobe Photoshop Elements 5.0 (20060914.r.77) Windows"
[DateTime ] = "2007:08:03 11:08:23"
[Artist ] = "SQA Author 1"
[Copyright ] = ".. SQA Copyright 1"
[ExifOffset ] = @ 0x0988
[XPComment ] = "SQA Description 1"
[XPSubject ] = "SQA Description 1"
[IFD0.0xEA1C ] = 0x[1CEA0000 00080000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000...]
Offset to Next IFD = 0x00001218

EXIF IFD1 @ Absolute 0x00001236
Dir Length = 0x0006
[Compression ] = JPEG
[XResolution ] = -1096/28633108
[YResolution ] = -1096/28633108
[ResolutionUnit ] = Inch
[JpegIFOffset ] = @ +0x1276 = @ 0x1294
[JpegIFByteCount ] = 11109
Offset to Next IFD = 0x00000000

EXIF SubIFD @ Absolute 0x000009A6
Dir Length = 0x0007
[ExifVersion ] = 02.10
[UserComment ] = "S"
[FlashPixVersion ] = 01.00
[ColorSpace ] = sRGB
[ExifImageWidth ] = 5500
[ExifImageHeight ] = 5524
[SubIFD.0xEA1C ] = 0x[1CEA0000 00080000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000...]

from libvips.

Great, glad it's working, I've made it an official 7.30.4.

I'll close this issue and put your jpeg problem here:

https://github.com/jcupitt/libvips/issues/37

It'll make it easier for people to find if we split the two problems up.

from libvips.

Funny, I just ran into a simmiliar/identical issue on linux. Generated corrupted thumbnails even from fairly small images. Got the latest libvips from github, recompiled and works like a charm, thanks for fixing it.

Just in case this was a different issue here is the source image:

And here is the generated thumbnail:

Used command and version below:

$ vips --version && vipsthumbnail -s 300 -o thumbnail.jpg -v macro.jpg
vips-7.31.0-Sat Nov  3 16:36:57 EDT 2012
thumbnailing macro.jpg
detected format as jpeg
using fast jpeg shrink, factor 8
thumbnailing macro.jpg as thumbnail.jpg
integer shrink by 1
residual scale by 0.513699
bilinear interpolation

from libvips.

I'm setting the same problem as well with vips-7.30.6. It seems to happen when I try to create a really small thumbnail.
i.e. original image size (864, 1296) and i'm trying to scale it to (13, 20)

pixel

The error message is
vips warning: VipsJpeg: read gave 320 warnings
vips warning: VipsJpeg: Application transferred too many scanlines

I only get this message in a modified version of vipsthumbnails.c to generate multiple thumbnail sizes from an image.

from libvips.

Hi, I've just found a nasty bug in the processing pipeline used by vipsthumbnail (among others). On heavily-loaded systems there was a deadlock between two caches, one of the locks would then time out and you'd get a corrupted thumbnail. This might be the problem you're seeing.

I think this is fixed now, would you be able to test again?

http://www.vips.ecs.soton.ac.uk/supported/7.30/vips-7.30.7.tar.gz

from libvips.

Seems to be better now but if I use with -c 1, it will give some warnings:

$ time ./vipsthumbnail -c 1 -s 1280  /tmp/hs-2009-02-d-full_jpg.jpg                                                 
vips cache: miss 0x50a0820
  - jpegload "/tmp/hs-2009-02-d-full_jpg.jpg" VipsForeignLoadJpegFile (0x50a0820)
vips cache: miss 0x50a08b0
  - shrink ((VipsImage*) 0x50851d0) 1.000000 1.000000 VipsShrink (0x50a08b0)
vips cache: miss 0x50bc030
  - tilecache ((VipsImage*) 0x5085650) VipsTileCache (0x50bc030)
vips cache: miss 0x50bf000
  - embed ((VipsImage*) 0x50b23c0) 0 0 1528 594 VipsEmbed (0x50bf000)
vips cache: uncacheable 0x50c1030
  - jpegsave ((VipsImage*) 0x5085350) "/tmp/tn_hs-2009-02-d-full_jpg.jpg" VipsForeignSaveJpegFile (0x50c1030)
vips cache: miss 0x50c10b0
  - cast ((VipsImage*) 0x5085350) ((VipsBandFormat) VIPS_FORMAT_UCHAR) VipsCast (0x50c10b0)
vips cache: miss 0x50a0ee0
  - sequential ((VipsImage*) 0x50b2b40) VipsSequential (0x50a0ee0)
vips cache: miss 0x51e33f0
  - linecache ((VipsImage*) 0x50b2b40) VipsLineCache (0x51e33f0)

from libvips.

Looks like -c is actually turning on --vips-cache-trace, a thing to show the actions of the vips8 operation cache. Try --vips-concurrency 1 and see if you get any warnings.

I'll look into why the cache tracer is turning on, it shouldn't, I think.

from libvips.

Here's a patch to remove a lot of the internal flag abbrevisions:

jcupitt@6fe6171

it'll be in the next version. Thanks for reporting that.

I'll close this issue -- reopen if you're still seeing corruption.

from libvips.