Received: from gate7.olympiakos.com ([207.176.88.85]) by shared1-mail.whowhere.com; Fri Mar 30 20:34:57 2001
Received: from localhost (daemon@localhost)
	by gate7.olympiakos.com (8.9.3/8.9.3) with SMTP id WAA05067;
	Fri, 30 Mar 2001 22:52:44 -0500
Received: by gate7.olympiakos.com (bulk_mailer v1.9); Fri, 30 Mar 2001 22:52:11 -0500
Received: (from majordom@localhost)
	by gate7.olympiakos.com (8.9.3/8.9.3) id WAA05019
	for tiff-outgoing; Fri, 30 Mar 2001 22:52:11 -0500
X-Authentication-Warning: gate7.olympiakos.com: majordom set sender to owner-tiff@olympiakos.com using -f
Received: from mailout00.sul.t-online.com (mailout00.sul.t-online.com [194.25.134.16])
	by gate7.olympiakos.com (8.9.3/8.9.3) with ESMTP id WAA05016
	for <tiff@olympiakos.com>; Fri, 30 Mar 2001 22:52:09 -0500
Received: from fwd02.sul.t-online.com 
	by mailout00.sul.t-online.com with smtp 
	id 14ig9D-0005UA-04; Thu, 29 Mar 2001 19:23:47 +0200
Received: from pD90164BF.dip.t-dialin.net (027122869-0001@[217.1.100.191]) by fwd02.sul.t-online.com
	with smtp id 14ig91-08NRNwC; Thu, 29 Mar 2001 19:23:35 +0200
Date: 29 Mar 2001 19:23:47 +0100
From: Andreas_Kleinert@t-online.de (Andreas R. Kleinert)
Subject: Re: Bit depth
To: "Martí Maria" <marti@littlecms.com>
In-Reply-To: <005701c0b845$a25d4690$02001aac@MM2000>
Message-ID: <1830.488T2352T11634426info@ar-kleinert.de>
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Cc: tiff@olympiakos.com
X-Mailer: THOR 2.6a (Amiga;TCP/IP)
X-Sender: 027122869-0001@t-dialin.net
Sender: owner-tiff@olympiakos.com
Status: RO
Content-Length: 1805
Lines: 51

>Max value of 11 bits: 2047 = 0x7FF, if you apply a
>left shif of 5 you got 65504=0xFFe0, while you should
>obtain maximum 16 bit value: 0xFFFF

>This is a frequent mistake when converting from 8 to 16 bits,
>many implementations I've seen does simply shift left 8, while
>they should multiply by 257

 One also could do:

    in8   = 2047;
    out16 = (in8 << 5) | (in8 >> 6);

 This is equal to  2047*32 + 2047/64 and gives 65535 as well.

 Is not just useful in this particular case, but also,
 when e.g. converting 4 bit per gun colors into 8 bit per gun
 colors (for example in 12 bit truecolor TIFFs or in old 4 bit
 colormapped palettes). In this case it would be:

    in8  = 0x0F;         // 4:8 bits, max. 15
    out8 = in8<<4 | in8;

 Thus, in the 12 bit per sample case, I would do the following:

    in_red8   = upper4bit(  in12 );
    in_green8 = middle4bit( in12 );
    in_blue8  = lower4bit(  in12 );

    out_red8   = in_red8  << 4 | in_red8;
    out_green8 = in_green8<< 4 | in_green8;
    out_blue8  = in_blue8 << 4 | in_blue8;

 ...which gives a linear upscaling of the color components
 of the original 12 bit "truecolor" image.

 After that, apply downscaling to 16 bit, if really necessary.
 Or merge both into one step, if unavoidable :)

 If I'm not mistaken, 12 bit TIFFs are really valid (don't
 remember, whether they did contain triplets of byte nibbles
 or 16 bit values with only 12 bits used).

 But why not just convert the 10/12 bit values and store
 them as real 16/24 bit ones. Most readers won't be able
 to handle anything except 1,4,8,15/16,24.

--
Andreas_Kleinert@t-online.de  | http://www.ar-kleinert.de             |
Freelance Consultant & Writer | Software Engineering                  |
 *** PerSuaSiVe SoftWorX ***  | x86 Win/Linux, 68k/PPC Amiga and more |

