We are using TabLibSharp library to processing JPG images generated with Piexif. It complains that the format is bad.
using EXIFTOOL we have identified the issue is missing NextIFD pointers in the file.
We used EXIFTOOL -h -v image.jpg > image.html
It generates a very useful display of the bytes in the file.
IFD0 contains a number of fields and is followed by a NextIFD pointer. If there is no thumbnail, then this is null. But if a Thumbnail exists, then this is the offset for IFD1 ... this part is all ok.
Th ExifIFD block contains all of the EXIF fields but it should then have a NextIFD pointer. In JPG files from other apps, this is typically NULL. I have never seen a second EXIF block. But, Piexif is missing this pointer.
Some image processing apps ignore this but EXIFTOOL shows it - and it picks up the first 4 bytes from the following data element. This then causes problems for TagLibSharp when it tries to parse the next IFD block.
The same issue occurs with the GPSIFD and the InteroperabilityIFD.
The solution is the addition of 4 0x00 bytes at the end of these data blocks. This will be seen as the NextIFD pointer and indicate that there are no further records.
We are using TabLibSharp library to processing JPG images generated with Piexif. It complains that the format is bad. using EXIFTOOL we have identified the issue is missing NextIFD pointers in the file. We used EXIFTOOL -h -v image.jpg > image.html It generates a very useful display of the bytes in the file.
IFD0 contains a number of fields and is followed by a NextIFD pointer. If there is no thumbnail, then this is null. But if a Thumbnail exists, then this is the offset for IFD1 ... this part is all ok. Th ExifIFD block contains all of the EXIF fields but it should then have a NextIFD pointer. In JPG files from other apps, this is typically NULL. I have never seen a second EXIF block. But, Piexif is missing this pointer. Some image processing apps ignore this but EXIFTOOL shows it - and it picks up the first 4 bytes from the following data element. This then causes problems for TagLibSharp when it tries to parse the next IFD block. The same issue occurs with the GPSIFD and the InteroperabilityIFD.
The solution is the addition of 4 0x00 bytes at the end of these data blocks. This will be seen as the NextIFD pointer and indicate that there are no further records.