Return-Path: <tiff-bounces@lists.maptools.org>
Received: from inmx001.isp.belgacom.be (inmx001.isp.belgacom.be [195.238.5.1])
        by inas036.isp.belgacom.be (8.12.11/8.12.11/Skynet-IN-AS-2.03) with ESMTP id l3GBxOBo019014
        for <joris.at.lebbeke@skynet.be>; Mon, 16 Apr 2007 13:59:26 +0200
        (envelope-from <tiff-bounces@lists.maptools.org>)
Received: from mailgate103.isp.belgacom.be (mailgate103.isp.belgacom.be [195.238.6.84])
	by inmx001.isp.belgacom.be (Postfix) with ESMTP id 343185A804F
	for <joris.at.lebbeke@skynet.be>; Mon, 16 Apr 2007 13:59:25 +0200 (CEST)
Received: from r153.dmsolutions.ca (HELO duke.maptools.org) ([209.217.116.153])
  by in.mx.skynet.be with ESMTP; 16 Apr 2007 13:56:01 +0200
Received: from duke.maptools.org (duke.maptools.org [127.0.0.1])
	by duke.maptools.org (8.12.11/8.12.10) with ESMTP id l3GBjZoi032681;
	Mon, 16 Apr 2007 07:46:29 -0400
Received: from poczta.o2.pl (mx10.go2.pl [193.17.41.74])
	by duke.maptools.org (8.12.11/8.12.10) with ESMTP id l3GBjWvG032677
	for <tiff@lists.maptools.org>; Mon, 16 Apr 2007 07:45:33 -0400
Received: from poczta.o2.pl (mx10.go2.pl [127.0.0.1])
	by poczta.o2.pl (Postfix) with ESMTP id ED67C58022
	for <tiff@lists.maptools.org>; Mon, 16 Apr 2007 13:45:30 +0200 (CEST)
Received: from [192.168.40.31] (giy250.internetdsl.tpnet.pl [83.12.232.250])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by poczta.o2.pl (Postfix) with ESMTP
	for <tiff@lists.maptools.org>; Mon, 16 Apr 2007 13:45:30 +0200 (CEST)
Message-ID: <462361EE.5050003@go2.pl>
Date: Mon, 16 Apr 2007 13:45:50 +0200
From: mikk <mikk@go2.pl>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: tiff@lists.maptools.org
Content-Type: text/plain; charset=ISO-8859-2; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [Tiff] TIFFReadRGBAImage and palette images
X-BeenThere: tiff@lists.maptools.org
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: TIFF and libtiff discussion <tiff.lists.maptools.org>
List-Unsubscribe: <http://lists.maptools.org/mailman/listinfo/tiff>,
	<mailto:tiff-request@lists.maptools.org?subject=unsubscribe>
List-Archive: <http://lists.maptools.org/mailman/private/tiff>
List-Post: <mailto:tiff@lists.maptools.org>
List-Help: <mailto:tiff-request@lists.maptools.org?subject=help>
List-Subscribe: <http://lists.maptools.org/mailman/listinfo/tiff>,
	<mailto:tiff-request@lists.maptools.org?subject=subscribe>
Sender: tiff-bounces@lists.maptools.org
Errors-To: tiff-bounces@lists.maptools.org
X-UIDL: 000000000023ceae.000022f2
X-MSP-STORE: Mon, 16 Apr 2007 13:59:35 +0200
Status:   

Hello all,

I have a TIFF image with PhotometricInterpretation = Palette, 
BitsPerSample = 8, SamplesPerPixel = 1.
I load the image into a 32 bit pixel buffer with TIFFReadRGBAImage. 
Before loading the image I built an inverse color lookup table from 
palette, where the table keys are 32 bit color values built from R, G, B 
components translated to 8 bit, and the table values are palette 
indices. I use the formula of v8Bit = ((v16Bit) * 255) / ((1L<<16)-1).

After editing without changing color space I want to save the image from 
the pixel buffer. I'm trying to avoid looking for nearest palette index 
by minimal Euclidian distance for performance reasons (and there is no 
need, because colors have not changed). So, I iterate through the 32 bit 
pixel buffer, read the color value and look for the palette index in the 
inverse lookup table to save it in a strip buffer. Unfortunately, 
looking up for palette index based on key from pixel color components 
doesn't return valid palette index. It seems that I use different 
conversion from 16 bit palette to build lookup key value than the 
TIFFReadRGBAImage uses to represent pixels.

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))

What should I think about it?

Kind regards,
mikk
_______________________________________________
Tiff mailing list: Tiff@lists.maptools.org
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/
