AWARE SYSTEMS
TIFF and LibTiff Mail List Archive

Thread

2007.10.22 17:40 "[Tiff] bad version number 10752", by Kai-Uwe Behrmann
2007.10.22 18:31 "Re: [Tiff] bad version number 10752", by Bob Friesenhahn
2007.10.22 18:50 "Re: [Tiff] bad version number 10752", by Kai-Uwe Behrmann
2007.10.22 18:57 "Re: [Tiff] bad version number 10752", by Bob Friesenhahn
2007.10.23 15:05 "Re: [Tiff] bad version number 10752", by Kai-Uwe Behrmann
2007.10.23 15:45 "Re: [Tiff] bad version number 10752", by Bob Friesenhahn
2007.10.22 20:07 "Re: [Tiff] bad version number 10752", by Toby Thain
2007.10.23 02:33 "Re: [Tiff] bad version number 10752", by Graeme Gill
2007.10.23 06:28 "Re: [Tiff] bad version number 10752", by Kai-Uwe Behrmann
2007.10.23 07:41 "Re: [Tiff] bad version number 10752", by Graeme Gill
2007.10.23 08:10 "Re: [Tiff] bad version number 10752", by John

2007.10.23 08:10 "Re: [Tiff] bad version number 10752", by John

On 10/23/07, Graeme Gill <graeme2@argyllcms.com> wrote:

Reads elegant. What would you suggest?

If you're not familiar with the approach, take a look at the source code in icclib.

It's not as "efficient" as some other approaches, but in this age of super fast core CPU speed, and relatively slow memory sytems, the lack of efficiency is moot. It also avoids issues with misaligned words etc., which trouble some architectures.

I do a mix in my library: I do endian-independent read for the header, then for the data I test endianness at runtime and insert a swap operation if file endianness does not match CPU endianness.

I suppose it depends on the mix of parsing file structure vs. reading large amounts of data. If you're parsing, I agree that reading a byte at a time is fine. If you need to get a large volume of data out of a file, then I think you need something lower level.

John