Return-Path: <awaresystems.be+caf_=filtered=awaresystems.be@gmail.com>
Delivered-To: filtered@awaresystems.be
Received: from mx-s.one.com (mx-s.one.com [91.198.169.250])
	by mail6.local (Postfix) with ESMTP id A1DC48014F8C6
	for <filtered@awaresystems.be>; Wed, 17 Apr 2013 20:33:05 +0200 (CEST)
X-Virus-Scanned: by one.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
Received-SPF: pass (mx-s: domain of awaresystems.be+caf_=filtered=awaresystems.be@gmail.com designates 209.85.215.45 as permitted sender)
X-Greylist: whitelisted by SQLgrey-1.8.0-rc2
Received: from mail-la0-f45.google.com (mail-la0-f45.google.com [209.85.215.45])
	by mx-s.one.com (Postfix) with ESMTP id 4DE29DCA081
	for <filtered@awaresystems.be>; Wed, 17 Apr 2013 18:33:05 +0000 (UTC)
Received: by mail-la0-f45.google.com with SMTP id gw10so1803996lab.18
        for <filtered@awaresystems.be>; Wed, 17 Apr 2013 11:33:04 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20120113;
        h=x-received:x-forwarded-to:x-forwarded-for:delivered-to:x-received
         :domainkey-status:received-spf:x-gmail-fetch-info:delivered-to
         :x-virus-scanned:x-amavis-alert:x-greylist:from:to:date:thread-topic
         :thread-index:message-id:in-reply-to:accept-language
         :content-language:x-ms-has-attach:x-ms-tnef-correlator:user-agent
         :acceptlanguage:mime-version:cc:subject:x-beenthere
         :x-mailman-version:precedence:list-id:list-unsubscribe:list-archive
         :list-post:list-help:list-subscribe:content-type:mime-version:sender
         :errors-to;
        bh=E0FFABt0u1WzkO8bJOgStpPSxckXM9Sn9A4JM0KQcZ8=;
        b=Y6gU3RJpK0MEcfoQPQkArehJONXPDuDF0+6hrIRuSkTC53OmpEBere8M7n1FONMGqb
         QKgLBYaOUJpsU6+b9VlNtkZBUx64YqEI7704saadXqlN6u63D3dyfhzS/wZnaZAgovx3
         EpHsake821+nPH7IULZqMKDwbkyuCrKLD/4ak8RTtwx+qoZcSycVYi32+U5CIHrSVEM8
         IEE4iDPmQcjnqg8bMBYeUHlammnwGdCnc6DzBGmOx616LEpB3JdFFHpZzmj7qFyJliWh
         969tE29TwbF9hJce5QC7gHN0rxVY2ZYyTMYQL1MT7lu4TD5W+VMbVhLC5jBa0I8fs/Mz
         UD0g==
X-Received: by 10.152.111.67 with SMTP id ig3mr4095743lab.41.1366223584773;
        Wed, 17 Apr 2013 11:33:04 -0700 (PDT)
X-Forwarded-To: filtered@awaresystems.be
X-Forwarded-For: awaresystems.be@gmail.com filtered@awaresystems.be
Delivered-To: awaresystems.be@gmail.com
Received: by 10.114.11.131 with SMTP id q3csp106292ldb;
        Wed, 17 Apr 2013 11:33:04 -0700 (PDT)
X-Received: by 10.152.111.67 with SMTP id ig3mr4095690lab.41.1366223583059;
        Wed, 17 Apr 2013 11:33:03 -0700 (PDT)
DomainKey-Status: bad format
Received-SPF: neutral (google.com: 91.198.169.250 is neither permitted nor denied by best guess record for domain of tiff-bounces@lists.maptools.org) client-ip=91.198.169.250;
Received: by 10.152.102.173 with POP3 id fp13mf1372619lab.37;
        Wed, 17 Apr 2013 11:33:02 -0700 (PDT)
X-Gmail-Fetch-Info: info@awaresystems.be 1 pop.awaresystems.be 110 info@awaresystems.be
Delivered-To: info@awaresystems.be
Received: from mx-s.one.com (mx-s.one.com [91.198.169.250])
	by mail6.local (Postfix) with ESMTP id E77FC8014F8C6
	for <info@awaresystems.be>; Wed, 17 Apr 2013 20:27:22 +0200 (CEST)
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0-rc2
Received: from lists.maptools.org (ks365428.kimsufi.com [94.23.4.142])
	by mx-s.one.com (Postfix) with ESMTP id ACC48DC2EDE
	for <info@awaresystems.be>; Wed, 17 Apr 2013 18:27:21 +0000 (UTC)
Received: from [10.1.0.241] (localhost.localdomain [127.0.0.1])
	by lists.maptools.org (Postfix) with ESMTP id 4852135C03F;
	Wed, 17 Apr 2013 13:25:49 -0500 (EST)
Received: from exprod6og124.obsmtp.com (exprod6og124.obsmtp.com [64.18.1.242])
	by lists.maptools.org (Postfix) with ESMTPS id BA65835C039
	for <tiff@lists.maptools.org>; Wed, 17 Apr 2013 13:19:12 -0500 (EST)
Received: from outbound-smtp-1.corp.adobe.com ([192.150.11.134]) by
	exprod6ob124.postini.com ([64.18.5.12]) with SMTP
	ID DSNKUW7nnVizbYC+emK6UsIYurK5l52+AhKh@postini.com;
	Wed, 17 Apr 2013 11:19:15 PDT
Received: from inner-relay-4.eur.adobe.com (inner-relay-4.adobe.com
	[193.104.215.14])
	by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id
	r3HIFv1v023027; Wed, 17 Apr 2013 11:15:58 -0700 (PDT)
Received: from nacas03.corp.adobe.com (nacas03.corp.adobe.com [10.8.189.121])
	by inner-relay-4.eur.adobe.com (8.12.10/8.12.9) with ESMTP id
	r3HIFAHC001937; Wed, 17 Apr 2013 11:19:04 -0700 (PDT)
Received: from nambx03.corp.adobe.com ([10.8.189.93]) by
	nacas03.corp.adobe.com ([10.8.189.121]) with mapi;
	Wed, 17 Apr 2013 11:18:16 -0700
From: Chris Cox <ccox@adobe.com>
To: =?iso-8859-1?Q?R=E9my_Abergel?= <remy.abergel@parisdescartes.fr>
Date: Wed, 17 Apr 2013 11:18:10 -0700
Thread-Topic: [Tiff] How 16bits-RGBA image pixels are interlaced ?
Thread-Index: Ac47erLa1kLQ1/SVQr2BAY57lnt3NAAHTeZP
Message-ID: <CD943572.5D4D4%ccox@adobe.com>
In-Reply-To: <516EB653.8050603@parisdescartes.fr>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-Entourage/13.16.0.130206
acceptlanguage: en-US
MIME-Version: 1.0
Cc: TIFF <tiff@lists.maptools.org>
Subject: Re: [Tiff] How 16bits-RGBA image pixels are interlaced ?
X-BeenThere: tiff@lists.maptools.org
X-Mailman-Version: 2.1.9
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>
Content-Type: multipart/mixed; boundary="===============0982385162=="
Mime-version: 1.0
Sender: tiff-bounces@lists.maptools.org
Errors-To: tiff-bounces@lists.maptools.org

--===============0982385162==
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_CD9435725D4D4ccoxadobecom_"

--_000_CD9435725D4D4ccoxadobecom_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Yes, using the strip and tile methods is preferable, but means that you wil=
l have to manage some of the strip and tile logic outside those calls (whic=
h should be easy if you are familiar with file formats or image processing)=
.

Chris



On 4/17/13 7:48 AM, "R=E9my Abergel" <remy.abergel@parisdescartes.fr> wrote=
:

  Hello Chris,

 Thank you for your answer, indeed I made a confusion between libtiff and t=
he TIFF format itself.
I have been reading more about TIFF format and I understand now your commen=
t.

 Until now I have been working with libtiff (http://www.remotesensing.org/l=
ibtiff/libtiff.html), I don't want to use higher level API because I don't =
want to introduce dependancies in my code.
 It seems that to be able to read all kind of TIFF would be to use TIFFRead=
EncodedStrip and TIFFReadEncodedTile functions because TIFFReadRGBAImage is=
 limited to images having 8-bits per sample.

 Does it seems correct to you?

 Thank you again for your comments,
 Regards,

 R=E9my.



Le 16/04/2013 19:41, Chris Cox a =E9crit :


Re: [Tiff] How 16bits-RGBA image pixels are interlaced ? TIFF supports inte=
rleaved and planar storage of pixel values.
 What you are describing is just one high level API for accessing the value=
s in the TIFF file.

 Extracting the values from a uint32 would be byte order dependent (varies =
between CPUs).

 The TIFF specification does spell out how 16 bit/channel values are stored=
 in the file format.
 But how they are retrieved from LibTIFF depends on which API you are using=
.

 Chris



 On 4/16/13 2:55 AM, "R=E9my Abergel" <remy.abergel@parisdescartes.fr> wrot=
e:


  Hello,

  I'm trying to deal with 16-bits per channel RGBA TIFF images through C la=
nguage, I could not find a lot of information about 16-bits images in the s=
pecifications.

  In case of a 8-bits per channel RGBA image, I understand that a pixel is =
stored as a uint32, and can be deinterlaced by grouping the 32 bits into 4 =
groups (R,G,B,A) of 8 bits.
  Then to deal with 8-bits per channel RGBA images, I'm doing the following=
 (see also enclosed source code):

  1. I store the image data as a uint32 tab (using TIFFReadRGBAImageOriente=
d) that I call data_tiff
  2. I deinterlace pixels using the following commands: (uint8) TIFFGetR(*d=
ata_tiff), (uint8) TIFFGetG(*data_tiff), (uint8) TIFFGetB(*data_tiff) & (ui=
nt8) TIFFGetA(*data_tiff)

  In case of a 16 bits per channel RGBA image, could you tell me how can I =
deinterlace pixels?
  if I could retreive image data as a uint64 tab, then I could do the follo=
wing:

  #define    TIFF16GetR(abgr)    ((abgr) & 0xffff)
  #define    TIFF16GetG(abgr)    (((abgr) >> 16) & 0xffff)
  #define    TIFF16GetB(abgr)    (((abgr) >> 32) & 0xffff)
  #define    TIFF16GetA(abgr)    (((abgr) >> 48) & 0xffff)

  1. I read the image data as a uint64 tab
  2. I deinterlace pixels using (uint16) TIFF16GetR(*data_tiff), (uint16) T=
IFF16GetG(*data_tiff), (uint16) TIFF16GetB(*data_tiff) & (uint16) TIFF16Get=
A(*data_tiff)

  but it seems that data are not natively stored in a uint64 tab, so I wond=
er how are interlaced 16-bits per channel images into a uint32 pixel tab.

  I'm also facing difficulties dealing with 16-bits grayscaled images in th=
e same way (using TIFFReadRGBAImageOriented to get image data and trying to=
 convert each pixel into a uint16)

  More generally, do you have any piece of documentation about 16 bits gray=
scale and color images?

  Thank you,
  Best Regards,

  R=E9my A.









--_000_CD9435725D4D4ccoxadobecom_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: [Tiff] How 16bits-RGBA image pixels are interlaced ?</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Myriad Pro"><SPAN STYLE=3D'font-size:10pt'><BR>
Yes, using the strip and tile methods is preferable, but means that you wil=
l have to manage some of the strip and tile logic outside those calls (whic=
h should be easy if you are familiar with file formats or image processing)=
.<BR>
<BR>
Chris<BR>
<BR>
<BR>
<BR>
On 4/17/13 7:48 AM, &quot;R&eacute;my Abergel&quot; &lt;<a href=3D"remy.abe=
rgel@parisdescartes.fr">remy.abergel@parisdescartes.fr</a>&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Myriad Pro"><SPAN STYLE=3D'font-siz=
e:10pt'> &nbsp;&nbsp;</SPAN></FONT><SPAN STYLE=3D'font-size:10pt'><FONT FAC=
E=3D"Monaco, Courier New">Hello Chris, <BR>
&nbsp;<BR>
&nbsp;Thank you for your answer, indeed I made a confusion between libtiff =
and the TIFF format itself.<BR>
</FONT><FONT FACE=3D"Myriad Pro"> </FONT><FONT FACE=3D"Monaco, Courier New"=
>I have been reading more about TIFF format and I understand now your comme=
nt. <BR>
&nbsp;<BR>
&nbsp;Until now I have been working with libtiff (<a href=3D"http://www.rem=
otesensing.org/libtiff/libtiff.html">http://www.remotesensing.org/libtiff/l=
ibtiff.html</a>), I don't want to use higher level API because I don't want=
 to introduce dependancies in my code. <BR>
&nbsp;It seems that to be able to read <B>all kind</B> of TIFF would be to =
use <FONT COLOR=3D"#FF0000">TIFFReadEncodedStrip</FONT> and <FONT COLOR=3D"=
#FF0000">TIFFReadEncodedTile</FONT> functions because <FONT COLOR=3D"#FF000=
0">TIFFReadRGBAImage</FONT> is limited to images having 8-bits per sample. =
<BR>
&nbsp;<BR>
&nbsp;Does it seems correct to you?<BR>
&nbsp;<BR>
&nbsp;Thank you again for your comments, <BR>
&nbsp;Regards, <BR>
&nbsp;<BR>
&nbsp;R&eacute;my. <BR>
&nbsp;<BR>
&nbsp;<BR>
&nbsp;</FONT><FONT FACE=3D"Myriad Pro"> <BR>
Le 16/04/2013 19:41, Chris Cox a &eacute;crit :<BR>
&nbsp;<BR>
&nbsp;<BR>
</FONT></SPAN><BLOCKQUOTE><SPAN STYLE=3D'font-size:10pt'><FONT FACE=3D"Myri=
ad Pro"> Re: [Tiff] How 16bits-RGBA image pixels are interlaced ? TIFF supp=
orts interleaved and planar storage of pixel values.<BR>
&nbsp;What you are describing is just one high level API for accessing the =
values in the TIFF file.<BR>
&nbsp;<BR>
&nbsp;Extracting the values from a uint32 would be byte order dependent (va=
ries between CPUs).<BR>
&nbsp;<BR>
&nbsp;The TIFF specification does spell out how 16 bit/channel values are s=
tored in the file format.<BR>
&nbsp;But how they are retrieved from LibTIFF depends on which API you are =
using.<BR>
&nbsp;<BR>
&nbsp;Chris<BR>
&nbsp;<BR>
&nbsp;<BR>
&nbsp;<BR>
&nbsp;On 4/16/13 2:55 AM, &quot;R&eacute;my Abergel&quot; &lt;<a href=3D"re=
my.abergel@parisdescartes.fr">remy.abergel@parisdescartes.fr</a>&gt; wrote:=
<BR>
&nbsp;<BR>
&nbsp;&nbsp;<BR>
</FONT></SPAN><BLOCKQUOTE><SPAN STYLE=3D'font-size:10pt'><FONT FACE=3D"Myri=
ad Pro"> &nbsp;&nbsp;</FONT><FONT FACE=3D"Monaco, Courier New">Hello, <BR>
&nbsp;&nbsp;<BR>
&nbsp;&nbsp;I'm trying to deal with 16-bits per channel RGBA TIFF images th=
rough C language, I could not find a lot of information about 16-bits image=
s in the specifications. <BR>
&nbsp;&nbsp;<BR>
&nbsp;&nbsp;In case of a 8-bits per channel RGBA image, I understand that a=
 pixel is stored as a uint32, and can be deinterlaced by grouping the 32 bi=
ts into 4 groups (R,G,B,A) of 8 bits. <BR>
&nbsp;&nbsp;Then to deal with 8-bits per channel RGBA images, I'm doing the=
 following (see also enclosed source code): <BR>
&nbsp;&nbsp;<BR>
&nbsp;&nbsp;1. I store the image data as a uint32 tab (using TIFFReadRGBAIm=
ageOriented) that I call data_tiff <BR>
&nbsp;&nbsp;2. I deinterlace pixels using the following commands: (uint8) T=
IFFGetR(*data_tiff), (uint8) TIFFGetG(*data_tiff), (uint8) TIFFGetB(*data_t=
iff) &amp; (uint8) TIFFGetA(*data_tiff)<BR>
&nbsp;&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;<B>In case of a 16 bits per channel RGBA image, could you tell =
me how can I deinterlace pixels? <BR>
&nbsp;</B> if I could retreive image data as a uint64 tab, then I could do =
the following: <BR>
&nbsp;&nbsp;<BR>
&nbsp;&nbsp;#define &nbsp;&nbsp;&nbsp;TIFF16GetR(abgr) &nbsp;&nbsp;&nbsp;((=
abgr) &amp; 0xffff)<BR>
&nbsp;&nbsp;#define &nbsp;&nbsp;&nbsp;TIFF16GetG(abgr) &nbsp;&nbsp;&nbsp;((=
(abgr) &gt;&gt; 16) &amp; 0xffff)<BR>
&nbsp;&nbsp;#define &nbsp;&nbsp;&nbsp;TIFF16GetB(abgr) &nbsp;&nbsp;&nbsp;((=
(abgr) &gt;&gt; 32) &amp; 0xffff)<BR>
&nbsp;&nbsp;#define &nbsp;&nbsp;&nbsp;TIFF16GetA(abgr) &nbsp;&nbsp;&nbsp;((=
(abgr) &gt;&gt; 48) &amp; 0xffff)<BR>
&nbsp;&nbsp;<BR>
&nbsp;&nbsp;1. I read the image data as a uint64 tab<BR>
&nbsp;&nbsp;2. I deinterlace pixels using (uint16) TIFF16GetR(*data_tiff), =
(uint16) TIFF16GetG(*data_tiff), (uint16) TIFF16GetB(*data_tiff) &amp; (uin=
t16) TIFF16GetA(*data_tiff)<BR>
&nbsp;&nbsp;<BR>
&nbsp;&nbsp;but it seems that data are not natively stored in a uint64 tab,=
 so I wonder how are interlaced 16-bits per channel images into a uint32 pi=
xel tab. <BR>
&nbsp;&nbsp;<BR>
&nbsp;&nbsp;I'm also facing difficulties dealing with <B>16-bits grayscaled=
 images</B> in the same way (using TIFFReadRGBAImageOriented to get image d=
ata and trying to convert each pixel into a uint16)<BR>
&nbsp;&nbsp;<BR>
&nbsp;&nbsp;More generally, <B>do you have any piece of documentation about=
 16 bits grayscale and color images?</B> <BR>
&nbsp;&nbsp;<BR>
&nbsp;&nbsp;Thank you, <BR>
&nbsp;&nbsp;Best Regards, <BR>
&nbsp;&nbsp;<BR>
&nbsp;&nbsp;R&eacute;my A. <BR>
&nbsp;&nbsp;<BR>
&nbsp;&nbsp;<BR>
&nbsp;&nbsp;<BR>
&nbsp;</FONT><FONT FACE=3D"Myriad Pro"> <BR>
&nbsp;<BR>
</FONT></SPAN></BLOCKQUOTE><SPAN STYLE=3D'font-size:10pt'><FONT FACE=3D"Myr=
iad Pro"> <BR>
</FONT></SPAN></BLOCKQUOTE><SPAN STYLE=3D'font-size:10pt'><FONT FACE=3D"Myr=
iad Pro"> <BR>
&nbsp;<BR>
</FONT></SPAN></BLOCKQUOTE>
</BODY>
</HTML>


--_000_CD9435725D4D4ccoxadobecom_--

--===============0982385162==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Tiff mailing list: Tiff@lists.maptools.org
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/
--===============0982385162==--
