Return-Path: <tiff-bounces@lists.maptools.org>
X-Original-To: info@awaresystems.be
Delivered-To: info@awaresystems.be
Received: from mx-i.b-one.net (mx-i.one.com [91.198.169.56])
	by mail9.b-one.net (Postfix) with ESMTP id E672C400B7B
	for <info@awaresystems.be>; Tue, 11 May 2010 19:36:02 +0200 (CEST)
Received: by mx-i.b-one.net (Postfix, from userid 106)
	id DEDA33CD6AE; Tue, 11 May 2010 19:36:02 +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=4 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-i.b-one.net (Postfix) with ESMTP id 0C4DF3CD6AC for
 <info@awaresystems.be>; Tue, 11 May 2010 19:36:02 +0200 (CEST)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by
 lists.maptools.org (Postfix) with ESMTP id 2D7131D646B0A; Tue, 11 May 2010
 12:34:55 -0500 (EST)
Received: from smtp.kreisbote.de (smtp.kreisbote.de [195.243.114.61]) by
 lists.maptools.org (Postfix) with ESMTP id BD9A31D651E99 for
 <tiff@lists.maptools.org>; Tue, 11 May 2010 12:33:25 -0500 (EST)
Received: from mail.kreisbote.de (m8.merkur-online.de [195.243.114.8]) by
 smtp.kreisbote.de (Postfix) with ESMTP id 1E8DE30009 for
 <tiff@lists.maptools.org>; Tue, 11 May 2010 19:33:24 +0200 (CEST)
Message-ID: <4BE994E4.1000501@kreisbote.de>
Date: Tue, 11 May 2010 19:33:24 +0200
From: Oliver Geisen <oliver.geisen@kreisbote.de>
Organization: Kreisboten Verlag =?ISO-8859-1?Q?M=FChlfellner_KG?=
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; de; rv:1.9.1.9)
 Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4
MIME-Version: 1.0
To: tiff@lists.maptools.org
References: <4BE98CD9.5080305@cybox.com>
In-Reply-To: <4BE98CD9.5080305@cybox.com>
Subject: Re: [Tiff] Combining multiple G4 images into a single output image
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

Hello Richard,

> could handle YCbCr compressed data.  From what I remember, libtiff is going to read a whole strip anyway and then hand off a scanline at a time as your read from the strip even if you call TIFFReadScanline.
>    
I also thought that libtiff is doing it that way. Because my tool should 
handle G4 compressed data only it must read a coded strip, decode it, 
and hand out the scanlines one by one. I'm also aware that there is no 
random access to the scanlines, but i don't need this anyway.

> Depending on the size of your final image, you may have to allocate a working buffer that is only as large as a few scanlines, ideally the size of a full strip in the output image rather than creating the full output image in memory before writing any of it out. This assumes all your input images will be pasted into the output buffer from left to right and the final image will be N * the width of the input images but only 1 * the height of the input image. If you have multiple rows and columns of subimages in the output image, you have to calculate the width of the widest subset and pad every scanline to match.
>    
I really thougt about reading the background image into memory and then 
read file by file to be placed and overwrite the background with their 
data at the given positions. Therefore i need to crop the lines to the 
width of the background (if they would float out to the right) and 
mask/shift if the placement is not on a byte boundary. Because of the 
high resolution of the image (1270dpi) i really don't think anybody 
would notice a displacement if round the x-value up or down to the next 
byte boundary. This would make a maximum error of 7 1270/inch wich are 
only about a tenth of a millimeter. Maybe i should at this as an option 
("--turbo").

> Reading non-byte-aligned samples is required to crop or combine images that are not a multiple of 8 bits per scanline but you will have to track the byte AND bit offsets across multiple input images when you paste the input scanlines into your output buffer. I only have to deal with that within a single source image. If you are reading a scanline at a time, it should not be too hard for Bilevel data.
> I am thinking about some code to speed up the masking operation but haven't written anything yet.
>    
In the case of merging/overlaping two pictures at bilevel, and the image 
on top is not placed at a byte boundary you need to mask and combine 
only the edges of the images, the fully overlapping part then only needs 
bit shifting. I'm not really shure what it means to do such massive 
shifting operations. It really depends on the size of the images to be 
placed. Maybe it could be optimized by calculating what is really seen 
later of the image to be placed and just skip full bytes which would be 
overwritten by images placed later. I also can think of some 
lookup-tables to aid masking and shifting. One LT could get a byte value 
multiplied with a shiftcount, building a pointer and just read back the 
precalculated value. This LT could be build on runtime by a function. 
This way no real shifting had to be done, but only lookups which may be 
much faster.
The same technique could be used to masking. The pointer could be calced 
by the original value and a mask value (saying: mask 0x54 with 
&b11110000). Such a table should not be larger than 256x256 bytes (64k).

> Regarding memory mapped files. There may be greater benefit for memory mapping in cases where an image is being rotated since access to the source data will require multiple passes through a given scanline.
>    
For now i don't need to support rotating, not even mirroring.

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