You have alpha support but the alpha is not part of the indexed palette. This means the indexed palette is saved separate from the alpha quantization. If I need an alpha as part of the indexed palette, I cannot merge the RBG indexed palette into the same palette with alpha without a special tool which would dither the image to make room for RGB + alpha versions of the color (and thus destructing the original palette).
What I would like to see is an option to have the indexed palette be RGBA so I can pick the RGB and the A on that palette entry. This would allow features like palette cycling to even include alpha, and indexed PNG does support alpha in the indexed palette.
indeed, indexed PNG supports RGBA palette entries. The disadvantage of this approach that, e.g. to have just 4 alpha scales along with “red” you are occupying 4 palette entries etc. .
Can you tell more about the use cases? Where will you use such images/animations?
While that is a disadvantage, it does allow you to have a single indexed PNG with alpha instead of having two different images. An example use case could be distributing an indexed color PNG with alpha for an embedded system or server where bandwidth and storage may be a limiting factor. Another use case is effects, e.g. a glowing effects using palette color rotations with alpha enabled between layers. This can be achieved by having an alpha attached to the glow so the intensity and alpha mixture of the top layer and background without ever having to adjust the image or loading new alpha bitmaps. This kind of trick was well used on the Amiga, except AFAIK the Amiga had no indexed alpha capability.
FYI - other pixel graphic programs can attach alpha to palettes, e.g. Aseprite (though Aseprite is lacking useful features of Pro Motion).
As for systems that use indexed RGBA palettes, I am not familiar with any that currently exist. However, I have early access to an entirely new system which would make use of that indexed color method. Due to architecture constraints, splitting the alpha into another map is not a feasible solution (as it would require memory look-ups on “Alpha” separate from the indexed color which cannot work in the hardware pipeline). Being able to attach alpha directly to the palette entry would be extremely helpful as well as being able to recommend an off the shelf tool that has the all the necessary features. Otherwise, developers would have to be program alpha manually in code (and artists and coders are not always one and the same).
If the alpha map and alpha in the palette have an option to be linked (i.e. drawing from the palette sets the alpha of the map) then that should provide the necessary editing feature. Or if the alpha value was exclusively attached to indexed color being painted that would work as well (i.e. where the color and alpha are painted together simultaneously). I’m not sure how easy this would be in your drawing engine but that’s our use case.
Understood
I’m adding this request to my list, but at the moment I can’t do any estimation about when this can be included.
A quite simple, intermediate step could be to offer the PNG palettized alpha transparency file i/o. Today you can only use the 32bit PNG format to save alpha per pixel from within PM as you already noticed. Of course the limit of 256 RGBA combinations are exceeded quickly when you are not forced to assemble the RGBA palette on your own and use per pixel alpha values, but it might work for most of the cases. Also, the palette would have to be generated, based on all existing RGB/A combinations in the image/animation, so it won’t be the same palette used when editing the image.
Would it make sense to offer i/o for this format without having the real RGBA palette management?
Thanks! Much appreciated. This is the only lacking “must have” feature for us. Hopefully time will allow before we have to start on the image work.
We did consider using 32-bit ARGB at first then flattening to a palette. Unfortunately using a pure 32-bit wouldn’t have the desired level of control that using a 256-entry palette would. There are currently several post-processing tools which can perform 32-bit ARGB color to 256 indexed color (with alpha and dithering) translation. However, the translation process is mostly at the mercy of the post processing tool and the palette can get shifted around. This makes doing animation effects difficult if we can’t have entire control over the palette. We’d need to write a custom tool which would have to coordinate color palettes across many images and that would be even more difficult (especially factoring existing tools do a lot of clever dithering which would be difficult to coordinate across images).
Linking alpha to the indexed palette entry gives the artist has complete control over how the alpha indices are chosen. This allows them to make intelligent and artistic decisions on which colors are necessary to produce the desired effect in a way tools could not and share palettes across images. Furthermore, if the application in question uses fewer than 256 colors (e.g. 16) then not having complete control of the resultant palette could end up causing issues with palette mapping on tiles and sprites.
How many levels of alpha would you require?
Also, there is a file i/o plugin interface. If you have some developer at hand then he/she could probably easily create a file export that takes care of ordered palette handling.
If colors and alpha are limited to e.g. 16 colors and 8 alpha values then the following approach could work:
The project is set up to use 3 bits for the alpha channel resulting in 8 possible alpha values.
The artist works just on the color palette without thinking about any alpha. If he wants to use alpha then he/she can use it freely. As said before there are only 8 levels and PM will take care of not using more.
The file exporter now always creates an indexed ARGB-palette where for every color in the palette (16) all possible alpha values (8) are joined. So, e.g. if the first color is FF0000 (red) then the first 8 entries are red along with 7 different alpha values: 20FF00000, 40FF0000… and then the next color is used. The 8th combination would always have zero alpha, so it can/must be omitted.
Of course this only works if number of colors multiplied with number of possible alpha values (-1) does not exceed 255 (256th entry is zero alpha with white 00FFFFFF).
If the number of values exceeds this limit then it could also work to just use the color/alpha combinations that are actually in use. The basic palette order is then still there.
This way it might free your artists from the burden to always fiddle around with color/alpha combinations manually.
During runtime of your game it would be simple to check where a color (including its alpha combination variations) starts and ends, so you could even use cycling techniques at runtime (though only color based within PM where the engine also uses alpha).
The dynamic palette creation (built from only those ARGB combinations that are used instead of using every alpha with every color) would still create different palettes, but this would also be the case if you exceed the limit manually over all image/animation assets being created.
Does it make any sense or did I completely miss the point?
Can you tell some more about the specs (color and alpha transparency) that the engine/system will use?
Ideally, the palette could contain up to 256 levels of alpha (where each color could be assigned an alpha value). Obviously if all 256 levels were present in the palette, a very limited set of color choices would exist since each alpha is paird with a color in the palette.
Your suggestion would work in the specific case of 16 colors with 8 alpha values. However, I don’t think that’s a typical use case. For example, a very simple use case could be anti-aliased lines. A sprite with 15 colors could have a solid black outline. Color 16 could also be made black but have alpha = 0.5. Then it could be added to the outline to make it appear anti-aliased to better blend with the background. In that example, the artist having control over what the alpha value is for each palette entry is critical. Another case could be where 8 different sprites are each 16-colors but share the same 256 color palette. Using the method you described above would require a different palette per sprite or a different layer (which would be another palette).
While it would be possible to also create an alpha gradient using this suggestion, that’s not the primary use case.
Another use case example would be to create a glowing particle with bloom. Instead of implementing the bloom itself as a post-processing filter, it could be faked by blending a “glow” with decreasing alpha. The artist may choose to have the alpha decrease exponentially or logarithmically instead of linearly. In this case a gradient wouldn’t work. Depending on how complexity of the glowing object, it may be possible to include the center colors and the bloom fade in just 16 palette entries.
I think that your suggestion would work for a game running in an engine like Unity, but it wouldn’t work on hardware with limited CGRAM. The system has a limited but somewhat large CGRAM cache (around 4096 RGBA8888 colors). Not every layer has access to every color. Having multiple alpha levels of the same palette would greatly reduce the number of colors that could be used by the system. The 8-bit alpha value is treated like just another color channel until it reaches the blending stage. At that point the blending can perform color math by factoring alpha (i.e. what photoshop / gimp can accomplish). In normal blending mode, this does “result = A*layer + (1-A)*buffer”. A shift is done thus A=0xFF is treated as 1.0). A 1-bit alpha can still be accomplished by setting the alpha channel to 0x00 or 0xFF for fully solid or fully transparent. I’m not sure if that answers your question though.
