Page MenuHomePhabricator

Some broken TIF files on Commons not loading
Closed, InvalidPublicBUG REPORT

Description

Several Historic American Engineering Record (HAER) photos of the Thomas J. (T.J.) O'brien Lock and Dam on Wikimedia Commons are not loading either in search results or on their respective file page. More files may be affected, but these are what I've seen. This issue has been ongoing since at least 5 Feb. 2021. The problem has been reproduceable from different IP addresses (home & work) and from multiple browsers (Edge/Chrome/Explorer).

Steps to Reproduce:
To reproduce, visit any of the affected photos in this search:
https://commons.wikimedia.org/w/index.php?search=%22O%27Brien+Lock%22+haer
19 of the first 20 photos are showing a broken file link.
One example file is here:
https://commons.wikimedia.org/wiki/File:LOCK_VIEW._CONTROL_STATION_ON_RIGHT._LOOKING_SOUTHEAST._-_Illinois_Waterway,_Thomas_J._O%27Brien_Lock_and_Control_Works,_East_130th_Street,_Chicago,_Cook_County,_IL_HAER_IL-164-I-3.tif

Actual Results:
Where an image thumbnail or preview is usually located, a "broken image link" icon is present.

Expected Results:
In search results, an image thumbnail should be visible. On the file page, an image preview should be visible.

Event Timeline

Testing locally, it appears that vips doesn't like this file:

$ vips shrink "LOCK_VIEW._CONTROL_STATION_ON_RIGHT._LOOKING_SOUTHEAST._-_Illinois_Waterway,_Thomas_J._O'Brien_Lock_and_Control_Works,_East_130th_Street,_Chicago,_Cook_County,_IL_HAER_IL-164-I-3.tif" vips_result.png 3 3

(vips:4151): VIPS-WARNING **: 10:34:51.913: Bogus "StripByteCounts" field, ignoring and calculating from imagelength

(vips:4151): VIPS-WARNING **: 10:34:51.913: Bogus "StripByteCounts" field, ignoring and calculating from imagelength

(vips:4151): VIPS-WARNING **: 10:34:51.913: Bogus "StripByteCounts" field, ignoring and calculating from imagelength

(vips:4151): VIPS-WARNING **: 10:34:51.913: Bogus "StripByteCounts" field, ignoring and calculating from imagelength

(vips:4151): VIPS-WARNING **: 10:34:51.913: Bogus "StripByteCounts" field, ignoring and calculating from imagelength

(vips:4151): VIPS-WARNING **: 10:34:51.914: Bogus "StripByteCounts" field, ignoring and calculating from imagelength

(vips:4151): VIPS-WARNING **: 10:34:51.914: Bogus "StripByteCounts" field, ignoring and calculating from imagelength

(vips:4151): VIPS-WARNING **: 10:34:51.915: Bogus "StripByteCounts" field, ignoring and calculating from imagelength

(vips:4151): VIPS-WARNING **: 10:34:51.915: Bogus "StripByteCounts" field, ignoring and calculating from imagelength

(vips:4151): VIPS-WARNING **: 10:34:52.011: error in tile 0 x 1942

(vips:4151): VIPS-WARNING **: 10:34:52.011: error in tile 0 x 640
TIFFFillStrip: Read error at scanline 1941; got 82 bytes, expected 10032
tiff2vips: read error
vips2png: unable to write to target vips_result.png

ImageMagick ain't a fan either, but it did produce something:

$ convert -define tiff:exif-properties=no -resize 752x599^ -gravity center -extent 752x599 -quality 87 "LOCK_VIEW._CONTROL_STATION_ON_RIGHT._LOOKING_SOUTHEAST._-_Illinois_Waterway,_Thomas_J._O'Brien_Lock_and_Control_Works,_East_130th_Street,_Chicago,_Cook_County,_IL_HAER_IL-164-I-3.tif" output.jpg
convert: Bogus "StripByteCounts" field, ignoring and calculating from imagelength. `TIFFReadDirectory' @ warning/tiff.c/TIFFWarnings/960.
convert: Read error on strip 1942; got 82 bytes, expected 10032. `TIFFFillStrip' @ error/tiff.c/TIFFErrors/595.

output.jpg (599×752 px, 37 KB)

That's about half an image, which generally indicates corruption. The original from the LOC looks fine, so I've re-uploaded it. It'll take about an hour for the failure throttle to expire, then thumbnails should appear.

Aklapper renamed this task from Some Commons Photos Not Loading to Some broken TIF files on Commons not loading.Feb 9 2021, 4:01 PM

I've reuploaded the rest of the files as well.