Error: Error reading StripOffsets data in IFD0

Started by kocus, March 30, 2010, 06:13:25 PM

Previous topic - Next topic

kocus

Hello,
I've got some problems using your exif tool. I was trying to modify EXIF data of the picture taken by Hasselblad camera H3D-39 (orginally 28MP -> resized to 1MP) and got the error below.
My system is : Win7 32bit
I'm using exiftool version : 8.15
Command example (but every command which writes exif data gives error) : exiftool.exe -ISO=200 hassel1.jpg
Output :
Error: Error reading StripOffsets data in IFD0 - hassel1.jpg
    0 image files updated
    1 files weren't updated due to errors

I'm attaching the problematic file (got the same error on the orginal version & modified by Adobe Photoshop).

Thank you for your time.

Phil Harvey

Was the original JPEG straight out of the Camera?  If so, you should send a bug report to Hasselblad.

The StripOffsets, StripByteCounts and RowsPerStrip tags should not exist in a JPEG image.  ExifTool sees these tags and tries to copy the strip data which results in an error since the data doesn't exist.  I must admit that I am surprised Photoshop copies these invalid tags without complaining when it rewrites the image.

Unfortunately the StripXxxx tags are not user-writable, so you can't use exiftool to just remove them.  The only option to fix the EXIF of this image is to rebuild it from scratch.  The following command will fix this image by generating a valid EXIF segment from the original mess that Hasselblad made, preserving all of the valid information from the original file and discarding the invalid tags:

exiftool -exif:all= -tagsfromfile @ -exif:all -thumbnailimage -unsafe hassel1.jpg

- Phil
...where DIR is the name of a directory/folder containing the images.  On Mac/Linux/PowerShell, use single quotes (') instead of double quotes (") around arguments containing a dollar sign ($).

pb

I observe the same error with jpeg files generated from tif by Picasa, I believe v. 3.8.0, under windows xp.  Apparently Picasa simply copies the strip fields from the tif into jpeg, and also propagates them from any jpeg files that contain them.

I note however that exiftool gui shows data values for the three strip fields in the jpeg files, contrary to what I understand you to say about the nonexistence of the data.  Attaching the jpeg fails, although it is only 4MB.  The tif is 18MB and came from some commercial lab's scanner apparently under Photoshop.

Thanks for the exiftool command to strip out the strip data.  It would also help if you could provide it for a whole directory, to save me, and presumably others, figuring out the right syntax.

(BTW, I'd report the bug to Picasa, but they have in recent times decided to make that impossible.)

pb

I probably should have mentioned that I was using exiftool gui v3.38, which invokes exiftool v8.56.

Quote from: pb on June 24, 2011, 07:19:17 PM
I observe the same error with jpeg files generated from tif by Picasa, I believe v. 3.8.0, under windows xp.  Apparently Picasa simply copies the strip fields from the tif into jpeg, and also propagates them from any jpeg files that contain them.

I note however that exiftool gui shows data values for the three strip fields in the jpeg files, contrary to what I understand you to say about the nonexistence of the data.  Attaching the jpeg fails, although it is only 4MB.  The tif is 18MB and came from some commercial lab's scanner apparently under Photoshop.

Thanks for the exiftool command to strip out the strip data.  It would also help if you could provide it for a whole directory, to save me, and presumably others, figuring out the right syntax.

(BTW, I'd report the bug to Picasa, but they have in recent times decided to make that impossible.)

Phil Harvey

Quote from: pb on June 24, 2011, 07:19:17 PM
I note however that exiftool gui shows data values for the three strip fields in the jpeg files, contrary to what I understand you to say about the nonexistence of the data.

I said the strip data doesn't exist, which it doesn't.  The StripOffsets etc tags are just information which tells you where to find the strip data block in the file.

QuoteThanks for the exiftool command to strip out the strip data.  It would also help if you could provide it for a whole directory, to save me, and presumably others, figuring out the right syntax.

See FAQ number 20, and use a directory name instead of a file name to process all images in a directory.

- Phil
...where DIR is the name of a directory/folder containing the images.  On Mac/Linux/PowerShell, use single quotes (') instead of double quotes (") around arguments containing a dollar sign ($).

pb

Thanks!   I wasn't sure whether you meant the strip field had no data, or that the strips themselves were not there.

BogdanH

Hi,

Quote from: pb on June 24, 2011, 07:22:54 PM
I probably should have mentioned that I was using exiftool gui v3.38, which invokes exiftool v8.56.

Just curious: is there some special reason why you aren't using latest GUI version (v4.13)?

Bogdan

pb

Quote from: BogdanH on June 25, 2011, 04:42:07 AM
Hi,

Quote from: pb on June 24, 2011, 07:22:54 PM
I probably should have mentioned that I was using exiftool gui v3.38, which invokes exiftool v8.56.

Just curious: is there some special reason why you aren't using latest GUI version (v4.13)?

Bogdan

No special reason;  just a failure to keep up with all the different programs I need to keep up to date.  I'll download it forthwith.

--peter

pb

Quote from: pb on June 25, 2011, 01:45:03 PM
Quote from: BogdanH on June 25, 2011, 04:42:07 AM
Hi,

Quote from: pb on June 24, 2011, 07:22:54 PM
I probably should have mentioned that I was using exiftool gui v3.38, which invokes exiftool v8.56.

Just curious: is there some special reason why you aren't using latest GUI version (v4.13)?

Bogdan


No special reason;  just a failure to keep up with all the different programs I need to keep up to date.  I'll download it forthwith.

--peter

Aha!  The reason is that the first thing that comes up in a google search for "exiftool gui" is your old site http://freeweb.siol.net/hrastni3/foto/exif/exiftoolgui.htm 

This apparently is frozen at v3.38.

Similarly, the next result is http://freeweb.siol.net/hrastni3/  which says development has stopped.

4.12 is only the 5th result, and I don't see one for 4.13 on the first page of results, though it shows up if I search for it explicitly with "4.13".

I believe there may be some way to notify Google that those first rankings should be deprecated.

--peter

camerond

Quote from: Phil Harvey on March 30, 2010, 06:42:50 PM

The StripOffsets, StripByteCounts and RowsPerStrip tags should not exist in a JPEG image. ...

exiftool -exif:all= -tagsfromfile @ -exif:all -thumbnailimage -unsafe hassel1.jpg

Thanks for the tip.

Warning - really old thread!

I have dragged up this old thread because I have just come across this problem, all from images scanned as tiffs and later converted to jpegs. It is not a bug in exiftool, but the issue is alive and unwell.

The current version of Picasa (3.9.141 b259) is still writing these bad headers, and I have also found older files with similar problems, where the exif:software tag proudly proclaimed it was last written by Paint.NET v3.5.2  or GIMP 2.6.8. I have not verified that they were the initial cause of the problem, nor whether these programs still do it, but it may be more common than you think.

In some cases the StripOffsets was removed, but less dangerous tags were retained, such as:

  • Rows Per Strip
  • Strip Byte Counts
  • Compression - (jpegs were labelled Uncompressed or LZW), contradicting the value in IFD1 which said JPEG (Old Style)
  • Bits Per Sample - exiftool removes it as unsafe, but at least the values were correct
Even Photoshop (CS2) leaves in a few unnecessary and contradictory values (such as "Compression") when it saves tiff to jpeg.

Because these badly formatted files can lie dormant for years, I scanned all my files with:

exiftool  -r  -Exif:StripOffsets -Exif:Compression -Exif:RowsPerStrip -Exif:StripByteCounts -Exif:Software -if '$EXIF:StripOffsets or $Exif:RowsPerStrip or $Exif:StripByteCounts ' -ext jpg -ext jpeg  DIR

and then fixed the ones listed using the command Phil suggested (above).

StarGeek

Quote from: camerond on November 18, 2015, 04:39:29 AM
Compression - (jpegs were labelled Uncompressed or LZW), contradicting the value in IFD1 which said JPEG (Old Style)

I believe that the IFD1 compression value is describing the thumbnail in the Exif block and doesn't refer to the image itself.  The Uncompressed and LZW values refer to the compression of the original Tiff file.  I think it's the same with the Bits Per Sample tag in the Exif block (not counting FILE:BitsPerSample).  I have that in my tiff files, but I don't think it's normally added to most jpgs unless they're converted from another format. 

This is basically the another side of the problem of what programs are to do when they encounter metadata that they don't understand.  Should it be copied or ignored?  In this case, your programs are copying the data rather than tossing it.  I'm curious as to what the standard should be, but my google searches are failing me. 
* Did you read FAQ #3 and use the command listed there?
* Please use the Code button for exiftool code/output.
 
* Please include your OS, Exiftool version, and type of file you're processing (MP4, JPG, etc).

Phil Harvey

According to the MWG:

3.1.1 Creator
A Creator application creates the first instances of metadata in a new (image) file. It is usually (though not necessarily) the same application that creates the image data, e.g. an image processing application, a digital camera or a cell phone. One common aspect of a Creator application is that there is no old metadata to preserve.
A Creator must meet these criteria:
- It MUST have full knowledge of all metadata it is creating.
- It MUST always create standard compliant metadata in at least one form, as specified in this document.

3.1.2 Changer
A Changer application first reads metadata from an image file and then writes new or modified metadata back to a file.
The rules for an application in the Changer role are:
- Deletion of metadata MUST only be done with specific intent.
- It SHOULD obey rules for Consumer applications when reading metadata.
- It SHOULD keep all forms of metadata it modifies in sync with one another.


The problem here is that Adobe products all consider themselves Creators even if there is old metadata to preserve.  It's sort of a loophole that allows them to do whatever the hell they want. :(

- Phil
...where DIR is the name of a directory/folder containing the images.  On Mac/Linux/PowerShell, use single quotes (') instead of double quotes (") around arguments containing a dollar sign ($).

viosca

I know this is a very old thread, however, the information here was very helpful in understanding a problem.
The batch conversion tool of irfanview is also copying incompatible tif tags to jpg files.