Introduce IOP order v3.1 for testting purpose.

[TurboGit]

No description provided.

[TurboGit]

@jenshannoschwalm : I have added a 3.1 IOP order with finalscale & colorout swapped for testing purpose. I do see that the image keeps its luminosity but the color shift is still there to me.

In summary:

Exporting without HQ images are identical.
Exporting in HQ images are now keeping there exposure so better.

We still need to asses if this also avoid the magenta/green color cast shift.

[TurboGit]

Ok, testing on the RAW with the dog I see that the color cast of HQ matches the export which is not the case with 3.0 iop-order. So yes, now I see that this fixes the issue on my side.

[jenshannoschwalm]

Yes - works for me too.

There is one more subtle "problem" - if we downscale either in demosaic or finalscale and there is very strong local variance - due to strong noise, moire patterns or "synthetical data" - the scaling is let's say suboptimal and that might lead to a color shift.

This also depends on the chosen interpolator, for sure the lancoz variants are introducing more errors.

Not sure yet how to fix that. Experiments so far support the idea, to do some blurring before the downscaling, this can also be found in the science literature ... Don't know yet.
Anyway, this problem seems not related to the new iop-order.

[TurboGit]

Anyway, this problem seems not related to the new iop-order.

So should we go with this new iop order?

If so, I still need to make this new order the default.

[jenshannoschwalm]

So should we go with this new iop order?

I would say yes.

[TurboGit]

@jenshannoschwalm : Please can you test and review, I don't want to break something in this :) TIA.

[jenshannoschwalm]

Will do tomorrow ...

[jenshannoschwalm]

Did my review and quite intensive testing - see also #17787 .

1. Everything works as intended by this pr. Default for new imported raw images is correct, can switch module order in darkroom safely and with correct order afterwards. No problem at all. Works with duplicates, snapshots.
2. As we know this new order doesn't fully fix issues discussed in Image before export is too red, but after it is too green. #17758. There are still problems related to averaging data while interpolating. So pending work either in finalscale or the interpolators ... But as we are discussing iop_order here, i am pretty sure we a) can't do better for now and b) those remaining issues have to be solved otherwise and elsewhere.
3. Checked and proofread source, no objections or further suggestions.

Some ideas / questions:

1. I guess we really want the new order and can't "just replace" in 3.0 ?
2. In principle we also would want this for non_raw images, no ?

For the record:
While checking the iop_order related code, i am not sure about dt_ioppr_check_duplicate_iop_order(). It works on dt_iop_module_t so the order is int, not on dt_iop_order_entry_t where order is double. We correct the order there by diff / 2.0 or 0,5, both could lead to unchanged int iop_order. Or do i oversee something?

[TurboGit]

1. I guess we really want the new order and can't "just replace" in 3.0 ?

Right, this will change export for people having tailored the IOP to get proper export.

2. In principle we also would want this for non_raw images, no ?

Indeed. Will add the same change for non-raw.

Or do i oversee something?

No, seems like the check routine is broken indeed :( I'll open a separate issue and will fix.

[TurboGit]

@jenshannoschwalm : I have just pushed a new version with JPG support and fixing the check duplicate module routine. Should be ok for integration.

[jenshannoschwalm]

Just checked, ok for me too. Also checked the duplicate thing.