Problem converting from TIFF to JPG

[unterninja]

Hi,

I am trying to convert (a lot of) TIFF to JPG. However, it seems there is a problem when reading the TIFF file(s). What I do is the following:

[command]: convert a.TIFF b.jpg
[output]: convert: a.TIFF: Read error at scanline 4294967295; got 969 bytes, expected 1000. `TIFFFillStrip'.

I get the same error message when using mogrify. There is actually a jpg file written, but that is of course corrupt. To me the error message suggests that the error is in the reading of the input file - not in the creation of the new one.

My IM version is 6.2.8.0-4, and my libtiff version is 3.8.2-7.

If I open one of the TIFF files in Photoshop, and first change from "Bitmap" to "Grayscale", and second from "Grayscale" to "RGB", then the conversion works fine. I've been trying to find a way to do the same operations in IM, without success. I have read the FAQ, searched the forum and Googled, and tested quite a lot of options like -type, -colorspace, -channel and so on, but since I am not that adept at image processing I did not succeed. The error message is always the same, whatever I try.

Unfortunately, the Photoshop way is not an option for me, since I need to process huge amounts of TIFF files on a daily basis.

The question is: do I need to change the TIFF file to RGB before converting it, and in that case how do I do that? Alternatively, how do I otherwise make this conversion work?.

[fmw42]

Sounds like a tiff file error. But to be sure, you could post a link to one of your files here and we can test. Also it is possible that it is an IM bug. You are using VERY OLD version of IM and possibly libtif. You should update if you can. IM 6.2.8 is nearly 350 versions old!

[unterninja]

Thanks a lot for a quick reply.

The example file can be found here: http://urre.magnetit.se/img/a.TIFF

Note that this is one of three, randomly picked, TIFF:s that I have been working with - all of them have given the same error message when converted. All of my files comes from the same source, so if there is a file error it is probably at least consistent in all the files.

350 versions! I realize that I must try with upgrading IM, it might however take some time because I first need to get hold on the machine admin to get his clearance on that. I will post the results of the upgrade as soon as I have it.

[fmw42]

When I look at your image, it is totally white? Is that what you uploaded?

identify -verbose a.TIFF
Image: a.TIFF
Format: TIFF (Tagged Image File Format)
Class: DirectClass
Geometry: 992x313+0+0
Resolution: 300x300
Print size: 3.30667x1.04333
Units: PixelsPerInch
Type: Bilevel
Base type: Bilevel
Endianess: MSB
Colorspace: RGB
Rendering intent: Undefined
Interlace: None
Background color: white
Border color: rgb(223,223,223)
Matte color: grey74
Transparent color: black
Compose: Over
Page geometry: 992x313+0+0
Dispose: Undefined
Iterations: 0
Compression: Group4
Orientation: TopLeft
Properties:
date:create: 2010-08-09T10:21:16-07:00
date:modify: 2010-08-09T10:21:16-07:00
signature: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
tiff:endian: lsb
tiff:photometric: min-is-white
tiff:rows-per-strip: 4294967295
tiff:software: FileNet Corp.; Tagged Image File Format 6.0; SC version 0303010A
Artifacts:
verbose: true
Tainted: False
Filesize: 1.5KB
Number pixels: 310K
Pixels per second: 5.175M
User time: 0.020u
Elapsed time: 0:01.060
Version: ImageMagick 6.6.3-4 2010-08-08 Q16 http://www.imagemagick.org
identify: a.TIFF: Read error on strip 0; got 969 bytes, expected 1000. `TIFFFillStrip' @ error/tiff.c/TIFFErrors/494.

So the file has some problem that IM still sees in v6.6.3-4


convert a.TIFF a.jpg
convert: a.TIFF: Read error on strip 0; got 969 bytes, expected 1000. `TIFFFillStrip' @ error/tiff.c/TIFFErrors/494.

And the jpg could not be opened.

Using exiftool, the rowsperstrip seems rather oddly large!

exiftool -s -ee -g1 -u -n -D a.TIFF
---- ExifTool ----
- ExifToolVersion : 8.24
---- System ----
- FileName : a.TIFF
- Directory : .
- FileSize : 1497
- FileModifyDate : 2010:08:09 10:21:16-07:00
- FilePermissions : 644
---- File ----
- FileType : TIFF
- MIMEType : image/tiff
- ExifByteOrder : II
---- IFD0 ----
254 SubfileType : 0
256 ImageWidth : 992
257 ImageHeight : 313
258 BitsPerSample : 1
259 Compression : 4
262 PhotometricInterpretation : 0
266 FillOrder : 1
273 StripOffsets : 528
274 Orientation : 1
277 SamplesPerPixel : 1
278 RowsPerStrip : 4294967295
279 StripByteCounts : 1000
282 XResolution : 300
283 YResolution : 300
293 T6Options : 0
296 ResolutionUnit : 2
305 Software : FileNet Corp.; Tagged Image File Format 6.0; SC version 0303010A
---- Composite ----
- ImageSize : 992x313

I am not enough of an expert on exiftool to know if you can change that parameter. I tried but it did not work. Perhaps someone else can help on this matter.

[Drarakel]

"RowsPerStrip" is writable with ExifTool, but not "StripByteCounts". And as this last tag is wrong here (or the image data not complete), ExifTool can't even change the first tag...

For a current ImageMagick, only "StripByteCounts" is important here. After this value is adjusted, there are still some error messages, but the important part of the image can be read (->"Levior"). I didn't look at the compressed image data of this file though..
"RowsPerStrip" could be valid, as the maximum value means that the strip contains all rows of the image, I think.

Some image viewers are a bit more 'forgiving' with such TIFF errors. The Windows image viewer for example can display it right away (but displays one row less when compared to the output of the other tools). IrfanView can display it - if either the "StripByteCounts" value or the "RowsPerStrip" value is adjusted. I would say, with IrfanView it looks best, as the lower rows (the rows that can't be decoded anymore) are filled with white there. In ImageMagick/libtiff or the Windows image viewer, the lower rows are filled with black.

I guess, all this doesn't really help you. You're searching for a method to convert the files automatically, right? But as your TIFF files really seem to be corrupt, you could be out of luck. One could try to patch libtiff to handle these files. Or one could try to write a script that adjusts the "StripByteCounts" values in these files. Probably not easy - and risky. The best approach probably is to open the files manually in e.g. Photoshop (as you wrote that Photoshop can open them).

[unterninja]

First, thank you both for taking your time and for providing very informative answers.

@Drarakel: I tried exiftool, which only gave me the error message: "Sorry, StripByteCounts is not writable". From what I understand you have manged to change the StripByteCounts value somehow - which tool were you using to do that?
For me, i will need to find a way to automate the conversion process so I think I will try to go with your suggestion to write a script for adjusting that value - after all, I can easily get access to the correct number to write for each file by reading the error message from IM. Or is there maybe an easier way to read out the correct value of StripByteCounts?

Thanks again to both of you!

[fmw42]

I tried exiftool, which only gave me the error message: "Sorry, StripByteCounts is not writable".

I had the same problem when I tried it. I did not get that message, but it simply said no image was changed. I even tried writing to a new image.

[Drarakel]

For that "a.TIFF" file, I just changed the values in a hex editor. But that can't be done in a script that easily..

But you could use an 'adjusted' ExifTool.
Take that configuration file (which includes a basic, writable definition of "StripByteCounts"):
ExifTool_config.zip (Link deleted)
Unzip it into your ExifTool directory. After that you should be able to update the value with "exiftool -StripByteCounts=969 a.TIFF" in this example. (You might take a look into the ExifTool documentation - and maybe the TIFF specification - for a better ExifTool configuration file.)

Regarding the value of "StripByteCounts": Yeah, you could probably take the maximum value from the ImageMagick error message (from "got ... bytes"). Or compute it from 'FileSize'-'StripOffsets'. Of course, the file will be still somewhat corrupt, but at least partly readable with IM/libtiff.
With the above configuration file, you can even do it with one exiftool command:

Code: Select all

exiftool "-IFD0:StripByteCounts<Composite:MaxByteCounts" -if "$IFD0:StripByteCounts > $Composite:MaxByteCounts" a.TIFF -execute "-IFD0:RowsPerStrip<IFD0:ImageHeight" -if "$IFD0:RowsPerStrip > $IFD0:ImageHeight" a.TIFF

(The second part with "RowsPerStrip" is not really necessary..)
Then all you have to do is loop over your files with that.

All this only applies to TIFF files with only one strip (one StripByteCounts value and one StripOffets value). If there are more of them, ExifTool won't update the StripByteCounts values with the above commands. But if you have always only one strip per file, then the above should work.

[fmw42]

You are trying to patch a problem. Why not look to the source of the problem and get it fixed there. Apparently the software creating the TIFF files is corrupting them. Go to the maker of that tool and ask them to fix the bug.

[unterninja]

I bow my head to both of you, for again giving me both quick, informative and helpful answers. This is the way it ought to be at more places.

What I've done at the moment is to approach the creator of the files, and asked them if they can deliver the files in a non-corrupt version. If that is not an option, which I believe it will turn out not to be, then I will go with the exiftool solution.

Again, many thanks for helping me out in an area where my knowledge was rather small. That knowledge has now grown quite a bit. This is going to be fun to proceed with now.