Hacker News Reader

Comment by 8n4vidtmkvmk | Hacker News Reader

I've been having a problem recently.. apparently every modern image format has a max of either 16K or 64K width or height. I generated a PNG with stable diffusion that was about 70K pixels tall and 2GB. never figured out how to compress it. jpg, webp and avif wouldn't accept it.

View on HN

It is also crazy to me that so many image formats have such small size caps. I understand not wanting to use extra space for small images, but I can't think of any reason to have a maximum image size smaller than your maximum hard drive size. You probably don't want to unconditionally store 8 bytes for width and height, but you could pretty easily make it only use 1 byte for small images and for anything big, you won't miss the extra 6 bytes.

It may have to do with limitations of allocating memory chunks on 32-bit machines when these formats were originally designed. The decoder allocates a contiguous buffer that can hold the whole image.

WebP is recent enough that it shouldn't have even been a real concern. 16383×16383 even in 2010 was an absurdly small size. I've had PNGs and JPEGs with larger dimensions for longer than WebP has even existed.

My guess the limits are because, WebP is based on WebM (video)

I agree those limits are too small.

WebP's lossy codec is based on VP8 intraframes; the lossless codec is original. Either mode of which is contained in a RIFF file, which is where the dimension limits happen (RIFF's headers have enough space to represent 2^14-1).

WebM is, strictly speaking, a container format that is a subset of Matroska. It doesn't have any real relation to WebP.

One solution would be to hold multiple images inside of another wrapper container like zip. The client code would have to handle stitching them together.

That would be a new image file format.

Not a good idea for lossy codecs. You might get seams.

OpenEXR (designed for, and used by the VFX industry) supports dimensions up to int32 = 2 billion, but is a float16/float32 pixel format only (It can do int32 for IDs, so technically you could multiplex/combine/bitshift 8-bit values into one int32 if you really wanted).

JPEG should be fine with those dimensions (did you try mozjpeg's cjpeg?), but WebP is contained in a RIFF format and has a limit of 16383 pixels in either of its dimensions. Don't know the technicals of AVIF, but being derived from a video format, it's not going to be designed for large sizes in the first place, and I don't know if it also uses RIFF for the same limits.

PNG and JPEG XL are actually made for, well, still images; JPEG XL especially has no practical limitation on dimensions, it'll take whatever you can throw at it, given you have the hardware to process it. JPEG XL is either lossy or lossless at your option ;)

JPEG's technically limited to 64x64k dimensions per the spec (65500 pixels with libjpeg and libturbojpeg), so if you want arbitrary software to be able to open images in that format, you'd be limited to that...

TIFF will support that size and larger. It can use JPEG or ZLIB compression as standard, or even WEBP or JPEG-XL which are unofficially supported by a small number of TIFF libraries.

jpeg-xl should do it. It was specifically designed to make sure it can support crazy resolutions and number of channels.

Depending on what you want to do withe the compressed result, then you could also.. tile it. Not great, probably some common data structures get duplicated within the tiles, but maybe that gactors out for really large images?

Just an idea.

Reply on news.ycombinator.com