Microsoft paid $13B for this tech

JhZJhZJhZJhZJhZJhZJhZJhZ

Only cool Lemmy insiders get the joke

We shall call it Jizz Jizz

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!)

ZJh (base64) in binary is 011001 001001 100001

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

much appreciated!

I'm German and I think I just had a stroke.

If it's Dall-E, it inserts the words 'ethnically ambiguous' into images constantly. I'm not the only one who's noticed.

https://knowyourmeme.com/memes/events/ethnically-ambiguous-ai-prompt-injection

did it give you the images in base64 from an llm, or from an image generation model ?

It makes sense that they do that since the media and randoms on the internet think everything chatGPT and Bing chat say is as valid as info from OpenAI and MS official spokespersons.

Thing is, there wasn't even a chance of having a full Tay incident. The problem with Tay was that it was a learning model, so people could teach it to be more messed up.

Meanwhile, ChatGPT doesn't learn, and instead has a preset dataset it knows (hence why it only knows things up to September 2021), so the main reason why it got so heavily censored is more likely to avoid much more minor incidents, which imo is dumb.

The problem is the model. It was trained on lots of poor quality data. The lobotomy is the consequence of the poor data. If they spent 13 billion on having the data analysed prior to training they could have made their own thing much better.

But can it be decoded into an image?

lol

cool username, btw.