search

Jas6666 / grafx2

Automatically exported from code.google.com/p/grafx2
0 stars 0 forks source link

Color reduction to a preset palette #277

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago 
On loading a 24bit picture, I suggest GrafX2 would open a panel where the
user chooses which palette to use:
- new adaptive palette (current behavior)
- adapt to current palette
- maybe, propose a "web-safe" 332 RGB palette as well (I mention it because
it has extremely fast conversion, we use it for preview)

The 2nd choice is new. It would keep the current palette before the
loading, and color-reduce the image to it.
This would be very useful to convert several images, initially in RGB, to
the same, fixed palette.
First you would create a significant sample of graphics, using the Gimp for
example. Then you could load it in Grafx2 with adaptive method to generate
the common palette. Reorder the palette as needed, then you can use the new
function to load-convert any RGB file to this palette.

Optionally, the conversion could take into account the "tag colors to
exclude" settings: Excluded colors would not be obtained by the color
reduction. It can be useful if you have a few color indices in the palette
that you use for special effects and don't want the conversion to pick
them. This part is really not mandatory, because you can always use the
color-replacer tool after conversion to change some colors globally. Or
before converting many files, load a variant of the palette where the
colors to exclude have some improbable RGB values that shouldn't be
auto-picked, like neon pink.

Original issue reported on code.google.com by yrizoud on 8 Dec 2009 at 10:19

GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago

Original comment by pulkoma...@gmail.com on 5 Apr 2010 at 8:50

GoogleCodeExporter commented 8 years ago

Original comment by pulkoma...@gmail.com on 22 Aug 2010 at 1:34

GoogleCodeExporter commented 8 years ago 
We have code for 1st and 3rd choices (used in ARM port).
The second can be done with the lookup part of the first, that uses a tree for 
fast color selection. Easily extractable but needs a color tree built from the 
palette.

The tree currently relies on properties of median cut clusters (a cluster is 
always made of two smaller ones) ; building such a tree from a given set of 
colors may not be easy.
The color lookup used for the transparency effect could also be used, but it is 
slower, as it browses the full palette for each pixel, whereas the tree only 
needs log2(palette size).

Note that once the tree is built, it could also be used to speedup transparency.

Finally, if we provide a color reduction setup screen, we might as well allow 
enabling dithering in it.

Original comment by pulkoma...@gmail.com on 14 Dec 2011 at 9:49

GoogleCodeExporter commented 8 years ago 
Arbitering issues that make it to v2.4

Original comment by yrizoud on 8 Mar 2012 at 7:18