AWARE [SYSTEMS] Imaging expertise for the Delphi developer
AWare Systems, Imaging expertise for the Delphi developer, Home TIFF and LibTiff Mailing List Archive

LibTiff Mailing List

TIFF and LibTiff Mailing List Archive
May 2010

Previous Thread
Next Thread

Previous by Thread
Next by Thread

Previous by Date
Next by Date


The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems

Valid HTML 4.01!


2010.05.08 18:39 "Merge several TIFFG4 images", by Oliver Geisen
2010.05.10 04:04 "Merging multiple Group4 compressed TIFF files", by Richard Nolde
2010.05.11 07:00 "Merging multiple Group4 compressed TIFF files", by Oliver Geisen
2010.05.11 15:22 "Re: Merging multiple Group4 compressed TIFF files", by Bob Friesenhahn
2010.05.11 16:59 "Combining multiple G4 images into a single output image", by Richard Nolde
2010.05.11 17:33 "Re: Combining multiple G4 images into a single output image", by Oliver Geisen
2010.05.11 19:15 "Re: Combining multiple G4 images into a single output image", by Olivier Paquet
2010.05.12 16:47 "Re: Combining multiple G4 images into a single output image", by Bob Friesenhahn

2010.05.11 16:59 "Combining multiple G4 images into a single output image", by Richard Nolde

Oliver wrote:
Thank you Richard.
Yes, i want to combine several images of different size onto a bigger one,
so pointing me to tiffcrop was a good idea. After getting a bit deeper into
libtiff i guess it would be ok to read (or create) the background image (i
call it "the pasteboard") into memory, so it does not matter if the TIFF
organization was tiled or striped. Then read one image after the other an
paste the lines at the location given. Therefore i need to access the image
raster pixel in memory, calc the offset and overwrite the background image
data with the read data from each image. The order i read the images is
equal to their layer in the
pasteboard. After that i can write out the pasteboard image as a new file.

Now, is it ok (in question of speed) to use TIFFReadScanline or should I use
some lower level functions?


If you are going to make a special purpose utility and you are sure that you
will never need to access data that is compressed in ways that require
access to multiple scanlines at once, the TIFFReadScanline interface should
work fine.  My first version of tiffcrop used that interface but I changed
to a strip oriented reading approach so that I 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.

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.

My approach in tiffcrop handles tiled or strip oriented images and always
loads them into a single memory block as interleaved RGB/Grayscale/Bilevel
samples at depths from 1 to 32 bits per sample without expanding them to a
larger sample size for the intermediate processing. After manipulating the
data, the image can be written out as tiles or strips regardless of the
input formats.

The difference between what you want to do and what tiffcrop does involves
your use of multiple input files that are opened concurrently rather than
sequentially. It might be possible to add a command line option and an
alternative path through the code for opening all the files at once with
additional data structures to handle access to all of the TIFF* handles.
Most of the code that you need has a counterpart in tiffcrop that you could
adapt to deal with multiple input files by keeping track of the read offsets
into each input file and updating the write offset after each read. 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.


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.