From: cr88192@gmail.com   
      
   On 10/31/2025 2:32 PM, BGB wrote:   
   > On 10/31/2025 1:21 PM, BGB wrote:   
   >   
   > ...   
   >   
   >>   
   >> In a lot of the cases, I was using an 8-bit indexed color or color-   
   >> cell mode. For indexed color, one needs to send each image through a   
   >> palette conversion (to the OS color palette); or run a color-cell   
   >> encoder. Mostly because the display HW used 128K of VRAM.   
   >>   
   >> And, even if RAM backed, there are bandwidth problems with going   
   >> bigger; so higher-resolutions had typically worked to reduce the bits   
   >> per pixel:   
   >>     320x200: 16 bpp   
   >>     640x400: 4 bpp (color cell), 8 bpp (uses 256K, sorta works)   
   >>     800x600: 2 or 4 bpp color-cell   
   >>    1024x768: 1 bpp monochrome, other experiments (*1)   
   >>      Or, use the 2 bpp mode, for 192K.   
   >>   
   >> *1: Bayer Pattern Mode/Logic (where the pattern of pixels also encodes   
   >> the color);   
   >> One possibility also being to use an indexed color pair for every 8x8,   
   >> allowing for a 1.25 bpp color cell mode.   
   >>   
   >   
   >   
   > Expanding on this:   
   > Idea 1, original:   
   > Each group of 2x2 pixels understood as:   
   >    G R   
   >    B G   
   > With each pixel alternating color.   
   >   
   > But, slightly better for quality is to operate on blocks of 4x4 pixels,   
   > with the pixel bits encoding color indirectly for the whole 4x4 block:   
   >    G R G B   
   >    B G R G   
   >    G R G B   
   >    B G R G   
   > So, if >= 4 G bits are set, G is High.   
   > So, if >= 2 R bits are set, R is High.   
   > So, if >= 2 B bits are set, B is High.   
   > If > 8 bits are set, I is high.   
   >   
   > The non-set pixels usually assuming either 0000 (Black) or 1000 (Dark   
   > Grey) depending on I bit. Or, a low intensity version of the main color   
   > if over 75% of a given bit are set in a given way (say, for mostly flat   
   > color blocks).   
   >   
   > Still kinda sucks, but allows a crude approximation of 16 color graphics   
   > at 1 bpp...   
   >   
      
   Well, anyways, here is me testing with another variation of the idea   
   (after thinking about it again).   
      
   Using a joke image as a test case here...   
      
   https://x.com/cr88192/status/1984694932666261839   
      
   This variation uses:   
      Y R   
      B G   
      
   In this case tiling as:   
      Y R Y R ...   
      B G B G ...   
      Y R Y R ...   
      B G B G ...   
      ...   
      
   Where, Y is a pure luma value.   
      May or may not use this, or:   
        Y R B G Y R B G   
        B G Y R B G Y R   
        ...   
      But, prior pattern is simpler to deal with.   
      
   Note that having every line follow the same pattern (with no   
   alternation) would lead to obvious vertical lines in the output.   
      
      
   With a different (slightly more complicated color recovery algorithm),   
   and was operating on 8x8 pixel blocks.   
      
   With 4x4, there is effectively 4 bits per channel, which is enough to   
   recover 1 bit of color per channel.   
      
   With 8x8, there are 16 bits, and it is possible to recover ~ 3 bits per   
   channel, allowing for roughly a RGB333 color space (though, the vectors   
   are normalized here).   
      
   Having both a Y and G channel slightly helps with the color-recovery   
   process; and allows a way to signal a monochrome block (if Y==G, the   
   block is assumed to be monochrome, and the R/B bits can be used more   
   freely for expressing luma).   
      
   Where:   
   Chroma accuracy comes at the expense of luma accuracy;   
   An increased colorspace comes at the cost of spatial resolution of chroma;   
   ...   
      
      
   Dealing with chroma does have the effect of making the dithering process   
   more complicated. As noted, reliable recovery of the color vector is   
   itself a bit fiddly (and is very sensitive to the encoder side dither   
   process).   
      
   The former image was itself an example of an artifact caused by the   
   dithering process, which in this case was over-boosting the green   
   channel (and rotating the dither matrix would result in drastic color   
   shifts). The later image was mostly after I realized the issue with the   
   dither pattern, and modified how it was being handled (replacing the use   
   of an 8x8 ordered dither with a 4x4 ordered dither, and then rotating   
   the matrix for each channel).   
      
      
   Image quality isn't great, but then again, not sure how to do that much   
   better with a naive 1 bit/pixel encoding.   
      
      
   I guess, an open question here is whether the color-recovery algorithm   
   would be practical for hardware / FPGA.   
      
   One possible could be:   
      Use LUT4 to map 4b -> 2b (as a count)   
      Then, map 2x2b -> 3b (adder)   
      Then, map 2x3b -> 4b (adder), then discard LSB.   
      Then, select max or R/G/B/Y;   
        This is used as an inverse normalization scale.   
      Feed each value and scale through a LUT (for R/G/B)   
        Getting a 5-bit scaled RGB;   
        Roughly: (Val<<5)/Max   
      Compose a 5-bit RGB555 value used for each pixel that is set.   
      
   Actual pixel decoding process works the same as with 8x8 blocks of 1 bit   
   monochome, selecting minimum or maximum color based on each bit.   
      
   Possibly, Y could also be used to select "relative" minimum and maximum   
   values, vs full intensity and black, but this would add more logic   
   complexity.   
      
      
   Pros/Cons:   
      +: Looks better than per-pixel Bayer-RGB   
      +: Looks better than 4x4 RGBI   
      -: Would require more complex decoder logic;   
      -: Requires specialized dither logic to not look like broken crap.   
      -: Doesn't give passable results if handed naive grayscale dithering.   
      
   Per-Pixel RGB still holds up OK with naive grayscale dither.   
   But, this approach is a lot more particular.   
      
   the RGBI approach seems intermediate, more likely to decode grayscale   
   patterns as gray.   
      
      
      
   I guess a more open question is if such a thing could be useful (it is   
   pretty far down the image-quality scale). But, OTOH, with simpler   
   (non-randomized) dither patterns; it can LZ compress OK (depending on   
   image, can get 0.1 to 0.8 bpp; which is generally JPEG territory).   
      
   If combined with delta encoding or similar; could almost be adapted into   
   a very crappy video codec.   
      
   Well, or LZ4, where (at 320x200) one could potentially hold several   
   frames of video in a 64K sliding window.   
      
   But, image quality might be unacceptably poor. Also if decoded in   
   software, the color-reconstruction is likely to be more computationally   
   expensive than just using a CRAM style codec (while also giving worse   
   image quality).   
      
      
   More just interesting that I was able to get things "almost half-way   
   passable" from 1 bpp monochrome.   
      
      
   ...   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)