| 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 |
Thread2005.04.11 21:04 "Re: TIFF Technote 3, draft 1", by Chris CoxAt 10:34 AM +0200 4/11/05, Joris wrote: > > I've just posted draft 1 of TIFF Technote 3 at > > http://chriscox.org/TIFFTN3d1.pdf > > This technote covers improvements for floating point image data > > support available in Photoshop CS2. > > > > Let me know if you see any errors, and if I need to provide more > > details anywhere. > > <quote> > This means that the predictor reorders the bytes into a semi-BigEndian order, > and that the TIFF reader and writer should not change the byte order of the > image data outside of the predictor. > </quote> > > I think I know what you mean, but it's mighty confusing. Wouldn't it serve your > intention better to use the word 'bit-order' in relation to the throwing around > bits scheme that serves the predictor, rather then the word 'byte-order'? No, because it really is moving the bytes. The bit order remains constant. > Also, possibly I'm being stupid, but I'm unsure about how the regular > Intel/Motorola byte-order issue applies to the 16bit float format. Does swapping > apply in such a case, i.e. is the image data differently swapped in Intel and > Motorola byte order files? Perhaps a note about that could be a useful addition, > if I'm not being plain stupid. Without the predictor, you do have to byte swap the image data for floating point data that has BitsPerSample equal to a multiple of 8. Yeah, that should be obvious. With this predictor, you don't need to do that extra step, because the predictor does byte reordering as part of the prediction process. (which complicates the TIFF pipeline a little, but does help compression quite a bit). Chris |
|||||||