2008.11.21 21:27 "[Tiff] Re: RGB to palette images", by Richard Nolde

Kevin Myers wrote:
> Hi Richard,
>

> Thanks for the offer, but due to the size of some of my images, I > don't think that tiffcrop would be a good solution if it requires

> loading entire images into memory. For some of the images that I work > with, the entire image will not fit into available address space on a

> 32 bit machine, and unfortunately I am limited to working under a 32 > bit Windows OS at the present time.

>

The virtual address space should be at least as big as the size of the largest TIFF image 2^32 or 4 GB and you need BIGTiff to load anything larger anyhow since standard TIFFs use 32 bit offsets into the file and will bomb over that size.

> See the reply that I just wrote to Bob Friesenhahn and copied to the > tiff list as to why color reduction really isn't an issue for the

> particular images that I am working with...
>

Tiffcrop reads images by scanline or tile currently. It is just that to image rotations, you make your life much simpler if you have the whole image in memory instead of thrashing the disk every time you need another row or column from the image. For many operations, it would be entirely possible to read a scanline process the data and then write the scanline. Your case is the simplest possible if the images are not tiled, so you could make a stripped down version of tiffcrop aka tiffresample by stripping out all the unneeded stuff or if you want to get very basic, write a simple program that 1) Opens the TIFF file

2) Reads each scanline to extract the data and add entries to your palette structure, building a histogram if you would every need more than 256 entries, etc.

3) Rewinds the file and converts it one line at a time 4) Writes out the new palettized data

You cannot do it in one pass because the entries in a palettized image are indices into the palette, which you have not built unless you have seen all the entries. In the special case that you know all the possible values ahead of time, you could do it in one pass. You could also do it in one pass if you knew in advance the mapping you wanted to use between the input values and the output values, eg for a USGS topo map, there are only a fixed number of possible colors and you can be sure that only a specific set of RGB values will appear in the data stream. In that case, build you palette table at the top of the code, and convert RGB triplets to palette indices on the fly.

If you want to link with a new version of LIBTIFF, download the CodeBlocks IDE with mingw tools. It gives you an easy way to build projects and the GNU tools needed to examine executables. Since you don't have source code or object code for the legacy app, you cannot relink it, but you could use nm to dump the symbols in your original program and see if there are any paths or version dependencies coded into the executable. Codeblocks would allow you to rebuild the libtiff DLL from a new version of libtiff. I don't do a lot of Windows programming, so I don't know how the entry points are resolved at runtime, but you might be able to load the program into a debugger and see what OS calls it is making to find the DLL and/or where it is looking by stepping through the program and watching the calls in the stack frames. It could be as simple as putting the new DLL where the program is expecting to find it. Try running the strings command on your executable and looking for paths.

> For those images that DO fit into memory, and DO require color

> reduction, I can use the existing GraphicsMagick utility for this > purpose. However, the color reduction algorithms used by

> GraphicsMagick produce much less than ideal results on many of my > *scanned* images (which do contain a large number of colors). I have

> been doing some preliminary investigations into a potentially superior > color reduction algorithm, but don't yet have anything concrete.

>
> Regards,
> Kevin M.
>
>
> ----- Original Message ----- From: "Richard Nolde" <nrichard8@qwest.net>
> To: <kmyers1@clearwire.net>
> Sent: Friday, November 21, 2008 13:25
> Subject: RGB to palette images
>
>
>> Kevin,

>> Tiffcrop is the closest thing to what you want but it too loads the >> entire image into memory, at least in the current implementation. If

>> you wanted to write a function to do the conversion, I might be able >> to add it to tiffcrop at some point. Here are a few things that come

>> to mind. Since an 8 bit palette is limited to 256 entries, you have >> to decide which 256 values you will use in your palette out of 256 *

>> 256 * 256 possibilities in a 24 bit RGB image. There are lots of ways >> to approach this but most likely you will need to scan the entire

>> image and decide what the most frequently used combinations of RGB >> values are and build a palette from them. Then you have to decide

>> what to do with the rest of the RGB values. Somehow, you have to >> assign them to the "nearest" palette entry, whatever that means.

>> BTW, TIFF palettes are usually 16 bit rather than 8 bit. See the man >> page for pal2rgb for going the other way. TIFF supports many color

>> spaces and you would have to deal with them as well. The task is >> non-trivial.

>>
>> Richard Nolde

I'm looking for a command line utility with a version that runs under Windows which can convert a 24 bit color TIFF image to an 8 bit palettized TIFF image. But I need something that works similar to tiffcp that does the processing without loading the whole image into memory at once. I am aware of the very useful GraphicsMagick and ImageMagick utilities, but they both load the whole image into memory, which can be quite slow and somewhat problematic for some of the extremely large images that I work with.

Any suggestions?

>>
>
>
>