Comment by m348e912
Comment by m348e912 2 days ago
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
Comment by m348e912 2 days ago
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
> 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
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!
"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
It couldn't have been a wrapper - it understood a tiny tiny fraction of the things that Gnu units does.
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.
The only practical way to work with such large images is if they are tiled and pyramidal anyway
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.
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.
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...
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.
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.
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.)
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:
No Gemini, you can't equate meters and miles, even if they do both abbreviate to 'm' sometimes.