LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
July 2009
Previous Thread
Next Thread
Previous by Thread
Next by Thread
Previous by Date
Next by Date
Contact
The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems
Thread
2009.07.09 14:37 "Re: TIFFTAG_RICHTIFFIPTC definition", by Joris Van Damme
Ian, > Please can someone tell me why the TIFFTAG_RICHTIFFIPTC tag is defined as > using type TIFF_LONG? The information is actually an array of bytes not > longs so swapping the bytes if the byte order of the computer and file > differ corrupts the data. You're right. This is a historical mistake, and it leads to trouble. My humble advice when it comes to writing is using the datatype TIFF_BYTE or TIFF_UNDEFINED. The latter is probably the most 'correct' as it literaly signifies that the data is of mixed type and byte order and widths of data members is defined outside the scope of TIFF. The datatype TIFF_BYTE can be used as amounting to the same thing, though, mostly. Some will recommend against this because that might lead to incompatibility with older software. However, I feel writing longs and the subsequent byte order confusion with several combinations of writer machine byte order, file byte order, and reader machine byte order leads to incompatibilities with stupid IPTC-is-LONG interpreters also, and moreover writing longs is just plain incorrect. I feel propagating the problem into the future indefinetly, like Adobe does, is in nobody's best interest in the long run. My humble advice when it comes to reading, is reading the tag normally and troublefree when it has the datatype TIFF_BYTE or TIFF_UNDEFINED. If however it has the datatype TIFF_LONG, then read it with whatever byteswapping or not byteswapping that is the most convinient (probably the normal byteswapping selection depending on whether file byte order and machine byte order differ). If the result can be interpreted as IPTC data, then the problem is solved. If it doesn't make sense, byteswap the data (again?), and try interpreting it as IPTC data again. That'll robustly work in every situation. Best regards, Joris