LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
April 2007
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
2007.04.17 08:36 "Re: TIFFReadRGBAImage and palette images", by Joris Van Damme
mikk,
mikk wrote:
> After short investigation I found that "translation" of the 16 bit
> palette is done in tif_getimage.c.
> What transformation from 16-bit palette entries to 8-bit palette
> entries is done when TIFFReadRGBAImage is called?
> In tif_getimage.c (libtiff 3.8.2) I can see:
>
> static void
> cvtcmap(TIFFRGBAImage* img)
> {
> uint16* r = img->redcmap;
> uint16* g = img->greencmap;
> uint16* b = img->bluecmap;
> long i;
>
> for (i = (1L<<img->bitspersample)-1; i >= 0; i--) {
> #define CVT(x) ((uint16)((x)>>8)) // <---------- !!! LOOK
> HERE !!! r[i] = CVT(r[i]);
> g[i] = CVT(g[i]);
> b[i] = CVT(b[i]);
> #undef CVT
> }
> }
>
> Does it mean that plain bit shifting for values of color components in
> palette is done when TIFFReadRGBAImage is called? Is this done
> intentionally? I've seen some discussions in this mailing list with
> conclusions that it shouldn't be done by bit shifting because of error
> distribution. For example, in pal2rgb tool the conversion macro used
> to translate palette from 16 bit to 8 bit is defined as mine and is:
> #define CVT(x) (((x) * 255) / ((1L<<16)-1))
If I remember correctly, I've recently replaced some of the 16->8 bit
converting in tif_getimage.c. It used to be bitshifting, but I changed it to
be mathematically correct, and still be fast because the new version is
based on a LUT.
I'm not sure I remember correctly, and it certainly seems from your comments
I didn't change bitdepth conversion of palette entries. Perhaps a
library-wide search will get you the LUT (that isn't directly declared in
tif_getimage.c itself, I think), knowing myself it probably has 16To8 and
likely also 'Lut' in its name. From there, you can likely trace its usage,
and that should likely enable you to use that same LUT in this instance
(unless the LUT is calculated when needed only, in that case it's probably
better to calculate the palette without LUT dependence as that may be a
shorter calculation).
Please let us know what you find.
Best regards,
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