Update the very outdated camera support page

[victoryforce]

This page should be updated with each release. Unfortunately, it was forgotten and reflected camera support in darktable 3.4, when 4.0 was already released.

Since at the moment support for raw formats is provided by two libraries, we can't just run rawspeed's check_camera_support utility and get a list of all supported models.

Fortunately, there are not many "cr3" models from Canon, so the data about them was added manually, taking the list of models from the release announcement. In the future, it will be possible to automate it more (well, if rawspeed will still be catching up), for which you need to keep a list of models that create "cr3" files. Then we can check their support by the libraw library by searching its cameralist.cpp file.

Additionally, the number of supported models in the table header was corrected and percentages were recalculated.

[elstoc]

I'd rather find some way to automate this from darktable and then update dtorg. Otherwise errors will creep in and we have no [easy] way to confirm the changes you've made are correct.

Is there a FR on the darktable repo for this?

[paperdigits]

I thought there was a script in the darktable/rawspeed repo that generated this?

On August 6, 2022 1:35:00 PM PDT, Chris Elston @.***> wrote:

I'd rather find some way to automate this from darktable and then update dtorg. Otherwise errors will creep in and we have no [easy] way to confirm the changes you've made are correct.

-- Reply to this email directly or view it on GitHub: https://github.com/darktable-org/dtorg/pull/199#issuecomment-1207279094 You are receiving this because you are subscribed to this thread.

Message ID: @.***>

[elstoc]

@paperdigits there is but we also use libraw now

[victoryforce]

I'd rather find some way to automate this from darktable and then update dtorg.

Of course, that would be ideal.

But in the real world:

• automation requires improvement of the script written in ruby
• the author of the script has long been uninterested even in such simple things as accepting PR in the rawspeed repository, what can we say about improving the script
• I have no experience working with ruby
• I can try to learn ruby ​​at a level sufficient to improve the script (it's even interesting to some extent), but learning about ruby ​​is not very high (to say the least) on my priority list, so it will take a lot of time

Why I think it's better to accept my fix first and then work on full automation:

• errors (many errors) have already crept into this page simply because it is terribly outdated.
• you may suspect me of errors, but my editing has in any case greatly reduced the number of errors on this page (even if some remain).
• I checked on the raw samples that the models specified in the release announcement are really supported.
• I can assume the possibility that some supported model was forgotten to be mentioned in the release announcement, and as a result I did not include it in the list. But I don't think it's worth rejecting my much more accurate list because of this possibility.
• I did not check the accuracy of the extended support (WB presets, noise profiles etc) specified in the announcement. I can assume that there may be incomplete information. It actually can be and I think that this is the maximum inaccuracy that can be in reality. (I can also check this manually for more accuracy)

[elstoc]

I don't suspect errors, I just have no way to confirm one way or another so will have to take your word for it that it's an improvement and is accurate. Would you mind raising an issue against the darktable project, which perhaps is the only place where we could produce a single combined output from libraw and rawspeed (I'm very much guessing here). Also stuff is more likely to get merged in that repo.