From: cr88192@gmail.com   
      
   On 11/2/2025 9:06 AM, Robert Finch wrote:   
   > On 2025-11-02 3:21 a.m., BGB wrote:   
   >> 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).   
   >>   
   >>   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)