• 4 Posts
  • 32 Comments
Joined 1 year ago
cake
Cake day: June 6th, 2023

help-circle






  • I wish I had your research skills. Where does it even say that?

    The letters may have been chosen for early, limited 7-segment display drivers, such as a hex-to-7seg decoder. However, these fell out of use when transistors were no longer expensive in the 1990s and it made more sense to minimize the number of chips rather than each chip’s complexity, so the main microcontroller used 14 GPIO pins or a single external LED driver to multiplex all 6 digits. Before the 1990s, it probably did not make sense to make this device digital at all, I think gyms would just use analog clocks with marked dials.



  • First sentence of my post, for this very reason – they own the franchise, after all. The law may also change the other way but that’s very unlikely to happen in the US within 50 years.

    I wonder if they could develop a system of draconian DRM (only their own theatres with metal detectors, personalized online streams…) and mildly edit movies every few decades so that they can destroy the original and effectively renew copyright. The gaming industry’s always-online DRM makes nuking a release possible but copyright lasts for about 20 console generations (we’ve only had 8 so far!) so they don’t even have to do that.









  • I analyzed it in another comment: the header says the image is 300x300px 8-bit RGBA but the data is invalid. Most viewers will notice that and show an error.

    However, the syntax it used for embedding images is valid, as data:image/png;base64, is the start of a valid image URL and you can use it like other image URLs in supported Markdown interpretors.

    Example, using the 103-byte Google Maps’ sea tiles, and a 178-byte GIF:

    ![Google Maps sea map tile](data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAQAAAAEAAQMAAABmvDolAAAAA1BMVEW10NBjBBbqAAAAH0lEQVRoge3BAQ0AAADCoPdPbQ43oAAAAAAAAAAAvg0hAAABmmDh1QAAAABJRU5ErkJggg==)
    ![wink.gif](data:image/gif;base64,R0lGODlhDwAVAKIEAAAAAP//AP//3v///wAAAAAAAAAAAAAAACH/C05FVFNDQVBFMi4wAwEAAAAh+QQFlgAEACwAAAAADwAVAAADSUiq0L2QtEDpg6Bqu/LeAGN5wVRKlVmS6qe17hiDHvlyNciho5N2sxDGtoIMBgyH8Kg4IiMEZ1NKlUarSOdTe81arZHvE3olJAAAIfkEBR4ABAAsCAAEAAQABQAAAwYIGtz+ASQAOw==)
    

    renders as

    Google Maps sea map tile wink.gif

    Works in the default web interface


  • I prefer hexadecimal. The encoded data in its entirety is

    89 50 4E 47 0D 0A 1A 0A 
    00 00 00 0D 49 48 44 52 
    00 00 01 2C 00 00 01 2C 
    08 06 00 00 00 B9 B4 AC 
    33 00 00 01 A4 49 44 41 
    54 78 9C ED DD 41 8E 83 
    40 10 85 E1 7F 7F E4 B2 
    72 25 92 61 64 98 59 26 
    16 49 85 92 61 64 98 59 
    26 16 49 85 92 61 64 98 
    59 26 16 49 85 92 61 64 
    98 59 26 16 49 85 92 61 
    64 98 59 26 16 49 85 92 
    61 64 98 59 26 16 49 85 
    92 61 64 98 59 26 16 49 
    85 92 61 64 98 59 26 16 
    49 85 92 61 64 98 59 26 
    16 49 85 92 61 64 98 59 
    26 16 49 85 92 61 64 98 
    59 26 16 49 85 92 61 64 
    98 59 26 16 49 85 92 61 
    64 98 59 26 16 49 85 92 
    61 64 98 59 26 16 49 85 
    92 61 64 98 59 26 16 49 
    85 92 61 64 98 59 26 16 
    49 85 92 61 64 98 59 26 
    16 49 85 92 61 64 98 59 
    26 16 49 85 92 61 64 98 
    59 26 16 49 85 92 61 64 
    98 59 26 1(abrupt end at 4 bits of last byte)
    

    We can analyze the PNG file header. Surprisingly, some of it makes sense.

    89 50 4E 47 0D 0A 1A 0A //PNG signature (0x89 P N G 0xD 0xA 0x1A 0xA)
    
    00 00 00 0D // Start of chunk with data length 13 bytes
    49 48 44 52 // Type of chunk: IHDR (image header)
    00 00 01 2C // Width: 300 px
    00 00 01 2C // Height: 300 px 
    08 // Bits per color channel: 8 
    06 // Color format: 6 (RGBA)
    00 // Compression method: 0 (DEFLATE)
    00 // Filter method: 0 (Adaptive)
    00 // Interlace method: 0 (None)
    B9 B4 AC 33 // CRC-32 of chunk (invalid, should be 79 7D 8E 75)
    
    00 00 01 A4 // Start of chunk with data length 420 bytes
    49 44 41 54 // Type of chunk: IDAT (image data)
    78 9C ED DD 41 8E 83 40 
    10 85 E1 7F 7F E4 B2 72 25 
    92 61 64 98 59 26 16 49 85
    92 61 64 98 59 26 16 49 85
    92 61 64 98 59 26 16 49 85
    92 61 64 98 59 26 16 49 85
    92 61 64 98 59 26 16 49 85
    92 61 64 98 59 26 16 49 85
    92 61 64 98 59 26 16 49 85
    92 61 64 98 59 26 16 49 85
    92 61 64 98 59 26 16 49 85
    92 61 64 98 59 26 16 49 85
    92 61 64 98 59 26 16 49 85
    92 61 64 98 59 26 16 49 85
    92 61 64 98 59 26 16 49 85
    92 61 64 98 59 26 16 49 85
    92 61 64 98 59 26 16 49 85
    92 61 64 98 59 26 16 49 85
    92 61 64 98 59 26 16 49 85
    92 61 64 98 59 26 16 49 85
    92 61 64 98 59 26 16 49 85
    92 61 64 98 59 26 1
    // 194.5 of the expected 420 data bytes, invalid when attempting to deflate
    // the deflate algorithm needs a Huffman tree but an unfull one is presented
    

    Credits to the PNG chunk inspector at nayuki.io

    You may try to figure out if the header checksum was stolen from elsewhere and corresponds to another common image size but I cannot be bothered. The data could be subjected to forensic analysis but we only really have 21 unique bytes, the rest is likely nonsense because data encoded by the DEFLATE algorithm is unlikely to be so repetitive. Also, the image in total will likely have just 481 bytes (8+(8+13+4)+(8+420+4)+16), as a less-than-65535-byte IDAT chunk tends to be the last one before a 16-byte trailer. There are very few 300x300 PNGs of such small size we could call memes, most of it will have to be just solid color. Example of a 256x256 map tile you can store in around that size (467 B):
    OSM tile for Crozet Islands at around 1:10 000 000 scale, the archipelago the area of Malta is represented by about 10 white pixels with the exclusive economic zone circles of radius 5 px around the islands
    (And this one is pre-optimized, using an indexed palette of just 13 distinct RGB colors as opposed to the full RGBA gamut!)



  • I think you can guess that part. I doubt a current LLM can create a valid PNG, even if it’s just a 1x1px one that has been created before. This is partially because PNGs have a checksum and the LLM has definitely not seen enough PNGs in base64 to figure out the algorithm, and is not optimized to calculate checksums. In fact, I analyzed the image and the image header checksum is wrong even though the header makes sense (was likely stolen). Also, it gets penalized for repetition, which occurs a lot in image headers.

    AFAIK, the smallest valid image you see mentioned on the web is a 35-byte transparent pixel GIF, and the smallest PNG is a black pixel with 67 bytes:

    data:image/gif;base64,R0lGODlhAQABAAAAACH5BAEAAAAALAAAAAABAAEAAAIBAAA=
    data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABAQAAAAA3bvkkAAAACklEQVR4AWNgAAAAAgABc3UBGAAAAABJRU5ErkJggg==
    

    Testing rendering: Alt text for the GIF; if you see it, it failed, Alt text for the PNG; if you see it, it failed, another 67-byte PNG but 8 px wide: , or 1 gray pixel: , or a green one:

    The article + the generator