[continued from previous message]   
      
   often just using a RasPi or similar).   
      
   Like, this isn't much beyond where I was a decade ago.   
      
      
      
   More recent activity has been in other areas, mostly involving BGBCC's   
   resource-converter stuff:   
   Working some on trying to improve my UPIC stuff, as UPIC turned out to   
   be "kinda useful" (*1).   
      
      
   *1: UPIC kinda resembles T.81 JPEG, but:   
      Uses STF+AdRice rather than Huffman;   
      Used BHT+RCT rather than DCT+YCbCr;   
      ...   
      
   A few more recent extensions were:   
      Optionally adds:   
        WHT, LGT-5/3, and DCT transforms;   
        YCoCg-R and Approx_YCbCr.   
   Encoder can try out different options and pick the configuration that   
   maximizes Q/bpp (lossy) or minimizes size (lossless, excludes DCT and   
   Approx_YCbCr as these are inherently lossy).   
      
   Had noted that the "winner" seems to depend a lot on image type and quality:   
      Lossless:   
        BHT or LGT-5/3 usually win (BHT wins more often).   
        More often RCT wins over YCoCg-R.   
        So, BHT + RCT seems to dominate for Lossless.   
      Near Lossless (high quality):   
        LGT-5/3 and YCoCg-R often jump into the lead.   
      Low Quality:   
        DCT and Approx_YCbCr often more into the lead for photo-like images;   
        LGT-5/3 and YCoCg still do well for cartoon-like images though.   
      
   WHT could do OK for photo-like images, but:   
      Only holds a lead at lower quality levels;   
      Almost always loses to DCT when DCT is still an option;   
      So, WHT is making the worse showing here;   
      Though, is faster than DCT, and supports lossless.   
        Nevermind if for Lossless it nearly always loses to LGT-5/3.   
      
   Approx_YCbCr is basically an approximation of YCbCr:   
      Y=(G*4+R*3+B)/8   
      U=B-Y   
      V=R-Y   
   Though, this isn't exact, and:   
      U=(B-Y)/2+128   
      V=(R-Y)/2+128   
   Would technically be closer.   
      
   Though, in UPIC, the DC bias is 0 rather than 128, so differs here from   
   JPEG.   
      
      
   Had experimented with a few other possibilities, but none was   
   particularly competitive.   
      
      
   Where:   
      BHT    : Block Haar (Wavelet) Transform   
        Recursively maps: (A,B) => ((A+B)/2, A-B)   
        Split into averages and differences, applied recursively.   
      LGT 5/3: Block (Le Gall–Tabatabai) 5/3 (Wavelet)   
        Recursively split even/odd, predict odds from averages of evens.   
        Bottom step resembles Haar.   
      WHT    : Walsh-Hadamard Transform   
        Kinda resembles BHT, but more complicated.   
        There is also another kinda WHT, but it did worse:   
          (A+B+C+D, A+B-C-D, A-B-C+D, A-B+C-D)   
      DCT    : Discrete Cosine Transform   
        Basically the same thing JPEG used here.   
        Lossy only (making DCT lossless is too slow).   
      
   As with T.81 JPEG, UPIC works with 8x8 blocks, typically organized into   
   a 16x16 macroblock with 4:2:0 or 4:4:4 chroma subsampling. As in the   
   Theora codec, the individual sub-blocks within a macroblock (when more   
   than one) are encoded in Hilbert order (U shaped). The format also   
   natively supports an alpha channel.   
      
   In this case, the 8x8 transforms are formed by two levels of 1D   
   transform. Horizontal then vertical for encode, vertical then horizontal   
   for decode (correct ordering here is important for lossless).   
      
      
   Had noted in some testing:   
      Lossless compression, for many images, can beat PNG.   
      At near-lossless quality, Q/bpp also beats T.81 JPEG.   
      
   But:   
   For "very synthetic" images, such as pie charts or graphs, PNG tends to   
   win over UPIC in terms of size (though UPIC still wins in being faster   
   to decode than PNG and with less memory footprint).   
      
   At the lower end of the quality scale (mostly under 30%), JPEG still   
   holds on well for Q/bpp, ... But, this is very sensitive to how the   
   quantization matrix is computed (and needs to tune the quantization   
   matrix used for the specific transform).   
      
   Possible reasons:   
   STF+AdRice is slightly less optimal than Huffman;   
   The zero count was reduced from 4 to 3 bits, which is weaker with more   
   longer runs of zeroes (more common with flat color blocks and at low   
   quality levels).   
      
   One considered by untested possibility:   
   Jointly encoding groups of four 8x8 blocks as one giant 256-entry block   
   (to partly consolidate the long zero runs and the early EOBs). Unclear   
   if it would be worth the added complexity though.   
      
      
   Had considered using a variant of my BT5B codec as an image format for   
   textures, but ended deciding against this as the Q/bpp was kinda awful   
   (and it started to seem better to use UPIC instead and just eat the   
   extra CPU time for converting this to DXT1 or DXT5). While my older   
   (BTIC4B) format had worked OK, it is considerably more complicated (and   
   UPIC being "like JPEG but faster" and transcoding to DXT1 is "maybe good   
   enough").   
      
   Where basically, for technical reasons, BT5B was essentially unable to   
   significantly beat the DDS format in Q/bpp. Could get smaller files, but   
   at much worse quality; being still essentially similar tech to the   
   MS-CRAM video codec (well, and for similar reasons for why one wouldn't   
   really want to store textures via CRAM; though was at least possible to   
   get closer to 1:1 with DDS for quality, but then essentially also   
   roughly 1:1 in terms of file size).   
      
      
   Note that for a decode path to DXT1/5, UPIC generally decodes and   
   trasforms each macroblock at a time (this is more cache friendly than   
   decoding the entire image to RGBA and then DXT encoding it; though it   
   still uses full-image passes for mipmap generation).   
      
   Note that Q/bpp could be improved, technically, by feeding the image   
   through a bitwise range coder, but this would have a significant adverse   
   impact on speed.   
      
   ...   
      
      
      
   Also (probably feature creep) ended up adding 3D model conversion and   
   CSG stuff to BGBCC (including a makeshift interpreter for the SCAD /   
   OpenSCAD language).   
      
   This was in part because:   
   BGBCC's core also mostly serves the core as part of my WAD4 packing tool;   
   It is useful to have model conversion stuff.   
      
   It would partly take over the role of using my current 3D engine for   
   model conversion.   
      
   In the 3D engine I had typically be using a modified BASIC dialect, but   
   had mostly designed the models originally in OpenSCAD, and using the   
   SCAD language allows keeping the models intact (but OpenSCAD doesn't   
   natively support colors or textures for any of the 3D model export formats).   
      
   Initially, these were only supported for my own 3D model format (used   
   for my 3D engine) but also supported (in a not yet released version)   
   using the "Wavefront OBJ" format (theoretically tried implementing some   
   of the color extensions for Binary STL, but nothing seemed able to   
   import them with color).   
      
   Other formats had other drawbacks:   
      AMF: More complicated, poorly supported;   
        XML based.   
      3MF: Much more complicated.   
        Format consists of XML blobs inside a ZIP based package, ...   
      DAE: Yeah, no.   
      3DS: Also no.   
      
   DAE and 3DS seem more sane for high-end mesh modeling, not so much for CSG.   
      
      
   Doing CSG with skeletal animation is currently supported for my BASIC   
   dialect; could map it over to SCAD, but would not have any direct   
   equivalent in OpenSCAD.   
      
   For textures, can map the textures over to "color()" which is then   
   understood as identifying a texture if not using a normal color   
   name/value. There is no direct need to specify ST/UV coords here, as   
   these are implied via texture projection.   
      
   Textures may be specified with planes, and then when projecting it will   
   pick the plane for this texture that is the closest match to the face   
   normal.   
      
   Sorta like:   
      texturename:   
        image [ Sx Sy Sz So ] [ Tx Ty Tz To ]   
        ...   
   Where: N = S x T   
      S/T encoding both the scale and translation along the axis.   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)