5 ms·
Connecting the iDOTs (2020)
- fouc 5y agoSeems related to how apple handles PNGs like the recent discussion about ambiguous PNGs https://news.ycombinator.com/item?id=29586549 https://news.ycombinator.com/item?id=29586549
- lelandfe 5y agoYeah, we’ve come full circle now. This was the first post: https://news.ycombinator.com/item?id=29573792 https://news.ycombinator.com/item?id=29573792 Then someone posted the GitHub repo, and now someone has the posted the link that provided the initial insight (linked to on the original page)
- gbingles 5y agoI was wondering if exactly that was possible. Generate an iDOT that leads to chunks a "regular" renderer would never look for. Really curious that it happens in Safari sometimes though...
- moonchild 5y ago> The only value I have ever seen is "0x40". (The iDOT chunk contains 28 bytes, and this value is 0x28 in hex. So maybe this is related?) This is backwards, I guess? 0x40 is clearly not 0x28; nor is 28 0x28; but 0x28 is 40 (decimal).
- vmception 5y agoMaybe they should find logic gates in the decompression algorithm, use those to emulate a threaded cpu, and launch a multithreaded decoding process on that cpu which finds the original decompression process in memory and executes on the same image being decompressed
- acchow 5y agoErrr, is this some joke related to ForcedEntry? edit: the name of NSO's iMessage zero click exploit is ForcedEntry
- vmception 5y agoThe answer was available to Apple all along, if only the technique was patented to promote the progress of science and useful arts so that Apple engineers could be inspired on how to use their own operating system
- edoceo 5y agoCan you explain it plainly? I seems like there's a funny joke or irony in there but I don't have the experience to detect it properly.
- PaulBGD_ 5y agoThere was a recent 0 day in iMessage relating to image parsing, in a open library that Apple used. I’m not sure why the poster is being so vague, but the blog post is an interesting read. The second comment just seems like a dig at apple in general.
- vmception 5y agoNSO Group’s iOS exploit was sold to nation states who spied on journalists and dissidents with it. The code behind it got leaked a few days ago and its a mind bending process that essentially did what I described, using an old image decompression algorithm. Its so absurd and also perceptive that making fun of it is the best way to process it.
- my123 5y agoA commenter to that article (nolen) wrote: > I was involved in adding this to PNGs in ~2011 or so. I don't remember the details but you've got this pretty much right. > The reason was indeed performance: on the first retina iPads, decoding PNGs was a huge portion of the total launch times for some apps, while one of the two cores sat completely idle. My guess is that it's still at least somewhat useful today, even with much much faster single-thread performance, because screen sizes have also grown quite a bit. Interesting that PNG parsing was a severe bottleneck a decade ago...
- userbinator 5y agoI'm surprised too; in the Windows world, two decades ago, "skins" were popular and those essentially turned every single UI element into a bitmap. On the hardware of that time, their impact on performance was pretty minimal. Of course, "every UI element is a bitmap" is not a good idea anyway, for other reasons, but seems to have someone become the norm for web and mobile.
- rp1 5y agoBitmaps take memory, but are quite efficient from a runtime perspective because they aren’t encoded.
- Retric 5y agoBitmaps take both bandwidth and space, either can be an issue.
- giantrobot 5y ago> Bitmaps take memory, but are quite efficient from a runtime perspective because they aren’t encoded. Memory and bandwidth. To decode/display an image it's got to be loaded from storage. In the case of a Retina display iPad that's 2048x1536px. With a 24-bit color depth that's a 9MB bitmap to load from disk (SSD or whatever). I just did a test with ImageMagick. The same 2048x1536 image encoded to an uncompressed Windows bitmap is 9MB while the same image as a PNG (PNG24, zlib level 9, with adaptive scanline filtering) is only 4MB. That's less than half the data to load off disk. Unless CPU power is at an absolute premium you're probably better off with an image with lossless compression rather than completely uncompressed.
- mmastrac 5y agoIf I recall correctly, the iPad/iPhone-compiled PNG files had the color channels optimized for the graphics hardware of the devices as well - they wouldn't decode properly anywhere else.
- pornel 5y agoYes, but "optimized" is overselling it. It stored RGBA in a premultiplied form. IMHO it was an unnecessary spec breakage, and a misplaced focus. The most expensive part of decoding PNG is zlib inflate, so any reduction in input data is more important than post-processing savings. If Apple stored app launch images (the feature it's been invented for) as opaque RGB, then colorspace conversion would also be free, and they'd also be saving a quarter of the most expensive stage of decoding. Instead, they've kept the big expensive part big and expensive, and shaved off 3 instructions from the almost free part.
- gfaure 5y ago> (The odd capitalizations are used as binary flags and determines whether a chunk is required or optional, and when it is retained or removed.) I found this commingling of human-readable data and metadata quite novel. I can't bring to mind another format which does this.
- deleted 5y ago[deleted]