But we were getting closer!! ![]()
I never said there should be a deadline. They had it ready a year ago. If there were issues forcing delays. Of course i would understand.
Open source is special but it does not mean a free pass. We can point out issues when they occur. Open source does not mean untouchable.
Maybe my misinterpretation. I get the feeling people are treating this as if libraw is the poster child for open source. There are millions of other open source projects both big and small. Does libraw act respectively towards the community? You decide.
you can point out your issue, but thatâs just freedom of speech. But also thereâs no such thing as an obligation to listen or try to meet everybodyâs demands.
If you donât like the freedom of the developer to prioritize their time and work then youâre free to pay someone to fulfill your expectations. Or fork and do it better ![]()
I think most of the feedback is from open source developers who struggle to manage a real life - open source dev balance.
I have 2 projects that are over a year old, bringing group persistence across database instances to darktable and adding the lua-scripts to darktable releases. Group persistence was almost complete 9 months ago and then my life turned into a Lemony Snickets A Series of Unfortunate Events book. In just the last week Iâve picked it back up and am trying to finish it.
As far as adding the lua-scripts to the release I did some preliminary work and figured out a course of action and then it fell by the wayside when real life took over. Itâs still my plan to do it, but it doesnât have a timeline at present.
Iâm not even going to mention the other open source areas Iâve neglected, but there are some.
A year sounds like a lot of time to get something done. When I was young and single, responsible for only myself, it truly was. Now that Iâm older and have numerous responsibilities, some of which I have little control over, I find a year FLYS by.
Actually quite the opposite. Most opensource licenses have a clause like:
âbecause the program is licensed free of charge, there is no warranty for the program, to the extent permitted by applicable law. except when otherwise stated in writing the copyright holders and/or other parties provide the program âas isâ without warranty of any kind, either expressed or implied, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose. the entire risk as to the quality and performance of the program is with you. should the program prove defective, you assume the cost of all necessary servicing, repair or correction.â
For the record, I do agree with this completely. I would prefer libraw to act much faster. That would be more respectful of the community, and better for the ecosystem.
But I also know from my own experience that you sometimes just⌠canât. It is ultimately up to dev(s?), not me, and I trust they have good reasons for doing the things the way theyâre doing them. Iâm grateful theyâre doing the work at all â while at the same time wishing theyâd do it faster. But I often canât bring myself to do things faster either, because
sometimes.
On a different note, I highly respect that, @pilgrim, you stayed calm and polite throughout this exchange. This is unusual, and praiseworthy. Thank you for that.
I believe libraw delays the relaese so their pay-for products get it first and keep their âmarket advantage.â They donât seem to take pull requests and it is a true âthrow it over the fenceâ open source. I donât think there is a âcommunityâ around it. So in that case, you either take it or leave it, and weâve chosen to take it, despite the draw backs, to get CR3 support which Roman was unable or uninterested in supporting in rawspeed. âIt is what it isâ is the correct turn of phrase here.
@cytrinox Are you perhaps considering a C API for rawler?
As someone who also maintains an open source software project I can emphasise somewhat with their position. My understanding is that libraw sells commercial support for their product. This means that what they ship has to work and, more to the point, the main developers need to have a working understanding of all of the codeâafter all they may be required by contract to fix a bug in it.
Given this I can understand why they hold pull requests to such high standards and are so hesitant about merging. If you donât have full confidence in a feature, do not fully understand the code, your only real option here is not to merge. The upside is limited (a new feature) but the downside is unbounded (having to fix code you donât understand which may turn out to be buggy and or incomplete).
Now, holding back releases is another matter entirely, but if this is what is required for them to be able to devote meaningful time to the project then it is likely a worthwhile tradeoff.
Regards, Freddie.
Yes, but without a timeline.
Once a C API is available, I fear that more people will push for integration into darktable. I donât think rawler is mature enough to be integrated into a project with such a large user base (at least not yet). Anyone who wants to use a camera in darktable that is not yet supported but is already in rawler can convert the files to DNGs using dnglab. That is the main purpose for which I developed dnglab & rawler, and for sure, DNGs are larger - yes, but storage space is cheap these days.
If someone really want to improve faster camera support, just ask your camera dealer for a camera with public available documentation about their image & compression format.
fwiw i have a thin c-wrapper rust library.
only one way to find out⌠but i can relate to your sentiment here. large user bases come with a lot of tiring noise. i suppose dt uses multiple backends anyways and could fall back to whatever in case rawler doesnât work. i found using rawler really a pleasure, using it as the default backend for years now.
Why not blame them fully?
Add Canon EOS R6 Mark III support by JuanPabloZambrano ¡ Pull Request #745 ¡ LibRaw/LibRaw ¡ GitHub and a few other people going to be disappointed