Hacker News Reader

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.

View on HN

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.

Reply on news.ycombinator.com