Hacker News Reader

Hacker News

Comment by m348e912 | Hacker News Reader

Full thread

m348e912

A full-resolution, maximum-size JPEG XL image (1,073,741,823 × 1,073,741,824):

Uncompressed: 3.5–7 exabytes Realistically compressed: Tens to hundreds of petabytes

Thats a serious high-res image

View on HN

At 600DPI that's over a marathon in each dimension.

I do wonder if there are any DOS vectors that need to be considered if such a large image can be defined in relatively small byte space.

I was going to work out how many A4 pages that was to print, but google's magic calculator that worked really well has been replaced by Gemini which produces this trash:

    Number of A4 pages=0.0625 square meters per A4 page * 784 square miles   =13,200 A4 pages.

No Gemini, you can't equate meters and miles, even if they do both abbreviate to 'm' sometimes.

Wolfram alpha is the better calculator for that sort of thing.

A better Gemini also works. Google Search seems to use the most minimal of Geminis, giving it a bad rep.

Prompt: “How many A4 pages would a 1073741823×1073741824 image printed at 600dpi be?”

Gemini Pro: “It would require approximately 33.1 billion (33,127,520,230) A4 pages to print that image.

To put that into perspective, the image would cover an area of 2,066 square kilometers […].

The Math

1. Image Dimensions: 1,073,741,823 × 1,073,741,824 pixels.

2. Physical Size: At 600 DPI, the image measures roughly 45.45 km wide by 45.45 km tall.

3. A4 Area: A single sheet of A4 paper (210 mm * 297 mm) covers approximately 0.06237 m².

4. Result: 2,066,163,436 m² / 0.06237 m² ≈ 33,127,520,230 pages.”

Alternatively, rink (https://rinkcalc.app/) :

> (1073741823 / (600/inch))**2 / A4paper

approx. 3.312752e10 (dimensionless)

Grok 4.1 beta finds the answer: approximately 33.1 billion pages.

> I do wonder if there are any DOS vectors that need to be considered if such a large image can be defined in relatively small byte space.

You can already DOS with SVG images. Usually, the browser tab crashes before worse things happen. Most sites therefore do not allow SVG uploads, except GitHub for some reason.

svg is also just kind of annoying to deal with, because the image may or may not even have a size, and if it does, it can be specified in a bunch of different units, so it's a lot harder to get this if you want to store the size of the image or use it anywhere in your code

"Google's magic calculator" was probably just a wrapper to GNU Units [0], which produces:

  $ units
  You have: (1073741823/(600/inch))**2 / A4paper  
  You want:  
         Definition: 3.312752e+10

Equivalent tools: Qalc, Numbat

0: https://news.ycombinator.com/item?id=36994418

It couldn't have been a wrapper - it understood a tiny tiny fraction of the things that Gnu units does.

Using a naive rectangular approximation (40x10^6m x 20x10^6m - infinite resolution at the poles), that's a map of the Earth with a resolution of 37mm per pixel at the equator. Lower resolution than I expected!

The only practical way to work with such large images is if they are tiled and pyramidal anyway

what does pyramidal mean in this context?

Tiled at different zoom levels

Probably, multiple resolutions of the same thing. E.g. a lower res image of the entire scene and then higher resolution versions of sections. As you zoom in, the higher resolution versions get used so that you can see more detail while limiting memory consumption.

Replicated at different resolutions depending on your zoom level.

One patch at low resolution is backed by four higher-resolution images, each of which is backed by four higher-resolution images, and so on... All on top of an index to fetch the right images for your zoom level and camera position.

Except in the case of a format like JPEG, there is no duplication - higher layers are used to "fill in the gaps" in the data from lower layers.

I think it means encoded in such a way that you first have low res version, then higher res versions, then even higher res versions etc.

JPEG and friends transforms the image data into the frequency domain. Regular old JPEG uses the discrete cosine transformation[1] for this on 8x8 blocks of pixels. This is why with heavily compressed JPEG images you can see blocky artifacts[2]. JPEG XL uses variable block size DCT.

Lets stick to old JPEG as it's easier to explain. The DCT takes the 8x8 pixels of a block and transforms it to 8x8 magnitudes of different frequency components. In one corner you have the DC component, ie zero frequency, which represents the average of all 8x8 pixels. Around it you have the lowest non-zero frequency components. You have three of those, one which has a non-zero x frequency, one with a non-zero y frequency, and one where both x and y are non-zero. The elements next to those are the next-higher frequency components.

To reconstruct the 8x8 pixels, you run the inverse discrete cosine transformation, which is lossless (to within rounding errors).

However, due to Nyquist[3], you don't need those higher-frequency components if you want a lower-resolution image. So if you instead strip away the highest-frequency components so you're left with a 7x7 block, you can run the inverse transform on that to get a 7x7 block of pixels which perfectly represents a 7/8 = 87.5% sized version of the original 8x8 block. And you can do this for each block in the image to get a 87.5% sized image.

Now, the pyramidal scheme takes advantage of this by rearranging how the elements in each transformed block is stored. First it stores the DC components of all the blocks the image. If you just used those, you'd get an image which perfectly represents a 1/8th-sized image.

Next it stores all the lowest-frequency components for all the blocks. Using the DC and those you have effectively 2x2 blocks, and can perfectly reconstruct a quarter-sized image.

Now, if the decoder knows the target size the image will be displayed at, it can then just stop reading when it has sufficiently large blocks to reconstruct the image near the target size.

Note that most good old JPEG decoders supports this already, however since the blocks are stored one after another it still requires reading the entire file from disk. If you have a fast disk and not too large images it can often be a win regardless. But if you have huge images which are often not used in their full resolution, then the pyramidal scheme is better.

[1]: https://en.wikipedia.org/wiki/Discrete_cosine_transform

[2]: https://eyy.co/tools/artifact-generator/ (artifact intensity 80 or above)

[3]: https://en.wikipedia.org/wiki/Nyquist%E2%80%93Shannon_sampli...

We call those mipmaps.

Which JXL supports, by the way. Tiling is mandatory for images bigger than 2048x2048, and you can construct images based on an 8x downscaled version, recursing that up to 4 times for up to 4096x downscaling.

That is awesome. In my domain, images (TIFFs usually) are up to 1m x 1m pixels and scaling usually goes 4x so that if you need 2x scaling you can just read 4 times as many tiles from the higher resolution level and downscale. With 8x scaling you need to go a level further - reading 16 pixels from the image to create 1 pixel of output. Not great but it would work and 4096 scaling would make the lowest resolution image 256 x 256 which is just what you need.

Yes, but unlike AVIF, JPEG XL supports progressive decoding, so you can see the picture in lower quality long before the download has finished. (Ordinary JPEG also supports progressive decoding, but in a much less efficient manner, which means you have to wait longer for previews with lower quality.)

I don’t think the issue with the exabyte image is progressive decoding, though it would at least get you an image of what is bringing down your machine while you wait for the inevitable!

An image of earth at very roughly 4cmx4cm resolution? (If I've knocked the zero's off correctly)

Each pixel would represent roughly 16cm^2 using a cylindrical equal-area projection. They would only be square at the equator though (representing less distance E-W and more distance N-S as you move away from the equator).

No projection of a sphere on a rectangle can preserve both direction and area.

I admit it, I was applying Cunningham’s Law. Disappointingly(?), you came to the same answer.

I admit I trusted your math; you seem to be off by a factor of 4:

  You have: 510.1e6km^2/1073741824/1073741824
  You want: cm^2
   * 4.4244122
   / 0.22601872

Strangely enough, units lacks area_earth, so I used the number from https://iere.org/what-is-the-area-of-the-earth/

I was starting with the length of the equator and assuming a spherical cow^Hplanet.

Did you perhaps use the diameter of the earth rather than the radius?

#PiIsWrong

https://www.tauday.com/

  You have: (40075km/tau)^2*4*pi/1073741824/1073741824
  You want: cm^2
   * 4.434018
   / 0.22552908

A selfie at that resolution would be some sort of super-resolution microscopy.

Reply on news.ycombinator.com