CaptureOne raw output is too bright

[TarekAH]

Hi!
I am just wondering if anyone is using CaptureOne for processing raw images, specifically from PhaseOne cameras.
I've been trying to convert the raw image into a tiff format and it goes just well. However, the problem is the tiff after conversion with NO ICC profile or color correction being applied yet and supposedly with a linear response, still it seems to me so bright unlike other raw converter and contradicting the common sense where you expect to see a dark/dim output!

Anyone has some speculation on the matter, what is going on?

here is the raw-->tiff output from
1- CaptureOne
https://imgur.com/a/J31yXj6
2- Libraw
https://imgur.com/sod2EHn

best,
Tarek

[bhurley]

Just checking: you say no ICC profile or color correction, but do you have the curve set to Linear Response instead of Auto? This is on the color tab, under Base Characteristics. If it's set to Auto or anything other than Linear Response that might be the problem.

[TarekAH]

@bhurley thanks for the response.
yeah I've mentioned that the curve response is set to "linear" but still the output is really strange for me!
it seems just like there is an auto-brightness adjustment being done

*PS: I will include a link to the output photo I am getting

[TarekAH]

oh by the way...
do you happen to know, if so, what value of gamma correction CaptureOne is using?

I've been reading for days online but it seems it is a secret kept by the company with some speculation saying it is around 1.8 :/

[bhurley]

Okay, and did you verify that your process recipe for TIFF does not include a profile? See https://support.captureone.com/hc/en...ecipe-settings

[TarekAH]

Okay, and did you verify that your process recipe for TIFF does not include a profile? See https://support.captureone.com/hc/en...ecipe-settings

I usually don't use any of the recipe, simply I just export it as a variant and make sure that the selected ICC profile is set to "embed camera profile". (you cannot choose to have none :/ )

and anyway, I've tried to select all the available profiles from the list one by one and yet the result is not as expected at all.

[Manfred M]

I usually don't use any of the recipe, simply I just export it as a variant and make sure that the selected ICC profile is set to "embed camera profile". (you cannot choose to have none :/ )

and anyway, I've tried to select all the available profiles from the list one by one and yet the result is not as expected at all.

Tarek(?) Welcome to CiC. Based on some of the things you have written, you seem a bit unclear as to how raw convertors / parametric editors work. I don't know your background in photography, so please excuse me if I go into things you already know and understand.

The data brought in from your camera is just that, data. What the raw convertor does is to convert that to an image file, in your case a TIFF. There are three pieces of information that the raw converter needs to have in order to create an image file; the colour space you want to have the file working in, the colour temperature and the gamma curve. The last item is the only one that you can't control and it is built in. So far as I know, the universally accepted value is 2.2, although some time ago (~ 10 years if I recall correctly. Apple was using a value of 1.8, but switched to 2.2 like everyone else). Regardless, a gamma curve is a bit of a historical anomaly; it was necessary in the old cathode ray tube displays that were not linear like current displays. Nicely said, the gamma curve is applied to create the data and an inverse is applied when the computer's display driver processes the image an the net output is linear.

Embedding the camera profile is likely your issue. When I use this for one of my raw files, it comes out looking muddy like yours. Typically what happens is that when there is a colour space issue, the software will default to sRGB and a wide gamut colour space will appear "muddy". Rather than using the camera profile one, I suggest you select a wide gamut colour space like Adobe RGB or ProPhoto RGB and I suspect that will go a long way to resolving what you are seeing.

The other thing to remember is that raw data is rather dull when converted, so most raw converters apply sharpening and contrast. These are values you should be setting in Capture One. Your output should be an image file that looks the way you want it to. That is what the parametric editor part of the raw converter is used for.

I am no expert of Capture One, as I primarily use it for tethered capture. I tend to use Adobe Camera Raw and to a lesser extent DxO Labs PhotoLab 3. I do use Capture One on occasion.

[xpatUSA]

oh by the way...
do you happen to know, if so, what value of gamma correction CaptureOne is using?

I've been reading for days online but it seems it is a secret kept by the company with some speculation saying it is around 1.8 :/

I don't use Capture One but I can tell you that the gamma in any converter is auto-set depending on the working color space. 1.8 for ProPhoto, 2.2 for Adobe, 2.4 plus a linear portion for sRGB, etc, etc.

[bhurley]

I don't use Capture One but I can tell you that the gamma in any converter is auto-set depending on the working color space. 1.8 for ProPhoto, 2.2 for Adobe, 2.4 plus a linear portion for sRGB, etc, etc.

This seems like the most likely explanation for what you're seeing. I'm mostly doing cinematography these days and when grading you have to set your gamma based on the environment in which your deliverable will be used: gamma 2.2 would be for viewing on computer monitors (typically in a brightly lit office); gamma 2.4 is for viewing on televisions (typically in more dimly lit environments); I think cinema is typically gamma 2.6 (completely dark environments). If you had your reference monitor set to gamma 2.4 but delivered in gamma 2.2 it would look too bright and contrasty in comparison; similarly if your monitor is set it gamma 2.2 but you deliver your file in gamma 2.4 it'll look washed out and not contrasty enough.

In Capture One's render recipes you can set the output color space profile and based on xpatUSA's comment above each of those color space profiles has a default gamma assigned to it. So probably what's going on is that you're choosing a different color space (and thus gamma) for the rendered file compared with the one you've used in other raw processing applications.

[xpatUSA]

here is the raw-->tiff output from
1- CaptureOne
https://imgur.com/a/J31yXj6
2- Libraw
https://imgur.com/sod2EHn

Something is not matching the original complaint: These two images have the same brightness in FireFox on my sRGB monitor.

[Manfred M]

This seems like the most likely explanation for what you're seeing. I'm mostly doing cinematography these days and when grading you have to set your gamma based on the environment in which your deliverable will be used: gamma 2.2 would be for viewing on computer monitors (typically in a brightly lit office); gamma 2.4 is for viewing on televisions (typically in more dimly lit environments); I think cinema is typically gamma 2.6 (completely dark environments). If you had your reference monitor set to gamma 2.4 but delivered in gamma 2.2 it would look too bright and contrasty in comparison; similarly if your monitor is set it gamma 2.2 but you deliver your file in gamma 2.4 it'll look washed out and not contrasty enough.

In Capture One's render recipes you can set the output color space profile and based on xpatUSA's comment above each of those color space profiles has a default gamma assigned to it. So probably what's going on is that you're choosing a different color space (and thus gamma) for the rendered file compared with the one you've used in other raw processing applications.

We are getting way too complicated here. The real issue is that these samples are:

(a) Badly underexposed; and

(b) the white balance is off.

The black swatch should have readings close to 0,0,0 and the white close to 255, 255, 255. They are not even in the ballpark.





Call me when the test swatch looks more like this (this uses the x-Rite ColorChecker Passport target).

[xpatUSA]

We are getting way too complicated here.

The black swatch should have readings close to 0,0,0 and the white close to 255, 255, 255.

Are you sure, Manfred? The data-sheet for my Mini Color-checker lists 52 for black and 243 for white (sRGB, D65).

In Lab, D50 it lists L* as 20.46 and 96.54 respectively. Certainly not zero and one hundred ...

[bhurley]

Something is not matching the original complaint: These two images have the same brightness in FireFox on my sRGB monitor.

They look different to me; the export from libraw is noticeably darker. I found this potentially helpful forum exchange on libraw's default gamma profile for TIFF exports: https://www.libraw.org/node/2594

[Manfred M]

Are you sure, Manfred? The data-sheet for my Mini Color-checker lists 52 for black and 243 for white (sRGB, D65).

In Lab, D50 it lists L* as 20.46 and 96.54 respectively. Certainly not zero and one hundred ...

Nicely said, so what? The numeric values of what was printed will not necessarily match the test swatch I shot. I'm not working in a lab environment with controlled lighting. I was shooting a test swatch for profiling purposes outdoors in the courtyard of my house. All I every look for is neutral tones; the exact values really don't matter for the type of work I do.

I probably take more care with this aspect of photography than most.

[xpatUSA]

Originally Posted by TarekAH here is the raw-->tiff output from
1- CaptureOne
https://imgur.com/a/J31yXj6
2- Libraw
https://imgur.com/sod2EHn

They look different to me; the export from libraw is noticeably darker.

Yes, I withdraw my comment about brightness.

For some reason the links in the OP, quoted above, both go to the same image, captioned "SpyderCheckr24 Libraw raw-->tiff output" which leaves me with egg on my face ...

Thanks, Tarek.

[xpatUSA]

Nicely said, so what?

You effectively advised Tarek that patch 24 should come out black "close to 0,0,0" and that patch 19 should come out white "close to 255,255,255". This in spite of the published fact that neither of those patches have that tonality, unless the Passport is radically different to my X-rite mini checker.

The numeric values of what was printed will not necessarily match the test swatch I shot. I'm not working in a lab environment with controlled lighting. I was shooting a test swatch for profiling purposes outdoors in the courtyard of my house. All I [ever] look for is neutral tones; the exact values really don't matter for the type of work I do.

So based on that, next time I shoot and post something with jet black shadows I'll be aware that "the exact values really don't matter" and that 0,0,0 is probably good enough,eh?

I probably take more care with this aspect of photography than most.

Curiously enough, the neutral patches seem about right in the above ... all a bit confusing to this old man ...

[Manfred M]

You effectively advised Tarek that patch 24 should come out black "close to 0,0,0" and that patch 19 should come out white "close to 255,255,255". This in spite of the published fact that neither of those patches have that tonality, unless the Passport is radically different to my X-rite mini checker.

The last time I checked black is 0,0,0 and white is 256, 256, 256. It doesn't matter what that actual values are as printed. The reflected light will virtually always give somewhat different values. I was careful enough to use the words "close to

So based on that, next time I shoot and post something with jet black shadows I'll be aware that "the exact values really don't matter" and that 0,0,0 is probably good enough,eh?



Curiously enough, the neutral patches seem about right in the above ... all a bit confusing to this old man ...

Ted - let me say it again; "so what". Please explain why getting the value right on actually matters?

Shots of these test cards tend to be used for one of two purposes:

1. Ensuring that one can generate a colour neutral image based on using the card to set the appropriate white balance; and

2. Using the card to generate a camera or scene specific profile. Here the actual colours are known inside the profiling software and the difference between the value read from the image is used to create the profile. The exact values are not necessary as the software determines the delta between the as shot value and the actual value.

Where there can be an issue, I suspect, is when the exposure is so far off that the sample point is too far from nominal to work with.

As long as the black square not crushed or the white square is not clipped, the other values don't really matter.

Unless there is a very specific reason, that Tarek has not mentioned, to pull some other data out of the card, my answer is more than sufficient.

[dje]

Hi!
I am just wondering if anyone is using CaptureOne for processing raw images, specifically from PhaseOne cameras.
I've been trying to convert the raw image into a tiff format and it goes just well. However, the problem is the tiff after conversion with NO ICC profile or color correction being applied yet and supposedly with a linear response, still it seems to me so bright unlike other raw converter and contradicting the common sense where you expect to see a dark/dim output!

Anyone has some speculation on the matter, what is going on?

here is the raw-->tiff output from
1- CaptureOne
https://imgur.com/a/J31yXj6
2- Libraw
https://imgur.com/sod2EHn

best,
Tarek

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

[xpatUSA]

Ted - let me say it again; "so what". Please explain why getting the value right on actually matters?

I'll try, Manfred.

The issue under discussion in this thread is that of a raw image rendered by Capture One being brighter than that same raw rendered by another converter (LibRaw).

The example provided by Tarek was a rendition of a 24-patch X-Rite color-checker card. Tarek's only concern was about the relative brightness between two converters. Choosing not to address that concern, you took it upon yourself to criticize instead the "exposure" of one image only, thereby missing the point of this thread. In post #11 you further showed an example image with incorrect values for the "black" and "white" patches. How your example was created I have no idea, but producing a shot of the card with the mid-gray patch rendered at about 160 when it should be about 120 certainly emphasizes your expressed opinion that "the other values don't really matter"

Shots of these test cards tend to be used for one of two purposes:

1. Ensuring that one can generate a colour neutral image based on using the card to set the appropriate white balance; and

2. Using the card to generate a camera or scene specific profile. Here the actual colours are known inside the profiling software and the difference between the value read from the image is used to create the profile. The exact values are not necessary as the software determines the delta between the as shot value and the actual value.

There is a third purpose, checking an imager for color and tonal accuracy - see Imatest for examples of that.

Where there can be an issue, I suspect, is when the exposure is so far off that the sample point is too far from nominal to work with.

As long as the black square not crushed or the white square is not clipped, the other values don't really matter.

Unless there is a very specific reason, that Tarek has not mentioned, to pull some other data out of the card, my answer is more than sufficient.

And misleading, IMHO.

[Manfred M]

I'll try, Manfred.

The issue under discussion in this thread is that of a raw image rendered by Capture One being brighter than that same raw rendered by another converter (LibRaw).

The example provided by Tarek was a rendition of a 24-patch X-Rite color-checker card. Tarek's only concern was about the relative brightness between two converters. Choosing not to address that concern, you took it upon yourself to criticize instead the "exposure" of one image only, thereby missing the point of this thread. In post #11 you further showed an example image with incorrect values for the "black" and "white" patches. How your example was created I have no idea, but producing a shot of the card with the mid-gray patch rendered at about 160 when it should be about 120 certainly emphasizes your expressed opinion that "the other values don't really matter"



There is a third purpose, checking an imager for color and tonal accuracy - see Imatest for examples of that.



And misleading, IMHO.

Sorry Ted - there are some comments he makes that make me suspicious regarding his approach. No colour raw processors provide exactly the same output, so having a difference is the norm. In general they all have a default behaviour and unless you are using an open source one and have dissected the code, we don't know exactly what is happening "under the hood".

The one thing I do know is that in order to create any image file, like a TIFF, one has to assign a colour space. The only thing we know is that he assigned is "Embed Camera Profile". This is nothing more than a custom ICC profile for the camera, not a colour space. No idea as to how that will impact the image output, but I'm fairly certain the output will be a bit strange as some of the software defaults are bound to kick in.

Secondly, in order to output an image profile, a colour space has to be selected. Unfortunately, we have no information here as both samples have been converted to sRGB. When I look at the two, I've seen this many times before - the muddiness tends to be what we see when a wide gamut image is interpreted as a narrow gamut (sRGB) image.

This is one of the original images:





This is what happens when I converted the image to a wide profile colour space (ProPhoto in this example) and then assigned (not converted) it as an sRGB image. Notice how much darker and duller the image is. Very similar to what we see in the original images.



I can't match exactly what happened because I don't have the original raw data, but as I mentioned in #7, this is what I suspect is causing the difference in colours, at a high level. I get suspicious when an inappropriate profile is assigned as a colour space.



Still, I do have an issue with analyzing badly underexposed images. That suggests some technical issues in capture.