Return-Path: owner-tiff@olympiakos.com
Return-Path: <owner-tiff@olympiakos.com>
Received: from localhost (localhost [127.0.0.1])
	by at1895.spb.edu (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f5L7ogoB004876
	for <dron@localhost>; Thu, 21 Jun 2001 11:56:21 +0400
Received: from eudoramail.com [209.185.123.45]
	by localhost with POP3 (fetchmail-5.8.1)
	for dron@localhost (single-drop); Thu, 21 Jun 2001 11:56:21 +0400 (MSD)
Received: from gate7.olympiakos.com ([207.176.88.85]) by shared1-mail.whowhere.com; Wed Jun 20 15:35:15 2001
Received: from localhost (daemon@localhost)
	by gate7.olympiakos.com (8.9.3/8.9.3) with SMTP id SAA32216;
	Wed, 20 Jun 2001 18:22:46 -0400
Received: by gate7.olympiakos.com (bulk_mailer v1.9); Wed, 20 Jun 2001 18:21:34 -0400
Received: (from majordom@localhost)
	by gate7.olympiakos.com (8.9.3/8.9.3) id SAA32017
	for tiff-outgoing; Wed, 20 Jun 2001 18:21:34 -0400
X-Authentication-Warning: gate7.olympiakos.com: majordom set sender to owner-tiff@olympiakos.com using -f
Received: from kodakr.kodak.com (kodakr.kodak.com [192.232.119.69])
	by gate7.olympiakos.com (8.9.3/8.9.3) with ESMTP id SAA31999
	for <tiff@olympiakos.com>; Wed, 20 Jun 2001 18:21:30 -0400
Received: from felix (felix.cgs.kodak.com [150.102.17.1])
	by kodakr.kodak.com (8.11.1/8.11.1) with SMTP id f5KGoHR02207
	for <tiff@olympiakos.com>; Wed, 20 Jun 2001 12:50:17 -0400 (EDT)
Received: from hecgsw7 by felix (SMI-8.6/10.1)
	id MAA23261; Wed, 20 Jun 2001 12:49:44 -0400
Message-ID: <000801c0f9a9$8089fd10$451f6696@kodak.com>
From: "Neil Talsania" <neil.talsania@kodak.com>
To: <tiff@olympiakos.com>
Subject: Possible bug with Big versus Little Endian
Date: Wed, 20 Jun 2001 12:53:16 -0400
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0005_01C0F987.F92D7160"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Sender: owner-tiff@olympiakos.com
Status: RO
Content-Length: 5291
Lines: 121

This is a multi-part message in MIME format.

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

Hi,
  I have encountered a problem when running my application on a big =
endian versus little endian machine. The file I am creating has the SMIN =
and SMAX tags set. The image data is 8bps so the SMIN and SMAX tags are =
of type BYTE. There are 3 bands in the file, so there are 3 values in =
the SMIN and SMAX tag (of course all the same value) The file that I am =
creating is a big endian type file (regardless of architecture of =
system). The code works great when I create the file on a big endian =
machine and then read it on a big endian machine. But it does not work =
if I create the file on a little endian machine. The error that I get is =
that the values must match on all three bands for SMAX.

I stepped through the code in the debugger, and I think that I have the =
problem isolated, and put in a fix that seems to work. The problem seems =
to be that the SMAX tag has 3 BYTE values that are stored in byte 0,1,2 =
of the char * which is then memcpy into the integer offset variable. =
Then, when the header is actually written, the data is flipped because =
the file is big endian, but the architecture is little endian. But then =
when I go to read this file on the big endian machine I get the error. =
The reason is that the reading the big endian file on a big endian =
machine, I will read the offset, and now my values are in the wrong =
bytes, because the read code is only dependent on the file type.=20

The fix that I put in is in the write. In the TIFFWriteByteArray =
function, if I am less than 4 bytes instead of just doing the memcpy, I =
check to see if I am going to be swapped on write. IF not then I do the =
memcpy, but if so, then I swap the bytes here, then everything seems to =
work.

If anyone has any opinions on why my fix is not the right thing, please =
let me know. If I get a chance to get more detail form the one system =
moved over to where I can include it, I will probably create a new bug =
report for this. I realize that if I could provide more information, my =
problem might have a beter chance of getting resolved.

Neil Talsania

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2919.6307" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp; I have encountered a problem =
when running my=20
application on a big endian versus little endian machine. The file I am =
creating=20
has the SMIN and SMAX tags set. The image data is 8bps so the SMIN and =
SMAX tags=20
are of type BYTE. There are 3 bands in the file, so there are 3 values =
in the=20
SMIN and SMAX tag (of course all the same value)</FONT><FONT =
face=3DArial size=3D2>=20
The file that I am creating is a big endian type file (regardless of=20
architecture of system). The code works great when I create the file on =
a big=20
endian machine and then read it on a big endian machine. But it does not =
work if=20
I create the file on a little endian machine. The error that I get is =
that the=20
values must match on all three bands for SMAX.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I stepped through the code in the =
debugger, and I=20
think that I have the problem isolated, and put in a fix that seems to =
work. The=20
problem seems to be that the SMAX tag has 3 BYTE values that are stored =
in byte=20
0,1,2 of the char * which is then memcpy into the integer offset =
variable. Then,=20
when the header is actually written, the data is flipped because the =
file is big=20
endian, but the architecture is little endian. But then when I go to =
read this=20
file on the big endian machine I get the error. The reason is that the =
reading=20
the big endian file on a big endian machine, I will read the offset, and =
now my=20
values are in the wrong bytes, because the read code is only dependent =
on the=20
file type. </FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>The fix that I put in is in the write. =
In the=20
TIFFWriteByteArray function, if I am less than 4 bytes instead of just =
doing the=20
memcpy, I check to see if I am going to be swapped on write. IF not then =
I do=20
the memcpy, but if so, then I swap the bytes here, then everything seems =
to=20
work.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>If anyone has any opinions on why my =
fix is not the=20
right thing, please let me know. If I get a chance to get more detail =
form the=20
one system moved over to where I can include it, I will probably create =
a new=20
bug report for this. I realize that if I could provide more information, =
my=20
problem might have a beter chance of getting resolved.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Neil =
Talsania</FONT></DIV></BODY></HTML>

------=_NextPart_000_0005_01C0F987.F92D7160--

