Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Octree mapping review and improvements #3394

Open
1 of 4 tasks
Gasparoken opened this issue Jun 24, 2022 · 0 comments
Open
1 of 4 tasks

Octree mapping review and improvements #3394

Gasparoken opened this issue Jun 24, 2022 · 0 comments
Labels
feature Feature request, or something should be improved logic medium priority time-5 ui
Milestone

Comments

@Gasparoken
Copy link
Member

Gasparoken commented Jun 24, 2022

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:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature Feature request, or something should be improved logic medium priority time-5 ui
Projects
None yet
Development

No branches or pull requests

1 participant