It has been suggested it can take 12 to 18 months before a specific RAW format is supported and then added into darktable. Can anyone confirm the timeframe for LibRaw and when darktable will add support for the canon R5 Mark II camera? Someone must know the timeline. Considering we are now at the point when support should be close to implementation.
if you provide the patch! very very soon!
if you can only provide sample files. it depends on how many code changes are needed
if you dont do anything to help and just ask for it … it can take a lot of time.
Only LibRaw developers know the timeline.
darktable will add it in the release after LibRaw publishes it.
“Pulling on the grass doesn’t make it grow faster.”
3 Likes
As it turns out, not how it works w/ LibRaw…
Understood but considering the popularity of the camera. Hard to believe there have been no samples supplied after almost a year.
It is not about samples (they’re available on RPU), it is about LibRaw’s update policy (i.e. business strategy).
Caveat emptor
Given that 0.21 came out end of 2022 (and last public snapshot in Feb), we might be lucky to have 0.22 at the end of this year (assuming they stick to the max 3yr policy gap between major releases). If we’re really lucky, it’ll happen before Dec 15, so we can actually use it in the next dt 5.4 Christmas release.
2 Likes
maybe time to use that rust raw loader library, which is used in vkdt.
There is also an ongoing RIIR effort for RawSpeed, perhaps it’ll handle more codecs as well. In any case, my guess is that near term, for this specific model, LibRaw version should come sooner…
Part of me feels we should blacklist LibRaw. Their approach does not fit the spirit of FOSS.
5 Likes
how so?
TBH … we dont need yet another raw library in rust. rather help rawler (GitHub - dnglab/dnglab: Camera RAW to DNG file format converter)
To put it mildly it sucks. It is very clear LibRaw has the information required and has had a working version as far back as Feb. It is clear the people that provided the snapshots were not treated fairly and are extremely frustrated. Their upgrade policy is terrible.
I understand there must be caution beyond what the user community might prefer. Still the policy does not come down from the high wizard. LibRaw should revisit their upgrade policy.
2 Likes
Yeah, their responses in that thread were pretty eye opening… Pretty Anti-contributor.
> Say the PR isn’t ready to merge without providing details
> Later say that the contributor didn’t do any tests besides Trust me bro
> Don’t have testing framework
> Ask for tests from the contributor confirming that he didn’t break anything else
Either create a testing framework for their project, or do the tests themselves. Volunteer contributors shouldn’t have to deal with such baggage.
Good thing other projects like rawler are gaining traction.
8 Likes
Oh, like libopenraw as well? 
1 Like
I want to start by saying, what they are doing seems perfectly legal to me.
It is very clear that the business/commercial interest are the priority when the release cycle can be 3 years. Outside contributions don’t seem to be welcomed.
Therefore I think if we want faster support and engaged contributions, we should stop using LibRaw and get behind a different project. Of course, which one…
3 Likes
I agree and it is pitiful. Makes me feel better about not understanding the RAW submission instructions. I might be clueless but reading the requirements for RAW submission had my head spinning.
1 Like
I find the business/commercial support is a reason why every three years is terrible. Yes, they want stability but every three years? This isn’t an OS.
1 Like
It’s not (primarily) about stability.
It has to be based on what darktable and other open source developers can agree upon. Without their support nothing we say matters. If only one agrees then they may not have the market power to gain support for the new project.