5 ms·
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 contiguou
by gyan 4y ago
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.
- chungy 4y agoWebP 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.
- gfxgirl 4y agoMy guess the limits are because, WebP is based on WebM (video) I agree those limits are too small.
- chungy 4y agoWebP'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.
- sitkack 4y agoOne solution would be to hold multiple images inside of another wrapper container like zip. The client code would have to handle stitching them together.