ordered dither checks and remapping possible?

[snibgo]

For the goal of "ordered dither with 16 specified colours", another possibility is like Fred's last suggestion but doing the "-ordered-dither" first, then the remap with no dither. This ensures that every output pixel is one of the 16, and the appearance is "ordered". I don't think this is the most accurate solution, but it may be good enough.

As a simple example, suppose we want just these four colours:

Code: Select all

%IMG7%magick ^
  xc:#f00 xc:#800 xc:#080 xc:#008 ^
  +append +repage ^
  map.png

And the source is my usual toes.png:


An ordinary remap gives:

Code: Select all

%IMG7%magick ^
  toes.png ^
  +dither -remap map.png ^
  od3_r.png

Code: Select all

%IMG7%magick ^
  toes.png ^
  -ordered-dither checks,8,8,8 ^
  +write od3_o.png ^
  +dither -remap map.png ^
  od3_d.png

The intermediate result od3_o is:


The final result od3_d is:


EDIT to add: the final result varies with different numbers of levels. For example, instead of "8,8,8" we might use "3,3,3", which has the final result:

[fmw42]

Good point about the ordering. I forgot that the dither will change colors.

[mattyrb]

Okay half way there

convert ', \\Source\\frame470.png', ' -ordered-dither checks,8,8,8 +write ', \\OrderedDither\\frame470.png', ' +dither -remap colormap.png ', '\\Remap\\frame470.png'

However I'm still missing reducing things to 16 colours.

[mattyrb]

Thanks for everyone's help with this btw! Really appreciate it!

[snibgo]

However I'm still missing reducing things to 16 colours.

I don't understand. If your colormap.png contains exactly 16 different colours, then your output will contain at most those 16 colours. Some of the colours in the map may not be used.

[mattyrb]

My colourmap contains a 9bit colourmap of 512 possible colours.

[snibgo]

Then my command will give you up to 512 colours. If you only want 16 colours, your colormap.png needs to contain only 16 colours.

I don't know what constraints you have, or how you have chosen the 512 colours. You could remap to those 512 colours, and find the 16 colours that occur most frequently.

Those might not be the best selection of 16; there might be a different selection that gives a smaller RMSE. A better selection method might be: remap to 512 colours. Find the least-used colour, and remove from the map. Repeat with 511 colours, then 510, etc until you have 16.

[mattyrb]

Then my command will give you up to 512 colours. If you only want 16 colours, your colormap.png needs to contain only 16 colours.

I don't know what constraints you have, or how you have chosen the 512 colours. You could remap to those 512 colours, and find the 16 colours that occur most frequently.

Those might not be the best selection of 16; there might be a different selection that gives a smaller RMSE. A better selection method might be: remap to 512 colours. Find the least-used colour, and remove from the map. Repeat with 511 colours, then 510, etc until you have 16.

I suppose I should give more context. I've written an video codec that plays PNGs of 16 colours that are optimised to a 512 colour palette. I've a python batch script that processes all of the images via commandline imagemagick (not sure on the version I should probably check!). I've got around 60 seconds of video at 12 FPS, so it's a little shy of 720 PNGs. I like that last suggestion but imagine it would be an insanely long process for 720 PNGs.

[snibgo]

... video codec that plays PNGs of 16 colours ...

Hmm. I would guess that you need the same 16 colours in each frame, to avoid flicker. If you have enough memory, you could append all the input frames together to make a huge image, and find the best 16 colours for that. If not enough memory, just take every fifth frame or something.

... an insanely long process ...

Yes. I suggest you try it first with the 16 most common colours. Also look at the statistics: there may be a long tail, and the first 32 colours account for 95% of the pixels. Then you might work from those 32 downwards.

In jobs like this, rather than trying to design the perfect solution, it can be more productive to create some solution, perhaps on a subset of the input. This can reveal conditions or problems or solutions that weren't obvious earlier.

[mattyrb]

Hmm. I would guess that you need the same 16 colours in each frame, to avoid flicker.

What I've found so far is applying the colormap before doing anything else reduces the flicker considerably.

In jobs like this, rather than trying to design the perfect solution, it can be more productive to create some solution, perhaps on a subset of the input. This can reveal conditions or problems or solutions that weren't obvious earlier.

Yeah I've had a few processing methods so far, I started out with using the python pillow library and straight up colour reduction without dither.

My video player works by building images using 8 x 8 pixel tiles. The tiles are compressed using a variant of LZH. The balance I'm having to find is between good colour and check dithering. If I use dither I get a much better images but the compression efficiency tends to drop. If I use pure colour reduction without dither you get much better compression as the images feature pure blocks of colour.