Support for the Olympus OM-1

Software RawTherapee
21

In theory, DNG converter, unless it’s old enough to have the same issue as what USUALLY happens for an unknown camera in RT, will inject color profile data into the DNG. Obviously if the camera is so new that DNG converter doesn’t have a color profile for it, you’re hosed until you get a colorchecker. DNG Converter does more than put the bayer data in a DNG container, if the camera is known, DNG Converter will inject the color matrix data too.

(Some people use DPReview’s studio scene as a basic rough color calibration, but keep in mind that a daylight-balanced LED, even a really good one, is still not actual daylight. But for most use cases it’s at least much better than nothing.)

22

I have an OM-1 now so if a file is required to have a poke around at just let me know.

Just looking into raw editing options until RT gets the update to use the new ORF files though but I can provide as much detail as I can now I’ve actually got the camera in hand!

23

FYI, the OM-1 is supported by ADC 14.2 released last month.

24

Most raw formats are fundamentally organized as TIFFs. That makes the fundamental parsing of file sections consistent camera-to-camera, but the differences in tag IDs and placement may cause need for parsing changes.

After that, it’s the information provided in the metadata to support processing that changes the most, IMHO. For instance, Nikon DSLRs wouldn’t report a decent text lens nomenclature, so raw processors had to engage in stupid pet tricks to divine such. With the new mirrorless cameras, they now populate the EXIF LensID tag quite nicely.

One thing that the major manufacturers have not provided in-raw has been default color primaries. So, raw processors need to keep a large dataset of such for all the supported cameras. Doesn’t make sense, as each cameras’ JPEG engine needs those primaries to produce JPEGs, so they’re in there, somewhere… That’s the main purpose behind RT’s camconst.json file, which you can inspect and modify to your satisfaction, or peril. The DNG format contains tags to provide primaries, and cell phone cameras that use the DNG format usually populate the tags, but the quality of their data has been spotty.

Some things upon which to cogitate…

1 Like
25

@Sterling101 Welcome to the forum! Do share your raw files here:

Take a look at your camera’s manual / support website to see all the possible raw files you can generate with the camera. E.g., compressed and uncompressed, cropped and full crop, etc. We prefer to have the full set from a single source. Thanks!

1 Like
26

I’ll have a look at the details and get a full set uploaded.
Currently looking for a temporary workaround to get at least some access to a raw file from the camera. Welcome to Win10 in a VM again for a short while!

2 Likes
27

Full set of raw’s uploaded to raw.pixls.us for all crops.
Need to produce a hi-res hand-held and tripod but out of time right now so will do those tonight but should give a little starter at least!

2 Likes
28

OM-1 support · LibRaw/LibRaw@adcb898 · GitHub will probably be useful as far as hints - it looks like many of the changes are handling cases where the ORF reports “OM SYS” or “OM Digi” instead of “OLYMPUS” - which is kind of what I suspected might be the problem.

Might try taking a crack at this next week.

3 Likes
29

I did a full upload to raw.pixls.us but after a week I can’t see anything listed on the repo from my uploads?
Am I missing something here or does it take some time for it to be added to the repo?

30

The uploads need to be manually approved.

1 Like
31

ART (agriggio / ART / wiki / Home — Bitbucket), a fork of Rawtherapee, supports the OM-1. I bet you could just copy it’s rtdata/commatrices.json and rtdata/wbpresets.json to the rawtherapee source code, compile, and it would work, but I have not tried. I prefer ART anyway

1 Like
32

Is the OM-1 raw file already supported now by RawTherapee? I am thinking about buying this camera. RawTherapee is my raw file editor, so if OM-1 is not supported I will have to wait untill it is.

33

I haven’t had time to poke at this, so nothing yet.

34

Om Systems OM-1 RAW support seems to be in a recent pre-release build of darktable 3.90, so many thanks to the developers! I’m talking about 3.9.0+1568~gca7a55940.

1 Like
35

I hopefully downloaded ART (Sep 04, 2020), but it shows up with a circle-slash over it, and when the downloaded art.app opened, Terminal says, “The application cannot be opened because its executable is missing.”

Any clues? Are there any newer executables? That came from the “Continuous build” repository, but I guess “continuous” means at least 21 months…

The newest RawTherapee runs for me, but OM-1 raw files are just black squares.

MacOS Catalina (10.15.7).

EDIT: I tried compiling from source. cmake gave me this cryptic warning: “The package name passed to find_package_handle_standard_args (MACINTEGRATION) does not match the name of the calling package (MacIntegration).” Then make failed at: " clang: error: invalid version number in ‘-mmacosx-version-min=’".

36

That (no OM-1 support) is also why I started working with ART, which works fine on my windows computer. I miss some things I used to use in RT, but I start to like the more simple UI and the masking options.

37

@Entropy512 - Andy Dodd:

Hi, Andy,
right now being in process of creating a OM-1 “full set”,
we just discovered that this has already been provided by @Sterling101:
“Full set of raw’s uploaded to raw.pixls.us for all crops” (Leigh Windridge, Mar 11).

Since your answer from May 19, have you had time to look into this?
We would prefer not to create and submit “double work” …

Otherwise, If additional data sets would be helpful, we would be happy to contribute.

But please, let us know.

Thank you very much, indeed.
Kind regards from Munich, Germany
...
BTW: At the time being, Filebin rejects:
“The storage capacity is reached and new file uploads will be rejected. Please come back later.”

38

ART: “raw_crop” and per-iso ranges “white” seemingly missing:

cammatrices.json:
{
“make_model” : “OM DIGITAL SOLUTIONS OM-1”,
“dcraw_matrix” : [9488, -3983, -714, -2887, 10945, 2229, -137, 960, 5786]
},
Lines 3402 … 3405 in [ Bitbucket ]

wbpresets.json:
{
“make_model” : “OM DIGITAL SOLUTIONS OM-1”,
“presets” : [
{ “name” : “incandescent”, “multipliers” : [ 1.352, 1, 3.219 ] },
{ “name” : “flash”, “multipliers” : [ 2.609, 1, 1.477 ] },
{ “name” : “fine weather”, “multipliers” : [ 2.258, 1, 1.766 ] },
{ “name” : “cloudy”, “multipliers” : [ 2.422, 1, 1.586 ] },
{ “name” : “shade”, “multipliers” : [ 2.648, 1, 1.406 ] },
{ “name” : “daylight fluorescent”, “multipliers” : [ 2.445, 1, 2.031 ] },
{ “name” : “day white fluorescent”, “multipliers” : [ 2.547, 1, 1.719 ] },
{ “name” : “cool white fluorescent”, “multipliers” : [ 2.141, 1, 2.57 ] }
]
},
Lines 5834 … 5846 in [ Bitbucket ]

39

Exploiting Gentoo,
first I’ve added “OLYMPUS E-M1MarkIII” and “OM Digital Solutions OM-1” description blocks
into ~/.config/RawTherapee/camconst_json ;
then into a patch
/etc/portage/patches/media-gfx/rawtherapee/camconst-json__OLYMPUS.diff,
with re-build extending system-wide /usr/share/rawtherapee/camconst.json .

RESULTS are same:

Opening ORF taken with E-M1MarkIII work fine.

Opening ORF taken with OM-1 will read meta-data,
then will throw ERROR
“Unexpected end of file
Cannot use camera white balance.”

ERGO:
Upgrading camconst.json is not sufficient.

Running hexedit on ORF taken with OM-1 exhibits XML / rdf structures
which were not present up to E-M1MarkIII :

################################################################

OM Digital Solutions
.
OM-1
.
.
Version 1.2
.

<?xpacket begin="..." id="W5M0MpCehiHzreSzNTczkc9d"?>

.
<x:xmpmeta xmlns:x=“adobe:ns:meta/”>
.
<rdf:RDF xmlns:rdf=“http://www.w3.org/1999/02/22-rdf-syntax-ns#”>
.
<rdf:Description rdf:about="" xmlns:xmp=“http://ns.adobe.com/xap/1.0/” xmp:Rating=“0”/>
.
</rdf:RDF>
.
</x:xmpmeta>
.

################################################################

RawTherapee 5.8 rtengine/dcraw.cc embeds DCRAW_VERSION “9.28” .

As expected, no mention of “OM Digital Solutions” yet.

void CLASS parse_makernote
depends on “OLYMPUS” ;

void CLASS apply_tiff()
dito

void CLASS olympus_load_raw()
hard-coded read loops over row and col

################################################################

Mar 11 - May 19 - Okt 19 :

As stated above, we would be happy to contribute “full set” data.
I have even contacted OMDS development …

But all of this only makes sense if there is anybody out there committing to integrate contributions.

Without support of current flagship cameras,
all the bells and whistles in 5.9-RC will neither shine nor ring.

40

Yup. This is well known and established. I simply haven’t gotten around to poking at this yet, even though it looks like the changes aren’t TOO significant based on the scope of the libraw patch. Partly because I’m seriously thinking of replacing the hacked-up dcraw with libraw if other developers agree with me on that approach, rather than waste any significant time on the current implementation - but that would be a major change that has to be done after 5.9 is released, which has taken a lot longer than anticipated for a variety of reasons.

I have poked in the bowels of dcraw before, but it’s hard to FORC3 myself to deal with dave’s oddball loop macros. (Those who have read the source code understand what I mean here… And yes, FORC3 was intentionally copied that way.)

2 Likes