bad alpha in -remap from RGBA8888 to RGBA4444

Questions and postings pertaining to the usage of ImageMagick regardless of the interface. This includes the command-line utilities, as well as the C and C++ APIs. Usage questions are like "How do I use ImageMagick to create drop shadows?".
davecazz
Posts: 15
Joined: 2012-02-08T14:43:55-07:00
Authentication code: 8675308

Re: bad alpha in -remap from RGBA8888 to RGBA4444

Post by davecazz »

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.
User avatar
fmw42
Posts: 25562
Joined: 2007-07-02T17:14:51-07:00
Authentication code: 1152
Location: Sunnyvale, California, USA

Re: bad alpha in -remap from RGBA8888 to RGBA4444

Post by fmw42 »

Well sorry I cannot help much further. I hope Anthony gets online later and can help you more.
User avatar
anthony
Posts: 8883
Joined: 2004-05-31T19:27:03-07:00
Authentication code: 8675308
Location: Brisbane, Australia

Re: bad alpha in -remap from RGBA8888 to RGBA4444

Post by anthony »

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

See http://www.imagemagick.org/Usage/quantize/#color_trans
Anthony Thyssen -- Webmaster for ImageMagick Example Pages
https://imagemagick.org/Usage/
davecazz
Posts: 15
Joined: 2012-02-08T14:43:55-07:00
Authentication code: 8675308

Re: bad alpha in -remap from RGBA8888 to RGBA4444

Post by davecazz »

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.
davecazz
Posts: 15
Joined: 2012-02-08T14:43:55-07:00
Authentication code: 8675308

Re: bad alpha in -remap from RGBA8888 to RGBA4444

Post by davecazz »

and I just tried it with -quantize transparent and it removed the alpha channel in the resulting image.
User avatar
fmw42
Posts: 25562
Joined: 2007-07-02T17:14:51-07:00
Authentication code: 1152
Location: Sunnyvale, California, USA

Re: bad alpha in -remap from RGBA8888 to RGBA4444

Post by fmw42 »

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.
davecazz
Posts: 15
Joined: 2012-02-08T14:43:55-07:00
Authentication code: 8675308

Re: bad alpha in -remap from RGBA8888 to RGBA4444

Post by davecazz »

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.
User avatar
anthony
Posts: 8883
Joined: 2004-05-31T19:27:03-07:00
Authentication code: 8675308
Location: Brisbane, Australia

Re: bad alpha in -remap from RGBA8888 to RGBA4444

Post by anthony »

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.
Anthony Thyssen -- Webmaster for ImageMagick Example Pages
https://imagemagick.org/Usage/
User avatar
anthony
Posts: 8883
Joined: 2004-05-31T19:27:03-07:00
Authentication code: 8675308
Location: Brisbane, Australia

Re: bad alpha in -remap from RGBA8888 to RGBA4444

Post by anthony »

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!!!!
Anthony Thyssen -- Webmaster for ImageMagick Example Pages
https://imagemagick.org/Usage/
davecazz
Posts: 15
Joined: 2012-02-08T14:43:55-07:00
Authentication code: 8675308

Re: bad alpha in -remap from RGBA8888 to RGBA4444

Post by davecazz »

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.
davecazz
Posts: 15
Joined: 2012-02-08T14:43:55-07:00
Authentication code: 8675308

Re: bad alpha in -remap from RGBA8888 to RGBA4444

Post by davecazz »

actually my bad, I didnt see your edit on your message. going to try that out now.
davecazz
Posts: 15
Joined: 2012-02-08T14:43:55-07:00
Authentication code: 8675308

Re: bad alpha in -remap from RGBA8888 to RGBA4444

Post by davecazz »

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
Image

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

Image

This is the ideal I'm trying to get to. on an iPad or retina display you can actually tell the difference.
User avatar
anthony
Posts: 8883
Joined: 2004-05-31T19:27:03-07:00
Authentication code: 8675308
Location: Brisbane, Australia

Re: bad alpha in -remap from RGBA8888 to RGBA4444

Post by anthony »

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.
Anthony Thyssen -- Webmaster for ImageMagick Example Pages
https://imagemagick.org/Usage/
Post Reply