| 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.05.26 16:23 "Re: Jpeg and YCbCr", by Joris Van DammeJean-Yves, > Yes, but do this conform to TIFF specifications ? My head is turned in a completely different direction right now. If I should think about this too much, it might explode... But do remember that the TIFF specification intends to say barely little about what you cannot do. It mostly provides examples of what you can do, and thus it sets a spirit and line of action, and the community tends to accept all logical extensions as legit TIFF. Bob's 3 bits per pixel palette images are a perfect example. Nowhere in the spec mentioned this is. But it is a logical extension of what is mentioned, and it is completely unambigious. > The problem is with tif's PHOTOMETRIC_CIELAB continous tones *signed* > representation which are, for now, without special case, > traited as unsigned value by jpeg compressor/decompressor. > A slight "2 or 3" difference around "128" unsigned values, > can cause at the end, a differences like +/- 125 in signed vals. OK, exploding now my head does. You are aware of course that there are two possible encoding of CIE L*a*b*? (Three, if you count ITULAB.) Does your remark apply to all of these? I really couldn't say without looking it up... Besides, we're spinning, this discussion of L*a*b* in JPEG-in-TIFF actually started with a discussion of JPEG compression of palettes... > > Would you consider posting more uniformly? > > Is it ok like this ? It's mighty fine. Thanks! 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 |
|||||||