Fix Canon EOS 5D Mark II crop

[kmilos]

See https://discuss.pixls.us/t/how-can-i-merge-these-three-cr2-images-to-an-hdr-without-them-turning-bright-pink/43482

[LebedevRI]

To confirm my understanding, the problem really is that the produced "HDR" DNG ends up with different [Bayer] CFA Phase, not that some black/white level is wrong due to the crop?

Then, while i acknowledge that it seems to fix this particular instance, i'm skeptical that this is the right fix. Does dt forget to shift the CFA after cropping the raw?

[kmilos]

i'm skeptical that this is the right fix. Does dt forget to shift the CFA after cropping the raw?

It is indeed not a generic fix for the problem. HDR merge in raw is a bit of corner use case and doesn't get enough testing. For the general demosaic use case, dt handles the crop and pattern shift just fine. I'll check if the same is missing in that HDR code path...

I think we should still merge this regardless, having and odd size image is just weird.

[LebedevRI]

I need to check if the crop is actually wrong and needs adjusting, maybe it does, but i'm not really sure this makes sense from the consistency standpoint, as a matter of a rule, since there's always the DNG's where we can't possibly control what the crop is.

[kmilos]

FWIW, this is LibRaw's output:

$ unprocessed_raw.exe -T Canon\ -\ EOS\ 5D\ Mark\ II\ -\ RAW\ \(3_2\).cr2
Processing file Canon - EOS 5D Mark II - RAW (3_2).cr2
Image size: 5634x3752
Raw size: 5792x3804
Margins: top=52, left=158
Unpacked....
Stored to file Canon - EOS 5D Mark II - RAW (3_2).cr2.tiff

[LibRaw]

LibRaw's output:

LibRaw's top/left margins are always multiple of 2 for bayer/mutiple of 6 for X-Trans to avoid ambiguity (What exactly do the filter specifications refer to - the full image or the visible area?)