You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Octree mapping is used to generate a well-known color organization: by knowing the RGB number a color represents, we know where to look in the color map without having to iteratively search one by one. The Octree mapping is better than a simple listing of consecutive indices since it would take a lot of memory to achieve the same thing without data loss.
Octree mapping is also used to accomplish another function: creating a suggested color palette by the sprite itself. In this case octree mapping is used as an intermediate step to achieve the final color palette.
Why is needed to keep on memory a color map in INDEXED color mode?
When pasting a new "source" RGBA image (for example) into a "destination" INDEXED sprite. A quantization process must be run on the entire “source” image:
Iteratively each pixel of "source" RGBA image is converted to an index according to its color by looking at the octree mapping. Currently, if the color does NOT belong to the palette of the “destination” sprite, the mapping will return an index that was generated from approximations in doc::OctreeNode::fillOrphansNodes function based on the "destination" palette, this is thought this way for speed performance reasons.
However, it would be good to venture NOT to fill the empty spaces of the mapping with fillOrphansNodes, and see if it is convenient to add each new color of the “source” sprite to the octree mapping. This will slow down the conversion but it will get a better quantization of the “source” image.
Background:
Octree mapping is used to generate a well-known color organization: by knowing the RGB number a color represents, we know where to look in the color map without having to iteratively search one by one. The Octree mapping is better than a simple listing of consecutive indices since it would take a lot of memory to achieve the same thing without data loss.
Octree mapping is also used to accomplish another function: creating a suggested color palette by the sprite itself. In this case octree mapping is used as an intermediate step to achieve the final color palette.
Why is needed to keep on memory a color map in INDEXED color mode?
When pasting a new "source" RGBA image (for example) into a "destination" INDEXED sprite. A quantization process must be run on the entire “source” image:
Iteratively each pixel of "source" RGBA image is converted to an index according to its color by looking at the octree mapping. Currently, if the color does NOT belong to the palette of the “destination” sprite, the mapping will return an index that was generated from approximations in doc::OctreeNode::fillOrphansNodes function based on the "destination" palette, this is thought this way for speed performance reasons.
However, it would be good to venture NOT to fill the empty spaces of the mapping with fillOrphansNodes, and see if it is convenient to add each new color of the “source” sprite to the octree mapping. This will slow down the conversion but it will get a better quantization of the “source” image.
Tasks:
1. Improve color quantization (
changeadd others color distance criteria inside findBestfit() function by other proven color distances like LinearRGB, CIELAB, CIEXYZ), see about adding different quantization methods (not present in the UI yet). Related: Improve the octree quantization method using better Euclidean color distance #2787,2. Discard the doc::OctreeNode::fillOrphansNodes implementation of filling empty branches of the octree. Related: Crash converting RGB sprite to indexed with octree #3337.
3. Implement in UI the selection of color quantization methods (Preferences > Experimental > Quantization method: Linear RGB, CIELAB, CIEXYZ). Related: Improve the octree quantization method using better Euclidean color distance #2787
4. Check that the conversion preview works correctly during the Sprite > Color Mode > More Options… dialog when an RGB>>INDEXED conversion is wanted.
The text was updated successfully, but these errors were encountered: