Felix Bünemann

Yes, because we do YCbCr 4:2:0 with subsample_mode on, but without subsample_mode off and mct 1 OpenJPEG does YCbCr 4:4:4, so of course file size is larger. I can't judge...

The JPEG2000 image shows as grayscale in any app on my Mac: Preview, Safari, Pixelmator. You are right, converting the file back to jpg gives the correct colors. But if...

@jcupitt Yes, the bug doesn't happen with odd widths. Eg. 1023x1023px OK, 1024x1024px buggy.

Here's an example what it looks like after converting back from JPEG200 to JPEG using ImageMagick: Source 1023x1023px:  Source 1024x1024px: 

I noticed that converting the even width JPEG200 to PNG using `opj_decompress` from the OpenJPEG CLI tools also works fine.

I noticed some difference when dumping the files with `opj_dump`: 1023x1023px created by Vips: ``` Image info { x0=0, y0=0 x1=1023, y1=1023 numcomps=3 component 0 { dx=1, dy=1 prec=8 sgnd=0...

@jcupitt The problem seems to be related to chroma subsampling, if I use `vips jp2ksave Earth1024.jpg Earth1024_no_ss.j2k --subsample-mode off` the image looks fine in all viewers. I noticed that the...

@jcupitt I found that ImageMagick sets x1 and y1 differently, based on which subsampling is used: https://github.com/ImageMagick/ImageMagick/blob/main/coders/jp2.c#L1019 But Vips just uses width and height: https://github.com/libvips/libvips/blob/master/libvips/foreign/jp2ksave.c#L714

Hmm, that's not it, I tried the following patch and still grayscale: ```diff diff --git a/libvips/foreign/jp2ksave.c b/libvips/foreign/jp2ksave.c index 530ce61f4..9a6c4a96d 100644 --- a/libvips/foreign/jp2ksave.c +++ b/libvips/foreign/jp2ksave.c @@ -711,8 +711,8 @@ vips_foreign_save_jp2k_new_image( VipsImage...

However the computation of x1 and y1 in libvips seems to be wrong, see: https://github.com/uclouvain/openjpeg/blob/master/src/bin/jp2/convertpng.c#L212 That matches what I did in my patch above, I'm only ignoring x0 and y0,...