John Cupitt
Ah, nice find! I'll have a look, thanks @mbklein
Yes, `opj_decompress` is presumably using some extra API for computing tile indexes, but I've not found time to discover it yet.
I found something: ``` $ vips crop y1980-25.jp2 x.png 1024 0 748 1024 ``` (ie. fetch tile 1) seems to work fine. It only fails if you try to fetch...
Well done! Sorry I wasn't more active on this issue. openjpeg don't generally move too quickly, so we could perhaps patch openjpeg to fix this in our binaries if we...
Wow, I wouldn't have guessed that as a possible fix! Crazy stuff. Tile-at-a-time reading is a big win, especially for large images, since you don't need to keep the whole...
I had another thought -- could this be a regression from previous versions of openjpeg? It might be worth quickly testing with 2.4 and before to see if they handle...
Then I suppose the only workaround is to add a flag to put the libvips jp2k loader into one-shot mode. This will be slower and have worse memory behaviour, but...
Hi @dloebl, Yes, that's strange. I see: ``` $ vips black huge.png 30000 30000 $ /usr/bin/time -f %M:%e vipsthumbnail huge.png -o x.png --size 20x20 268800:4.07 $ /usr/bin/time -f %M:%e vipsthumbnail...