On Thu Mar 20 00:24:33 2025 +0000, Matteo Bruni wrote:
Thanks for the deep dive. It makes sense to me, very interesting! Don't go crazy into further investigations, BUT if you're already set up, you could try to disable chroma subsampling[1] and see if that checks out. At any rate, the current version seems certainly fine for this general `D3DXSaveVolumeToFile()` test and this MR. It's up to you how to follow up on this JPEG compression detail. If disabling chroma subsampling does the trick, we have a path to properly fixing it, at some point. Either way, a test highlighting the issue would be probably ideal, with a small comment explaining the issue and possibly a `FIXME()` when saving to `D3DXIFF_JPG`. But I'm cool anyway, as long as there will be *something* to remind us when we forget. [1]: With a very quick and dirty search I found this:
cinfo->comp_info[0].v_samp_factor = 1; cinfo->comp_info[0].h_samp_factor = 1;which might or might not be easy to integrate into windowscodecs and do the right thing...
Ah yep, changing those component sampling factors fixes the old tests, it actually makes our encoder produce better results than the native one. :)
I'll write a test showing this in the next MR. As for how to integrate it into windowscodecs, it looks like there's an option to set [WICJpegYCrCbSubsamplingOption](https://learn.microsoft.com/en-us/windows/win32/api/wincodec/ne-wincodec-wic...) which we don't currently handle.
Thanks for the thorough review and looking further into this! :D