With such a photo, I should have no hope that my local print shop would be able to accurately reproduce the displayed colors. They ask for sRGB profile if ever. I use that for standard print.
Two years ago, I used a professional lab for a few prints. They asked for tiff file with adobe RGB profile. They sent me their print profiles for soft proofing. Prints were so much better!
As display gamuts and printer gamuts are quite different, the result of print can be quite surprising.
Some people here locally print their photos. They can help you to set up a print workflow.
Is your monitor calibrated? IrfanView does not have colour management. You should open the .jpg on Darktable and if your monitor is calibrated, compare.
This is really a gamut nightmare . A decent monitor reproduces the sRGB color space which is also web standard. Colors directly derived from light sources are often difficult to map into this space.
It gets even worse when you try to print on paper. While the monitor uses additive color mixing, prints employ substractive color mixing having a differnt smaller color space using mostly CMYK as colors. The result then strongly depends on the software setup to map the colors and the possibilities of printer and paper used.
I don’t have SSF data for the Olympus E-M1, so my rendition relies on the libraw matrix. In rawproc, with a default-parameter filmic curve and only one color transform, camera → sRGB at output:
That’s what I thought originally but the expanses of blues and violets produced by Adobe Standard processing fit pretty well within Adobe RGB as shown earlier, not an extreme case after all. sRGB has more trouble, for instance near the purple spotlight reflections.
Differences are mainly due to subjective application of saturation and contrast.
Yes, but you can reproduce this only on monitors with full AdobeRGB color space. If you don’t have such a device or want to publish/share on the web, it gets difficult. And printing is the real challenge .
That’s an interesting result.
When I inspected my pic in darktable I had negative values all over.
But digging more into it (Darktable 3.4):
The RGB values the color picker shows depend on the setting of histogram and softproof profile. If both profiles point to srgb I get negative values…
If I change the histogram profile to lets say linear ProPhoto the lowest RGB value I can find is zero…
Does that makes sense?
Well, black and white is not an option. The special thing about the building is, among other things, the lighting after sunset.
The colors change with the time. I made a series of pictures with certain details at different colors. One in black and white does not really fit into the series…
Your color result is a nice one!
Unfortunately my monitor does not show full AdobeRGB color space…
So if I want to edit and print the image properly I need a better monitor and a print provider that can handle AdobeRGB, right?
Interesting to learn that someone experimented with it I think my own days of doing so are over, except perhaps images dominant in cyan and aqua. It comes at the expense of colour accuracy. Still, the colour gradations are pleasing in your edit.
If one follows the DNG spec for raw conversion there are several checkpoints during the process where one needs to block negative values to zero. At each of such points I add the relative pixels to an out-of-gamut RGB image. Values are set to either 255 or zero in the appropriate color plane. I usually carry clipped pixels over then just after projection to the destination color space, but before any further processing, I add in those as well. It’s usually obvious by comparison to the rendered image which are clipped vs blocked.
The resulting image above doesn’t show you by how much values are blocked/clipped, just that they are. I find it is useful to quickly see how much clipping/blocking is due to somewhat objective ‘gamut’ issues vs subjective ones by further processing, as in this discussion. Not many options for the operator with the former, many more for the latter.
Assuming the DNG spec process, the checkpoints I use are basically in linear space just after matrix multiplication:
conversion to XYZ
conversion to ProPhoto (if LUTs are in the dcp)
conversion to destination color space.
These are the stats I get using the DNG tags for the capture in this thread with ‘basic’ table:
Ant these are for the same with the ‘look’ table applied:
I don’t know what part of this functionality is available in raw converters discussed around here.
. A decent monitor reproduces the sRGB color space which is also web standard. Colors directly derived from light sources are often difficult to map into this space.
.
I think my own days of doing so are over, except perhaps images dominant in cyan and aqua. It comes at the expense of colour accuracy. Still, the colour gradations are pleasing in your edit.
