LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
July 2007
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
Thread
2007.07.20 04:26 "Bit shifts vs lookup tables", by Richard Nolde
1. Re: Re: Bit shifting and rotating of TIFF images (Chris Cox) > That could be on an Intel processor with slow shifts (worst on the Pentium > 4). > > On most processors, the shift would be considerably faster than a memory > lookup. > > Chris > It is also worth noting that a general purpose program like tiffcrop is meant to run on a wide variety of processors and memory architectures whereas you can code anything you want if you are only going to run on a specific machine. When I began working with libtiff, I ran a Digital Equipment Corp (remember them?) Vax which was notoriously slow with tight loops. It was a CISC machine, and there was probably a single instruction to shift bits in a whole region of memory, but it would have required coding in the native machine language to take advantage of it. Given that one of the reasons people use TIFF is for cross platform portability, I chose to use the resources available with ANSI C. Look at some of the extended macros that were used in the original code to support the DEC VAX floating point formats. The DEC VAX does not support IEEE floating point, but Karsten Spang provided a set of macros that converted from IEEE to DEC D-Float and G-float. I used these and other similar constructs to convert data from a 24 bit Bruker ASPECT spectometer with a 48 bit floating point format to DEC VAX float and IEEE floats among other things. You could build a series of lookup tables, one table for each of the 255 possible pairs required for a given bit shift as dictated by the position in the byte where your data starts, eg, one for a one bit shift, another for a 2 bit shift, etc. Once you know the number of bits that you will be masking and shifting, you would access only that lookup table for all the bytes that are shifted by that number of bits. Given that you still have to mask and shift to get the bits to be reversed and it takes two memory accesses to the lookup table for each reversal, it might not help much. Alternately, you could mask and shift the parts of the two bytes and combine them into one aligned byte which you then reverse with a single lookup table and write out to the new image. I'd be curious to compare your final results on G3/4 encoded images when your target location is not byte aligned with what you would get with tight loops to do the reversing. Richard Nolde