| AWARE [SYSTEMS] | Imaging expertise for the Delphi developer | |||||||
![]() |
TIFF and LibTiff Mailing List Archive | |||||||
LibTiff Mailing List
TIFF and LibTiff Mailing List Archive Contact
The TIFF Mailing List Homepage |
Thread2004.09.17 14:53 "Re: BigTIFF Tag Value Count issue", by Joris Van Damme> > If I'm not mistaking, on most processors there is a gain from aligning of > > data, whilst things still work if data is not aligned. Thus, it pays to > > build... > > With some processors (particularly RISC type processors), attempting > to read unaligned data results in a program crash. Probably Intel x86 > is not one of those processors. IIRC, there's a processor flag that can be set on Intel Pentium familly that mimicks that behaviour, but I may be misremembering. But I wish you would draw conclusions, as, to me, you seem to be stepping on your own point. If misaligned data can cause such disasters, and you're memory mapping the file, you'll have to design your code to check correct alignment anyway, and be prepared to copy the structures if needed to properly aligned locations, since we can't trust everyone to align the IFD structure as we lay it out in the BigTIFF spec. If all this code logic has to be built anyway, does this not make designing aligment in the spec less important, and is this not another argument pro regular IO instead of memory mapping for this kind of codec application? So I remain with my original point of view - memory mapping is not really good design, but let's be friendly to memory mappers if there's no cost to us - alignment inside a file is not really an important issue, but let's do it anyway if there's no substantial cost to us Joris Van Damme info@awaresystems.be http://www.awaresystems.be Download your free TIFF tag viewer for windows here: http://www.awaresystems.be/imaging/tiff/astifftagviewer.html |
|||||||