Support for Canon Automatic Lighting Optimizer EXIF flag in newer (CR3) files

[cytrinox]

PR #19375 added highlight preservation modes, but only for older Canon cameras. In CR3 files, the EXIF tag name has changed.

This patch adds support for the new tag "Exif.CanonLiOp.AutoLightingOptimizer"

I've also added a call to dt_exif_img_check_additional_tags() to libraw io path as it was only called in rawspeed io yet. This function is responsible to load the EXIF tags required for #19375 to work.

[ralfbrown]

Release note:

• Added Canon Automatic Lighting Optimizer support for CR3-format images

[kmilos]

@TurboGit @ralfbrown This was meant for master branch, no?

[TurboGit]

Ah good catch, the merge was registered on 5.4.x branch.

@cytrinox : Please never ever do that! All branches must be merged on master except for very rare cases where we need separate code on master & release branch.

[kmilos]

@TurboGit P.S. Also, there are still missing commits and the actual 5.4.1 tag on the 5.4.x branch...

[TurboGit]

You're speaking of all changes on nightly.yml? That's fine, those were needed to create the 5.4.1 binaries on GitLab.

[kmilos]

That's fine

See the big fat warning at 75089bd

That tagged commit is nowhere to be found:

$ git tag -l release-5*
release-5.0.0
release-5.0.1
release-5.1.0
release-5.2.0
release-5.2.1
release-5.3.0
release-5.4.0
release-5.5.0

So, no, not fine - users/devs cannot check out the 5.4.1 release.

Maybe not a huge deal after the fact, but can't really agree w/ that release process: the release tag should be on a commit from the branch, and the source tarball generated from that commit for reproducibility.

[TurboGit]

I'm no fan of the situation either. But after tagging and trying to create the release on GitLab I found that there was issues. For example no x86_64 macOS release. Since the tag was already pushed I didn't want to move it.

Should I move the tag to top of darktable-5.4.x branch now? What do you think? Maybe preferable to the current situation.

[kmilos]

Should I move the tag to top of darktable-5.4.x branch now? What do you think? Maybe preferable to the current situation.

I thinks so - adding those missing 3-4 commits to the branch (if the hash stays?) shouldn't really move the tag. But I think you should also reset the 5.4.x branch to c3f96ca beforehand...

Worst case (as commits are not in the darktable repo so probably can't keep the hash), I'd: 1. reset, 2. add those missing commits, and then retag.

[TurboGit]

I haven't reset otherwise we won't be able to recreate the binaries from GitLab-CI if needed. I have moved the tag to the commit where one can recreate the 5.4.1 release as it was released. I still don't understand one thing, why the tag was on an unreachable commit. What a mess !

[kmilos]

I have moved the tag to the commit where one can recreate the 5.4.1 release as it was released. I still don't understand one thing, why the tag was on an unreachable commit.

Hm, there was less harm in resetting to c3f96ca and then applying those commits on top. Now the tag doesn't correspond to the released package for sure 😉 - it now also contains this extra unreleased commit acd5b79

What a mess !

That's what release checklists are for 😉 (and no rushing...)

[TurboGit]

That's what release checklists are for 😉 (and no rushing...)

Trust me, I did follow the checklist...