bad alpha in -remap from RGBA8888 to RGBA4444

[davecazz]

Hello, trying to use image magick to do some 32 to 16 bit color reduction.

it seems to be doing some really weird dithering with the alpha channel though.

here is the original image



I have a RGBA4444 color table image



I use the following command line for the remap

convert uranus.png -remap imagepalettergba4444.png RemapUranus.png

here is the result



I then tried to turn off dithering, and got this result

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



any help out there? I would love to use image magick for this step in the process so in the future I can start playing around with custom ordered dither patterns

[fmw42]

I am not sure what you expect, but the last result looks about right to me, since you have reduced the number of colors from millions of colors to 961 32-bit colors (including only a few graylevels in the alpha channel). So you should expect banding. However, I will defer to the IM developers as they have more expertise than I. I can reproduce your results for the latter image.

see http://www.imagemagick.org/Usage/quantize/

[davecazz]

I can see how you might think that at first glance but there is a problem in the alpha channel. the alpha channel has been reduced improperly.

if you load it into a visual image editor, you can see that the original image is pretty much 100% solid alpha in the middle, 0% outside of the graphic, and only deviates along the edges ala anti-aliasing.

however, both images have a lot of 0 < alpha < 100 in the middle of the image which is causing extra banding to occur.

here are two result images from pvrtextool that illustrate how its supposed to look.

no dither version



dither version looks pretty close to original

[fmw42]

I will admit that I am not an expert on colortable remapping. So you could be right. I will bow out and let the IM developers reply.

[davecazz]

the last two images are remapped with a different tool called PVRTexTool that is meant to create textures optiized for mobile graphic hardware.

they are both doing the same operation, or rather I'm trying to do the same operation with ImageMagick. PVRTexTool has an option to just reduce an image from RGBA8888 or RGBA4444 with or without dithering and without needing me to add a color table. but the dithering is not supported in the command line so I cant add it to my build process.

Also, in my last post, the second image is not the original image, it's actually a dithered RGBA4444 image based on the original RGBA8888 data achieved with PVRTexTool.

I may be using the wrong function to accomplish this in image magick though.

I read through http://www.imagemagick.org/Usage/quantize/ pretty carefully before I started and I picked up the following two sections.

http://www.imagemagick.org/Usage/quantize/#remap seems to indicate the function to use if you want to reduce an image to a known set of colors.

http://www.imagemagick.org/Usage/quanti ... t_colormap seemed to indicate a way to create a RGB565 colormap that could be used in the function above. it suggests using an ordered dither although it's not abvious how to incorporate alpha dithering with an ordered dither.


I hope I explained what I am doing properly, please ask me if I can add detail somewhere.

[fmw42]

Your color table, looks a lot like a HALD color transformation image. Look at http://www.imagemagick.org/Usage/color_mods/#hald-clut
http://www.imagemagick.org/Usage/color_ ... ald_limits


However, I have not tried using it with transparency and don't know to what extent the IM Hald and -hald-clut support transparency. The latter link talks about that. But you could try it or wait for the IM developers to respond.

[davecazz]

yea, it's very similar in terms of the color image, those images are 3d color lookup tables. R,G and B being the dimensions. my color table would be classified as a 4d table because it adds alpha.

the use the the table is a bit different though. with the 3D color mapping on that page, they are looking up each RGB value in the identity HALD, finding the pixel location of that color, and then replacing the color in the image with the color found at the same location in the HALD you want to use for the transformation. there isn't necessarily a reduction of colors in the result image unless the HALD was designed to do that. but even in that case, there would be no dithering because you just do a one-to-one color lookup and replace.

What we are trying to do her,e is reduce the number of colors in the source image. In the past we would want to reduce it to a 256 color palette for use in a animated GIF but now-a-days we just need to reduce the image from a 32bit pixel format (RGBA8888) to a 16bit color format (RGBA4444, RGBA1555, RGB565). the Quantization step isn't required because hardware doesnt handle palettized formats anymore. you pretty much just have to reduce the number of bits that represent your color channels and dither it to reduce color banding.

[davecazz]

oh yea, and the reason why the image looks like that is because you are just doing a nested for loop for red, green, and blue from 0 to 255. you see a step each time the inner color loops back to 0.

[fmw42]

from a 32bit pixel format (RGBA8888) to a 16bit color format (RGBA4444, RGBA1555, RGB565)

Well, I will show my ignorance here, but what do these different number formats mean? Is the number the number of bits of rgba each? Apparently from what I can find it has to do with iPhone (or other cellphone displays).

It would seem that this is more relevant for PNG format and the PNG developer for IM would likely need to comment here if there is any built-in mechanism.

More importantly is there a reference to how your other tool is doing the color reduction from the generated color table image? If it is just a reduction of color bits, then Anthony could probably tell you how to do that in IM, when he gets online. The dithering aspect is out of my league, but he is likely to know more about that than most others here.

[davecazz]

that's exactly right. RGBA8888 means 8 bits red, 8 bits blue, 8 bits green and 8 bits alpha. this is the color format of a typical 32bit color pixel.

RGB565 represents a 16bit pixel value with 5 bits red, 6 bits green, 5 bits blue but no alpha.
RGBA5551 is also 16 bit but you remove 1 bit from green and apply it to alpha, alpha can only be on or off in this format.

it's not so much png development but game development. png happens to be a useful file format but this applies to any 32 bit file format. BMP, TGA, etc.

you are right though, we happen to be working on an iphone game but like I said, this also applies to pc and console games.

there isnt really a reference for how they are doing it. in the ui there are just radio buttons where you select the color format you want to convert to and a checkbox that says whether you want to dither or not. I believe they use Floyd Steinberg dithering.

this is something the developer could answer pretty quickly, I'm sure there is some option that I am missing or the tool just doesnt handle alpha remapping with that many colors.

[fmw42]

I have sent a message to Anthony to look at this topic. I am not sure if he will be online tonight or not. But he will answer if he can when he gets caught up.

The IM developers are working hard now on the new IM 7 system, though it will still be some months before an alpha is ready. So they are a bit pre-occupied, but do look at the forum generally every day.


If you are good with math and bit operations, you can probably generate the non-dithered versions using -fx. See http://www.imagemagick.org/script/fx.php I believe that there was some relatively recent topic on doing bit reduction. You can search the forum and see if you can find that. It might give you some clues. I don't know of any specific function in IM today that does that, but I cannot say that for sure. You can look at the list of IM functions at:

http://www.imagemagick.org/script/comma ... ptions.php
http://www.imagemagick.org/Usage/reference.html
http://www.imagemagick.org/Usage/

-depth generally does not give you the flexibility to choose how many bits of color to use for each channel, but it allows you to choose the depth you want and the choices are format dependent. So I doubt that this is what you want.

[davecazz]

sure, thanks for your help

[fmw42]

Sorry we cross-posted. I don't know if you saw my edited comments about using -fx above. If so, ignore this message.

[davecazz]

thanks, I'll check that out. for the most part, I can reduce the bit depth of colors in an image with python and PIL pretty easily, its the dithering I'm trying to get use of. even with dithering, the guys at PVRTexTool are planning a build that exposes that to their command line version fairly soon. my main goal is to get to the custom ordered dithering that only ImageMagick can do. I would love to explore http://www.imagemagick.org/Usage/quanti ... _threshold and see if I can do a version of our game with an old school retro dithered look.

[fmw42]

This might be relevant for future reference:

viewtopic.php?f=2&t=20089


This was, I believe, the link I was searching for:

viewtopic.php?f=2&t=17425