This is going to be one of those posts that I can’t avoid showing off my ignorance.
Olynpus’s new camera, the OM-1 has created a fair amount of buzz, some claiming it really is the “wow camera” and others claiming that its improved noise performance is just a lot of hot air. I thought I would like to look for myself at the raw files in RawTherapee. I’m suspicious of comparisons based on Lightroom.
But RawTherapee can’t properly open orf files created by an OM-1. It can read some of the metadata; for example it recognizes the camera as an OM-1, but there is no image data and it can’t display the embedded jpeg. Why is that? Do you have to write a separate parser for every new variant of raw file that comes along? Is that something one could expect to occur in a reasonable length of time or would it have to wait until after 4.9 is released. According to this post on the PhotoMechanic Forum, the OM-1 orf file doesn’t seem that different: Support for new OM System (Olympus) OM-1 Camera
The current version of the Adobe DNG converter does indeed support the OM-1. I installed it but there is no sign of a camera profile for the OM-1. Does that imply that the converter is using the “Adobe Standard” tone curve? Is the Adobe standard tone curve essentially equivalent to the Camera standard tone curve in the Color Management section?
If I want to compare the raw files from two different cameras for noise etc., and I compare the dng files instead, am I introducing any biases?
That’s not quite my issue. I don’t currently own or have access to an OM-1. But I’m interested in its performance and I wanted to be able to look at some of the publicly available raw files at a more basic level than what I believe Lightroom allows. I didn’t care whether it had an accurate profile, etc, I just wanted to be able to look at the raw unprocessed data. Since the camera produces an orf file, as all of the other Olympus / OMD cameras do, I was surprised that RawTherapee couldn’t interpret it. Hence my question as to whether each new camera model requires writing its own specific parser. I also wanted to know whether, in general, processing a dng file gives equivalent results to processing a raw file.
A new parser isn’t needed, but there are enough specifics for a particular camera that we can’t just declare “orf support” and have that carry forward to new cameras.
Can I conclude from your statement then that RT has some sort of white list of supported cameras and then if a camera is not listed then RT does not try to interpret the file?
New products have new/different features/hardware. Having the same raw file extension is not a catch-all. Camera Raw from Adobe, which is behind Lightroom, had to be updated at some point. Sometimes the support takes a while to completely take advantage of the raw files. The timing depends on industry connections and the money and priorities involved (insider stuff).
Therefore I answered your question: the only way for us to know what OM-1 is about is to get a comprehensive raw file set to examine and then integrate that information into RT and other raw processors. Be practical and follow the instructions. (Perhaps linking to the raw files out there would be a good start. Hopefully, they have the whole set…)
PS - Making visual comparisons would be impractical. Open source processors tend to have a different workflow than say the in-camera JPEG processing engine and what Adobe thinks is “good”. When you open the raw processor, most likely you will be disappointed by the dull appearance. But no worries, once you finish your edit, with skill and patience, it will look better than Lightroom and in-camera JPEG.
I’ll just leave it at that. I’m trying to ask some general questions as to how things work but for whatever reason we’re just talking past each other.
I have been using RT for a long time and I appreciate its power and what it can do. But it doesn’t follow from that that I understand how it does it under the hood in any meaningful way.
FWIW, it appears to me that @bobm is doing due diligence on the OM-,1 and FOSS support for it, before parting with a stack of dollars on one. That seems perfectly reasonable to me. Better to ask the questions before buying the camera than to buy the camera and then face disappointment upon finding that it’s not supported yet.
I still like the camera, but not enough to pre-order it. The one small thing I liked was the USB C charging. That means one less thing to carry and forget while traveling.
@bobm Also, this in a new stacked sensor, so I would expect some work will need to be performed to process the raw file. Give it time for it to be fully supported.
I tried to add support for this camera in my rawspeed file (darktable) but I failed. I think it has to do with the new company name.
@kmilos, would you know why just adding the camera model name , manufacturer’s name and the right black levels/color matrix wouldn’t work for these .ORF files?
Not true, however you can usually assume that if it’s unknown, the interpretation attempt will likely not be ideal. Most notably you will not get good color rendering without that camera’s color response getting profiled. RT can either pull some metadata from Adobe products, or more ideally, a full DCP profile is generated - How to create DCP color profiles - RawPedia
However in your case, RT is choking more severely on the file. Without a few example files, the reason for this is completely unknown. USUALLY a new camera model just needs color tuning, but sometimes the file format changes. Those changes may be subtle (requiring only a quick fix to handle), or may be massive (For example, newer Sony cameras now offer lossless compressed raw, which RT doesn’t support yet.)
Given the change to the company, it could be as simple as RT automatically reacts to a certain metadata tag being “Olympus” and does not do that for the new company name, and thus the name needs to be added to that special handling. I’m just making a wild guess here. Without a file to poke at, it’s just guessing as to what changed in the file to break compatibility.
Thank you very much. That was the sort of answer and level of detail that I was seeking. Enough so that I would have a general idea of what (or what sort of thing) might be going on, bu not so much that I could overcome it.
Note that sometimes format changes are extreme - see Canon’s CR3 format. But that’s usually pretty rare.
I suspect this is probably a more minor change, but without a few example files and time to do a root cause analysis of the failure, who knows.
In my case, there’s a known limitation (Sony lossless compressed not supported yet), I work around that by shooting uncompressed or lossy compressed, as I’ve been doing for every previous Sony camera I’ve owned.
Apparently the file is just different enough that it doesn’t work. It’s not a deliberate whitelist or blacklist… It simply doesn’t work.
That might be because of a slightly different file structure , a different compression inside , or a crudely written parser , or something completely different. I have no clue, but it doesn’t work.
I’m with you that if the file didn’t change that much , i would expect it to work with maybe only color differences because of a missing profile . But you never know what is different inside.
You could try just using dcraw or the dcraw - emu in the libraw package , or Darktable , or something else. They might have the same issue , maybe not.
As for DNG converter… Basically they are just putting the Bayer data in a DNG container. The same as using a file without official support , the colors might be of because of a missing or wrongly interpreted color profile . It should work to just have a look at something 'like unprocessed linear pixels ’ to analyze noise performance… but the truth is you never really know for sure.
