posterize TIFF-files: how to prevent change of color-depth?

[MaxiPunkt]

Hi there,

on my computer I'm running Fedora FC27, ImageMagick version is

Code: Select all

$ rpm -qa | grep ImageMagick
ImageMagick-6.9.9.27-1.fc27.x86_64
ImageMagick-libs-6.9.9.27-1.fc27.x86_64

I'm using a BASH-script which does the following:
1) scanning into TIFF-file(s) (SANE's scanimage)
2) create multipage-TIFF (LibTIFF's tiffcp)
3) image optimization into multipage-TIFF (ImageMagick's convert)
4) convert multipage-TIFF to PDF (LibTIFF's tiff2pdf)


Beside general image optimization I want to shrink file size by using ImageMagick's option "-posterize <level>" without dithering.
The TIFF-file(s) to convert all have a color-depth of 8bit (grayscale or sRGB) in the beginning.

Resulting TIFF-file grayscale (high posterize color-level):

Code: Select all

convert +dither -posterize 64 <IN_FILE>.tif <OUT_FILE>.tif

=> color-depth will be kept at 8bit, as expected.

Resulting TIFF-file sRGB (low posterize color-level):

Code: Select all

convert +dither -posterize 8 <IN_FILE>.tif <OUT_FILE>.tif

=> color-depth will be kept at 8bit, as expected.

Resulting TIFF-file sRGB (high posterize color-level):

Code: Select all

convert +dither -posterize 64 -depth 8 <IN_FILE>.tif <OUT_FILE>.tif

=> color-depth changes to 16bit!


So for some reason color-depth will be changed from 8bit to 16bit for higher color-level values when trying to convert sRGB TIFF-files.
Option "-depth 8" unfortunately will be ignored.

Don't know for sure if described behavior of ImageMagick's convert for TIFF-files is intended, or if I possibly found a bug.

How can I workaround this problem?
LibTIFF's tiff2pdf can only handle 8bit TIFF-files!

[fmw42]

Posterize with large values makes more than the 256 maximum colors that is needed for an 8-bit palette image. Perhaps you just want to use +dither -colors X with X up to a maximum of 256.

[MaxiPunkt]

Starting point is a sRGB-image with "only" 8bits, which is (2⁸)³=256³=16,7Mio colors.
For my understanding option "-posterize 64" should reduce colors to a maximum of 64³ = 262.1444 defined color levels.

But for some reason I don't understand "convert" does increase color-depth to 16bit.
This means that the resulting image is modified to store even more colors, although the approach is to reduce amount of colors.
Moreover issuing option "-depth 8" will even be ignored. This behavior currently doesn't make sense - at least for me.

Btw. - found out that with PNG-files (8bit) it does work:

Code: Select all

convert +dither -posterize 64 <IN_FILE>.png <OUT_FILE>.png

So for me it seems that "-posterize" could be broken for TIFF-files - is it?

[fmw42]

You are starting with 8-bits per channel pixels. I thought you wanted 8-bits total per image pixels. If you are getting 16-bits on Q16 and it would fit into 8-bits per channel pixel, then just add -depth 8 to your command. Note that proper IM syntax reads the input right after convert and not at the end.

[MaxiPunkt]

If you are getting 16-bits on Q16 and it would fit into 8-bits per channel pixel, then just add -depth 8 to your command.

As already mentioned above - this currently does _not_ work for TIFF-files for whatever reason!

Note that proper IM syntax reads the input right after convert and not at the end.

Unfortunately this doesn't make any difference as well.

Did I find a bug, or is it a feature I currently do not understand?
Any suggestions to solve the problem? (not using TIFF is not an option for me )

[fmw42]

try

Code: Select all

convert image.tif +dither -posterize 64 -depth 8 -type truecolor image2.tif

Seems to work for me using IM 6.9.9.34 Q16 Mac OSX.

[MaxiPunkt]

Cool, indeed this works for me as well - seems this could be a workaround for the problem for now.

But still the question is:
Why is it necessary to add all these options to keep color-depth at 8bits for TIFF-conversion using "-posterize"?
I currently would expect to get same result without the need to add all this...

[fmw42]

Sorry, I do not know. One of the developers would need to explain?

-depth 8 is needed if you are on a Q16 IM install otherwise it defaults to 16-bits. I am not sure why -type truecolor is needed for tif when not for png, for example. I suspect that is just the way the liftiff delegate works. It needs the extra flag to make it 8-bits and not 16-bits.

[snibgo]

Why is it necessary to add all these options to keep color-depth at 8bits for TIFF-conversion using "-posterize"?

What do you mean by "color depth of 8 bits"? Is that bits/channel/pixel, or bits/pixel total? How are you measuring it? With exiftool or similar, I hope. IM won't tell you how the data is stored in the file.

Tiff has more storage modes than PNG. One of these is 16 bits/pixel (total, not per channel). Perhaps this is what you are seeing.

[MaxiPunkt]

Converting with "-posterize 8" color-depth will be kept at 8bit w/o additional parameters.
Converting with "-posterize 64" color-depth will be kept only at 8bit when additionally issuing "-depth 8" and "-type truecolor".

So IMHO behavior for TIFF-conversion currently is inconsistent, isn't it?


With color-depth being at 8bit I tried to adapt common IM-terms, which is 8bit per channel.

How I am "measuring" this problem:
tiff2pdf succeeds with original 8bit-TIFF generated by "scanimage" and "tiffcp".
tiff2pdf fails with resulting 16bit-TIFF of "convert" complaining that 16bit TIFF's are not supported.
Other applications (Okular, Gwenview, KuickShow) are not able to open/display resulting 16bit-TIFF as well.
File-size increases after convert operation.

Just to illustrate the problem:

Code: Select all

$ identify testit-orig.tif
testit-orig.tif[0] TIFF 974x886 974x886+0+0 8-bit sRGB 2.5259MiB 0.000u 0:00.000
testit-orig.tif[1] TIFF 974x886 974x886+0+0 8-bit sRGB 2.5259MiB 0.000u 0:00.000

$ tiff2pdf testit-orig.tif -o testit-orig.pdf

Code: Select all

$ convert +dither -posterize 64 testit-orig.tif testit-new.tif

Code: Select all

$ identify testit-new.tif
testit-new.tif[0] TIFF 974x886 974x886+0+0 16-bit sRGB 65536c 3243290B 0.000u 0:00.000
testit-new.tif[1] TIFF 974x886 974x886+0+0 16-bit sRGB 65536c 3243290B 0.000u 0:00.000

$ tiff2pdf testit-new.tif -o testit-new.pdf
tiff2pdf: No support for testit-new.tif with 16 bits per sample.
tiff2pdf: An error occurred creating output PDF file.

[fmw42]

As I said above:

Code: Select all

I suspect that is just the way the liftiff delegate works. It needs the extra flag to make it 8-bits and not 16-bits, perhaps depending upon the number of colors.

[snibgo]

tiff2pdf ... 16 bits per sample.

I suspect this is the 16 bit (total) per pixel TIFF format. What does exiftool say about the file? Under "Bits per sample" does it say "16" or "16 16 16"?

[MaxiPunkt]

Code: Select all

$ exiftool testit-orig.tif | grep "Bits Per Sample"
Bits Per Sample                 : 8 8 8

Code: Select all

$ exiftool testit-new.tif | grep "Bits Per Sample"
Bits Per Sample                 : 16

Code: Select all

$ exiftool testit-new2.tif | grep "Bits Per Sample"
Bits Per Sample                 : 8

[snibgo]

So, does that answer the question? testit_new is stored with 16 bits/pixel total. But you need 3x8 bits (ie 24 bits total) per pixel, and the way to force three channels is with "-type truecolor".

[MaxiPunkt]

O.k. thank you two guys for your amazingly quick replies to my questions + finding the solution for my problem.

So my conclusion is that ImageMagick currently tries to store output into a rare (but probably valid) format (16bit/total) which causes all the trouble.
I would appreciate if ImageMagick would keep the 8bit per channel (=24bit/total) in the near future (file-size even is smaller, then), but for now I'm happy using "-type" option to workaround this issue.

Cheers!