Could someone please explain how this would be implemented and the steps involved.
Thanks,
Mike
I don’t understand what you mean. With this commit, @Lawrence37 enabled an automated build for Windows directly within the main RawTherapee repository. The older system provided by @Carmelo_DrRaw was broken and maintenance was out of our own hands.
Thanks to Lawrence, we will have a new, official, general purpose build available whenever something is committed to the dev branch. The zip and installer show up here: https://github.com/Beep6581/RawTherapee/releases/tag/nightly-github-actions
We will need a little time to update some documentation so that everybody knows 
2 Likes
Thanks, Roel,
Now I understand.
Nice to have Windows-Dev builds, thanks.
Sorry for hijacking this thread, but the lens correction module doesn’t seem to work. All the dropdown dialogs are greyed out.
It happens with the portable zip and installer exe and raws from 4 different cams. Am I missing something?
1 Like
No, you are correct.
Looking into it…
@apostel338 How did you install this version of RT? Did you use the zip or the installer?
In any case, could you please use Windows Explorer, type in the address bar %LOCALAPPDATA%/RawTherapee5-dev, open the options file with Notepad or something, scroll all the way to the bottom and copy/paste the [Lensfun] block here?
I tried both.
option file says:
[Lensfun]
DBDirectory=././share/lensfun
It seems to work when I change it to
[Lensfun]
DBDirectory=././share/lensfun/version_1
Thank you for looking into it.
Interesting, the first option is definitely wrong and not what the automated build generates. Perhaps it’s a leftover of a previous configuration?
Otherwise, now you know how to solve it. I don’t think this is something we can fix in general. Right, @Lawrence37 ?
dafuq, yes it seems to be like that. I deleted the folder and the newly created one is fine. I tried gaaneds builds in the past. Sorry for false alert.
The new builds have the same cache suffix as the old ones, but the lensfun files are in a different directory. I can change the directory to be consistent with the old builds. Otherwise, I can leave it as-is and anyone who has used the old builds previously need to update the lensfun directory in preferences.
Being that most of us are upgrading from the old build, I think, wouldn’t it make sense to change the directory to be consistent with the old builds as you suggested?
Ages ago, it was chosen to put the DB in share/lensfun and all previous builds have their DB at this location and it was ok.
very old lensfun builds will use version_1. New versions will use
version_2
the only problem is to be coherent between the option file and the build.
1 Like
@gaaned92, now that automated has been implemented, will you continue to offer your builds?
I’d highly recommend you build against lensfun 0.3.2. 0.3.95 is a beta release.
I’m probably missing something, but how is one to know when these files were released if there is no date?
You can either look in the corresponding ...-AboutThisBuild.txt or view the build history at https://github.com/Beep6581/RawTherapee/actions
I would have liked to add the date or version in the name, but it’s not so easy.
1 Like
Yes, but be aware that its more dev than dev ! as I also build bleeding edge versions of lensfun, lcms2, exiv2, with extra optimization for lcms2
!!??
v0.3.2 dates back to 15/11/2015, 7 years old!
v0.3.95 is even described as an alpha release.
v0.3.95 is from 29/06/2018 and there are about 740 commits after this date. I suppose they are useful.
Sorry, but I don’t agree, at least for development builds.
The best would be to help the lensfun team to freeze and tag a new version.
I don’t know the issues with the script language used and if it permits to append a string to a string.
In bash, it is rather straightforward
name of branch
BRANCH=$(echo $(git symbolic-ref --short -q HEAD))
version
VERSION=$(git describe --tags --always)
Commits number from last tag
GIT_TAG=$(git tag --merged HEAD)
GIT_COMMITS=$(git rev-list --count HEAD --not ${GIT_TAG})
Changelog from two last tags
CHANGELOG=$TEMP/changelog-"$BRANCH"-"$VERSION.txt"
git log `git describe --tags --abbrev=0`..HEAD > $CHANGELOG
git describe --tags --abbrev=0 >> $CHANGELOG
git log $(git describe --abbrev=0 --tags $(git describe --abbrev=0)^)...$(git describe --abbrev=0) >> $CHANGELOG
git describe --tags --abbrev=0 $(git describe --tags --abbrev=0)^ >> $CHANGELOG
Date of last commit. I use that and not the date of build
COMMIT_DATE=$(git show -s --format=%cd --date=format:%y%m%d)
Afaik, there are known issues, regardless of the number of commits to lensfun after 0.3.2. See e.g. lensfun >=0.3.95 break existing image edits with lens corrections enabled · Issue #2813 · darktable-org/darktable · GitHub, Update lensfun 0.3.95 function calls by payano · Pull Request #10507 · darktable-org/darktable · GitHub and Support lensfun library to 2.0.0 by payano · Pull Request #9049 · darktable-org/darktable · GitHub (the last two were not merged). The lensfun API has changed, so unless RawTherapee updates to accommodate the new methods, there will be issues. See: Scaling API backward compatibility to 0.3.2 by uchrisu · Pull Request #1174 · lensfun/lensfun · GitHub
1 Like
@Thanatomanic
As long as I can build without warning or error and that the results of lensfun correction seem good or at least sensible, I don’t bother. But surely I am wrong.
I will make some comparisons with automatic build to observe the differences.
edit: as far as I can see after examining 11 images, the difference is not discernible. Perhaps, in some corner case, last lensfun development version could bring some improvement.
So, as far as I can assess, there is no real drawback to stay with 0.3.2.