Canon Makernotes and byte ordering
Posted: Wed Nov 07, 2012 6:57 am
Hi,
I have a situation where makernotes are not being displayed by XnView in images I manipulate with exiftool - I saw it first in v1.99.4, and it is the same in v1.99.5.
background:
For panoramas, I shoot raw (Canon EOS), convert to 16-bit tiff, run through Hugin, Photoshop and then finally save as jpeg.
Just for completion, I like to have fixed data, such as lens, exposure conditions, ISO stored in the exif data for the final image.
I use the following command in exiftool to copy over the information I want:
Now, this seems to work fine if I use exiftool to view the resulting metadata but XnView just shows an empty block of makernotes.
The problem stems from the fact that Photoshop (I use the CS1 version) always swaps to big-endian byte ordering for jpegs.
Using exiftools htmldump I can see that the various IFD blocks are big-endian, including the ExifIFD, but the makernotes block remains little-endian.
Phil Harvey has made some comments about it in the exiftool forums: where he says exiftool has to rely on some heuristics to determine byte ordering of the makernotes block.
Workaround: I simply use XnView to convert from the final tiff to jpeg. So long as I use a little-endian jpeg there is no problem with XnView understanding the makernotes transfer.
Other info:
Canon's own DPP program can read the makernotes in the jpegs with mixed byte ordering, so perhaps that is a hint that it expects makernotes to always be little endian. Either that, or else they did not even think about it.
JpegSnoop also cannot understand the mixed byte ordering. PhotoME does understand it.
It seems Photoshop-CS5 has changed to using little-endian with save-as jpeg - at least under ms-windows - but I can't afford to keep upgrading
. And it still strips out makernotes. Hugin also stripped out the makernotes and lens/exposure info from the resulting tiff file.
I have a situation where makernotes are not being displayed by XnView in images I manipulate with exiftool - I saw it first in v1.99.4, and it is the same in v1.99.5.
background:
For panoramas, I shoot raw (Canon EOS), convert to 16-bit tiff, run through Hugin, Photoshop and then finally save as jpeg.
Just for completion, I like to have fixed data, such as lens, exposure conditions, ISO stored in the exif data for the final image.
I use the following command in exiftool to copy over the information I want:
Code: Select all
exiftool -tagsFromFile <input> -MakerNotes -make -model -Exif:GPS -Exif:ExposureTime -Exif:FNumber ...etc... -Exif:WhiteBalance <output>
The problem stems from the fact that Photoshop (I use the CS1 version) always swaps to big-endian byte ordering for jpegs.
Using exiftools htmldump I can see that the various IFD blocks are big-endian, including the ExifIFD, but the makernotes block remains little-endian.
Phil Harvey has made some comments about it in the exiftool forums: where he says exiftool has to rely on some heuristics to determine byte ordering of the makernotes block.
Workaround: I simply use XnView to convert from the final tiff to jpeg. So long as I use a little-endian jpeg there is no problem with XnView understanding the makernotes transfer.
Other info:
Canon's own DPP program can read the makernotes in the jpegs with mixed byte ordering, so perhaps that is a hint that it expects makernotes to always be little endian. Either that, or else they did not even think about it.
JpegSnoop also cannot understand the mixed byte ordering. PhotoME does understand it.
It seems Photoshop-CS5 has changed to using little-endian with save-as jpeg - at least under ms-windows - but I can't afford to keep upgrading
