Return-Path: <tiff-bounces@lists.maptools.org>
X-Original-To: info@awaresystems.be
Delivered-To: info@awaresystems.be
Received: from mx-e.b-one.net (mx-e.one.com [91.198.169.52])
	by mail9.b-one.net (Postfix) with ESMTP id B6BE740024C
	for <info@awaresystems.be>; Sat, 12 Dec 2009 04:06:03 +0100 (CET)
X-Virus-Scanned: by one.com
X-Spam-Score: 0.001
X-Spam-Level: 
X-Spam-Status: No, score=0.001 tagged_above=0 required=6
	tests=[HTML_MESSAGE=0.001]
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.4
Received: from lists.maptools.org (lists.maptools.org [65.39.174.144])
	by mx-e.b-one.net (Postfix) with ESMTP id 99CBBDF9
	for <info@awaresystems.be>; Sat, 12 Dec 2009 04:06:02 +0100 (CET)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by lists.maptools.org (Postfix) with ESMTP id 4EB0B1D19CCC2;
	Fri, 11 Dec 2009 22:04:28 -0500 (EST)
Received: from tecgraf.puc-rio.br (duchamp.tecgraf.puc-rio.br [139.82.85.1])
	by lists.maptools.org (Postfix) with ESMTPS id 9F90F1D203D69
	for <tiff@lists.maptools.org>; Fri, 11 Dec 2009 21:38:41 -0500 (EST)
Received: from antonio (magritte [10.0.8.92])
	by tecgraf.puc-rio.br (8.12.11.20060308/8.12.11) with ESMTP id
	nBC2caRS018946; Sat, 12 Dec 2009 00:38:36 -0200
From: "Antonio Scuri" <scuri@tecgraf.puc-rio.br>
To: <gene@pc-backup.com>, "'Steve Mills'" <smills@multi-ad.com>
References: <0CAB92DF-9766-485E-AB24-6C995925929F@multiad.com>	<2045F7DD5B1E4987B16C926D5A61EBD4@awarec74cb3e1c>	<D1697835-9E70-459D-9B60-D25F49411585@multiad.com>	<000001ca79d6$4f547de0$edfd79a0$@puc-rio.br>	<6A6CA554-B984-4D34-AAC4-1C21A23C0C9D@multiad.com>	<002201ca7a7d$301343b0$9039cb10$@puc-rio.br>	<B227A229-34E6-42F0-BE3E-0B73853B022B@multiad.com>
	<1260558676.4033.368.camel@PCB-Bench-01>
In-Reply-To: <1260558676.4033.368.camel@PCB-Bench-01>
Date: Sat, 12 Dec 2009 00:37:36 -0200
Message-ID: <000301ca7ad4$1144d6e0$33ce84a0$@puc-rio.br>
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Acp6mF5ZZpm5FV4JTFWQeamYoD9CwwAOmuWQ
Content-Language: pt-br
X-Virus-Status: Clean
Cc: 'tiff list' <tiff@lists.maptools.org>
Subject: Re: [Tiff] YCbCr
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="===============1077939706=="
Mime-version: 1.0
Sender: tiff-bounces@lists.maptools.org
Errors-To: tiff-bounces@lists.maptools.org

This is a multi-part message in MIME format.

--===============1077939706==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0004_01CA7AC3.4DBC06E0"
Content-Language: pt-br

This is a multi-part message in MIME format.

------=_NextPart_000_0004_01CA7AC3.4DBC06E0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

  My recommendation for you is to start at the TIFF format specification =
pdf. It has several interesting explanations that will answer some of =
your questions.

=20

  Anyway, here are some comments.=20

=20

  Yes there is no pre-defined conversion between CMYK and everything =
else. It really depends on how you should interpret the K component, and =
this usually involves the printer profile you are going to use.

=20

  Using libTIFF you can access images that are in the YCbCr color space =
in its raw state or with an automatic conversion to RGB. At least in the =
JPEG compression. The libtiff high level functions to load an RGB image =
do not use the automatic conversion, they load the image as YCbCr and =
then convert the raw data to RGB itself. By the way this is a recent =
change in libtiff.

=20

Best Regards,

Antonio Scuri

=20

From: tiff-bounces@lists.maptools.org =
[mailto:tiff-bounces@lists.maptools.org] On Behalf Of Gene Amtower
Sent: sexta-feira, 11 de dezembro de 2009 17:11
To: Steve Mills
Cc: tiff list
Subject: Re: [Tiff] YCbCr

=20

Well, I was following this thread thinking I might learn something from =
the discussion, but somewhere along the way, it went off the tracks for =
me!

This last post confuses me because the original post mentioned that the =
TIFFTAG_PHOTOMETRIC tag was reporting YCbCr, where as this one suggests =
the image is in CMYK.  Are we still talking about the original image =
from the first post?  If so, why is there this apparent contradiction =
between the first and last post?

All of this info got me to reading on the web, and I see that YCbCr is a =
colorspace primarily used for signal transmission to reduce the amount =
of transmission bandwidth, hence the downsampling of the Cb and Cr =
components because they carry less data.  Info on Wikipedia provides =
conversion formulas to/from RGB that depend on conversion factors that =
are not universal.  From these formulas, a red pixel ends up generating =
a value in each of the Y, Cb, and Cr pixel values because "Y" carries =
the primary luminance info, while Cb and Cr only communicate a =
"difference" value for the Red and Blue components.  It also suggested =
to me that you can't really view YCbCr values directly because they are =
calculated values used in data transmission that aren't directly related =
to the RGB world that we live in.  From what I can tell, YCbCr and CMYK =
are completely different colorspaces for either signal transmission or =
printing (respectively), and converting from one to the other actually =
involves an intermediate pass through the RGB space, with both =
conversions involving variable formulas that depend on =
hardware-dependent and implementation-dependent mapping algorithms.  It =
sounds like there is NO universal way to convert between these three =
representations.  There's also the RGBA colorspace that includes =
transparency info in the Alpha A channel - does this impact YCbCr and =
CMYK representations at all, or is this impossible in these alternate =
colorspaces?

If anyone cares to enlighten me, can you help me understand this =
discussion on LibTiff handling of RGB, CMYK, and YCbCr without going =
into a long dissertation on images, color spaces, TVs, and printing =
processes?  Is it possible to store YCbCr image data in a TIFF file?  If =
so, are there mechanisms built into LibTiff to convert it automatically =
to RGB for viewing, or is that up to the primary application to perform =
necessary conversions to the viewable world?  With the inherent =
variability of YCbCr color values, how would Steve even know if he was =
getting valid YCbCr data when reading the values from the image file?

I guess a quick summary of the colorspace capabilities in LibTiff and =
the Tiff standard in general would be really helpful to the uninitiated =
among us.  I know there's a lot of vagueness in the TIFF standard, but =
explain as much as possible, please!

Thanks,

   Gene



On Fri, 2009-12-11 at 10:58 -0600, Steve Mills wrote:=20

=20
On Dec 11, 2009, at 10:15:39, Antonio Scuri wrote:
=20
>  As Joris pointed out, you actually get Y Cb and Cr planes. So the =
first
> component, that looks red, is infact Y, and indeed has the correct =
size. But
> the Cb and Cr planes are downsampled. At least this is what I got =
here.
=20
What if the file is jpeg-compressed cmyk? The TIFFTAG_PHOTOMETRIC tag =
says it's cmyk, not YCbCr. I expect cmyk data in this case, but it sure =
doesn't look correct.
=20
_________________________________________________________
Steve Mills                              Me: 952-401-6255
Senior Software Architect                         MultiAd
smills@multiad.com                       www.multi-ad.com
=20
=20
_______________________________________________
Tiff mailing list: Tiff@lists.maptools.org
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/

------=_NextPart_000_0004_01CA7AC3.4DBC06E0
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dutf-8">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
pre
	{mso-style-priority:99;
	mso-style-link:"HTML Preformatted Char";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
span.HTMLPreformattedChar
	{mso-style-name:"HTML Preformatted Char";
	mso-style-priority:99;
	mso-style-link:"HTML Preformatted";
	font-family:Consolas;}
span.EmailStyle19
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:70.85pt 3.0cm 70.85pt 3.0cm;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DPT-BR link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>=C2=A0=C2=A0<span lang=3DEN-US>My recommendation for you =
is to start at the
TIFF format specification pdf. It has several interesting explanations =
that
will answer some of your questions.<o:p></o:p></span></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>=C2=A0 Anyway, here are some comments. =
<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>=C2=A0 Yes there is no pre-defined conversion between =
CMYK and everything
else. It really depends on how you should interpret the K component, and =
this
usually involves the printer profile you are going to =
use.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>=C2=A0 Using libTIFF you can access images that are in =
the YCbCr color
space in its raw state or with an automatic conversion to RGB. At least =
in the
JPEG compression. The libtiff high level functions to load an RGB image =
do not
use the automatic conversion, they load the image as YCbCr and then =
convert the
raw data to RGB itself. By the way this is a recent change in =
libtiff.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Best Regards,<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Antonio Scuri<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0cm 0cm =
0cm 4.0pt'>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt =
0cm 0cm 0cm'>

<p class=3DMsoNormal><b><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:
"Tahoma","sans-serif"'>From:</span></b><span lang=3DEN-US =
style=3D'font-size:10.0pt;
font-family:"Tahoma","sans-serif"'> tiff-bounces@lists.maptools.org
[mailto:tiff-bounces@lists.maptools.org] <b>On Behalf Of </b>Gene =
Amtower<br>
<b>Sent:</b> sexta-feira, 11 de dezembro de 2009 17:11<br>
<b>To:</b> Steve Mills<br>
<b>Cc:</b> tiff list<br>
<b>Subject:</b> Re: [Tiff] YCbCr<o:p></o:p></span></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>Well, I was following this thread thinking I might =
learn
something from the discussion, but somewhere along the way, it went off =
the
tracks for me!<br>
<br>
This last post confuses me because the original post mentioned that the
TIFFTAG_PHOTOMETRIC tag was reporting YCbCr, where as this one suggests =
the
image is in CMYK.&nbsp; Are we still talking about the original image =
from the
first post?&nbsp; If so, why is there this apparent contradiction =
between the
first and last post?<br>
<br>
All of this info got me to reading on the web, and I see that YCbCr is a
colorspace primarily used for signal transmission to reduce the amount =
of
transmission bandwidth, hence the downsampling of the Cb and Cr =
components
because they carry less data.&nbsp; Info on Wikipedia provides =
conversion
formulas to/from RGB that depend on conversion factors that are not
universal.&nbsp; From these formulas, a red pixel ends up generating a =
value in
each of the Y, Cb, and Cr pixel values because &quot;Y&quot; carries the
primary luminance info, while Cb and Cr only communicate a
&quot;difference&quot; value for the Red and Blue components.&nbsp; It =
also
suggested to me that you can't really view YCbCr values directly because =
they
are calculated values used in data transmission that aren't directly =
related to
the RGB world that we live in.&nbsp; From what I can tell, YCbCr and =
CMYK are completely
different colorspaces for either signal transmission or printing
(respectively), and converting from one to the other actually involves =
an
intermediate pass through the RGB space, with both conversions involving
variable formulas that depend on hardware-dependent and
implementation-dependent mapping algorithms.&nbsp; It sounds like there =
is NO
universal way to convert between these three representations.&nbsp; =
There's
also the RGBA colorspace that includes transparency info in the Alpha A =
channel
- does this impact YCbCr and CMYK representations at all, or is this =
impossible
in these alternate colorspaces?<br>
<br>
If anyone cares to enlighten me, can you help me understand this =
discussion on
LibTiff handling of RGB, CMYK, and YCbCr without going into a long =
dissertation
on images, color spaces, TVs, and printing processes?&nbsp; Is it =
possible to
store YCbCr image data in a TIFF file?&nbsp; If so, are there mechanisms =
built
into LibTiff to convert it automatically to RGB for viewing, or is that =
up to
the primary application to perform necessary conversions to the viewable
world?&nbsp; With the inherent variability of YCbCr color values, how =
would
Steve even know if he was getting valid YCbCr data when reading the =
values from
the image file?<br>
<br>
I guess a quick summary of the colorspace capabilities in LibTiff and =
the Tiff
standard in general would be really helpful to the uninitiated among =
us.&nbsp;
I know there's a lot of vagueness in the TIFF standard, but explain as =
much as
possible, please!<br>
<br>
Thanks,<br>
<br>
&nbsp;&nbsp; Gene<br>
<br>
<br>
<br>
On Fri, 2009-12-11 at 10:58 -0600, Steve Mills wrote: <o:p></o:p></p>

<pre><o:p>&nbsp;</o:p></pre><pre><span style=3D'color:black'>On Dec 11, =
2009, at 10:15:39, Antonio Scuri =
wrote:</span><o:p></o:p></pre><pre><o:p>&nbsp;</o:p></pre><pre><span
style=3D'color:black'>&gt;=C2=A0 As Joris pointed out, you actually get =
Y Cb and Cr planes. So the first</span><o:p></o:p></pre><pre><span
style=3D'color:black'>&gt; component, that looks red, is infact Y, and =
indeed has the correct size. But</span><o:p></o:p></pre><pre><span
style=3D'color:black'>&gt; the Cb and Cr planes are downsampled. At =
least this is what I got =
here.</span><o:p></o:p></pre><pre><o:p>&nbsp;</o:p></pre><pre><span
style=3D'color:black'>What if the file is jpeg-compressed cmyk? The =
TIFFTAG_PHOTOMETRIC tag says it's cmyk, not YCbCr. I expect cmyk data in =
this case, but it sure doesn't look =
correct.</span><o:p></o:p></pre><pre><o:p>&nbsp;</o:p></pre><pre><span
style=3D'color:black'>___________________________________________________=
______</span><o:p></o:p></pre><pre><span
style=3D'color:black'>Steve =
Mills=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Me: =
952-401-6255</span><o:p></o:p></pre><pre><span
style=3D'color:black'>Senior Software =
Architect=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 MultiAd</span><o:p></o:p></pre><pre><span
style=3D'color:black'><a =
href=3D"mailto:smills@multiad.com">smills@multiad.com</a>=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <a
href=3D"http://www.multi-ad.com">www.multi-ad.com</a></span><o:p></o:p></=
pre><pre><o:p>&nbsp;</o:p></pre><pre><o:p>&nbsp;</o:p></pre><pre><span
style=3D'color:black'>_______________________________________________</sp=
an><o:p></o:p></pre><pre><span
style=3D'color:black'>Tiff mailing list: <a =
href=3D"mailto:Tiff@lists.maptools.org">Tiff@lists.maptools.org</a></span=
><o:p></o:p></pre><pre><span
style=3D'color:black'><a =
href=3D"http://lists.maptools.org/mailman/listinfo/tiff">http://lists.map=
tools.org/mailman/listinfo/tiff</a></span><o:p></o:p></pre><pre><span
style=3D'color:black'><a =
href=3D"http://www.remotesensing.org/libtiff/">http://www.remotesensing.o=
rg/libtiff/</a></span><o:p></o:p></pre></div>

</div>

</body>

</html>

------=_NextPart_000_0004_01CA7AC3.4DBC06E0--


--===============1077939706==
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/
--===============1077939706==--
