For Fuji cameras users

Processing
1

I’ve ported code from dnglab that would allow Darktable users to decode lossy-compressed RAF files.

However, it seems the maintainer, Roman, is no longer interested in maintaining the project:

So for now, you’ll need to build from the PR yourself for this to work.

1 Like
2

I do think the better long-term solution would be to use Rawler instead of LibRaw, which would solve several issues at once. No more having to deal with LibRaw’s release policies, plus support for CR3 and JPEG-XL compressed DNGs.

@cytrinox Do you still consider Rawler not ready for primetime?

1 Like
3

Well, to me it looks like Darktable users are a bit stuck with rawspeed not moving forward. So far:

  1. rawspeed’s C++ development has slowed significantly.
  2. “Oxidized RawSpeed” exists, but we don’t know what it covers or how well it works yet.
  3. dnglab is actively maintained and developed.
  4. Darktable knows how to “speak” rawspeed’s language.

So, thinking from a Darktable user’s perspective, someone could:

  1. Fork rawspeed.
  2. Try to pull in the outstanding PRs.
  3. Identify problem areas (CR3, DNG JPEG-XL, etc.) and write a wrapper that delegates those calls to dnglab.

It’s not an ideal situation, but it’s much better than not being able to use the raw files you actually have. This way we wouldn’t exclude anyone, we’d keep the good existing implementations, and changes to Darktable itself would stay minimal.

This isn’t ideal software design, but from a user’s perspective, it would be very satisfying.

4

No, it needs a stable C FFI first and this is not yet on the roadmap. Maybe for v0.10.0.

2 Likes
5

VKDT uses rawler, I’ve compiled with it and it seems to work fine.

1 Like
6

As I already mentioned elsewhere in the forum, the point is not which raw decoding library is more feature and camera model complete at any given point in time, as that advantage shifts and changes from one to the other…

The fundamental issue, with all due respect to Roman (RawSpeed), Daniel (rawler), and Hubert (libopenraw), is that all three* projects are (for whatever reason) unfortunately currently operating with a single bottleneck and a single point of failure (and this is not specific to these, I sadly feel FLOSS maintainer/developer burn-out everywhere). Hopping to any of the alternatives might improve end user experience temporarily, but the risk to come back full circle to the same stalling situation remains.

* I didn’t include LibRaw in the same bag as it brings its own set of issues…

2 Likes
7

Forking and merging a few PR is easy. A commitment to long term maintenance of the fork is the real issue.

1 Like
8

Brainstorming.

What if we had a section in preferences to pick which raw decoder to use?. In an order of operations style. By default raw speed is first, then rawler, then libraw, then xyz. Each one will have a checkbox like opencl. We could add the words (experimental) to the rawler one. This gives the user the option of which one to use (and the associated risks).

9

sounds like a lot of maintenance burden