Finally, I can calmly watch the performance of my stock portfolio
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
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):
(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: , , another 67-byte PNG but 8 px wide: , or 1 gray pixel: , or a green one:
What the video doesn't address: Did the politicians face any consequences?
Can we finally get mixed zoning??
And people still have the audacity to say ViSuALLy iMpAiReD pEoPLe aRe jUsT 1% oF iNtErNeT uSeRs... Meanwhile I am enjoying a free 1 MB/day of cellular data on a prepaid card due to a provider’s billing glitch so I have my SIM in an old 2G Nokia and browse the web on Opera Mini with images disabled.
I believe in the curb cut effect so I try to follow accessibility guidelines wherever possible. I wonder when YT allows for visually impaired audio tracks so that people who only listen don’t miss important details conveyed viaually in video essays. I hate it when the narrator refers to a simple pie chart when they could have said the percentage out loud, especially if they speak redundantly elsewhere. Or when creators of obviously scripted videos don't at least upload the script for better subtitles. Or when video annotations were removed instead of YT making at least the non-interactive ones work on mobile. Or when websites and apps restrict copying text... and all other DRM can go fuck itself, too.
Once they gave us faster processors and enabled ASM programming, they were objectively the superior option. I am still wondering if we ever get a programmable & graphing calculator with a a 128x64 reflective display, either a rechargeable Li-Ion cell or one AAA battery that lasts forever and does not make the unit terribly thick so that it fits comfortably in a pocket, and has USB-mini-B or C of course. I wrote Snake, Mastermind and TriPeaks for the pictured CASIO CFX-9850 PLUS and coding was a better experience than on TI. However, our course taught TI, there were no affordable second-hand CASIOs and I wanted ready-made ASM games like 2048, Mario and Tetris so I went with the TI-84 Plus for IB.
The programs I wrote are still somewhere on my hard drive and I will publish their source as text as well as a CA-124-friendly file at some point. They work on newer programmable monochrome 128x64 CASIOs too if you remove colors and adjust for the faster processor. Unfortunately, the lack of comments and single-letter variables mean that the code is a mess but I might have the reworked versions somewhere too.
If you don't want to use the potentially unstable Nightly, Dev or Beta, you can use Fennec (stable builds with dev features).
Is still does, experimentally, if you enable developer settings, rather unintuitively through a Firefox Add-Ons account. Developer settings are not available in the official release but the Nightly builds as well as some forks, like 🦊Fennec, include them.
toss
Don’t throw them out yet if they work flawlessly. Give them to someone you know or just leave them somewhere. Also, you might need your old iPhone for some reason and so you should probably keep one (possibly semi-broken) cable.
Is there more info about this? I could only find Chinese forums like https://m-weibo-cn.translate.goog/status/OdaBMza1L?from=page_1005052963774131_profile&wvr=6&mod=weibotime&jumpfrom=weibocom
The chips (basic TTL logic, perhaps) are all DIP. This may predate the term "open source".