Hi-Res is essentially a more constrained version of Double Hi-Res, in which only about half of the 560 horizontal screen pixels can be independently addressed.
In particular an 8 bit byte in screen memory controls 14 or 15 screen pixels. Bits 0-7 are doubled, and bit 8 shifts these 14 dots to the right if enabled. In this case bit 7 of the previous byte is repeated a third time.
This means that we have to optimize all 8 bits at once and move forward in increments of 14 screen pixels.
There's also a timing difference that results in a phase shift of the NTSC colour signal, which means the mappings from dot patterns to effective colours are rotated.
Error diffusion seems to give best results if we only distribute about 2/3 of the quantization error according to the dither pattern.
all palettes. This will be useful for Total Replay which does an
animation effect when displaying the image (first set palettes, then
transition in pixels)
- this requires us to go back to computing k-means ourself instead of
using sklearn, since it can't keep some centroids fixed
- try to be more careful about //gs RGB values, which are in the
Rec.601 colour space. This isn't quite right yet - the issue seems
to be that since we dither in linear RGB space but quantize in the
nonlinear space, small differences may lead to a +/- 1 in the 4-bit
//gs RGB value, which is quite noticeable. Instead we need to be
clustering and/or dithering with awareness of the quantized palette
space.
direction. Otherwise, errors can accumulate in an RGB channel if
there are no palette colours with an extremal value, and then when
we introduce a new palette the error all suddenly discharges in a
spurious horizontal line. This now gives quite good results!
* Switch to using L1-norm for k-means, per suggestion of Lucas
Scharenbroich: "A k-medians effectively uses an L1 distance metric
instead of L2 for k-means. Using a squared distance metric causes
the fit to "fall off" too quickly and allows too many of the k
centroids to cluster around areas of high density, which results in
many similar colors being selected. A linear cost function forces
the centroids to spread out since the error influence has a broader
range."
can't figure out why contrast=2 is needed (openemulator uses a default
value of 1, so there must be a factor of 2x somewhere), or where the
slight hue rotation comes from - perhaps this is somehow introduced by
the more complex band-pass filtering that openemulator does?
I needed to also account for the DHGR timing difference that
introduces a phase offset of 1 pixel between the memory values and
displayed pixel timings.
Fix a last-minute bug with palette precomputation.
Use this to precompute a new ntsc palette with 256 entries (though
only 84 unique colours) that are available by appropriate pixel
sequences. Unfortunately the precomputed distance matrix for this
palette is 4GB!
Optimize the precomputation to be less memory hungry, while also
making efficient use of the mmapped output file.
Add support for dithering images using this 8-bit palette depth,
i.e. to optimize for NTSC rendering. This often gives better image
quality since more colours are available, especially when modulating
areas of similar colour.
Fix 140 pixel dithering and render the output including NTSC fringing
instead of the unrealistic 140px output that doesn't include it.
Add support for rendering output image using any target palette, which
is useful e.g. for comparing how an 8-pixel NTSC rendered image will
be displayed on an emulator using 4-pixel ntsc emulation (there is
usually some colour bias, because the 8 pixel chroma blending tends to
average away colours).
Switch the output binary format to write AUX memory first, which
matches the image format of other utilities.
KrisKennaway