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

Contact

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



Valid HTML 4.01!



Thread

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.12 16:47 "Re: Combining multiple G4 images into a single output image", by Bob Friesenhahn

On Tue, 11 May 2010, Oliver Geisen wrote:
>>
> 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.

Unless you do something really silly, the Group4 compression in 
libtiff will dominate the time for what you will be doing since it is 
much more complex.

Look up tables may be useful for older CPUs but on newer/modern CPUs, 
a direct algorithmic approach is usually best since it avoids memory 
access latency and cache thrashing.

Bob
-- 
Bob Friesenhahn
bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/