RapidRAW 1.6.5 – strange colour rendering with an Olympus E-M1X ORF

I noticed something rather strange while testing RapidRAW 1.6.5 and I’m wondering if anyone else has encountered something similar.

I’m using exactly the same Olympus E-M1X ORF in three different RAW editors, all running their latest versions: RapidRAW 1.6.5, RawTherapee and Safelight .

The overall rendering is different between the three, which is of course perfectly normal. What caught my attention, however, is something much more specific.

I’ve included three screenshots and a small crop rather than showing the complete photograph, as I don’t have permission to publish the full image. The cropped area is enough to show the issue.

In the actual scene, a slatted wooden door/panel on the right is blue/grey, while the wooden chair supporting the painting is brown. Safelight and RawTherapee reproduce that relationship correctly.

RapidRAW does something quite different: the door becomes brown while the chair takes on a distinctly blue/grey colour. In other words, two clearly different physical colours appear to be effectively exchanged.

I’ve reset the RapidRAW image completely and tried different white-balance and tonal settings, but I can’t get those colours into the correct relationship. The result remains essentially the same.

This doesn’t look like a simple warmer/cooler white-balance difference to me. It seems more fundamental, possibly somewhere in the camera colour matrix/profile or RAW colour pipeline.

Has anyone else seen anything like this with RapidRAW, particularly with Olympus/OM System or other Micro Four Thirds RAW files?

I’m not claiming that RapidRAW generally produces incorrect colours. I’m simply trying to understand what could cause this particular behaviour, especially since the same ORF renders correctly in both RawTherapee and Safelight.

Has anyone encountered a similar colour-matrix or camera-profile issue?

1 Like

The R and B channels are swapped. This is already fixed upstream, but unfortunately not yet pulled in by RapidRAW.

1 Like

Ah, that explains it. I was already suspecting that this was happening somewhere in the RAW decoding rather than being a white-balance or profile issue, but I hadn’t realised the R and B channels were actually being swapped.

I see that the fix dates back to August, while RapidRAW has had several releases since then, including 1.6.5, so it’s a little surprising that this fix still hasn’t made it into RapidRAW.

Good to know the issue is already fixed upstream, though. At least now we know exactly what caused the rather bizarre colour reversal I was seeing. Thanks for pointing me to the issue and PR!

1 Like

I have only sympathy for Timon, maintaining a fork of anything is not at the least bit fun…

1 Like

Ah, that makes sense. I wasn’t aware that RapidRAW is maintaining its own dnglab fork. That certainly puts the delay in a different perspective.

It does make me wonder, though, how upstream fixes like this are handled. The E-M1X CFA issue seems quite fundamental to RAW processing, while RapidRAW is also developing new features at a very fast pace. I suppose keeping a fork in sync with upstream is quite a challenge in itself.

Thanks for the clarification, it certainly gives some useful context to what I was seeing.
All the best !
Marc.

1 Like

I need to find a way to maintain the fork better, it gets out of sync so quickly. Haven’t had time to find a proper strategy for this yet…

4 Likes

Having a whole blog article written about a missing upstream sync was definitely motivation to pull it tonight! :smile:

Fix is merged: fix Olympus E-M1X CFA pattern · CyberTimon/RapidRAW-DngLab@a32bc1f and will land in the next release.

Best,
Timon

3 Likes

@CyberTimon Good going. While at it, there are a couple of more bits still different/missing:

Canon EOS C50 support · dnglab/dnglab@cc88ce0 · GitHub

move rawler/data/cameras/panasonic/l10.toml → rawler/data/cameras/panasonic/dmc-l10.toml to clearly de-duplicate from the new DC-L10 (thanks Panasonic)

remove rawler/data/cameras/panasonic/tz91.toml (now alias in tz90)
remove rawler/data/cameras/sony/a6100a.toml (now alias in a6100)
remove rawler/data/cameras/sony/a6400a.toml (now alias in a6400)

(And of course there are some pending PRs w/ trivial camera support you might want to consider…)

Not sure when, but I noticed this a few weeks ago with a raw image; didn’t occur to me it was a channel issue at that time; just used Darktable on that particular image. Now I know. Can just use the GIMP to swap these channels out until a solution occurs or just use DT. Like RapidRaw for it’s simplicity and do like the controls that are available as well, but still I usually complete in the GIMP anyway. Keep up the great work. Nice to be able to use Winget (Win11 terminal) to upgrade; very quick and doesn’t require admin terminal. :slight_smile:

winget install --id CyberTimon.RapidRAW

Talk about timing! I literally downloaded RapidRAW about 20 minutes ago to test it out. By sheer luck, the very first image I imported into my gallery was an ORF file shot on an E-M1X, to test the Apple RAW 9 denoise.

Coming from Lightroom and Darktable, I was puzzled by what was happening with the colors. Honestly, this just shows how brutally hard software development is. Putting thousands of hours into a passion project as a solo dev is a massive undertaking, and if I hadn’t chanced upon your post, I probably would have assumed it was broken, deleted the app and moved on.

A huge thank you to Marc for making the post, and kudos to Timon and the rest of the contributors for all their hard work and ongoing support.