PureRaw 3 messes up Greens with Olympus OM-1

I’m a new DXO customer experiencing a problem with PureRaw 3. I contacted DXO Support but after a week have received no response, so I’m posting here in hope that someone might be able to help.

I’m looking specifically for feedback from DXO or people that use the OM-1.

Running latest version of PR3, 3.1.0/b532/x64, Windows 11, CPU processing.
Camera is Olympus/OM System OM-1. I’m running on a calibrated monitor with an avg delta e of 0.7.

I shoot primarily landscape & nature, so greens are important. The issue I’m seeing is that PR3 messes up the greens in my images, making them look browner.
It does this on a wide variety of images, and it happens regardless of which noise reduction method is chosen; it does the same thing on Prime, DeepPrime, or HQ.

Examples from two images are shown. PR3 is on the left, camera native is on the right. The camera colors are correct, because they match what I see with my eyes when shooting.

You can see clearly that the greens in the diffused background have shifted strongly towards brown or yellow, making the foliage appear sickly. (If you can’t see it in the example, there may be a problem with your calibration or color perception. The effect is very noticeable.)

I have examined the histograms of OM-1 images run through PureRaw, and what consistently happens is that PR3 boosts the red channel, while reducing the green and blue channels.

Does PR3 do this with all cameras, or is it just the OM-1? Is there something I can do to prevent PR3 from doing this? Trying to correct it can be a pain and can introduce other artifacts. Does this happen when using PhotoLab, or just PureRaw?

Can DXO fix it, or will they?

Thanks…

Here’s the image:

The problem you raise is one of those that cannot be solved easily, moreover with two small images.
Your request is missing several essential information:

  • are your images PR3 exports in jpeg, in Tiff, or in dng?
  • on what are you viewing these images: PR3 after export? another software (ACR, LR, PS…)? And in which color space (Adobe RGB, Srgb…)?
  • you indicate that the images of the camera are correct for the colors. But is it a jpeg produced by the camera, a raw processed in software?

To better understand your question and be able to answer it, it would be good to specify this information. And even better to make a raw file “affected by this issue” available on a file sharing site for us to process with PureRAW and possibly PhotoLab.

2 Likes

Thanks for your response.

The color shift occurs whether PR3 produces DNG, TIFF, or JPEG. The color shift is visible, and the same, regardless of what software I use to view the images. (The fact that PR3’s TIFF and JPEG output differ from each other in brightness and tonality is an another obvious issue.) As I said, I am using a color managed workflow, so the applications are profile aware. I compare the images in Photoshop. Irfanview shows identical results.

The color shifts are apparent when comparing to the straight-out-of-camera jpeg and/or to the output from OM Workspace; when viewing raw you’re testing the application’s camera matching profile. Since the PR3 “Compare Processing Results” screen shows the muddy greens for both the before and after, my assumption is that the color shift is occuring when it first interprets the raw file. Hence my question about Photolab. I wondered if it might do a better job with its camera matching profiles than PR3.

The color space is SRGB.

Sorry if you didn’t like the size of the images. Perhaps because I am a new member, the forum software was kind enough to reduce the size of the image I provided. Because the issue is one of color and not resolution or fine detail, the image I submitted is adequate to show the color shift. Regretfully I did forget to attach a profile to the composite image I uploaded, but it still shows the difference when viewed in SRGB.

Moreover, as I said, I examined the histograms. Histograms are objective, not subjective.

I have provided links to the camera jpeg and raw here (White Balance 6300K, Natural), if the forum let’s me post multiple links:

I’d be interested to know if your processing produces different results than I depicted.

I’ve tested a good number of images with PR3. Generally it produces good color matching (at least to the camera’s Natural profile, which is all I’ve compared with PR3) but not with greens, and to me greens are crucial.

Thank you…

Yeah, sorry, but it got me again. I provided a link to download, not as an embedded image.

If you are unable to download the original, please tell me how I can post links on this forum without the forum software changing them.

Thanks…

No problem: I was able to upload the raw ORF file to Dropbox.
But you seem to indicate that there was also the corresponding jpeg file, it doesn’t seem to be available for download, it would be very interesting to have it as a basis for comparison to see what color rendering you expect.
Note: the clickable jpeg jpeg image on the forum does not allow you to start from an original jpeg file, it is important, among other things, to know which profile is recorded by the camera.
Much too late today (here) to do a more complete search: I’ll see tomorrow. But I’ve done some testing and I’m having a hard time seeing where the problem would be at the moment (the display in PhotoLab, PR3 and the imported dng in Photoshop look very close to me, but it needs to be clarified all that.
The fact that jpegs are different from dngs is not a bug, but a feature of PureRAW: DxO considers that jpegs will generally be used directly, and therefore it applies a particular luminosity correction. This is not the case for tiff or dng for which processing will be continued in another software.

The image shown in my post, above the download link to the raw, is the link to the original jpeg on dropbox.

You can download it from dropbox by opening it in your browser and doing a “save image as”. If your browser works properly, you will get the original file. I tried it in Edge, and the download is binary identical to the upload.

The forum software monkeys with every link I put in a post. It is troublesome compared to other forums I have used. Here I have tried inserting the same link again, explicitly calling it a link. It is identical to the link in the previous post. Use this, if the forum doesn’t break it, or use the method I gave you above.
https://www.dropbox.com/s/bhbbreh95sw1ias/Green%20Shift%20P4159106%20OLY%201_4000s%2075mm%20f4.0%20ISO%201600%20WB%206300.JPG?dl=0

Regarding your comment about JPEG vs TIFF, you might not consider it a bug, but it’s a flaw. If people wanted an edited JPEG with adjusted luminosity, they would edit it. The fact that PR3 runs the whole demosaicing and NR process separately to produce a JPEG, doubling the processing time, when it could be converted from the tiff in less than a second, is bad design. Once the processing to the raw is complete, generating a TIFF and/or JPEG in addition to the DNG should be immediate. The way PR3 does it is, in my view, ridiculous and without benefit. But no matter, I just won’t use what the implementation made a useless feature. The color is my concern, because that’s something I would have to fight on every image.

Thanks for looking into it…

Having used a variety of Olympus PEN and OM-D cameras with PhotoLab/OpticsPro, I’ve seen this a lot. It’s a long-existing problem with the “standard” color rendering from RAW. It does not match the out-of-camera JPEG rendering when there’s foliage or earthy tones. Olympus has a secret sauce that’s hard to replicate. As you’ve noticed, red and yellow tend to be oversaturated. The RAW conversion doesn’t put as much color info into the green channel as you’d expect. Furthermore, I find that using an Adobe DCP rendering in PhotoLab for Olympus cameras isn’t much better. There are several ways to quickly and easily get a better rendering from RAW with PhotoLab, but I don’t know if that’s possible with PureRAW.

I had a look at your image and found differences in colour rendering depending on which app I used to display the .orf file. These differences are a fact that we can accept or try to work around with more or less effort. Let’s have a look why we get such differences.

  1. Camera manufacturers render colours in a way that they deem to be “true to life”, “pleasing” or whatever criteria they choose as a reference.
  2. Software manufacturers render colours in a way that they deem to be “true to life”, “pleasing” or whatever criteria they choose as a reference.
  3. As soon as the camera and software manufacturers are not the same, differences start to come up, because the respective ideas about what “good/right/true…colour” is, are different.
  4. Differences in colour rendering can be reduced by measuring colour rendition against an accepted/known standard…which needs to be done at least at the beginning and the end of the workflow. As we don’t know the manufacturers’ references, we’re in no position to objectively establish if the respective colour rendering is “correct”, which brings us to the point of colour preferences being an utterly subjective field on which we can fight about this or that rendition being “truer” than the other. (Search the Internet for “colour science” and related discussions)
  5. “Seeing colour” is a chemical/electrical process and no two (human) beings see the same colours, but they can agree on whether a colour might be bear the name “green” or “red” or “blue”…but even this understanding is different if you check out the primaries that have been selected for different colour spaces…which brings us to the next point.

Colour rendering being a matter of choice rather than truth, colours close to the edges of a colour space are often shifted in order to make them a part of the output image or for finer colour separation etc. and those shifts depend on who does them and how, no matter if we’re talking about OM Systems, PureRaw or PhotoLab. While we cannot change how OMS renders colours, we can do something about it with DxO’s products. Sadly, PureRaw is not the one for colour work, but PhotoLab has a set of tools that allow better control or influence of how colours are rendered.

To make a long post short:

  • forget “truth” in colour rendering (unless you’re into repro)

OK, I got the original jpeg fine from the link. Note: in Edge by image copy, most of the metadata is missing, unlike the link file.

Your comments call for several observations.

The first, which we find quite often here and which Egregius and platypus have explained, is due to the individual perception of color, and also to the interpretation made of it by the engineers of the brands to make jpeg cameras from raw from the sensor.
Many new users of third-party software like DxO (but also LR/ACR, etc.) consider that the jpeg of the camera is the faithful representation of what they have seen, and they are confirmed in this opinion by the software provided by the brand of the camera, which is able to reproduce exactly the same rendering from the raw.
They therefore expect DxO (ACR, etc.) to give identical colorimetric rendering, which is impossible since the demosaicing engines are different. They can emulate a render, not exactly copy the original render.
The problem is that the original rendering of the camera is often flattering to please the user! It’s quite logical: a true neutral rendering (which can generally also be adjusted in the camera) is often dull and not very “appetizing”… so not very selling! The user gets used to this rendering which for him is “the truth” whereas this is generally not the case. Please note, this is not a criticism, just an observation: I too, like many others here, have gone through this stage.

Next, I think we shouldn’t misunderstand what PureRAW can do: it’s not general purpose demosaicing software like PhotoLab, it’s a “preprocessor” whose main purpose is to take advantage of the quality of noise processing and DxO lens profiles in an RGB file to be exported to another software (LR, PS, C1…) where the settings will be finalized according to the user’s habits. The most efficient way to do this is to create a linear dng which will behave exactly like a raw for all settings other than those (noise, optics) already made.
The other possibilities of files exported by PureRAW are incidental: the jpeg does not really benefit from being used, the Tiff offers significantly fewer possibilities than the dng, even if it has more than the jpeg.

In the context of a “normal” use of PureRAW with a dng, your observation concerning the “color shift” does not make sense: the dng has no particular color rendering, except that of the camera sensor. The jpeg thumbnail incorporated into the dng has of course one so that it can be displayed on a screen: the one defined by DxO, but not the linear dng file itself. It is the software to which this dng is exported which, when opened, applies a profile to it, either by default or chosen by the user.
If you have Photoshop or Lightroom, you can check it yourself:

  • export dng in PureRAW to PS or LR.
  • open it: it is displayed with the predefined settings in ACR (in particular the color profile (Adobe color or other). Note: DxO = color rendering = Adobe color profile
  • take the original raw file and open it in PS or LR.
    Compare the two: they are strictly identical from a colorimetric point of view!
    DxO PureRAW has therefore absolutely not intervened in the colorimetry and cannot have created the slightest shift in the case of a dng.

Obviously for a Tiff, it’s different since it is mandatory to apply a color rendering before exporting. PureRAW will apply the color rendering that has been defined by DxO as the closest to the default rendering of the camera… for the majority of cases that do not necessarily correspond to your settings or your particular shooting conditions. But of course if this is not suitable, it is still possible to partly change this color setting in the destination software (LR, PS…), even if the possibilities are more limited here than for a dng.

Finally for a jpeg, DxO considered (rightly for me, but this is only my opinion) that it was a file not intended to be used and logically added an intelligent brightness correction, variable according to image and its content.

I have to take a break, but I will continue later.

As an example:

  • raw orf file opened directly in Photoshop / ACR (top)
  • PureRAW dng file exported in Photoshop (bottom)
    The two color renderings are identical.

Thanks for your effort in typing all that, but it was unnecessary. I’m well aware of the issues surrounding rendering of raw data. But in light of it, it seems appropriate to repeat some basic information myself. The issue you’re talking about is why camera matching profiles exist in the first place. One of the factors people use in their camera purchasing decisions is “How does this camera render color?” You have Sony color, Canon Color, Olympus Color, etc. This may indeed only have meaning in the context of the rendered image and not the raw, but nonetheless it IS the “truth” for that brand, because it shows the desire and color science of the manufacturer; it is how cameras are marketed; it is what differentiates the output of one camera from another. Adobe and other vendors have therefore integrated camera matching profiles, to match to the greatest degree possible, the rendering intent of the manufacturers. Without this, we would all be using Adobe Camera Neutral and all cameras would look pretty much the same. So evaluating how software reproduces the rendering intent of a camera manufacturer is perfectly valid. It is in this context that I am referencing the reproduction of greens.

Your screenshot of a raw was produced with a rendering intent, either using a camera matching profile, or some other recipe, defaults in ACR or otherwise. Any software that renders a 12 or 14 bit raw file into an 8 or 16 bit color space for display is using a LUT or some other mathematical transformation to do so.

So my original question was predicated on wondering what PR3 is doing. Because if it’s trying to match the Olympus rendering in tiffs, IT’S NOT DOING A GOOD ENOUGH JOB, at least with greens. The situation is complicated because it then bakes in some rendering to the tiff, and then a DIFFERENT rendering to the jpeg. So DXO is editorializing to an extent in the developed images, but with what intent? Some “DXO Camera Neutral” perhaps? Does PR3 render all cameras to look the same, or is it supposed to be using built in camera matching profiles? I had hoped that PR3 would reproduce the camera’s rendering intent using built in profiles. I’m still not sure, from what you said, if it is trying to do that or not (with tiff) or if in the case of the OM-1 it is trying to do it but doing it badly.

It’s unclear to me if the “Photolab EA member” attached to your names indicates if you’re DXO employees or not. I’d like to know.

I had assumed, evidently wrongly, that PR3 would produce equivalent output to Photolab, minus all the adjustment capability.

So let me approach the question now from a different angle:

Does Photolab do a good job of matching the Olympus colors in this image, without a lot of fiddling? Does it use camera matching profiles, and in the case of the OM-1 is the profile good enough with greens? Again, based on this image, since I don’t seem to be encountering anyone here actually using the OM-1.

I understand that I could download the trial of PL6. But at this time I do not want to switch my workflow to Photolab, and I don’t want to expend the one trial DXO will give me for Photolab answering this one question when I might need to to a deeper dive some time in the future.

If someone would be kind enough to develop that ORF in PL6, using whatever equivalent PL6 has as a camera matching profile for the OM-1 “Natural” picture mode and post the jpeg, I’d be very interested to see how well it does.

I’m sorry you had difficulty downloading the jpeg; something’s wrong either with your Edge or your method. I tested it: click the image so it comes up full size in its own tab, then right click and “save image as” (do NOT use “copy image” as that is a clipboard function not a download) This produced a jpeg file; I did a binary comparison (fc /b) and they were identical. No discrepancy in exif or anything else.

Thanks…

We are not DxO employees, We are licensed PhotoLab customers.

Mark

1 Like

Your very long post does not allow me to answer it tonight (for me) with enough arguments and examples.

But very quickly:
First of all, on the question of belonging or not to DxO staff, I am simply like almost all the members of this forum, a user of DxO software (but since 2003). And like many here, I try to help those who ask technical or other questions. The (very?) rare times when DxO staff members intervene, it is always with the “DxO staff” badge.
For the jpeg, there was probably a problem somewhere (maybe on my end), but that doesn’t matter since you provided the link and I did upload that file.

For the “color problem” of dngs (and only dngs), what I wanted to show you is that there can’t be a problem at the dng stage since no color rendering is applied to the dng of PureRAW: the demosaicing has taken place, but the three RGB layers are independent and have remained in the original colorimetric space of the sensor. It is the software which will open this dng which will apply its own rendering to it. Exactly as it would with a non-demosaiced raw file to which by definition no color rendering is applied.

How PhotoLab handles all of this can’t be summed up in a few lines, so I’ll get to that tomorrow. What I can tell you quickly is that PL by default gives an identical rendering to what PureRAW gives (it’s the same engine), but that the adjustment possibilities are of course much greater since in PL we process an image entirely, while PureRAW is designed so that the rest of the processing is done in another software (PS, LR, C1…). The possibilities for setting color renderings in PL are very wide, and you can customize them with presets that you can then apply to other images.

The text you mention can be edited to provide more detail if you like.
Click on your avatar in the top RH corner of the forum, click on preferences (the little figurine icon), add something sensible and save the changes.

Thanks. Knowing you’re another user trying to help others actually makes me even more appreciative of your time; it wasn’t intended as a criticism. I was just curious as to whether DXO was responding, since as I said I never received a response through their support form. I saw some old posts from people with that same Photolab EA badge when the Early Experience program was first setup, and they seemed to be DXO employees telling others about the program, so that’s why I was unsure. It also lets me know I shouldn’t expect you to speak as to “why” the software does some of the thing it does. Why questions are for the developers…

As to your comments about the DNG, yes I acknowledge PR3 is not altering the coloring of the DNG other than doing the demosaicing and NR. But it is setting some kind of rendering intent for tiff and jpeg. I understand nothing about that can be changed by users in PR3.

So when you get a chance, what I’m hoping you can clarify is what PL6 can do differently in terms of camera matching. Since you mention that PR3 apes PL6 defaults, I’m still left wondering what that is: is it trying to use an Olympus-matching profile that’s just not good with greens, or is it using a different intent entirely, like DXO’s version of “Adobe Camera Neutral”. And if the latter, does using the camera matching profile actually produce good results?

Thanks again for your help, I appreciate it. It’s kind of you to spend your time helping others. I’ve done the same for others on other forums with other topics, so I know how it can be sometimes. :slight_smile:

Simple answer: No, PL doesn’t do a good job matching Olympus/OMDS JPEG color renderings with a single preset or color rendering setting. Not at all. As I said, this has been a problem for a very long time. DxO hasn’t shown any interest in correcting it when I’ve pointed it out to them.

So I decided not to use the JPEG as an absolute reference for color. It isn’t true to life anyway when it comes to foliage. The DxO default renderings for Olympus cameras and their Neutral rendering are more true, replicating the browns that Olympus turns green. Olympus color renderings look very nice, but they employ some tricks. Mainly, I’ve observed the following:

  • Olympus greens are awesome looking, but undersaturated with reduced contrast. They are shifted away from yellow/red, toward blue.

  • Olympus shifts yellow in two directions: some toward green, some toward red. You can’t really do the same in PhotoLab without a lot of work. A clear example is the yellow-orange-green blurred background to the left of the rightmost flower cluster in your photo. The only way I found to easily replicate in PL 6 what Olympus does here is to first turn off Smart Lighting and select the “Neutral color” generic rendering instead of the OM-1 rendering. Next, I select the yellow channel in the PhotoLab HSL tool, place the HSL eyedropper on the outer part of the yellowish blurred area - the part that should be greenish - and then shift the yellow channel quite a bit toward green. Voila. But the orange channel needs just a little bit more red, and getting that just like the Olympus JPEG rendering is difficult if not impossible with the HSL tool because of the overlap with yellow in PL. Instead I think you need to use a Local Adjustment broadly applied.

  • Now, to match Olympus grass green, I can select the green channel, shift it slightly toward blue, and significantly reduce its saturation. But now I find the yellow channel needs more tweaking.

  • I also have to significantly increase Luminance noise reduction (to 50+) so that the preview window shows something close to the Olympus JPEG.

  • Olympus JPEGs apply too much sharpening and don’t have as much resolution as you can get from RAW.

Thanks for your feedback Egregius. That’s disappointing to hear that they don’t want to do a better job.

Olympus undoubtedly has some special sauce, but all the camera manufacturers do, to one extent or another.

I’m going to have to dispute you about the DXO default renderings being more true though, at least with the images I’ve taken and processed with DXO. The ORF I uploaded is a perfect example. Because the tree is right outside my window, I can state definitively that the diffuse foliage in the background is in fact green, like the jpeg, and not the sickly brownish green color it appears in the DXO tiff. That’s just a fact, and it’s not debatable.

The late day golden sun was coming through dense foliage, putting a lot of golden light in there with the deep green of the leaves, and it makes for a beautiful seen as well as evidently a challenging picture for color rendition. The Olympus jpeg got it right. I did a custom white balance on that shot to get the colors right, but the colors in the jpeg are true (the camera of course shows the same colors in the image review). I underexposed it a bit because the camera of course has less dynamic range than the eye, and I wanted to favor getting those greens right, figuring I could boost the blossoms in post easily enough if I wanted.

The travails you describe in trying to correct the colors in PL6 are exactly what I want to avoid. I found it very tedious trying to fix the greens without messing up yellows as you said.

When I was looking on the DXO forums before posting, I saw some people (you might have been amongst them!) complaining about green rendition, but it was with other cameras. The OM-1 is relatively new and I didn’t see much posted about it here, other than people clamoring for DXO to support the camera at all for quite a while, and after that mostly nothing.

But being new to the DXO ecosystem, I hoped that the situation might have been improved by now.

While it can be tedious to change color neighbors, PhotoLab’s HSL tool offers a set of settings that I find easy to use and flexible enough for almost anything. Nevertheless, it might be worth trying to adjust HSL and add that to a preset as a replacement OMS sauce.

Alternatively, dcp profiles from other applications or some LUT might help, but again, not in PureRaw. With a DCP profile from Adobe DNG Converter and some HSL shifts in DPL6, I get this:


Green Shift P4159106 OLY 1_4000s 75mm f4.0 ISO 1600 WB 6300.ORF.dop (14.5 KB)

Not being an Olympus or OM specialist, I have no particular opinion on the way these cameras manage colors.
Egregius gave a good analysis to approach the color rendering that you think is the right one. This shows, even if it’s necessarily a little abstract, the adjustment possibilities of PhotoLab on color rendering. As he knows Olympus / OM well, his analysis is relevant and I will not return to this point.
In fact, we come back to what I wrote in a previous post: if you want to leave the software of the brand (whether OM or another!) for third-party software, you must abandon the idea of ​​copying the result jpeg camera: none (DxO LR, ACR…) will give you the strict correspondence with this color rendering.
Having experienced it, at first we all tend to consider the jpeg camera as “THE” reference. It is often a pleasant rendering, but rarely an objective rendering!

To return to PureRAW and to tiff and jpeg exports, the color rendering applied is the DxO profile of the camera (OM-1). If there are no other possible choices in PureRAW, with Photolab you also have the Color Neutral choice, which in the case of THIS image might be more appropriate… but that’s a question of 'personal appreciation. But as also indicated, you can fine-tune the color you want, or even use the rendering provided for other cameras if that seems better to you.

Finally, there is a point that has not been mentioned, but which can be very important here: the white balance.
I was quite surprised by the high value of the color temperature announced in the title of the file: 6300 K. This is not very usual for an image which seems to be taken in daylight (the exif says flash not in use), and obviously with the sun. Typically, White Balance values are in the range of 5000 to 5400 K under such circumstances (and in the season corresponding to the shooting date). Reading your post, I understood that you were looking to make the golden light of late afternoon. You indicate that what you saw on the camera corresponded to reality for the colors. Are you sure? The eye is easily deceived by the colors of a camera screen or by the viewfinder, which can have color drift. I don’t even know if there is a color calibration for screens/viewfinders, and everyone I know has a possibility of manual color adjustment… which is proof that no!
Personally, I never rely on camera visualization when I want accurate color reproduction: I always take at least one control image with a white balance chart. It is only when demosaicing on a calibrated screen that I adjust the white balance with this image from the WB chart.
When making a custom WB for this image, is that how you did it?

The goal is obviously not to criticize your approach, but to try to understand why the colors are not what you expect.

Yes I’m quite sure the colors are correct, because I went to some trouble to ensure that they were I know I took multiple shots of that view, and kept the one I finally got right. Auto White Balance did not do a good job.

As I’m sure you know, white balance in the real world can be tricky. The light we see when photographing pretty much anything does not render like a blackbody radiator; there is atmospheric diffraction, diffusion, reflected light from a variety of surfaces and substances before the sunlight actually reaches the sensor. In a circumstance like I was photographing, there’s no one correct temperature for the light source. It’s more like a concert with several lights of different colors shining on the subject. I’m shooting into a dark glade-like scene that is backlit; there is sunlight coming from the back, but also light diffusing through leaves and also bouncing off leaves.

Interpretation of what white balance is correct when you only have the image to look at is complicated by the lies we’re told by software. I don’t know about PL6, but when you load the image into ACR it does not identify 6300K as the temperature, even though that temp is in the exif; it picks Adobe’s equivalent temp+tint, because they want to go their own way. Monkeying with the white balance can help you correct the greens, but at the expense of making something else worse. I have another image that has red blossoms in it; trying to fix the greens with WB turns the blossoms magenta.

Would it be possible for you to develop the raw in PL6, just using the camera matching profile for the OM-1 Natural Picture Mode with no other adjustments and post it? I understand no adjustments are possible in PR3, but I’d be interested to know what DXO’s camera matching profile for the OM-1 does with this.


shown in DxO PhotoLab 6.5 (screen with ‘native’ calibration, covering P3 + AdobeRGB colour space)

Screen Shot 05-08-23 at 11.25 PM 001 Screen Shot 05-08-23 at 11.26 PM
left side → Generic renderings (OM-1) // right side → the same, but manual WB


ADDENDUM
according to the ExifData, the pic seems to be taken in the late afternoon … and should be quite warm