Return-Path: <tiff-bounces@lists.maptools.org>
Received: from inas018.isp.belgacom.be (localhost [127.0.0.1])
        by inav023.isp.belgacom.be (8.12.11.20060308/8.12.11/Skynet-IN-AV-3.00) with ESMTP id k8RN2346023295
        for <joris.at.lebbeke@skynet.be>; Thu, 28 Sep 2006 01:02:03 +0200
        (envelope-from <tiff-bounces@lists.maptools.org>)
Received: from inmx017.isp.belgacom.be (inmx017.isp.belgacom.be [195.238.4.129])
        by inas018.isp.belgacom.be (8.12.11.20060308/8.12.11/Skynet-IN-AS-2.03) with ESMTP id k8RN1rd1019205
        for <joris.at.lebbeke@skynet.be>; Thu, 28 Sep 2006 01:01:53 +0200
        (envelope-from <tiff-bounces@lists.maptools.org>)
Received: from duke.maptools.org (r153.dmsolutions.ca [209.217.116.153] (may be forged))
        by inmx017.isp.belgacom.be (8.12.11.20060308/8.12.11/Skynet-IN-2.32) with ESMTP id k8RN1hjO015456
        for <joris.at.lebbeke@skynet.be>; Thu, 28 Sep 2006 01:01:44 +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 k8RMuQbR016465;
	Wed, 27 Sep 2006 18:56:35 -0400
Received: from exprod6og50.obsmtp.com (exprod6og50.obsmtp.com [64.18.1.181])
	by duke.maptools.org (8.12.11/8.12.10) with SMTP id k8RMuGsl016462
	for <tiff@lists.maptools.org>; Wed, 27 Sep 2006 18:56:17 -0400
Received: from source ([192.150.11.134]) by exprod6ob50.postini.com
	([64.18.5.12]) with SMTP; Wed, 27 Sep 2006 15:56:15 PDT
Received: from inner-relay-3.eur.adobe.com (inner-relay-3.adobe.com
	[192.150.20.198] (may be forged))
	by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id
	k8RMrsnN026031; Wed, 27 Sep 2006 15:53:55 -0700 (PDT)
Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72])
	by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id
	k8RMu77W009424; Wed, 27 Sep 2006 15:56:08 -0700 (PDT)
Received: from namail3.corp.adobe.com ([10.8.192.66]) by fe2.corp.adobe.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 27 Sep 2006 15:56:07 -0700
Received: from 10.0.54.253 ([10.0.54.253]) by namail3.corp.adobe.com
	([10.8.192.66]) via Exchange Front-End Server
	namailhost.corp.adobe.com ([10.8.192.72]) with Microsoft
	Exchange Server HTTP-DAV ; Wed, 27 Sep 2006 22:56:06 +0000
User-Agent: Microsoft-Entourage/11.2.5.060620
Date: Wed, 27 Sep 2006 15:56:41 -0700
Subject: Re: [Tiff] Horizontal prediction for 16bit data
From: Chris Cox <ccox@adobe.com>
To: Joris <joris.at.lebbeke@skynet.be>, TIFF <tiff@lists.maptools.org>
Message-ID: <C1404FB9.4521B%ccox@adobe.com>
Thread-Topic: [Tiff] Horizontal prediction for 16bit data
Thread-Index: AcbiiDIQcFPYWE57EduEwQAKlZxm+A==
In-Reply-To: <000901c6e239$4c0ad770$2abdf651@dfgrrxsknr4e>
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 27 Sep 2006 22:56:07.0662 (UTC)
	FILETIME=[1E3160E0:01C6E288]
Cc: 
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.00001b28
X-MSP-STORE: Thu, 28 Sep 2006 01:02:05 --21-99
Status:   


Joris;

You need to do differencing in the host machine byte order, not the file
byte order (otherwise it won't work too well!).

And you must do differencing on the native size (16 bit, 32 bit, etc.) for
the horizontal differencing predictor.

One of these days I need to draw out the TIFF pipeline and put it in a
technote. (something I thought was obvious from the spec. but other people
keep missing)

Reorder planes -> difference -> byte order swap to file order -> compress
And the reverse
Decompress -> byte order swap to host order -> undo-difference -> reorder
planes


Chris



On 9/27/06 6:31 AM, "Joris" <joris.at.lebbeke@skynet.be> wrote:

> Folks,
> 
> I've some trouble with a testimage that uses prediction on 16bit integer
> grayscale data.
> 
> If I remember correctly (I've not double-checked but will do so if
> nobody can confirm nor contradict my memory), the spec says horizontal
> prediction is only valid for 8bit data. But we're forced to 'logically
> extend' the spec in many areas now, so we might as well look into this.
> 
> I see three possible 'logical extensions', and all seem to have some
> drawbacks.
> 
> 1) differentiate 16bit values after resolving file byte order
> This is a logical problem, as file byte order resolution in decoding
> needs to come after prediction resolution in my model. So some hack
> would be required, resolving file byte order, depredicting, and
> unresolving file byte order next. I've not yet investigated whether or
> not I arrive at logical impossibilities if I turn my model around, but
> could do so if required.
> 
> 2) differentiate 16bit values regardless of file byte order
> I think this wouldn't be very efficient, as to resulting compression
> ratio.
> 
> 3) differentiate 8bit values, always, just differentiate twice as many
> This solves the byte order issue, but still we'd be totally giving up on
> any possibility to extend to any bitdepth and we would be limiting
> prediction to multiples of 8bits from this point on.
> 
> Interestingly, when I implement option 1 or 2 decoding my testimage
> (there's no difference between 1 and 2 as far as my testimage is
> concerned since file byte order and machine byte order are the same), I
> get results identical to the results I get from the LibTiff RGBA
> interface. These results are clearly wrong as far as this particular
> testimage is concerned. When I implement option 3, I get clearly good
> results on this image. There's no indication in any tags where this
> testimage came from.
> 
> Any comments would be hugely appreciated. I'm not aware of how exactly
> this is handled in LibTiff. Does LibTiff support writing this stuff? If
> so, our single option would be to follow this. Does LibTiff not support
> writing, but resolves this when reading nonetheless? In this case, we
> ought to try and find out what flavors are 'out there' I think, as any
> decision we make will at least have to try and take that into account.
> Do many of us have such files in our testimage libraries? If they are
> rare at best at this point, our options may be considered more open
> perhaps.
> 
> 
> Best regards,
> 
> Joris Van Damme
> info@awaresystems.be
> http://www.awaresystems.be/
> Download your free TIFF tag viewer for windows here:
> http://www.awaresystems.be/imaging/tiff/astifftagviewer.html
> 
> _______________________________________________
> Tiff mailing list: Tiff@lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/tiff
> http://www.remotesensing.org/libtiff/

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