2008.11.21 23:51 "Re: [Tiff] Re: RGB to palette images", by Kevin Myers

FYI, I just tried using tiffmedian combined with Windows OS file compression on the scanned image of a paper version of a similar document to the computer generated image file previously tested below. Results were somewhat less favorable, but not really too bad considering the much greater color variation in the scanned image.

Using tiffmedian with both 16 and 32 colors resulted in poor color reproduction. I had to use 256 colors to get decent colors from the scanned image. Palettizing combined with file compression shrank the original 24 bit uncompressed image from 828682 KB to 110980 KB, a compression ratio of approximately 7.5 to 1. For comparison, the compression ratio on the computer generated document was 17.5 to 1. Looks like a smarter color reduction algorithm may still be necessary for scanned images.

s/KAM

> Frank Warmerdam wrote:
>

>> In the interest of completeness, the normal libtiff command for this >> task is tiffmedian. It does not require holding the whole image in RAM.

>>
>> However, it will not exactly preserve the color list from an RGB image
>> with
>> a very limited number of unique colors (as described) so it is likely not
>> a great solution for the problem.
>>
>
> Actually Frank, that may turn out to be exactly what I needed. I tried

> tiffmedian on one of my fairly large images, and it seemed to produce > excellent results and was very fast.

>

> By manual count just looking through the original image, I counted 16 > unique colors. I did not attempt to count the distinct colors using a

> program. Here is a summary of the output file size and color reproduction > results using different values for the number of color map entries and

> compared to several variations on the original image:

>
> original image, uncompressed, 302291 KB, original colors (8/24 bit RGB,
> unprocessed)

> original image, LZW tiff compression, 22611 KB, original colors (8/24 bit > RGB, tiff compression only)

> original image, LZW OS compression, 37692 KB, original colors (8/24 bit > RGB, OS compression only)

>
> tiffmedian, 16 colors, uncompressed, 100726 KB, fair color reproduction
> tiffmedian, 16 colors, LZW OS compression, 17112 KB, fair color
> reproduction
>
> tiffmedian, 32 colors, uncompressed, 100726 KB, excellent color
> reproduction
> tiffmedian, 32 colors, LZW OS compression, 17228 KB, excellent color
> reproduction
>
> tiffmedian, 256 colors, uncompressed, 100726 KB, excellent color
> reproduction
> tiffmedian, 256 colors, LZW OS compression, 17232 KB, excellent color
> reproduction
>

> Since my legacy app can't deal with LZW tiff compression, the second > option listed above is out, and all of the uncompressed images are far too

> big to be practical considering current laptop hard drive sizes and the > number of these images that I must have available on a single laptop

> (thousands!). Using Windows OS file compression alone drastically reduced > the file size down to about 38 MB. But using Windows compression combined

> with palettizing the image further reduced the file size by a signifcant > amount, down to about 17 MB. The 16 color palettized representation

> wasn't too good, but using either 32 colors or 256 colors allowed the file > size to be reduce to almost the same level with excellent color

> reproduction.
>

> So, it looks like using tiffmedian with 256 colors and Windows file > compression should be a perfectly adequate solution for the color images

> that I receive which have been programmatically generated using a > relatively small number of colors.

>

> Now onto my next problem involving scanned images of similar documents > that contain a much larger number of colors due to ink and paper

> variations, scanner noise, scanner resolution limits, color transitions, > etc...

>
> Thanks again!!!
>
> Kevin M.