Return-Path: <tiff-bounces@lists.maptools.org>
Received: from inas007.isp.belgacom.be (localhost [127.0.0.1])
        by inav026.isp.belgacom.be (8.12.11.20060308/8.12.11/Skynet-IN-AV-3.00) with ESMTP id k8R4qBCO031755
        for <joris.at.lebbeke@skynet.be>; Wed, 27 Sep 2006 06:52:11 +0200
        (envelope-from <tiff-bounces@lists.maptools.org>)
Received: from inmx002.isp.belgacom.be (inmx002.isp.belgacom.be [195.238.5.7])
        by inas007.isp.belgacom.be (8.12.11.20060308/8.12.11/Skynet-IN-AS-2.03) with ESMTP id k8R4q7rQ018978
        for <joris.at.lebbeke@skynet.be>; Wed, 27 Sep 2006 06:52:10 +0200
        (envelope-from <tiff-bounces@lists.maptools.org>)
Received: from duke.maptools.org (r153.dmsolutions.ca [209.217.116.153] (may be forged))
        by inmx002.isp.belgacom.be (8.12.11.20060308/8.12.11/Skynet-IN-2.32) with ESMTP id k8R4q66B029761
        for <joris.at.lebbeke@skynet.be>; Wed, 27 Sep 2006 06:52:06 +0200
        (envelope-from <tiff-bounces@lists.maptools.org>)
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 k8R4GRGm001840;
	Wed, 27 Sep 2006 00:17:06 -0400
Received: from mpls-qmqp-03.inet.qwest.net (mpls-qmqp-03.inet.qwest.net
	[63.231.195.114])
	by duke.maptools.org (8.12.11/8.12.10) with ESMTP id k8R4GO7r001837
	for <tiff@lists.maptools.org>; Wed, 27 Sep 2006 00:16:24 -0400
Received: from mpls-pop-13.inet.qwest.net (mpls-pop-13.inet.qwest.net
	[63.231.195.13]) by mpls-qmqp-03.inet.qwest.net (Postfix) with QMQP
	id 552C2623624; Wed, 27 Sep 2006 04:16:23 +0000 (UTC)
Received: from 71-33-161-219.hlrn.qwest.net (HELO ?127.0.0.1?) (71.33.161.219)
	by mpls-pop-13.inet.qwest.net with SMTP; 27 Sep 2006 04:16:23 -0000
Date: Tue, 26 Sep 2006 22:21:06 -0600
Message-ID: <4519FC32.4030506@qwest.net>
From: "Richard Nolde" <nrichard8@qwest.net>
To: "Joris" <joris.at.lebbeke@skynet.be>
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
MIME-Version: 1.0
References: <002001c6e12e$aff71a70$02b8f551@dfgrrxsknr4e>
In-Reply-To: <002001c6e12e$aff71a70$02b8f551@dfgrrxsknr4e>
Cc: Tiff List <tiff@lists.maptools.org>
Subject: [Tiff] YCbCr data in tiffcrop
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>
Content-Type: multipart/mixed; boundary="===============1203692407=="
Sender: tiff-bounces@lists.maptools.org
Errors-To: tiff-bounces@lists.maptools.org
X-UIDL: 000000000023ceae.00001b14
X-MSP-STORE: Wed, 27 Sep 2006 06:52:17 +0200
Status: RO

--===============1203692407==
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Joris / Bob/list,<br>
&nbsp;&nbsp; The routines that I am using for reading and writing the data are
exactly those used in tiffcp now and they handle strips and tiles in
contiguous and separate planar configurations. I found no indication
that they made any distinctions based on the color model or compression
since they call low level libtiff routines to handle the codecs. They
are documented as delivering the uncompressed data to the specified
buffer in scanlines or tiles as requested. I deduced by experiment,
that this buffer is always arranged as plannar config contiguous for
all the sample formats that I have been able to handle correctly.&nbsp; I
surmise that YCbCr data comes in differently because the resulting
image is shifted half an image width and badly color shifted but
vaguely recognizable when I try to mirror it horizontally. When
mirrored vertically, it gets chopped up into 4 quadrants with a stripe
in the center.&nbsp; Based on the explanation of YCbCr, which is admittedly
over my head, my simple copying and/or chopping of portions of the
image based on bits per sample and samples per pixel is probably not
going to work here unless I can reorder the data in the read buffer to
resemble a multi-byte per pixel sample with a known number of bytes to
grab for each pixel. RGBA works fine, but&nbsp; the sequence described by
Joris doesn't look too promising for pointer offset slicing and dicing.
I don't need YCbCr for my project but I wanted to try to support all
the options that tiffcp does since tiffcrop is a superset of tiffcp.
Given an infinite amount of time, I would like to add more functions
like multi-page splitting capabilities found in tiff2ps so that one
image can be spread over multiple output images.&nbsp; Tiff2ps relies on the
Postscript mask operator to do this but it is very inefficient storage
wise as it keeps a copy of the entire image for each page and just
masks off different regions each time.&nbsp; My code from tiffcrop could be
ported to tiff2ps to store only the cropped portion in each image.<br>
<br>
Richard Nolde<br>
<br>
Joris wrote:
<blockquote cite="mid002001c6e12e$aff71a70$02b8f551@dfgrrxsknr4e"
 type="cite">
  <pre wrap="">Joris wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">This applies to all forms of
subsampled YCbCr, uncompressed, LZW compressed, flate compressed,
whatever. Unfortunately, the LibJpeg library returns another
organisation, and a convertion needs to be made...
    </pre>
  </blockquote>
  <pre wrap=""><!---->
I meant, a convertion needs to be made inside tif_jpeg.c, that may not
have been clear. The purpose of this conversion is to take data
organisation as returned by LibJpeg, and reformat it into the
compression-independent organisation that is assumed by the rest of the
library, thus making all subsampled YCbCr organisation uniform.

I think there's currently a bug left in exactly this part of tif_jpeg.c,
presumably, seeing the output of some image, but I've not yet had the
time to investigate properly. This may additionally make it hard for
Richard to add subsampled YCbCr support inside tiffcrop, unless he
chooses to work from uncompressed subsampled YCbCr testimages and drops
the use of JPEGCOLORMODE_RGB if he's using it right now, which I'd
recommend anyway since that is the single shortest path to full
compression-independent support for subsampled YCbCr.


Best regards,

Joris Van Damme
<a class="moz-txt-link-abbreviated" href="mailto:info@awaresystems.be">info@awaresystems.be</a>
<a class="moz-txt-link-freetext" href="http://www.awaresystems.be/">http://www.awaresystems.be/</a>
Download your free TIFF tag viewer for windows here:
<a class="moz-txt-link-freetext" href="http://www.awaresystems.be/imaging/tiff/astifftagviewer.html">http://www.awaresystems.be/imaging/tiff/astifftagviewer.html</a>



  </pre>
</blockquote>
</body>
</html>

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