Glad to see you here! We have corresponded a bit more and it seems the issue is with Wayland as I’m on kubuntu 25.4. I’m having trouble trying to run X11 so if someone here knows a way to temporarily switch from Wayland please let me know as I’m keen to try this out.
@CyberTimon, welcome to pixls.us! You’re in the right place, I set out to write my own raw processor some years ago, and the commentary and feedback from the folks here were instrumental to getting it done.
out of curiosity, why is that? i use rawler with fuji xtrans and am not aware of a systematic issue here.
1 Like
Are you really using the rust dnglab dnglab/rawler at main · dnglab/dnglab rawler and it’s working?
On the rawler repo, there are many reports, that RAF files don’t get demosaiced correctly:
Output DNG is completely red and not recognized by certain RAW viewers · Issue #525 · dnglab/dnglab
Rawler processing of fuji images inconsistent · Issue #415 · dnglab/dnglab
rawler probably unpacks the X-Teans raw data correctly, but dnglab probably doesn’t apply the correct demosaic algorithm when generating the preview. These are fully independent steps.
2 Likes
It can’t open Fuji RAW’s, so it us unusible
yes. i also commented (in the past) on one of the issues you linked. i don’t use any dnglab demosaicing/preview generation, maybe that’s the difference.
1 Like
I can confirm this is fixed in the current release. Nice work!
1 Like
I’m curious how much work it would take to get RapidRAWs processing and color science on par with Darktable/RawTherapee. If people who want a FOSS alternative to LR/C1 etc… could get the power ofDarktable with a more conventional UI they’d be all over this software. I already see some hype online about RapidRAW which is how I found out about it.
We mustn’t be too far off? The recent shader improvements have made a noticeable difference. I think we are missing the input curves for RAW files that are applied upon import along with the display color space mapping. But I’m not knowledgeable enough to answer that, maybe someone like @hanatos or @paperdigits could weigh in?
I don’t believe it’s possible to have “all the power of darktable” with a simple UX. The power of darktable is that all the knobs are exposed.
I’d be most worried about getting solid color management, and since RapidRaw is electron, it isn’t clear we’ll ever have that.
4 Likes
Being not-that familiar with Electron, what of it would keep good color management from happening?
1 Like
Its a thing to package webapps as desktop apps. So there is a whole browser in there.
1 Like
The UI is Electron but the processing all seems to be done in Rust, so theoretically anything is possible. Electron apps have a reputation for only being able to be basic webapps, but it’s not really true.
3 Likes
It’s Tauri, not Electron. So while conceptually the same, it uses the system webview instead of bundling Chromium. And all modern browsers are color managed, but I don’t know if that is exposed to the app with Tauri or Electron.
3 Likes
In this case all the webview needs to do is not apply any color management at all and just display what is given. RapidRaw could either fetch the system profile or ask the user for it and then use it as its display profile.
Even with pure electron, not having color management in it is not a problem since we have control over the image data anyway. It’s only a problem in applications that merely display them.
Chromium uses Little Color Management System, the same lib I use in my image viewer at the moment, since it supports higher than 8bit pixel formats. Firefox uses qcms but is capped to 8bit.
1 Like
Yes I’m using dnglab’s demosaicing. I implemented my own demosaicing algo’s (the good one was Menon) which I then removed again the moment I switched form rawloader to rawler (from dnglab). After I implemented some other important features I will try to make the demosaicing algo’s work with X-trans sensors.
1 Like
Btw to everyone: All the processing happens in rust / wgsl. The tauri frontend (which is a webview / webbrowser) just displays the processed result. We have a lot of control over this.
6 Likes
Any x-ref for this? I would assume Chromium would rely on Google’s skcms…
Sorry, I am wrong apparently. I knew it had lcms2 as a dependency, so assumed it was for the entire browser, but apparently it’s for their pdf engine pdfium.
2 Likes
I think this is a wonderful project, keep it up! You will have a lot of fun, learn a lot, and benefit others.
For those, though, who think that a tool like any of the ‘big’ FOSS raw developers can be done overnight: it’s not just about adding a curve or other processing: it’s also about how those play together. For example, it sounds simple that a raster mask can be reused. But then comes cropping, lens correction, perspective correction and other distortions, and you also have to process the mask. This is just one example, and you may say, sure, a raster mask is just an image as well, we can run it through the same distortions as the main image, but there are other things, and when you want to add each and every one of them, it becomes non-trivial pretty fast.
This is not meant to discourage anyone from writing new software; I only meant to address unrealistic expectations, and explain why even ‘simple’ tools are great achievements, and why feature-rich applications can be rather complex code-wise.
12 Likes