Under certain conditions the EXIF data in a JPEG file exported from Photolab (tested with 5.5.0) is invalid: the EXIF IFD1 (thumbnail) contains the StripOffsets tag, which is not allowed for JPEG format thumbnails according to the EXIF specification (moreover, the StripOffsets tag points beyond the end of the file).
This causes a crash e.g. in latest version of Gimp when opening the file, and can cause problems when viewing the file with any other software.
Steps to reproduce:
Export with Photolab an image into a TIFF file (tested starting with an ORF file and a CR3 file, so probably the format of the original does not matter).
(Optionally edit the TIFF file e.g. with Nik SilverFx, but I noticed that this is not necessary to reproduce the bug)
Then export the TIFF file into a JPEG with Photolab
The thumbnail in the TIFF is in uncompressed RGB format, which is fine. The thumbnail in the JPEG is JPEG-compressed, which would also be fine, but some of the tags that are specific only to uncompressed data are copied over from the thumbnail in the TIFF (such as the StripOffsets and related tags). This is not correct according to the EXIF specification, and also the StripOffsets points to beyond the end of the JPEG file.
Expected behaviour: there are no invalid tags in the EXIF:IFD1.
Exporting directly a JPEG from an ORF with Photolab produces a JPEG with valid EXIF, where the thumbnail is stored using JPEG compression, and the EXIF:IFD1 contains no extra tags. The current behavior makes it difficult to use Nik tools with Photolab, as TIFF files are needed between Photolab and Nik, and often final export is into JPEGs (that are now broken).
Please pass this on to the programmers, they’ll understand the technical description above. I’d expect that this should be fairly easy to fix.
@Harri please be specific some of us don’t use Gimp so which other software experiences the problem and are you using DxPL(Win) or DxPL(Mac), always very important to specify?
At the end of the process I have the following, the TIFF export from the image plus an exported JPG from the TIFF using PL6.0.1 on Win 10 and the same for the next image when processed by PL5.5.0!?
The screenshot is the result of exiftool -htmlDump, and shows the IFD1 part corresponding to the thumbnail.
The left one looks correct. On the right there are extra tags that are not valid here (looks like they have been copied over from the tiff, but they are no longer valid inside a jpeg). For instance, the StripOffset is way too large (larger than the size of the jpeg file). The actual thumbnail is in jpeg format in both cases, at offset 0x60d0 on the left and at offset 0x6166 on the right.
The StripOffset is clearly wrong, and anyway it should not be used at all with jpeg compressed thumbnail data according to the Exif specification.
What probably happens with Gimp is that it tries to read strip data at the given offset, but since that is beyond the end of the file it runs into an access violation. (I’ll be making a bug report to the Gimp project also, since earlier versions have been more robust.)
Let me know if there is any further information that would be helpful.
Comparing the two images:
the one on the left is with Photolab first ORF to TIFF, then TIFF to JPEG.
the one on the right is with Photolab ORF to JPEG
The left image has extra tags in the thumbnail section, that seem to have been copied from the TIFF file by mistake. These tags are not valid for this file any more, so in effect the JPEG file is invalid.
In your example, you should convert your TIFF to a JPEG, and then compare the two JPEGs with each other.
The above workflow happens naturally when using Nik tools with Photolab, so the problem is real.
I tested this now also with Photolab 6 (version 6.0.1 on windows 10), and it has the same problem: if the original is a tiff, and it is exported into a jpeg, those same tags as above (that are invalid for a jpeg) are written into the exif thumbnail directory of the jpeg.
