Return-Path: <tiff-bounces@lists.maptools.org>
X-Original-To: info@awaresystems.be
Delivered-To: info@awaresystems.be
Received: from mx-g.b-one.net (mx-g.one.com [91.198.169.54])
	by mail9.b-one.net (Postfix) with ESMTP id BDCA4400124
	for <info@awaresystems.be>; Wed,  7 Oct 2009 23:31:22 +0200 (CEST)
X-Virus-Scanned: by one.com
X-Spam-Score: 0
X-Spam-Level: 
X-Spam-Status: No, score=0 tagged_above=0 required=6 tests=[none]
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.4
Received: from lists.maptools.org (lists.maptools.org [65.39.174.144])
	by mx-g.b-one.net (Postfix) with ESMTP id 2063314002A8
	for <info@awaresystems.be>; Wed,  7 Oct 2009 23:31:22 +0200 (CEST)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by lists.maptools.org (Postfix) with ESMTP id 3DE481D18B0E6;
	Wed,  7 Oct 2009 16:30:30 -0500 (EST)
Received: from blade.simplesystems.org (blade.simplesystems.org [65.66.246.74])
	by lists.maptools.org (Postfix) with ESMTPS id B47411D1F46DD
	for <tiff@lists.maptools.org>; Wed,  7 Oct 2009 16:26:15 -0500 (EST)
Received: from freddy.simplesystems.org (freddy.simplesystems.org
	[65.66.246.65])
	by blade.simplesystems.org (8.13.8+Sun/8.13.8) with ESMTP id
	n97LQE8h023462; Wed, 7 Oct 2009 16:26:14 -0500 (CDT)
Date: Wed, 7 Oct 2009 16:26:14 -0500 (CDT)
From: Bob Friesenhahn <bfriesen@simple.dallas.tx.us>
X-X-Sender: bfriesen@freddy.simplesystems.org
To: Eskandar Ensafi <Ensafi@SpaceComputer.Com>
In-Reply-To: <009101ca478a$630150d0$2903f270$@com>
Message-ID: <alpine.GSO.2.01.0910071614460.15399@freddy.simplesystems.org>
References: <007c01ca4783$dfa4fc60$9eeef520$@com>
	<alpine.GSO.2.01.0910071454200.15399@freddy.simplesystems.org>
	<009101ca478a$630150d0$2903f270$@com>
User-Agent: Alpine 2.01 (GSO 1266 2009-07-14)
MIME-Version: 1.0
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2
	(blade.simplesystems.org [65.66.246.90]);
	Wed, 07 Oct 2009 16:26:14 -0500 (CDT)
Cc: tiff@lists.maptools.org
Subject: Re: [Tiff] Wrong Native Bit Order on Intel x86_64
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: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tiff-bounces@lists.maptools.org
Errors-To: tiff-bounces@lists.maptools.org

On Wed, 7 Oct 2009, Eskandar Ensafi wrote:
>
> Hopefully, this tag is not being used by most applications because it
> would mean that when you write an image on a 64-bit system and try to view
> it on a 32-bit system, or vice versa, then the bits will be reversed and
> the image data will become rubbish.  I'm not so sure if "bit order" really
> matters, does it?

Of course bit order really does matter. If libtiff encounters a TIFF 
file written in a different order then it needs to reverse the order 
of the bits while reading.  If TIFF is requested to write output in a 
different order than the native order, then it needs to reverse the 
order of the bits while writing.  It does this via a TIFFReverseBits() 
function in libtiff/tif_swab.c.  This is important for FAX 
compression.

Here is where it is used:

   File        Function              Line
1 tif_jbig.c  JBIGDecode             86 TIFFReverseBits(tif->tif_rawdata, tif->tif_rawdatasize);
2 tif_jbig.c  JBIGOutputBie         175 TIFFReverseBits(buffer, len);
3 tif_read.c  TIFFFillStrip         354 TIFFReverseBits(tif->tif_rawdata, bytecount);
4 tif_read.c  TIFFFillTile          577 TIFFReverseBits(tif->tif_rawdata, bytecount);
5 tif_write.c TIFFWriteEncodedStrip 249 TIFFReverseBits(tif->tif_rawdata, tif->tif_rawcc);
6 tif_write.c TIFFWriteEncodedTile  404 TIFFReverseBits((unsigned char *)tif->tif_rawdata, tif->tif_rawcc);
7 tif_write.c TIFFFlushData1        687 TIFFReverseBits((unsigned char *)tif->tif_rawdata,

Some CPUs use a different fill order than others just like some CPUs 
are big endian and other CPUs are little endian.

It seems pretty mysterious that it took three years for this issue to 
be discovered and reported so probably there is something I am not 
understanding.

Bob
--
Bob Friesenhahn
bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
_______________________________________________
Tiff mailing list: Tiff@lists.maptools.org
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/
