Hacker News Reader

Comment by codetrotter | Hacker News Reader

Yep. I also remember a blog post from a few years ago about how fb removed some of the bytes in the JPEG thumbnails, because those bytes would always be the same in the thumbnails they created, so they kept those bytes separate and just added them back in on the client side before rendering the thumbnails

View on HN

As you get to small image sizes, the relative size of the quantization table and the Huffman encoding table becomes significant. You can easily just pick a standard version of these, leave them out of the image (which is no longer a valid JPEG), and then put them in at the destination to make a valid JPEG again.

I'm not finding a source, but I think I remember the tables being in the 1-2kB range.

Cheap MJPEG USB cameras do this. Their streaming data is like JPEG but without the tables since it would take up too much bandwidth.

Mentioned the FB blog post in my comment to this post. I didn't see any mention of the size of the fixed tables.

see https://news.ycombinator.com/item?id=35268708

This technic is very interesting. I imagine quite effective and very small JavaScript decoded.

I both love this level of optimization (for the novelty) and hate it (knowing all the work involved is being done with JS, on my machine, costing more CPU time than the bandwidth saved)

The claim being that the act of concatenating some bytestrings together is a massive time sink?

Decode from base64 json, concat, convert to a Blob, createObjectURL and feed back into an img? That's about the simplest way I can think to do it. Either that or blip it onto a canvas. Or convert it back to base64 in the form of a data-URI.

No reason to transfer the image data in JSON, just read the response as an ArrayBuffer. Pass over that and write it into a dataURI with the needed modifications in a single go.

How are you going to do that? There's other things in the payload. If it was just the image in the response you could read it as binary, but remember we want lots of tiny images coupled with titles and other metadata. You can use something other than JSON but it'll need some kind of structure that needs parsing.

I don't see how it would ever need to be more than a single pass over the data. Sure the logic might be mildly complicated, but nothing CPU intensive.

I just recently did some work in a much less sophisticated area of this. For folks who want to efficiently juggle image data into and out of canvas, ImageBitmap is a little known web API that does it very well. Unlike most web APIs dealing with binary data that interfaces with user interaction, you can use it synchronously, and it’s vastly more efficient than juggling base64-blobs-URLs.

That was the 'blip it onto the canvas' approach :D I discovered that ImageBitmap type just recently too, it's been very handy for the little project I'm working on. My data still comes as base64 strings in JSON though.

Yeah you’re gonna have to async once to get the binary thing canvas works well with, but if it’s even remotely stable you can just memoize shuttling ImageBitmap back in as needed. For my use case it was just literally redrawing the same background image things get drawn on top of with an internal data structure that translates to canvas API. Switching from async calls to ImageBitmap basically made the difference between “this flickering is making me question medical facts about myself” and “I can see it lag if I’m trying really hard”. Which isn’t great but it’s more than good enough for what I was trying to solve.

Reply on news.ycombinator.com