Legacy ImageMagick Discussions Archive

and I was just thinking that another way to go about it is to separate the alpha from the RGB channels. dither the alpha channel as if its an 8 bit gray scale image, then apply that to the RGB reduced color image.

about the two articles.

this one talks about quantization, this applies to determining which colors to use for a paletized version of the graphic. so if I do a 256 color image and the image tends to have a lot of red in it, a good quantization algorithm will put more red colors into the palette or use the science behind a human's visual perception to make sure we dont choose colors that users would not notice.
viewtopic.php?f=2&t=20089

the other article just doesnt address dithering.it's just clipping the colors down to a set bit value. I think this is good for creating a color table. but it's weird, it also doesnt handle alpha, or doesnt seem to at least.

Well sorry I cannot help much further. I hope Anthony gets online later and can help you more.

To get color reduction to ignore alpha use the special setting -quantize transparent

See http://www.imagemagick.org/Usage/quantize/#color_trans

Hey Anthony,

thanks for responding. the question is actually at the start of the post. I'm not doing color quantization. just -remap using a color table image.

and I just tried it with -quantize transparent and it removed the alpha channel in the resulting image.

You can always extract the alpha channel, process the rgb channels without the alpha and then re-attach the alpha channel, using parenthesis processing and clones. However, I am not really sure that is what you want to do.

yea, I will do this as a last resort. there are many textures I have to process during the build phase, so getting it down to a single operation would be first choice.

Sorry for the very fast reply at first....

Note the reason your dither came out bad was that the current dither method is not actually selecting the nearest color from the color cube, but making a fast selection. This is known problem and a real pain. Add to that the psuedo random nature of e-dithers and you get a rather messly looking result.

Actually 'map' actually looks more like a HALD image to me, mathematically generated?

If you are using 'level colors' then you may like to use -ordered dither instead, which has built in level handling. And would probably work better than a psuedo-randomized error diffusion dither!
http://www.imagemagick.org/Usage/quanti ... red-dither

Hmmm try this...

Code: Select all

   convert uranus.png  -channel RGBA -ordered-dither checks,4 +channel uranus_od.png

Other threshold maps like 'o4x4' will spread the dither pattern a bit more making a smoother result. Actually using 'o8x8,4' produces a rather nice result! with only 4 levels of colors. Note if you mean 16 levels (2^4) then use a value of 16.

NOTE: if your image is sRGB (not linear) convert it to linear first before appling the ordered dither.

davecazz wrote:and I just tried it with -quantize transparent and it removed the alpha channel in the resulting image.

If it did you have found a bug!!!!

this is the command I sent,

convert uranus.png -quantize transparent -dither None -remap imagepalettergba4444.png RemapUranusNoDither.png

this got rid of the alpha channel.

actually my bad, I didnt see your edit on your message. going to try that out now.

anthony wrote:Actually 'map' actually looks more like a HALD image to me, mathematically generated?

yea, I created it in python, just 4 nested for loops iterating through all the possible values of RGBA

anthony wrote:Hmmm try this...
Code: Select all
   convert uranus.png  -channel RGBA -ordered-dither checks,4 +channel uranus_od.png
Other threshold maps like 'o4x4' will spread the dither pattern a bit more making a smoother result. Actually using 'o8x8,4' produces a rather nice result! with only 4 levels of colors. Note if you mean 16 levels (2^4) then use a value of 16.

Some of those options look pretty trippy, although the alpha is not coming through properly. look like there are only two alpha values in the resulting image. 100% and 93%, the 93% values should be 0, and there should be an alpha gradient within the planet glow area.

anthony wrote:NOTE: if your image is sRGB (not linear) convert it to linear first before appling the ordered dither.

no, it's linear.

take a look at these two images.

this is the original

this is actually a Floyd Steinberg dither and color reduction down to 4 bits per channel. 16 grades for RGBA

This is the ideal I'm trying to get to. on an iPad or retina display you can actually tell the difference.

davecazz wrote:
anthony wrote:A
anthony wrote:Hmmm try this...
Code: Select all
   convert uranus.png  -channel RGBA -ordered-dither checks,4 +channel uranus_od.png
Other threshold maps like 'o4x4' will spread the dither pattern a bit more making a smoother result. Actually using 'o8x8,4' produces a rather nice result! with only 4 levels of colors. Note if you mean 16 levels (2^4) then use a value of 16.
Some of those options look pretty trippy, although the alpha is not coming through properly. look like there are only two alpha values in the resulting image. 100% and 93%, the 93% values should be 0, and there should be an alpha gradient within the planet glow area.

Yeah.. I am not certain why the alpha is being replaced only by values of 100% and 93% That seems very weird!
I would need to get in and try to figure out just what is going wrong with that. The larger the 'levels' the more opaque the image is becoming. Could be some recent change caused by something in IMv7 (where transparency is saved as alpha values) being backported to IMv6 incorrectly (where transparency is saved internally as matte values).

It may also be the same reason we loose the transparency with an e-dither! as was previously pointed out.

In fact I am seeing a lot of odd behaviours with the dither routines! For example...

Code: Select all

  convert uranus.png  -posterize 16 uranus_posterize.png

is produces blocks of gray colors! And that is something I have never seen it do before.

Legacy ImageMagick Discussions Archive

bad alpha in -remap from RGBA8888 to RGBA4444

Re: bad alpha in -remap from RGBA8888 to RGBA4444

Re: bad alpha in -remap from RGBA8888 to RGBA4444

Re: bad alpha in -remap from RGBA8888 to RGBA4444

Re: bad alpha in -remap from RGBA8888 to RGBA4444

Re: bad alpha in -remap from RGBA8888 to RGBA4444

Re: bad alpha in -remap from RGBA8888 to RGBA4444

Re: bad alpha in -remap from RGBA8888 to RGBA4444

Re: bad alpha in -remap from RGBA8888 to RGBA4444

Re: bad alpha in -remap from RGBA8888 to RGBA4444

Re: bad alpha in -remap from RGBA8888 to RGBA4444

Re: bad alpha in -remap from RGBA8888 to RGBA4444

Re: bad alpha in -remap from RGBA8888 to RGBA4444

Re: bad alpha in -remap from RGBA8888 to RGBA4444