John Cupitt

I think we should also get rid of the libvips jp2k YCC conversion and just use mct (if I understand your discoveries correctly). And mct should be enabled iff subsample...

But we can use `mct` instead of implementing our own RGBYCC conversion, can't we? Aren't they functionally equivalent? Or that was my understanding. Yes, we still need to implement subsample/upsample,...

Oh heh I tried removing the ycc code and it's worse: ``` $ vips copy k2.jpg x.jp2[subsample-mode=on] $ ls -l x.jp2 -rw-r--r-- 1 john john 570288 Aug 2 18:23 x.jp2...

Sorry, I was pulled on to something else. OK, let's merge this and then adjust the CLRSPC in a separate commit.

This seems to be working for me on ubuntu 20.04 with libvips 8.10 and the system-installed libheif, x265 etc.: ``` $ wget https://images.weserv.nl/zebra.jpg --2020-09-06 13:25:04-- https://images.weserv.nl/zebra.jpg Resolving images.weserv.nl (images.weserv.nl)... 104.27.158.82,...

Ooop! Sorry, I missed the renaming there. Yes, I see the error too: ``` john@kiwi:~/pics$ vips copy x.heic.1 x.jpg (vips:409364): VIPS-WARNING **: 13:45:12.374: error in tile 0 x 0 heif:...

I think (from memory!) the check was for images smaller than one encoding tile. These used to not be clipped correctly.

Oh, you're right, it was the autorotate stuff that was breaking. That's gone now, fortunately. I'm not sure about this patch though. If that test fails, something is badly wrong,...

I had a quick go at another solution: https://github.com/libvips/libvips/compare/fix-heifload-clipping This clips the decoded image against the reported image size or pads the output, as required. It works with `poc.heic`, though...

Related: libheif 1.10 seem to have a bug setting the image dimensions. See: https://github.com/strukturag/libheif/issues/405 You need to test against 1.9.1.