CaptureOne raw output is too bright

[DanK]

These two images look identical to me in both Firefox and Vivaldi.

When I save them from the browser, they have the same file name.

When I convert them to jpegs and read them into Photoshop, they look identical.

Neither has an embedded profile.

So, I think you are perhaps not pasting links to the right photographs.

And if the issue is that the SAME capture processed in two different raw converters looks different once rendered by them, it seems to me that underexposure can't be the reason (constant between the two), and the dispute about proper values on a color checker is a red herring.

So, I think it's back to square one. There are lots of ways that two different raw processing engines might produce different renderings, but we have no evidence here of its happening, and certainly no evidence that would indicate where in the rendering or exporting process this might have happened.

[bhurley]

So, I think it's back to square one. There are lots of ways that two different raw processing engines might produce different renderings, but we have no evidence here of its happening, and certainly no evidence that would indicate where in the rendering or exporting process this might have happened.

FYI, one of the links shows two images (at least when I click on it) and you can plainly see the differences. To my eyes, the libraw export looks more log/linear whereas the Capture One export looks brighter and with more contrast.

[DanK]

FYI, one of the links shows two images (at least when I click on it) and you can plainly see the differences. To my eyes, the libraw export looks more log/linear whereas the Capture One export looks brighter and with more contrast.

Sorry, I didn't see the second one image at the bottom.

Not being a user of that software, I can't offer a suggestion about what's causing this.

It shouldn't be hard to figure out whether the transformation in the brighter one is linear. Read the screen captures into your software of choice and plot the L values of the squares in the second image against the L values of the squares in the first.

[Manfred M]

FYI, one of the links shows two images (at least when I click on it) and you can plainly see the differences. To my eyes, the libraw export looks more log/linear whereas the Capture One export looks brighter and with more contrast.

That is what I see as well Brad.

[Manfred M]

In an effort to establish some common ground, Manfred, could we agree on something other than, quote, "close to"? Like for example "roughly" or "between this value and that value"?

The term "close to" is rather subjective, IMO. For myself, numbers up to say 3 are close to zero but it would appear that even around 50 is close enough for your good self.

Somewhat relevant - Poynton has "Macbeth" black with a Y value of 3.1% and a white of 90%, neither of which I would regard as being "close to" zero or 100% respectively. Others here might or might not - but they seem to be keeping out of this titanic discussion ...

I'm hoping that you are familiar with this table:

https://xritephoto.com/documents/lit...Data-1p_EN.pdf

In particular, please see patches 19 to 24 where it is quite evident that the white patch is not pure white and that the black patch is not jet black.

If I were Tarek, interested only in the difference in output brightness between one converter and another, I would concentrate on the mid-gray patch #22 and would ignore the black and white patches as irrelevant ...

Ted - through my working life I had the opportunity to work with many people that presented reasoning like you do, so I know how to not fall into the traps. The point you want agreement on is irrelevant to what is going on here, so agreeing with you would set the discussions down a path you would like to take them, and in this particular case, you are getting into the the wrong area as to the root cause of what we are being asked.

My initial feelings are that Tarek is "over his head", based on what he has written and posted:

1. When I see badly underexposed test images, the alarm bells go off. Why are we seeing underexposed images with a very limited data range? Normally whenever tests are carried out we look to optimize this parameter.

2. Raw processor comparison - different raw processor give different results. These are highly personal choices, but regardless it is impossible to compare. These are "apples to oranges" comparisons and in my view meaningless in the context of the question being asked.

3. Not understanding the basic functionality of the Capture One workflow. Recipes are fundamental to the use of this tool and statements made by Tarek seem to suggest he is not all that familiar with them. To me that suggests limited familiarity with this tool.

4. Not understanding that an image file needs to have a colour space assigned to it. Again, that is very fundamental to how one outputs from a raw processor. Selecting "Embed Camera Profile" is not an appropriate selection. That being said, Phase One does not make this easy as all ICC and ICM profiles are accessible at this stage of the image output process. The correct choice in most cases will be the working colour space.

5. This is really an extension of what I wrote in #4; profiles assigned in the Base Characteristics Tool in Capture One. These can be assigned in either the Exposure or Color tool tabs. This is where we see a lot of variability in the output and as I mentioned in #7, where I suspect the main underlying problem lies

Look at how different the output looks, depending on which profile is selected. I made a short video capture of just one subset that I can use with my camera. The colours and brightness are all over the map.



CiC seems to not like linking to YouTube - here is the direct link: https://www.youtube.com/watch?v=gi9_JobrfMI

[xpatUSA]

Ted - through my working life I had the opportunity to work with many people that presented reasoning like you do, so I know how to not fall into the traps. The point you want agreement on is irrelevant to what is going on here, so agreeing with you would set the discussions down a path you would like to take them, and in this particular case, you are getting into the the wrong area as to the root cause of what we are being asked.<>

Manfred, I had already deleted that post. But, as can happen on this Forum, it continued on your computer somehow.

Please consider the "traps" withdrawn.

[TarekAH]

Hi again!
sorry I was just out of town.

I appreciate all the valuable comments set by you all, thanks

well let me clarify my intention and couple of things here:
my primary concern for now as @xpatUSA expressed is really understanding the difference in brightness between the output of two raw converter (specifically CaptureOne engine as it seems to me there is something under the hood happening "uncontrollable?" while exporting UNCORRECTED tiff image)

secondly, thanks @Manfred for all your comments. However, my intention is really more scientific than photographic as I am not seeking aesthetic appealing color chart (color values) rather studying the scientific response of all the elements (for now raw converters software behavior).
so as @xpatUSA mentioned again in one of his comment that a pitch dark black patch and very polished white patch are far from reality to fetch and usually they have quite of a range (<~50 for black, around >220 for white)

anyway, one of my intentions is to have "if possible" a very close output from CaptureOne to the output of Libraw hopefully. So for that I am seeking to understand the underlying mechanism very well of CaptureOne engine and hence my whole thread.

PS: @Manfred what you have mentioned about choosing the working color space is totally correct and thanks for clarifying that up but I've mentioned that I am putting the profile to "No Color Correction" as I am intending to apply my own custom ICC profile later on

[TarekAH]

Hi Tarek

There is very little information published by Capture One on how they apply icc camera profiles however Anders Torger has looked at this in conjunction with his DCamProf camera profiling software. See this link. He concludes that even with Linear Response Curve selected, the tonal response is not linear due to some "unknown" pre-processing done before the tone curve is applied. I think this may account for the difference in brightness you are seeing.

Dave

Hi Dave!

thanks for your link...that is totally true, I've been reading Torger's blog and it is really valuable.
His comment about CaptureOne unclear processing and "non-linearity" is kinda shocking for me but it is making it clear that their concern could be more into aesthetics as I can understand it

[dje]

Hi Dave!

thanks for your link...that is totally true, I've been reading Torger's blog and it is really valuable.
His comment about CaptureOne unclear processing and "non-linearity" is kinda shocking for me but it is making it clear that their concern could be more into aesthetics as I can understand it

Hi Tarek

I've been doing a bit more digging on Capture One's Internal Working color space and found this thread. Posts 63 and 84 are particularly relevant. It seems that CO doesn't use a standard working color space but rather the RGB adjustments are done on the de-mosaiced white balanced RAW values from the camera (referred to as "camera RGB space"). The camera profile is applied at the end of the processing pipeline for displaying the preview, calculating RGB numbers and exporting. This final process would involve using the camera profile to convert camera RGB to profile connection space (Lab in this case) and then using the standard color profile highlighted in the process recipe to convert to Adobe RGB, Prophoto RGB, sRGB etc.

In the process recipe you can select "Embed Camera Profile" but you would only use this for special work (for which I can't give you an example). Normally you would select one of the standard device independant color space profiles.

The gamma encoding in the output file is determined by the color space chosen. But for images viewed in a color managed system, the gamma is irrelevant to how the image appears. It is "neutralised" by the CMS before it reaches the display. The gamma will however affect the RGB readout values when you select a part of the image with an eyedropper or the cursor.

Dave.

[xpatUSA]

Excellent clarification, Dave. This pedantic old man is highly impressed!!

"Camera RGB space" sounds similar in principle to Kodak RIMM, an input-referred color encoding:

http://kronometric.org/phot/color/Kodak%20RIMM.pdf
.

[Manfred M]

Dave - not only did I find the two articles of interest, I noticed that David Grover / Phase One was being challenged by DigitalDog (a.k.a. Andrew Rodney) who has a very long and storied history in digital photography. He is part of the group that wrote the sharpening routines that Adobe bought and incorporated into Lightroom.


http://digitaldog.net/

In theory, I can understand where Grover is coming from in the points he makes, but the approach Phase One has chosen cannot be described as being particularly main stream or elegant. Do the theoretical advantages outweigh the technical limitations? Frankly, I am still not quite sure what a camera colour space is or why Phase One chose to go that route. I don't feel that Rodney's questions or concerns were adequately addressed.

[dje]

Excellent clarification, Dave. This pedantic old man is highly impressed!!

"Camera RGB space" sounds similar in principle to Kodak RIMM, an input-referred color encoding:

http://kronometric.org/phot/color/Kodak%20RIMM.pdf
.

Thanks Ted.

The "camera RGB space" is not really a defined color space at all and is device dependant. On the other hand, RIMM is a defined color space with the same chromaticities as ROMM and ProPhoto. The differences between these three are in the non-linear encoding (trc's or gamma if you like).

Dave

[dje]

In theory, I can understand where Grover is coming from in the points he makes, but the approach Phase One has chosen cannot be described as being particularly main stream or elegant. Do the theoretical advantages outweigh the technical limitations?

Manfred i have similar thoughts. I do like the raw conversions that CO does on my Sony files but doubt that this is related to their color space approach.

Dave

[xpatUSA]

Thanks Ted.

The "camera RGB space" is not really a defined color space at all and is device-dependent.

Indeed, Dave. For example, a particular Sigma camera goes straight from camera space to XYZ via the following 3x3 matrix:



For some reason it uses approx D55 as the white reference. Further processing then sets the output space, white balance, etc. For other Sigma models, the nine coefficients have other values than the above, thereby illustrating your device-dependency!

On the other hand, RIMM is a defined color space with the same chromaticities as ROMM and ProPhoto. The differences between these three are in the non-linear encoding (trc's or gamma if you like).

Dave

Yes indeed. Also ROMM and ProPhoto are the same as each other, as you probably know. A big difference in my mind is between the usage of ROMM and the later RIMM. RIMM is scene-referred: essentially being what-the-camera-saw but transformed to the RGB model with a particular white reference (D50) and with no adjustments to correct capture errors, wrong color balance, insufficiently pretty aesthetics, etc. ROMM, on the other hand, is output-referred and can contain any such adjustments.

http://kronometric.org/phot/gamut/Ko...te%20paper.pdf

http://kronometric.org/phot/gamut/Ko...te%20paper.pdf

Sometimes I find Kodak-speak pretty hard to understand ...

A related and interesting discussion here:

https://www.ledet.com/margulis/2007H...oPhoto_RGB.htm

Warning: high Rodney content ...

[Manfred M]

I do like the raw conversions that CO does on my Sony files

In my view, this is probably the most important consideration when processing an image.

[xpatUSA]

Originally Posted by dje I do like the raw conversions that CO does on my Sony files

In my view, this is probably the most important consideration when processing an image.

I think that a raw conversion with correct settings should place on my screen what I saw. No más, No menos.

[dje]

Sometimes I find Kodak-speak pretty hard to understand ...

Me too! Frankly I have trouble seeing a use for RIMM. Must read your references a few times.

Warning: high Rodney content ...

That's not uncommon!

[Manfred M]

Ted - The articles in the link to margulis were written in 2006 and while the colour spaces have not changed, the underlying processing engines have been updated numerous times, so it's hard to know as to how relevant the discussion is with current software.

[TarekAH]

Hi Tarek

I've been doing a bit more digging on Capture One's Internal Working color space and found this thread. Posts 63 and 84 are particularly relevant. It seems that CO doesn't use a standard working color space but rather the RGB adjustments are done on the de-mosaiced white balanced RAW values from the camera (referred to as "camera RGB space"). The camera profile is applied at the end of the processing pipeline for displaying the preview, calculating RGB numbers and exporting. This final process would involve using the camera profile t
Dave.

does that imply saying that you actually don't get a "pure" raw as it is but rather an "already modified" raw out of the camera directly?

(this what I could understand from the inner color space in the camera itself doing the mapping)

[dje]

does that imply saying that you actually don't get a "pure" raw as it is but rather an "already modified" raw out of the camera directly?

(this what I could understand from the inner color space in the camera itself doing the mapping)

No Tarek, the "pure" raw file out of the camera is opened up in CO. It then does a certain amount with the raw data including demosaicing and white balance. This is what happens with most raw processors. However with most processors, the next step is to apply a camera profile to convert the RGB information into a defined working color space such as Prophoto, and then apply further processing. But with CO, it continues on with processing using this semi-processed RGB data without converting to a standard color space. It's only at the end of the processing pipeline that the camera profile is applied for preview and export purposes.

That's how I understand it anyway!
Dave