Update on the PNG file: I’m reading and studying, and getting an education. Apparently the presence of two data blocks is normal with PNG files because limits are imposed on the size of each, whether those limits are traditional or hardware-imposed. Pixels in Q’s file are stored as 16-byte values, which is way overkill for what the human eye can detect, but that’s what was used. The first IDAT (image data) block in this file has a size of 0x80000 which is 32,768 sets of 16 bytes – a very clean, nice, even round number if you’re looking at binary values. 32767 is the max signed (specifies + or -) number you can have with 16-bit values. (Since 0 is included, 0 – 32767 is 32,768 distinct values). The second block is a continuation of the first.

But the problem remains: remove the second block and the image still displays normally.

Since PNG files use a technique called “filtering,” in addition to compression, it’s impossible to tell how many pixels are actually represented without decompressing the data. And here is where I’m hitting the same old merry-go-round that I always hit: bad documentation. There just isn’t any escaping it. It has cost me more time over the years than any other factor – exponentially.

According to documentation, there should be 4 bytes that say the size of the block. That part is good. The next four say IDAT to identify the block type. No problem. Then the data block begins. This is where EVERY SOURCE I can find assumes we’re all psychic and they just gloss over it …. okay then it’s the compressed data. See RFC1950 for that. So I look at RFC 1950 and nothing, nothing, nothing matches up.

Standard fare. Bad, bad, bad documentation.

So this is what I’m fighting. I have downloaded source code for 3 decoders in C++ and none of them compile. Errors galore. I hate high level languages … did I mention that? Say one thing, they do another. Out of control.

So … I’m working on it. I just have to claw my way through this incompetence in documentation and keep on searching until somebody decides to correctly document whatever truly follows IDAT because it is not an RFC1950 compatible compression stream.

>>148462

I'm not feeling pressured at all … I learned long ago that the worst possible fate in life is regretting what you didn't do. I'm concerned with that second data block. I'm going under the assumption that the image contains more pixels (data-wise) than are ever displayed. The image header declares the width and height of the image. If more pixel data than that is present, my guess is that it's decompressed and processed as a matter of course but then it's just tossed because it's never used. I've done enough testing where it's pretty much verified that yes, the black areas are just that - black. And the center section of the image shows all the earmarks of a JPG (lossy compression) that's been compressed / decompressed multiple times, with degradation occurring each time. Like making a copy of a copy of a copy. So the only viable chance for something to be in that image is extra pixel data that is never processed in anything that displays PNG images because the display width and height are declared in the header of the file. I've never heard that situation even referenced so it would be up to each display app to decide what to do if it encounters z pixels when x are called for by the width/height declaration.

I don't know any display that's 2436 pixels in height so that eliminates the "screen shot" theory. The max you're going to find on any computer monitor is 2160 in height. 8K exists at 4320 pixels high but if somebody has the money to afford that, they're not going to be posting on this board. And it still doesn't explain the odd number 2436.

>>148614

Unfortunately, my source is in assembly language. It's all I work with.

The problem is simply knowing what the data is that immediately follows IDAT in a PNG file. It doesn't match the RFC1950 specification. The bytes are all wrong. Maybe there's some kind of universal header that ZLIB inserts. I'm going to try feeding the data as-is into a ZLIB decompress function, which is a last resort. I didn't want to use it but there's no real choice here.

>>148626

I didn't know! Now I do! And the vertical centering of the non-black image would be its exact natural placement.

Now that I have this extra piece of data, there is just no aspect of this file that stands out as unusual in any way. Every last aspect adds up. People on the Q team would be the first ones to have an iPhone X.

I just verified it: iPhone X resolution 1135 x 2436, exactly the size of that image. I believe you just provided the last missing piece that will release me from this project. I think it's safe to assume there is nothing hidden in that image.

Plenty more will be coming from Q to keep us busy. You've saved me a jillion hours. I'm in your debt!

>>148895

Especially in this arena, I've learned a lot today that could come in very handy over the coming months.

>>148643

Born and bred. My mind works best at that tiny level of detail. That's where I'm tuned. I'm very much out in the cold in a world that lives on HLL's.

>>148783

I wasn't really in any condition to be taking this on today anyway. I have enough personal crises and pressure going on for a hundred people, and as many years. Mentally I'm a wreck today. Things will improve, but I should not have missed that.

>>148964

Thanks … that's what I'm thinking. I got familiar with the file format, which seems to be more heavily used every month; and now I've even committed the iPhoneX resolution to memory. I personally am a "never iPhone" devotee so I wouldn't normally know that.

Oh by the way … I don't think I posted the latest map last night. Remember the sample here is not supposed to be readable. Full size JPG (zipped) is 24 megs. http:// www.enigma-q.com/qmap.zip. Contains exactly 599 Q messages.

>>149083

Yyyyyyyyyeahhhhhh… if you could get yourself some lawwwwwwwwwwwyers, that would be terrific.

>>149121

So we have brought this matter to final "resolution."