@seebk we have already been talking about your mailing list post, but thank you for posting here as well, and 1000 thank yous for your work on the lensfun project.
@seebk just wanted to say thanks for all the effort. It’s easy to take it for granted when the program automatically adjusts for the lens’ shortcomings. Much appreciated!
@darix I won’t be at the LGM although it sounds like a lot of fun Did not follow the meeting for some while and wasn’t aware that it’s in Germany this year.
If you want to get in and help out in the Lensfun development that’s great. But the most important is to get a few people that make a plan and take care of the general maintenance tasks, coordinate the work and do this with a long-term scope. As I said on the mailing list, fixing a few things here and there and adding a new feature is one aspect. But making sure that it is all compatible between versions, everything works in the application context, that there are regular releases and fixes and that new features are maintained consistently is another story. And that’s where I see the biggest problem with my limited time.
@seebk, sorry this took a while to post, I’ve been working/thinking about it and also been busy with work/life/etc.
I would appreciate any feedback you may have about these.
Community plans for Lensfun
Project management tasks (immediate need!)
Migrate away from Source Forge
Get project admin access to the SourceForge project
Make an announcement that we’re moving!
Open a Lensfun category for support/mailing list on discuss.pixls.us
Archive the SF mailing list mails
Shutdown the SF mailing list
Migrate the SF wiki
Migrate the SF issues
Migrate the SF source code repo (to GitHub or GitLab? Under the pixls.us organization?)
Migrate website (get a domain name? Or just use GitHub pages?)
Make an announcement with the changes made above
Recruit new developers
Longer-term plans
Community participation
Contact closed-source applications and ask them to contribute (we should make it easier to add camera support to applications like darktable and RawTheapee; currently we must touch muliple projects)
Contact lens manufacturers and ask them to contribute (particularly 3rd party makes)
Developer/DevOps tasks
Use continuous integration to build packages (GitLab/Travis/CircleCI)
Use continuous integration for testing (GitLab/Appveyor)
Developer tasks
Make a new stable release
Allow database lens entries that contain calibration data from various crop factors. Lensfun then just picks the closest one for each requested modification.
Develop a strategy how to decouple the database from the library source code to allow a faster release of new profiles to the user base. There is already the lensfun-updata-data script, but this only works reliably on Linux and not on OSX and Windows until now.
Figure out how to share data between projects that need/use lensfun
Make getting full camera support easier: exiv2, lensfun, darktable, rawtherapee, other photo applications. Possibly maintain a database and generate the necessary files for each application
@paperdigits: There is already a Lensfun organisation on GitHub which is used for Thorsten Bronger’s calibration service. I can get in contact with him and ask about his opinion to make this the official repo.
There are two more things to consider when moving away from Sourceforge:
The lensfun-update-data script downloads the database from a Sourceforge http space. This has to be kept updated for a few years to make sure the script still works.
The Doxygen generated API docs are also on the Sourceforge webspace.
Both could be hosted on GitHub Pages in the future. It is not an ideal solution as GH Pages is not intended for this kind of hosting. But I would prefer it compared to using a dedicated web server where only a single person has access.
The Lensfun website is based on Jekyll, so GitHub Pages is the ideal environment for this.
we should make it easier to add camera support to applications like darktable and RawTheapee; currently we must touch muliple projects
Make getting full camera support easier: exiv2, lensfun, darktable, rawtherapee, other photo applications. Possibly maintain a database and generate the necessary files for each application
Not sure if I understand this. As soon as the camera is in Lensfun database it is available in each of the applications… isn’t it? The problem in my opinion is to find a way to push the database updates to the users.
Ah, these are excellent points. Thanks. I think we can make github pages work for the doxgen generated stuff, or we can merge those docs into the jekyll site.
Sorry I wasn’t clear. Actually, both of those points are pretty much the same, with the emphasis on the second point-- it includes lensfun and other projects.
When a new camera/lens comes out, we need to make additions to quite a few projects so that the camera/lens is useable in applications like darktable and RawTherapee.
We generally need to:
Collect a (raw) file
dump the metadata and find the lens name.
Submit the lens information to the exiv2 project to get the camera/lens name into exiv2 (darktable uses this to detect the lens name and match to the lens correction in lensfun)
Shoot calibration images for lensfun, process them with hugin
Submit the raw file to rawspeed/dcraw/other raw demoasicing libraries for support
I’m sure this isn’t even close to all the of the work that needs to be done, but it already touches multiple projects. I’d like to find a way to make all of that easier for people to contribute. Whether we just maintain a big database of cameras & lenses and other information necessary, it isn’t clear to me. But we need to do something in the future.
The main reason why I want to push on this front is that right now it takes way too long from “We have the information available” to “users can use it easily”.
Ok, I see, thanks for the clarifications. You are talking about all aspects of camera support including exif and raw decoding. Adding full camera support indeed is a long process right now in particular when considering that some Linux distributions like Debian are only updated in a 2-year cycle.
Regarding GitHub: I will move over the project from Sourceforge in the next weeks or so. Shouldn’t be too much effort I think…
I would suggest gitlab over github. One point is their CI and the other is that moving gitlab instances is easy. You can export your data and import it again
Btw. does lensfun already have support for Teleconvertors? I don’t own one yet but I wonder how the lens is reported.
A suggestion: Split the code base and the database into two separate projects.
With this organization, a robust database community could contribute without messing with the developers maintaining the code. If the v2 database organization is stable, I think this’d be a good way to manage all this going forward. But, if/when a v3 database is posited, a new database project could then be started…
I do not know GitLab very well, so it might have some benefits I do not know. But for Lensfun I think it is now best to be on a platform that is widely used to catch attraction of new developers. Once there is a stable team, moving Lensfun to GitLab or whatever platform is preferred shoudn’t be a big issue.
Btw. does lensfun already have support for Teleconvertors? I don’t own one yet but I wonder how the lens is reported.
A suggestion: Split the code base and the database into two separate projects.
That might make sense, but is a bigger step than one would imagine on first glance. It’s basically what I have summarised above as “Develop a strategy how to decouple the database from the library source code”. So I think that will be on the todo list but is one of the open items I never found the time to work on…
I just moved the website and transferred the roadmap into a couple of GitHub issues with a next release milestone. Still have to look into transferring the issues and archives, but that’s nothing to worry about.
I think one of the most important issues and easy for someone from the outside would now be to setup Travis and AppVeyor on GitHub