From: robfi680@gmail.com   
      
   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).   
   >   
   >   
   > More just interesting that I was able to get things "almost half-way   
   > passable" from 1 bpp monochrome.   
   >   
   >   
   > ...   
   >   
   >   
   >   
   I think your support for graphics is interesting; something to keep in   
   mind for displays with limited RAM.   
      
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)