Commit Graph

14 Commits

Author SHA1 Message Date
1d5bcfd74e Optimize make_data_tables and use instead of pickling. The
file sizes are a bit larger but it unblocks updating to python 3.8.
2023-01-24 21:49:33 +00:00
f7f5950637 - Stop using the 5x weighting for diff values, it was preventing from
consistently finding enough additional offsets (~2.5x avg instead of

- Remove instrumentation for fill rate now that it's served its purpose
2023-01-17 21:42:28 +00:00
0a3c81c8c6 - have Bitmap.apply() update the memory representation instead of
requiring callers to keep track of it

- stop trying to cache content_deltas, I think it results in losing
  deltas.  Instead just recompute the deltas for each page as we need
  it.  This is fast enough in practice.

- track the average fill rate for the additional offsets we emit.
  This should be close to 3 if we're succeeding in finding enough
  collateral work

- overhaul how we pass in the target memory maps.  The previous way
  didn't make sense: we weren't actually encoding for the target video
  frame, but were using an inconsistent mix of old and new frames.  I
  think this was causing image artifacting because we were aiming for
  the wrong thing.

- Add some debugging assertions that were used to track this down.
2023-01-17 21:39:05 +00:00
4f6d7a796a Fix some numpy deprecation warnings 2023-01-17 12:26:25 +00:00
f3d03a1b87 Update comments and fix some bugs
- use MASKED_DOTS since it does not have a simple relationship to the
- try disabling transposition distances for Damerau-Levenshtein, this
  may give better quality

- introduce separate notion of MASKED_DOTS which is the number of
  (coloured) pixels we can extract from MASKED_BITS.  For HGR this is
  not the same.
- fix bug in _fix_array_neighbours that was not fixing headers for HGR
- don't cache everything in byte_pair_differences, it's effectively
  unbounded.  Using 1M for LRU size seems to work just as well in
  practise, without leaking memory.
- fix bug in _diff_weights when comparing content, we want to evaluate
  the effect of storing content byte in each offset separately, not
- add a consistency check function (not currently wired up) to assert
  that headers/footers are in sync across columns
- HGR should have 16 body bits, this was causing headers not to
  propagate correctly to/from neighbouring column
- add test case for this bug

- Use 8 random bits consistently, using 16 in some places may have
  introduced bias
- ignore palette bit when comparing 0x00 and 0x7f in sanity check
2019-07-11 23:40:00 +01:00
ab29b01d0f Finish implementing HGRBitmap support.
- For HGRBitmap introduce a packed representation in the form
  hhHaaaaaaaABbbbbbbbFff where capitals indicate the location of the
  palette bit.  i.e. for header and footer we include the neighbouring
  2 data bits as in DHGR but also the palette bit from that byte, which
  is necessary to understand how these data bits unpack into dots.

  The nonstandard ordering of the palette bit for the odd data byte (B)
  is so that the masking by byte offset produces a contiguous sequence
  of bits, i.e. the 14-bit masked representation is still dense.

- Introduce a to_dots() classmethod that converts from the masked bit
  representation of dots influenced by a screen byte to the actual
  sequence of screen dots.  For DHGR this is the identity map since
  there are no shenanigans with palette bits causing dots to shift

- Add a bunch more unit tests, and add back the Sather tests for HGR
  artifact colours from palette bit interference, which now all pass!

- Reduce the size of the precomputed edit distance matrix by half by
  exploiting the fact that it is symmetrical under
  i << N + j <-> j << N + i where N is the size of the masked bit
  representation (i.e. transposing the original (i, j) -> dist
  metric matrix).
2019-07-07 21:22:44 +01:00
740dafbd74 Remove commented out code 2019-07-04 15:54:05 +01:00
5c550d8524 Separate the details of the bitmap packing from operations on the
packed representation (diff, apply etc).  This allows the (D)HGRBitmap
classes to focus on the bitmap packing and share common logic.

Numpy has unfortunate long-standing bugs to do with type coercion of
np.uint64, which leads to spurious "incompatible type" warnings when
e.g. operating on a np.uint64 and some other integer type.  To work
around this we cast explicitly to np.uint64 everywhere.

Get tests working again - for now HGR tests in are
disabled until I finish implementing new packing.

HGRBitmap is still incomplete although closer.
2019-07-04 15:21:20 +01:00
666272a8fc Checkpoint WIP for easier comparison to dhgr branch:
- naive version of NTSC artifacting, it uses a sliding 4-bit window to
  assign a nominal (D)HGR colour to each dot position.  A more
  sophisticated/correct implementation would model the YIQ signal

- Switch DHGRBitmap implementation to use a 34-bit representation of
  the 4-byte tuple, comprised of a 3-bit header and footer, plus
  4*7=28-bit body.  The headers/footers account for the influence on
  neighbouring tuples from the 4-bit NTSC window.

- With this model each screen byte influences 13 pixels, so we need to
  precompute 2^26 edit distances for all possible (source, target)
  13-bit sequences.

- Checkpointing not-yet-working HGR implementation.

- Add new unit tests but not yet all passing due to refactoring
2019-07-02 22:40:50 +01:00
ca817999f6 Parametrize the RGB palette to encode with, and support both NTSC and
IIGS palettes.

Move the palette diff_matrix generation into since
that is the only place it is used.

Demand-load the edit distance matrices when transcoding.
2019-06-15 21:02:00 +01:00
824154fd39 Compress the precomputed edit_distance arrays 2019-06-14 22:08:34 +01:00
c2c57b47d5 Add type annotations 2019-06-14 22:03:37 +01:00
4251c9938f Remove unused code.
Add a new DHGRBitmap class that efficiently represents the
DHGR interleaving of the (aux, main) MemoryMap as a sequence of
28-bit integers.

This allows for easily extracting the 8-bit and 12-bit subsequences
representing the DHGR pixels that are influenced when storing a byte
at offsets 0..3 within the interleaved (aux, main, aux, main)

Since we have precomputed all of the pairwise differences between
these 8- and 12-bit values, this allows us to efficiently compute the
edit distances between pairs of screen bytes (and/or arrays)
2019-06-13 23:44:41 +01:00
bbfcacd674 Move transcoder to new location 2019-03-21 16:10:16 +00:00