Return-Path: <tiff-bounces@remotesensing.org>
Received: from inmx006.isp.belgacom.be (inmx006.isp.belgacom.be [195.238.2.106])
        by mailst035.isp.belgacom.be (8.12.11/8.12.11/Skynet-MAILSTORE-2.14) with ESMTP id j0O1I5VH007050
        for <joris.at.lebbeke@skynet.be>; Mon, 24 Jan 2005 02:18:05 +0100
        (envelope-from <tiff-bounces@remotesensing.org>)
Received: from xserve.flids.com (adsl-065-083-169-202.sip.mco.bellsouth.net [65.83.169.202])
        by inmx006.isp.belgacom.be (8.12.11/8.12.11/Skynet-IN-2.32) with ESMTP id j0O1Hwfd013422
        for <joris.at.lebbeke@skynet.be>; Mon, 24 Jan 2005 02:18:00 +0100
        (envelope-from <tiff-bounces@remotesensing.org>)
Received: from adsl-065-083-169-202.sip.mco.bellsouth.net (localhost [127.0.0.1])
	by xserve.flids.com (Postfix) with ESMTP
	id 995945E59C6; Sun, 23 Jan 2005 20:17:36 -0500 (EST)
X-Original-To: tiff@remotesensing.org
Delivered-To: tiff@remotesensing.org
Received: from mailout08.sul.t-online.com (mailout08.sul.t-online.com
	[194.25.134.20])
	by xserve.flids.com (Postfix) with ESMTP id A35625E59B7
	for <tiff@remotesensing.org>; Sun, 23 Jan 2005 20:17:34 -0500 (EST)
Received: from fwd08.aul.t-online.de by mailout08.sul.t-online.com with smtp 
	id 1CssrF-0001gT-00; Mon, 24 Jan 2005 02:17:33 +0100
Received: from MAGNUM
	(ZB4C5oZGQeeGqwtXFWpMKderD8Q-9L6pAqbqHtWfJz5EgwWhyJx9g5@[217.245.160.12])
	by fmrl08.sul.t-online.com
	with smtp id 1Cssr6-1CBd4a0; Mon, 24 Jan 2005 02:17:24 +0100
From: Sherlog <sherlog@t-online.de>
To: <tiff@remotesensing.org>
Subject: Re: [Tiff] LibTiffDelphi
Date: Mon, 24 Jan 2005 02:17:23 +0100
X-Meow: Zrbj!
Message-ID: <41f53985$54bcfb5@meow-labs.de>
References: <000b01c5016a$b80f2a90$0501a8c0@MIKO4>
In-Reply-To: <000b01c5016a$b80f2a90$0501a8c0@MIKO4>
Organization: SNAFU Labs in Radis, Germany
X-No-Archive: yes
X-Mailer: Forte Agent 1.92/32.572:085  /\/\eo\/\/
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-ID: ZB4C5oZGQeeGqwtXFWpMKderD8Q-9L6pAqbqHtWfJz5EgwWhyJx9g5@t-dialin.net
X-TOI-MSGID: b1c9c011-6300-46a1-add4-723e4a567ca8
X-BeenThere: tiff@remotesensing.org
X-Mailman-Version: 2.1.2
Precedence: list
List-Id: TIFF and libtiff discussion  <tiff.remotesensing.org>
List-Unsubscribe: <http://xserve.flids.com/mailman/listinfo/tiff>,
	<mailto:tiff-request@remotesensing.org?subject=unsubscribe>
List-Archive: <http://xserve.flids.com/pipermail/tiff>
List-Post: <mailto:tiff@remotesensing.org>
List-Help: <mailto:tiff-request@remotesensing.org?subject=help>
List-Subscribe: <http://xserve.flids.com/mailman/listinfo/tiff>,
	<mailto:tiff-request@remotesensing.org?subject=subscribe>
Sender: tiff-bounces@remotesensing.org
Errors-To: tiff-bounces@remotesensing.org
X-UIDL: dda0701c8c7e01d1a332cc2c2f79579b

--+ in <000b01c5016a$b80f2a90$0501a8c0@MIKO4>:

Strange nick you have. <g>

> LibTiffDelphi.
...
>   TIFFSetField(imgtif, TIFFTAG_XRESOLUTION, 150.0);
>   TIFFSetField(imgtif, TIFFTAG_YRESOLUTION, 150.0);
>   TIFFSetField(imgtif, TIFFTAG_RESOLUTIONUNIT, RESUNIT_INCH);
...
>   TIFFClose(imgtif);
...
> tiffinfo says :
>   Resolution: 0, 0 pixels/inch

You have set the fields properly and flushed them properly, yet the values
have not appeared in the file. I'd say there is something fishy going on in
the interaction between the Delphi code and the C code - perhaps a runtime
issue. Trace into the TIFFSetField() calls and watch the CPU/FPU windows for
unusual things (you need a special build of LibTiffDelphi for tracing into
the C code). You'll probably find some Delphi/C clashes regarding FPU use.

Have you posted this to Aware Systems? They are providing LibTiffDelphi and
so they should know it better than anybody else; quite probably they can
pinpoint the problem just from the description.

Apart from that, you should rework your pixel transfer code a little. The
only reason that it 'sort of' works now is that you pass a pointer to the
last scanline of the original bitmap to TIFFWriteRawStrip() and since bitmaps
are what they are you are thus effectively passing a pointer to the whole
bitmap data (since the last row on screen is the first row in memory, aka
bottom-up bitmap). 

However, scanlines in bitmap data are required to be aligned on DWORD
boundaries (32 bits) while uncompressed 1-bit TIFF scanlines must be aligned
on byte boundaries. This coincides if ImageWidth is close to multiples of 32
(25..32, 57..64, 89..96 and so on) but for other widths it does not work.
Further, while bottom-up bitmaps are common there are also top-down bitmaps,
so the fact that your code sort of works is mostly an accident.

The copy loop might look like this (put this *after* the code that
initializes the TIFF field values):

|   with ImageBits.Picture.Bitmap do begin
|      assert(Monochrome = true, 'ImageBits.Picture.Bitmap.Monochrome = true');
|      for y := 0 to Height - 1 do
|         if 1 <> TIFFWriteScanLine(imgtif, Scanline[Height - y - 1], y, 0) then
|            raise Exception.Create('meow');  end;

This is for bottom-up bitmaps, of course. You have to search the Borland docs
in order to find out whether Borland expose the bottom-up/top-down property
on their Bitmap object or whether they guarantee that their bitmaps are
always bottom-up or whether they simply let the chips fall where they may as
usual. Note: in a raw Windows bitmap the height field is negative for a
top-down bitmap, there is no separate 'bottom-up/top-down' flag. 

An alternative to antisymmetric writing in the bottom-up case would be
adjusting the 'Orientation' TIFF field to match the bitmap's bottom-up-ness
but then there is no guarantee that simple-minded TIFF consuming programs
will show your image correctly (the atrocity known as Wang/Kodak/Microsoft
Imaging comes to mind).

Luck++,
sherlog
-- 
Sherlog    [Personenkennzahl 250866413515 / Stefan Otto / SO1801-RIPE]
_______________________________________________
Tiff mailing list
Tiff@remotesensing.org
http://xserve.flids.com/mailman/listinfo/tiff
