On Tue Mar 18 23:33:01 2025 +0000, Connor McAdams wrote:
Okay I don't know what I was saying earlier, spent some time thinking this over while taking a walk :D it had 8x8 quadrants before. AFAIU from some researching just now, JPEG is usually encoded as 4:2:0, which results in 8x8 blocks for luma, and 16x16 blocks for chroma IIUC. Which would explain why upping the size to 32x32 increases the accuracy of compression here. Not sure how much it matters, but wanted to make sure what I did actually made sense.
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...