Luminous Landscape Forum
Raw & Post Processing, Printing => Capture One Q&A => Topic started by: Dinarius on November 26, 2015, 10:14:25 am
-
In the colour tab in C1, under Base Characteristics/ICC Profile, I cannot find ProPhoto RGB. Am I going blind? Coz ProPhoto RGB is an option in the File/Export Images dialog.
So, if I'm right, and it isn't there, isn't it odd that you can't edit in ProPhoto, but there is the option to save in it?
Can I import ProPhoto RGB and make it an option to edit in?
Thanks.
D.
Ps. Adobe RGB 1998 is hidden under other. The default C1 chooses is the default for your camera, it seems.
-
In the colour tab in C1, under Base Characteristics/ICC Profile, I cannot find ProPhoto RGB. Am I going blind? Coz ProPhoto RGB is an option in the File/Export Images dialog.
So, if I'm right, and it isn't there, isn't it odd that you can't edit in ProPhoto, but there is the option to save in it?
Can I import ProPhoto RGB and make it an option to edit in?
Thanks.
D.
Ps. Adobe RGB 1998 is hidden under other. The default C1 chooses is the default for your camera, it seems.
This is the input profile for your camera, so in no way you would want to choose an output Color space!
-
David,
Thanks for the reply.
If I want to edit using a Gretag Color Checker in some of the images, and if I want to assign Adobe 1998 RGB values to it, or ProPhoto RGB values, then shouldn't I be choosing these spaces from that list?
If not, what RGB values am I getting from the chart in the image?
Thanks.
D.
-
Ok, am I right in thinking that if I leave Base Characteristics/ICC Profile at Camera Generic, but change View/Proof Profile to ProPhoto RGB, then the RBG values I'm seeing on the screen are in ProPhoto?
Thanks.
D.
-
If not, what RGB values am I getting from the chart in the image?
Another question only someone like David can answer is, what's the gamut of the processing color space and would you even need to use ProPhoto RGB?
Adobe has made it quite clear what the processing color space is: ProPhoto RGB primaries and thus it's gamut. So that would be a logical choice to select for some work. C1?
-
Another problem I have (related though not strictly relevant here) is that if I Pick a Colour Sample using the color picker in either the Basic or Advanced Color Editors, the RGB values in the Color Editor dialog are completely different from those above the image at the top of the screen.
This happens no matter how many selections I make from, say, a patch on a Gretag Color Checker.
I'm Windows 10. It would be interesting to know if others have the same problem.
So, which values are correct?
Thanks.
D.
-
Ok, am I right in thinking that if I leave Base Characteristics/ICC Profile at Camera Generic, but change View/Proof Profile to ProPhoto RGB, then the RBG values I'm seeing on the screen are in ProPhoto?
Thanks.
D.
Noooooooo!
You MUST have a camera profile in the Base Characteristics tool.
Goto View>Proof Profile. By default Capture One is proofing to your selected recipe.
Or you can choose any other profile you wish.
David
-
Another problem I have (related though not strictly relevant here) is that if I Pick a Colour Sample using the color picker in either the Basic or Advanced Color Editors, the RGB values in the Color Editor dialog are completely different from those above the image at the top of the screen.
This happens no matter how many selections I make from, say, a patch on a Gretag Color Checker.
I'm Windows 10. It would be interesting to know if others have the same problem.
So, which values are correct?
Thanks.
D.
Shouldn't be the case and not my experience. But have you already got color edits applied to the image? That will influence.
-
David, thanks for the reply.
The differing RGB read outs occur even if it's the first thing I do to an image. I hover the color picker over the Greteg color patch, carefully noting the values at the top of the screen. Then I click. The values in the Color Editor dialog are, typically, 15 points different for all three values. It's the same for Basic and Advanced editors.
What would be great would be to have the option of 1x1, 5x5 and 10x10 Color picker samples.
D.
-
Not meaning to hijack the thread, but when I select Proof Profile, i actually see two ProPhoto RGB profiles. Does it matter which one is selected? How did two of them get there in the first place?
-
Not meaning to hijack the thread, but when I select Proof Profile, i actually see two ProPhoto RGB profiles. Does it matter which one is selected? How did two of them get there in the first place?
Two sRGB profiles too. You're on a Mac right? Open the ColorSync utility, it will show you where every ICC profile everywhere on your Mac resides. You can also view if they are indeed the same 'spec' viewing various values.
-
Another question only someone like David can answer is, what's the gamut of the processing color space and would you even need to use ProPhoto RGB?
Hi Andrew,
This (http://help.phaseone.com/en/CO6/Output/Learn-More-about-file-formats/Colors-in-Capture-One.aspx) is what is publicly known. Capture One works in a very large color space, similar to that captured by camera sensors. A large color space ensures that little clipping of the color data can occur. Clipping is the loss of image information in a region of an image. Clipping appears when one or more color values are larger than the histogram (color space of the output file).
So my reading of that is that the workspace is somewhat larger than the camera space would render to in RGB coordinates, but maybe not as immense as ProPhoto RGB. This would potentially be a risk if significant saturation boosts were added and the internal processing is done in integer math, but I assume that there's at least some floating point math going on as well (as facillitated by OpenCL), which would avoid cumulative rounding errors and is quite fast on modern computers.
Exactly how large that workspace is, I do not know, but it is at least larger than (most/all) output modalities require. I've plotted some of the Camera profiles and they usually only exceed the printer media profiles in a few specific spots. Of course, because a profile can encode a color coordinate, doesn't mean that it's also a (meaningful) humanly visible color.
It therefore seems that CaptureOne correctly attempts to use as small a colorspace as needed (thus maximizing quantization accuracy), but large enough to avoid clipping at the source. One can output as ProPhoto RGB in case one needs to do postprocessing that involves saturation boosts, or one can directly output to an output medium profile. The choice of output profile is usually also the proofing profile setting in the viewer (but that can be changed by the user).
Cheers,
Bart
-
Hi Andrew,
This (http://help.phaseone.com/en/CO6/Output/Learn-More-about-file-formats/Colors-in-Capture-One.aspx) is what is publicly known.
Thanks but it doesn't answer the question. ;D
We both know this is BS: Capture One works in a very large color space, similar to that captured by camera sensors.
-
Thanks but it doesn't answer the question. ;D
We both know this is BS: Capture One works in a very large color space, similar to that captured by camera sensors.
Of course it is not bullshit, and you know it. The Raw camera RGB is profiled, and that can be expressed as a gamut by plotting the hull and calculating the size.
Cheers,
Bart
-
Of course it is not bullshit, and you know it. The Raw camera RGB is profiled, and that can be expressed as a gamut by plotting the hull and calculating the size.
When I stated we both knew it was BS, I assumed you understood the subject, sorry
Raw image data is in some native camera color space, but it is not a colorimetric color space, and has no single “correct” relationship to colorimetry. The same thing could be said about a color film negative. Someone has to make a choice of how to convert values in non-colorimetric color spaces to colorimetric ones. The choice is that I've asked about, the web page you provide didn't answer the question. There are better and worse choices, but no single correct conversion (unless the “scene” you are photographing has only three independent colorants, like when we scan film).Cameras don’t have primaries, they have spectral sensitivities, and the difference is important because a camera can capture all sorts of different primaries. Two different primaries may be captured as the same values by a camera, and the same primary may be captured as two different values by a camera (if the spectral power distributions of the primaries are different). A camera has colors it can capture and encode as unique values compared to others, that are imaginary (not visible) to us. There are colors we can see, but the camera can't capture that are imaginary to it. Most of the colors the camera can "see" we can see as well. Yet some cameras can “see colors“ outside the spectral locus however every attempt is usually made to filter those out. Most important is the fact that cameras “see colors“ inside the spectral locus differently than humans. No shipping camera that I know of meets the Luther-Ives condition. This means that cameras exhibit significant observer metamerism with respect to humans. The camera color space differs from a more common working color space in that it does not have a unique one to one transform to and from CIE XYZ. This is because the camera has different color filters than the human eye, and thus "sees" colors differently. Any translation from camera color space to CIE XYZ space is therefore an approximation. What is the CIE XYZ space?
The point is that if you think of camera primaries you can come to many incorrect conclusions because cameras capture spectrally. On the other hand, displays create colors using primaries. Primaries are defined colorimetrically so any color space defined using primaries is colorimetric. Native (raw) camera color spaces are almost never colorimetric, and therefore cannot be defined using primaries. Therefore, the measured pixel values don't even produce a gamut until they're mapped into a particular RGB space. Before then, *all* colors are (by definition) possible.
So no, whatever processing COLOR SPACE I've asked about isn't the same or even similar to that captured by a camera sensor!
Adobe for whatever reason has no issue telling it's users what the actual color space for processing is utilized: ProPhoto RGB primaries with a 1.0 TRC. C1's page was written with ambiguities and marketing BS.
-
The Raw camera RGB is profiled, and that can be expressed as a gamut by plotting the hull and calculating the size.
You do realize that the gamut of a profiled camera can't be any larger than the gamut of the target used to create the profile and it again has nothing to do with the processing color space (a real, colorimetric color space as Adobe defines for it's processing) used? You do realize that the so called 'color' captured by camera sensor has no color gamut?
-
You do realize that the gamut of a profiled camera can't be any larger than the gamut of the target used to create the profile
imagine yourself creating a simple matrix profile using for example a CC24 ColorChecker Classic target (with its quite low saturated patches)... but this is a matrix profile, there are no LUTs to clamp/limit the output of the color transform that is guided by that matrix
-
You do realize that the gamut of a profiled camera can't be any larger than the gamut of the target used to create the profile ...
The target is partly irrelevant because a profile is only using those target patches that are present to interpolate and, equally if not more important, extrapolate (all the way to a whiter white than the whitest reflective patch, and darker black than the darkest reflective patch with a veiling glare component). The full hull of the profile is larger than that of the most saturated patches of the target. How much larger the profile's gamut is, depends on how the profile was made. One can output with Capture One a capture of e.g. a CC24 target with the/a Camera profile attached, as is done for profiling. That will output the imageof the target without processing, and one could consider that embedded profile as the bare sensor profile, which has a gamut that can be plotted and compared.
... and it again has nothing to do with the processing color space (a real, colorimetric color space as Adobe defines for it's processing) used?
An input profile has everything to do with the processing working space, because it is converted from input space to workingspace / processing space. That Adobe supposedly described the space and Capture One did not explicitely is also irrelevant, they both use a space that is large enough (larger than the input profile gamut) to avoid clipping.
You do realize that the so called 'color' captured by camera sensor has no color gamut?
A color by itself has no gamut, but the colorspace that it is part of has a color gamut. Some of the camera's captured colors may be imaginary colors for human vision, but that's before processing and gamut mapping operations.
Cheers,
Bart
-
The target is partly irrelevant because a profile is only using those target patches that are present to interpolate and, equally if not more important, extrapolate (all the way to a whiter white than the whitest reflective patch, and darker black than the darkest reflective patch with a veiling glare component).
The profile itself, the one(s) you mention are equally irrelevant in telling us anything about the processing color space I've requested info about. None the less, the target and it's gamut certainly play a role or X-rite wouldn't have somewhat struggled to create three of them over the years (one with a group of very saturated but glossy and difficult to capture patches).
A color by itself has no gamut, but the colorspace that it is part of has a color gamut.
Agreed so what is the color space and thus gamut of the processing color space in C1? The URL you provided tells us nothing about it, further, the statement: Capture One works in a very large color space, similar to that captured by camera sensors, really? Nope.
-
I actually see two ProPhoto RGB profiles. Does it matter which one is selected? How did two of them get there in the first place?
You will find that there is one in the system preferences and one in your user preferences.
-
None the less, the target and it's gamut certainly play a role or X-rite wouldn't have somewhat struggled to create three of them over the years (one with a group of very saturated but glossy and difficult to capture patches).
one can assume that X-Rite (GretagMacbeth) apparently wanted to make a target suitable for creating "camera profiles" with LUTs where, if you create them using targets directly, you might need somewhat more reference points (patches) vs 24 (18 colored) in CC24-type targets and in case where you want LUTs you also want more to cover a wider gamut too... and struggle, I guess from reading around, has more to do with an average (and not so average) Joe not being able to make a proper shot with glossy/semi-gloss patches (ProfileMaker even had a provision /"ColorChecker DC wo gloss.txt" in reference files/ to ignore those patches in CCDC)... hence CCDC was abandoned, but CCSG still hands around...
-
When I stated we both knew it was BS, I assumed you understood the subject, sorry
Raw image data is in some native camera color space, but it is not a colorimetric color space, and has no single “correct” relationship to colorimetry. The same thing could be said about a color film negative. Someone has to make a choice of how to convert values in non-colorimetric color spaces to colorimetric ones. The choice is that I've asked about, the web page you provide didn't answer the question. There are better and worse choices, but no single correct conversion (unless the “scene” you are photographing has only three independent colorants, like when we scan film).Cameras don’t have primaries, they have spectral sensitivities, and the difference is important because a camera can capture all sorts of different primaries. Two different primaries may be captured as the same values by a camera, and the same primary may be captured as two different values by a camera (if the spectral power distributions of the primaries are different). A camera has colors it can capture and encode as unique values compared to others, that are imaginary (not visible) to us. There are colors we can see, but the camera can't capture that are imaginary to it. Most of the colors the camera can "see" we can see as well. Yet some cameras can “see colors“ outside the spectral locus however every attempt is usually made to filter those out. Most important is the fact that cameras “see colors“ inside the spectral locus differently than humans. No shipping camera that I know of meets the Luther-Ives condition. This means that cameras exhibit significant observer metamerism with respect to humans. The camera color space differs from a more common working color space in that it does not have a unique one to one transform to and from CIE XYZ. This is because the camera has different color filters than the human eye, and thus "sees" colors differently. Any translation from camera color space to CIE XYZ space is therefore an approximation. What is the CIE XYZ space?
The point is that if you think of camera primaries you can come to many incorrect conclusions because cameras capture spectrally. On the other hand, displays create colors using primaries. Primaries are defined colorimetrically so any color space defined using primaries is colorimetric. Native (raw) camera color spaces are almost never colorimetric, and therefore cannot be defined using primaries. Therefore, the measured pixel values don't even produce a gamut until they're mapped into a particular RGB space. Before then, *all* colors are (by definition) possible.
So no, whatever processing COLOR SPACE I've asked about isn't the same or even similar to that captured by a camera sensor!
Adobe for whatever reason has no issue telling it's users what the actual color space for processing is utilized: ProPhoto RGB primaries with a 1.0 TRC. C1's page was written with ambiguities and marketing BS.
Hi Andrew,
That link is from Capture One 6, discontinued in 2010, so no need to be so harsh!
If I knew the information you require, then I would have no problem imparting it. Truth is, I don't and my next question is, if you were armed with this information, what could you possibly do with it? (out of curiosity!)
D
-
Hi Andrew,
That link is from Capture One 6, discontinued in 2010, so no need to be so harsh!
If I knew the information you require, then I would have no problem imparting it. Truth is, I don't and my next question is, if you were armed with this information, what could you possibly do with it? (out of curiosity!)
I've also been wondering what would be next (it's too small, it's to big, it's not like LR?), and what's more, who's to say that it is a single colorspace with fixed primaries and white point? I'm not saying it is, but maybe the workspace adapts to the camera gamut that's required after a profile is assigned? What really matters, as I see it, is that the colorpace is large enough to avoid clipping, but not excessively large which would cause unnecessarily large quantization steps in 16-bit integer math, and thus result in lower precision and posterization risk.
Cheers,
Bart
-
what could you possibly do with it? (out of curiosity!)
well, he for example can be sure that colors outside of a certain gamut (after color transform guided by camera profile) will not be clamped further inside something internally - granted that somewhat can be tested - but why P1 for once stop being so secretive ?
-
well, he for example can be sure that colors outside of a certain gamut (after color transform guided by camera profile) will not be clamped further inside something internally - granted that somewhat can be tested - but why P1 for once stop being so secretive ?
Not being secretive - see above!
I am just thinking there must be a realllllly good reason to know information that you can't really do anything about.
-
Not being secretive - see above!
I am just thinking there must be a realllllly good reason to know information that you can't really do anything about.
you can actually - for example if that's really important to you then you can stop using C1 ... there is a thing called peace of mind.
-
you can actually - for example if that's really important to you then you can stop using C1 ... there is a thing called peace of mind.
Ok - happy with how the images look out of Capture One?
-
Ok - happy with how the images look out of Capture One?
as you know some people (granted a minority) like the numbers... and when the you try to dodge the answer it simply raises the questions/eyebrows, that's it...
-
as you know some people (granted a minority) like the numbers... and when the you try to dodge the answer it simply raises the questions/eyebrows, that's it...
I am not dodging! As I said earlier - I don't know the answer.
I would suggest to Andrew (and yourself) if it is something you need to know, then simply ask Tech support.
-
Hi Andrew,
That link is from Capture One 6, discontinued in 2010, so no need to be so harsh!
I'm not sure what to make of that statement David. Are you suggesting that since Capture one 6 is no longer, the nonsense statement I pointed out is more or less valid today? It isn't.
Why is the URL that Bart posted with the ridiculous statement still up?
If I knew the information you require, then I would have no problem imparting it. Truth is, I don't and my next question is, if you were armed with this information, what could you possibly do with it? (out of curiosity!)
Since you don't know the answer, how is telling us the URL Bart posted being about a discontinued produce relevant?
You asked, if armed with that info, what could you do with it? Answer the OP's question! See: http://forum.luminous-landscape.com/index.php?topic=106031.msg871608#msg871608
What's the gamut of the processing color space and would you even need to use ProPhoto RGB?
We know the processing color space of the ACR engine. Based on work I did years ago, I'm 99% certain that Aperture used a processing color space that had an Adobe RGB (1998) gamut. It's important because in Aperture, it would be pointless to encode into ProPhoto RGB working space! Just as the OP asked about ProPhoto and C1.
Your SIG states you are Business Support and Development Manager, Software for this company no? Then I assume, perhaps wrongly you have access to the engineers and marketing folks there too? And do you now realize as one would hope Bart does, that the statement: Capture One works in a very large color space, similar to that captured by camera sensors is rubbish.Better term than BS? Is it fair to have a URL with a statement, old or new that lies to the reader? Is there a reason why we can't get a simple answer to the processing color space gamut; bigger, smaller than Adobe RGB (1998) or ProPhoto RGB? Does the tech's at your company have reason to suggest the OP encode into ProPhoto RGB? Simple question despite the big lie someone in Marketing at C1 provided in the URL Bart posted. IF you don't know, do you know someone who does?
-
I am not dodging! As I said earlier - I don't know the answer.
I would suggest to Andrew (and yourself) if it is something you need to know, then simply ask Tech support.
I'd suggest to the OP he do the same. It's a shame a rep from a company cannot get the correct answers, ask their rep to answer as other companies do here or strive to educate himself on the facts of his product. Sorry David, I thought better of your ability to answer questions about your own product.
-
I've also been wondering what would be next (it's too small, it's to big, it's not like LR?), and what's more, who's to say that it is a single colorspace with fixed primaries and white point?
Wrong again Bart :'( . It would aid the OP, answer his question. You do realize (crap, I keep assuming you do), OK hopefully you understand that IF the colorimetric processing color space of a raw converter who's gamut can be now defined is smaller than say ProPhoto RGB, it's rather pointless to select that as the encoding color working space? Problem is, in terms of C1, WE DON'T KNOW and some here are unable to provide this simple information, instead reference nonsense: Capture One works in a very large color space, similar to that captured by camera sensors.
-
well, he for example can be sure that colors outside of a certain gamut (after color transform guided by camera profile) will not be clamped further inside something internally - granted that somewhat can be tested - but why P1 for once stop being so secretive ?
Exactly! :D
-
I am not dodging! As I said earlier - I don't know the answer.
David, but you as a "face" of P1 here can press developers to tell... come on... just look how many things Eric Chan from Adobe Labs shared here about the internals and what ? did that make ACR/LR worse or harmed it's marketshare ? on the contrary people (granted - a minority again) can understand better how to use Adobe converters, how to create camera profiles for them... goodwill might be good.
-
David, but you as a "face" of P1 here can press developers to tell... come on... just look how many things Eric Chan from Adobe Labs shared here about the internals and what ? did that make ACR/LR worse or harmed it's marketshare ? on the contrary people (granted - a minority again) can understand better how to use Adobe converters, how to create camera profiles for them... goodwill might be good.
Andrew / Mr Ego,
My goodness, please take a long deep breath. I can practically hear the blood vessels popping! There are many things in life to get excited / angry about - the working space of Capture One, should probably not be one of them.
1) The OP asked why couldn't he choose ProPhoto RGB in the Base Characteristics tool of Capture One. To which I answered and the OP seemed happy.
2) You may have not noticed but we have been in the midst of a new Capture One launch and therefore all R&D guys and girls have been pretty tied up and heads down concentrating on launch.
3) I will endeavour to find the answer out for you, before any more blood is spilt.
I had indeed intended to approach R&D about your (Andrew) question this week. My comments above were merely out of curiosity. i.e What are you going to do with this information.
I am sorry my Sig title has raised your expectations to one I cannot perform. To be honest, this is the first time anybody has send this question since I joined in 2012...therefore had not throughly researched the subject.
Peace!
David
-
Andrew / Mr Ego,
My goodness, please take a long deep breath. I can practically hear the blood vessels popping!
Just your imagination David. I personally have zero emotional baggage about C1 to affect my blood vessels. That you are unwilling or unable to find an answer to a simple question is telling.
1) The OP asked why couldn't he choose ProPhoto RGB in the Base Characteristics tool of Capture One. To which I answered and the OP seemed happy.
A nice, safe assumption on your part. Perhaps you're correct, perhaps the OP and others here, some perhaps thinking about an Adobe exit strategy would like to know if there's any reason to pick ProPhoto RGB as an encoding working space from raw data in C1. That you've gone out of your way not to answer the question and defend the silly URL Bart provided, let's say I'm curious now.
(2) You may have not noticed but we have been in the midst of a new Capture One launch and therefore all R&D guys and girls have been pretty tied up and heads down concentrating on launch.
No I didn't notice why should I? Sorry the company is so short staffed. All you have to do is promise you or someone who actually knows how the product operates from a colorimetry perspective will get back to us (and I'll hold you to that sir).
To be honest, this is the first time anybody has send this question since I joined in 2012...therefore had not throughly researched the subject.
So can you or anyone inside the company do that research and get us the answer? And further, how about that silly URL that's in serious need of fixing?
-
Just your imagination David. I personally have zero emotional baggage about C1 to affect my blood vessels. That you are unwilling or unable to find an answer to a simple question is telling. A nice, safe assumption on your part. Perhaps you're correct, perhaps the OP and others here, some perhaps thinking about an Adobe exit strategy would like to know if there's any reason to pick ProPhoto RGB as an encoding working space from raw data in C1. That you've gone out of your way not to answer the question and defend the silly URL Bart provided, let's say I'm curious now. No I didn't notice why should I? Sorry the company is so short staffed. All you have to do is promise you or someone who actually knows how the product operates from a colorimetry perspective will get back to us (and I'll hold you to that sir). So can you or anyone inside the company do that research and get us the answer? And further, how about that silly URL that's in serious need of fixing?
Did you miss point 3?
-
Did you miss point 3?
I missed the answer but I'm on hold (but not holding my breath, that would affect by blood vessels)
-
I missed the answer but I'm on hold (but not holding my breath, that would affect by blood vessels)
Good! Stay healthy!
You wrote a lot of stuff in angry bold like unwilling and unable - so therefore assumed you had missed my point that I would find out for you?
I didn't realise the required answer was so urgent.
-
You wrote a lot of stuff in angry bold like unwilling and unable - so therefore assumed you had missed my point that I would find out for you?
Bold is for emphasis. As the movie line goes: you've never seen me angry. ;D
-
Bold is for emphasis. As the movie line goes: you've never seen me angry. ;D
Ah - now I get it. I edited my post - http://forum.luminous-landscape.com/index.php?topic=106031.msg872377#msg872377 to help.
;)
-
Ah - now I get it. I edited my post - http://forum.luminous-landscape.com/index.php?topic=106031.msg872377#msg872377 (http://forum.luminous-landscape.com/index.php?topic=106031.msg872377#msg872377) to help.
;)
Good job. I'll try not to spit more blood in your direction.
-
3) I will endeavour to find the answer out for you, before any more blood is spilt.
thank you so much ! there are no bad feelings towards you or P1, but it is really a good thing if people intimate with internals can visit us once in a while and share things - no, we do not ask P1 to post a code that does demosaicking or NR for example - but some things really can be answered w/o harm - like for example the format of P1 "curves" .fcrv files so that people can create their own with their tools, w/o resorting to hex editors to dissect them first...
-
Wrong again Bart :'( . It would aid the OP, answer his question. You do realize (crap, I keep assuming you do), OK hopefully you understand that IF the colorimetric processing color space of a raw converter who's gamut can be now defined is smaller than say ProPhoto RGB, it's rather pointless to select that as the encoding color working space?
It's not entirely pointless if further processing (e.g. in Photoshop) is going to be used that can increase saturation even further. It prevents yet another profile conversion with introduction of rounding errors if not performed in floating-point math. Besides, a large portion of Prophoto RGB consists of coordinates for imaginary colors, how useful it that? It only helps a bit if one shrinks saturation again, because that might bring some imaginary colors back into useful gamut.
Problem is, in terms of C1, WE DON'T KNOW and some here are unable to provide this simple information, instead reference nonsense: Capture One works in a very large color space, similar to that captured by camera sensors.
Friendly advice, try not getting your knickers in a twist, and please dismount the high horse. You do not look good there. Asking things in a more reasonable voice might even help others who are reading this thread, this is not a pissing contest, unless you want it to be. Who knows, you might even get some answers, even if you have no intention whatsoever to switch to C1 or use anything else than LR. I'm cool with that.
Cheers,
Bart
-
thank you so much ! there are no bad feelings towards you or P1, but it is really a good thing if people intimate with internals can visit us once in a while and share things - no, we do not ask P1 to post a code that does demosaicking or NR for example - but some things really can be answered w/o harm - like for example the format of P1 "curves" .fcrv files so that people can create their own with their tools, w/o resorting to hex editors to dissect them first...
Agreed again.
David, no hard feelings, I know you're trying to help answer pertinent questions. When you first started with: I would suggest to Andrew (and yourself) if it is something you need to know, then simply ask Tech support but then moved to: I will endeavour to find the answer out for you, before any more blood is spilt, we made significant progress.
I do have to say, it might be either useful or hilarious to ask Tech Support the question, if time permits, maybe I will.
-
It's not entirely pointless if further processing (e.g. in Photoshop) is going to be used that can increase saturation even further.
No Bart, it really is pointless. Like the URL you posted which I guess doesn't count because it speaks of an older, discontinued product?
Besides, a large portion of Prophoto RGB consists of coordinates for imaginary colors, how useful it that? It only helps a bit if one shrinks saturation again, because that might bring some imaginary colors back into useful gamut.
Imaginary colors (device values) is the priced to be paid for a simple RGB working space where one can, if the converter supports it, provide real, actual colors captured that can be output. We've been over this far too often to have to describe this choice again. Truth be told, we don't know the gamut of the processing color space from C1 yet, the URL you provided was just an embarrassment for all concerned and some users do want and need to know such technicalities to select an appropriate RGB working space.
Friendly advice, try not getting your knickers in a twist, and please dismount the high horse.
Friendly advise, when someone uses sound color science to dismiss nonsense you posted, it doesn't mean that person has their knickers in a twist. It appears the people providing the nonsense are the ones in a twist. It appears that reality continues to ruin your life, and to believe those providing reality are the people with knickers in a twist or spitting blood. The only dog I have in this fight is pointing out Colorimetric BS of which you've provided thanks to the P1 URL.
-
No Bart, it really is pointless. Like the URL you posted which I guess doesn't count because it speaks of an older, discontinued product? Imaginary colors (device values) is the priced to be paid for a simple RGB working space where one can, if the converter supports it, provide real, actual colors captured that can be output. We've been over this far too often to have to describe this choice again. Truth be told, we don't know the gamut of the processing color space from C1 yet, the URL you provided was just an embarrassment for all concerned and some users do want and need to know such technicalities to select an appropriate RGB working space. Friendly advise, when someone uses sound color science to dismiss nonsense you posted, it doesn't mean that person has their knickers in a twist. It appears the people providing the nonsense are the ones in a twist. It appears that reality continues to ruin your life, and to believe those providing reality are the people with knickers in a twist or spitting blood. The only dog I have in this fight is pointing out Colorimetric BS of which you've provided thanks to the P1 URL.
I tend to not engage in a battle of wits with an unarmed person, so I'll leave the BS to you.
Cheers,
Bart
-
I tend to not engage in a battle of wits with an unarmed person, so I'll leave the BS to you.
Unarmed perhaps, technically correct, absolutely. You've so failed to understand this topic, you should exit ASAP to avoid further embarrassment .
Oh and Bart, I've got nothing at all against PhaseOne and there's always a possibility I'll go back to their products from Adobe. FWIW, I'll bet you dollars to donuts I was using their products long before you! I see one of my first reviews of their products appeared over 16 years ago in PEI magazine:
http://digitaldog.net/files/Filmvsdigital.pdf
-
What a fruitless debate …
My take on the way C1's color does work… just assumptions based on my work with C1 for some years…
First - as in any other decent RAW converter - there are "hidden" profiles working "under the hood" correcting the nonlinearity of the different camera sensors and model the cameras colors to match a certain target.
In C1 this target seems to be what is represented in the so called "No Color Correction" profile (it is the very same profile that is also used for and called "DNG File Neutral.ICC", "JPEG.ICC", "TIF.ICC" and "Color View.ICC).
This is, if you want so, the smallest nominator (after said individual camera profiling "under the hood") in C1.
This profile has a pretty small gamut and a Gamma of 1.8.
What is called "camera profile" in C1 are actually "camera specific working spaces" - these are table based profiles with a neutral grey axis (Gamma 1.8 ). These camera specific profiles (in conjunction with the so called "film curves") "model" color (based on the starting point of what the "No Color Correction" profile represents … so that you don't see pale, boring colors but "vivid" colors that make sense (…) - therefore they are much larger than the "no Color Correction" profile...
Since these camera specific working spaces are designed as table based input profiles they get assigned to the image file - the file is not converted into these profiles. This is why - on this stage of the processing chain - there's no way that color clipping can occur.
More on clipping: the "advanced Color Editor" PHYSICALLY alters the input profile. So if you increase saturation in the Advanced Color Editor, you expand the input profile! This is very important … as this avoids clipping BY DESIGN. You could produce clipping… if you choose an output color space that is not large enough to match the input profile. But one of the strengths of C1 is that you can choose to process with the input ("camera") profile embedded … so that no further color conversion takes place (which is also my preferred workflow - I also edit my photos in Photoshop in these "camera working spaces").
My assumption about C1's "internal color space" …: the Advanced Color Editor can add 200% global saturation. So if you take the "No Color Correction" Profile and increase saturation by 200% you will end up with a profile that is indeed much larger than ProPhoto-RGB. Since this is a Color Space C1 can produce with max. Saturation in the Color Editor I think it's not completely far-fetched to assume that this represents C1's internal color space ... or something close to it (see attachment - coloured=C1, white=ProPhoto-RGB).
In reply to the OP: set ProPhoto-RGB as "output" color space in the "process recepies" tab and don't worry about clipping …
-
The point is that if you think of camera primaries you can come to many incorrect conclusions because cameras capture spectrally. On the other hand, displays create colors using primaries. Primaries are defined colorimetrically so any color space defined using primaries is colorimetric. Native (raw) camera color spaces are almost never colorimetric, and therefore cannot be defined using primaries. Therefore, the measured pixel values don't even produce a gamut until they're mapped into a particular RGB space. Before then, *all* colors are (by definition) possible.
I'm not sure what you mean by the statement that camera sensors capture spectrally. The input is a spectrum and the sensor has a spectral sensitivity. Doug Kerr has an excellent post (http://dougkerr.net/Pumpkin/articles/Sensor_Colorimetry.pdf) on sensor colorimetry to which the interested reader can refer. The sensor does have spectral sensitivities and a typical response in shown in Fig 5 of Doug's post and is shown below. The sensor integrates the response at various wavelengths over the range of each of the RGB ranges and reports a single output value for each sensel. It does not record a spectrum.
If the camera filters followed the Luther-Ives criteria, one could produce a perfect metameric match to the spectral colors, but since no existing sensor conforms to these criteria, there will be metameric error which can be minimized when outputting to a colorimetric space. When outputting to the colorimetric space, any number of primaries can be chosen by making use of Grassman's Law (https://en.wikipedia.org/wiki/Grassmann%27s_law_(optics)). These primaries are those of the colorimetric space, not the sensor.
Bill
-
I'm not sure what you mean by the statement that camera sensors capture spectrally.
I was referring to cameras which don’t have primaries, they have spectral sensitivities. The image was recorded through a set of camera spectral sensitivities which defines the intrinsic colorimetric characteristics of the image. An simplistic way to think of this (while not purely accurate) is that the image was recorded through a set of "primaries" and these primaries define the color space of the image. Unless the camera spectral sensitivities are colorimetric, they do not define the intrinsic colorimetric characteristics of an image.
The input is a spectrum and the sensor has a spectral sensitivity. Doug Kerr has an excellent post on sensor colorimetry to which the interested reader can refer.
Agreed and I've read Doug's excellent piece.
If the camera filters followed the Luther-Ives criteria, one could produce a perfect metameric match to the spectral colors, but since no existing sensor conforms to these criteria, there will be metameric error which can be minimized when outputting to a colorimetric space.
Agreed, did bring up this issue below.
When outputting to the colorimetric space, any number of primaries can be chosen by making use of Grassman's Law. These primaries are those of the colorimetric space, not the sensor.
Absolutely agree, and that's where the URL that Bart provided is so flawed. Or his idea that some input profile tells us anything about those primaries the product assumes or 'knows' about the capture (spectral sensitivity) to get to this colorimetric space I've asked about in terms of it's color gamut.
-
Hi,
The ColorChecker RGB values differ between different RGBs.
In LR I can choose to display the Colour in Lab values, which I prefer to RGB values. I don't know if this is possible Capture One. That said, Lab is dependent on illuminant AFAIK.
Another option is to download a synthetic colour checker in a known RGB and open it in Capture One. From that image the RGB values for each reference field can be read out.
I see a problem with Capture One's colour handling being quite arbitrary and not at all documented. Capture One uses ICC but it's deployment is not well specified. Adobe's DNG profiles on the other hand are a quite comprehensive recipe for raw conversion and well documented.
Using good DNG or ICC profiles, colour conversion should be quite good for continuous spectra, even I don't know how C1 handles different illuminants. For complex illuminants a specific conversion profile is needed. For DNG, there are a couple of free tools, like Adobe's DNG Profile editor or the Color Checker Passport software.
Anders Torger, a frequent poster here has developed another tool called DCamProf that is much more flexible than the commercial tools but needs to be used at the command line. Anders has found out and resolved some intricacies in both C1's handling of ICC and Adobe's colour processing engine.
Anders Torger's approach is to develop a colour profile that leads to a correct colour rendition on which a "look" can be applied. A look would apply very subtle colour changes, to tweak colour rendition for it's intended purpose.
Best regards
Erik
Another problem I have (related though not strictly relevant here) is that if I Pick a Colour Sample using the color picker in either the Basic or Advanced Color Editors, the RGB values in the Color Editor dialog are completely different from those above the image at the top of the screen.
This happens no matter how many selections I make from, say, a patch on a Gretag Color Checker.
I'm Windows 10. It would be interesting to know if others have the same problem.
So, which values are correct?
Thanks.
D.
-
The ColorChecker RGB values differ between different RGBs.
In LR I can choose to display the Colour in Lab values, which I prefer to RGB values. I don't know if this is possible Capture One. That said, Lab is dependent on illuminant AFAIK.
If looking to match patch values for Cultural Heritage or art repro applications you can use Capture One Cultural Heritage Edition (http://dtdch.com/capture-one-ch/) which has a broad range of LAB Support and ICC profiles designed solely for color accuracy (no adaptions or embellishments for the purpose of pleasing color). These provide exceptionally high color accuracy out of box with supported light sources, as measured by FADGI and Metamorfoze Standards evaluations (http://dtdch.com/fadgi-image-performance-report/).
-
these are table based profiles with a neutral grey axis (Gamma 1.8 ).
except that you can perfectly use "not table" matrix+trc (gamma or actual 1D lut) profiles in C1 (color editor will not work though, but profile otherwise is totally usable)...
now with full LUT profiles you can simply clamp the demosaicked/with curve applied RGB (not yet in any proper colorimetric colorspace) data to an arbitrary smaller gamut within a proper colorimetric PCS - the question is what happens next, PCS can be cieXYZ or cieLAB - what C1 does next ? from PCS in icc/icm container to which color space ?
-
My assumption about C1's "internal color space" …: the Advanced Color Editor can add 200% global saturation. So if you take the "No Color Correction" Profile and increase saturation by 200% you will end up with a profile that is indeed much larger than ProPhoto-RGB.
then save it (from color editor) to icc/icm profile and repeat the process again... now what ? can't C1 say for example - we are using LAB internally (with necessary round-trips for whatever calculations when needed - like ACR/LR does trips to LAB from PropPhoto coordinates with gamma 1 to calculate some maskes or whatever Eric Chan mentioned once or twice) for example and that's it.
-
More on clipping: the "advanced Color Editor" PHYSICALLY alters the input profile. So if you increase saturation in the Advanced Color Editor, you expand the input profile!
PCS of the ''input" profile stays the same - cieLAB, you change (for the runtime only, unless you save it to icc/icm container to reuse) the lut with color editor and as a result the color transform clamps the data into a wider gamut (still subset of PCS).
-
David,
Regarding the discrepancies between the RGB readings at the top of the screen and those in the Color Tool dialog box, here is the reply I got from Support:
"Hello,
This is becuase the value you see at the top is the color after it has been converted to your output space, whereas the value in Colur editor is based only in the input profile you are editing."
1. There seems to be implicit in this reply an acknowledgement that the readings are different. Wouldn't you agree? (Though I know this is not your experience)
2. All I simply want to do is to be able to soft-proof/edit in ProPhoto RGB and then save my TIFFs in this same space. I'd like every RGB reading to be in PP RGB. So, what settings/preferences must I apply to the software to have this across the board? I've asked them the same question.
Thanks.
D.
Ps. Looks like I created something of a monster in starting this thread! 8)
-
If looking to match patch values for Cultural Heritage or art repro applications you can use Capture One Cultural Heritage Edition (http://dtdch.com/capture-one-ch/) which has a broad range of LAB Support and ICC profiles designed solely for color accuracy (no adaptions or embellishments for the purpose of pleasing color). These provide exceptionally high color accuracy out of box with supported light sources, as measured by FADGI and Metamorfoze Standards evaluations (http://dtdch.com/fadgi-image-performance-report/).
Thanks for the reply.
C1 CH is priced for institutions, not individuals, but it's a nice thought! 8)
D.
-
David,
Regarding the discrepancies between the RGB readings at the top of the screen and those in the Color Tool dialog box, here is the reply I got from Support:
"Hello,
This is becuase the value you see at the top is the color after it has been converted to your output space, whereas the value in Colur editor is based only in the input profile you are editing."
1. There seems to be implicit in this reply an acknowledgement that the readings are different. Wouldn't you agree? (Though I know this is not your experience)
2. All I simply want to do is to be able to soft-proof/edit in ProPhoto RGB and then save my TIFFs in this same space. I'd like every RGB reading to be in PP RGB. So, what settings/preferences must I apply to the software to have this across the board? I've asked them the same question.
Thanks.
D.
Ps. Looks like I created something of a monster in starting this thread! 8)
Ok - Yeah that does make sense.
1) What do you have set in View>Proof Profile
2) What is the output profile set to in the currently selected process recipe.
3) Have you changed anything in Base Characteristics?
-
Ok - Yeah that does make sense.
1) What do you have set in View>Proof Profile
It's set to ProPhoto
2) What is the output profile set to in the currently selected process recipe.
The ProPhoto box is ticked and highlighted in Process Recipes, and ProPhoto/16bit etc. is stated in the Process Summary tab below.
3) Have you changed anything in Base Characteristics?
No. It's set to Canon 1Ds Mklll
Anytime I'm saving a file, I highlight it in the film strip at the bottom and choose Export/Variants. The export recipe in the dialog that appears is always the same - PP RGB, 16bit, TIFF, 300px, etc...
Thanks.
D.
-
PCS of the ''input" profile stays the same - cieLAB, you change (for the runtime only, unless you save it to icc/icm container to reuse) the lut with color editor and as a result the color transform clamps the data into a wider gamut (still subset of PCS).
no, you don't have to save your edits to a new icc-profile. If you select "embed camera profile" on export the edited icc-profile will be assigned to the file.
Alternatively you can simply choose ProPhoto-RGB as output color space - it will sure encompass every color you will ever produce with the color editor...
-
2. All I simply want to do is to be able to soft-proof/edit in ProPhoto RGB and then save my TIFFs in this same space.
simply set ProPhot-RGB as output color space in the process recipe and be happy.
I'd like every RGB reading to be in PP RGB. So, what settings/preferences must I apply to the software to have this across the board?
if this is REALLY important to you... then you have to switch on Mac. The Windows version displays the values of the output profile on top of the viewer and the values of the input profile in the color editor. On Mac you'll also see the values of the output profile in the color editor.
Workaround for Windows: use the RGB-Read Out Pins (toolbar->color picker). As far as I remember they show the values of the output profile also on Windows... so you will see numerical changes of the output colors in the read out pins while editing colors.
-
if this is REALLY important to you... then you have to switch on Mac. The Windows version displays the values of the output profile on top of the viewer and the values of the input profile in the color editor. On Mac you'll also see the values of the output profile in the color editor.
Workaround for Windows: use the RGB-Read Out Pins (toolbar->color picker). As far as I remember they show the values of the output profile also on Windows... so you will see numerical changes of the output colors in the read out pins while editing colors.
Thanks for the reply.
Am hoping that David or Support can offer a solution. But, you seem to imply that there isn't one.
I'm wondering if Base Characteristics was also set to ProPhoto RGB, (there isn't such an option in the Base Characteristics/ICC Profile menu) instead of the camera model, would that solve the problem?
D.
-
Agreed again.
David, no hard feelings, I know you're trying to help answer pertinent questions. When you first started with: I would suggest to Andrew (and yourself) if it is something you need to know, then simply ask Tech support but then moved to: I will endeavour to find the answer out for you, before any more blood is spilt, we made significant progress.
I do have to say, it might be either useful or hilarious to ask Tech Support the question, if time permits, maybe I will.
Hi Andrew,
Please see below from Esben at Phase One.
Anyways, the thing is that we actually do most of the work in the native camera space. In fact, we can pretty much work in the native camera space all the way to the output file. The rule is that if you can export an image with an embedded profile, then we can work in the camera space all the way. In that case, the “colorimetric interpretation” is done by the program reading our output file (e.g. PhotoShop).
In fact, if you embed the camera profile and export as a tif, we embed tag 301 (TIFFTAG_TRANSFERFUNCTION) which you can use to get back to a colors-pace which is closely related to the data acquired by the sensor. Obviously, the data has been heavily processed, but the processing is controlled by the user. This feature is targeted at scientific applications and 3rd party software to build color profiles.
The gamut you can see in the camera profile does not limit the gamut used for internal processing in Capture One. While typically large, the gamut is mostly limited because it is intended to be converted to other profiles afterwards. Also, LUT-based ICC profiles which use Lab is the PCS, have a gamut limitation. However, the conversion from the camera space (the “colorimetric interpretation” if you will) is based on ICC profiles.
Now, there are a few exceptions where we are forced to convert into a standard color space:
1) Local color edits
2) Conversion to black&white
There are tradeoffs with this approach. While it allows us to extract just about everything provided in the file, it also means that we need a significant effort to get the best possible quality for a camera. However, it does mean we do not limit ourselves to standardize on a specific internal color space.
Kind regards,
Esben H-R Myosotis
Formerly “EsbenHR” on Luminous Landscape
-
1) Local color edits
it means Color Editor in C1 ?
-
no, you don't have to save your edits to a new icc-profile. If you select "embed camera profile" on export the edited icc-profile will be assigned to the file.
ok, you embed it instead of saving externally - the same thing (because you can extract it and save outside of C1 then)
-
2. All I simply want to do is to be able to soft-proof/edit in ProPhoto RGB and then save my TIFFs in this same space. I'd like every RGB reading to be in PP RGB. So, what settings/preferences must I apply to the software to have this across the board? I've asked them the same question.
[view] -> [proof profile] settings in C1 menu control what you see in RGB color readouts, as RGB numbers on top of the preview and RGB numbers in color editor
-
[view] -> [proof profile] settings in C1 menu control what you see in RGB color readouts, as RGB numbers on top of the preview and RGB numbers in color editor
I'm not sure what you mean by, " as RGB numbers on top of the preview and RGB numbers in color editor".
I'm assuming that the RGB numbers at the top of the screen are ProPhoto, because that's what I've got View/Proof Profile set to. Correct?
So, after taking a sample with the Color Tool picker, what RGB values am I seeing in the Color Tool dialog? (They're usually about 10-15 points higher than those at the top of the screen.)
Thanks.
D.
-
it means Color Editor in C1 ?
No Local Adjustments with the color editor.
-
No Local Adjustments with the color editor.
easier to understand when you don't call it "local adjusments". While it is basically the same it is more comprehensible to say: color adjustments on a LAYER
-
I'm not sure what you mean by, " as RGB numbers on top of the preview and RGB numbers in color editor".
I'm assuming that the RGB numbers at the top of the screen are ProPhoto, because that's what I've got View/Proof Profile set to. Correct?
yes
So, after taking a sample with the Color Tool picker, what RGB values am I seeing in the Color Tool dialog? (They're usually about 10-15 points higher than those at the top of the screen.)
this is not what I see... when I use the Pick Color Correction pipette in the same place where I put a color readout and check Color Editor -> Advanced tab... for whatever reason I might see 1-2 points difference in one component, usually Blue... for example I just did this exercise : top RGB + color readout in place are the same = 92/98/139 and Pick Color Correction selected 92/98/137 into Color Editor...
PS: I still 'd like to ask P1 (David) why the small difference between the numbers ?
-
[view] -> [proof profile] settings in C1 menu control what you see in RGB color readouts, as RGB numbers on top of the preview and RGB numbers in color editor
only on Mac. On Windows the color editor shows the RGB values of the input profile (at least in earlier versions of C1 ... but what I get from "Dinarius'" posts it still seems to apply up to now).
-
No Local Adjustments with the color editor.
so if I adjust colors without editor that does not count - only when layers are involved, correct ? just want to be sure that I am not missing anything... I wonder why the difference though ?
-
only on Mac. On Windows the color editor shows the RGB values of the input profile (at least in earlier versions of C1 ... but what I get from "Dinarius'" posts it still seems to apply up to now).
I am on Windows (PC/Win8.1x64) and I see (right now as we talk) that color editor when color is selected by "pick color correction" pipette follows the proof profile (C1 v9.x)... I select sRGB as proof, do the whole thing (put color readout and then use "pick color correction" pipette in the same spot with 400% magnification) see consistent RGB numbers, then I select PropPhotoRGB and redo the whole thing (put color readout and then use "pick color correction" pipette in the same spot with 400% magnification) - and see again the consistent RGB numbers between color readout and color editor (camera profile stays the same).
-
For the record, yes, I am PC - Windows 10.
There is the 10-15 point RGB difference I mentioned, between top of screen and Color Tool dialog.
And that's taking samples from a Gretag Colour Checker in the image and taking extreme care to not move the mouse cursor! 8)
D.
-
I am on Windows (PC/Win8.1x64) and I see (right now as we talk) that color editor when color is selected by "pick color correction" pipette follows the proof profile (C1 v9.x)... I select sRGB as proof, do the whole thing (put color readout and then use "pick color correction" pipette in the same spot with 400% magnification) see consistent RGB numbers, then I select PropPhotoRGB and redo the whole thing (put color readout and then use "pick color correction" pipette in the same spot with 400% magnification) - and see again the consistent RGB numbers between color readout and color editor (camera profile stays the same).
ok - good to know! so it's the same as on mac...
-
easier to understand when you don't call it "local adjusments". While it is basically the same it is more comprehensible to say: color adjustments on a LAYER
Just used to using the terminology as it is described in Capture One.
-
Ps. Looks like I created something of a monster in starting this thread! 8)
Not at all! Your questions are IMHO perfectly acceptable and relevant. The answers?
-
The answers?
Look up Dog!
-
Look up Dog!
The answers some of us are looking or is on the ceiling? ;D
King Father: Some day, all this will be yours.
Son: What, the Curtains?
-
The answers some of us are looking or is on the ceiling? ;D
King Father: Some day, all this will be yours.
Son: What, the Curtains?
You can try the ceiling if you like, but you might have more luck if you scroll up to Post #63
-
Please see below from Esben at Phase One.
Thank you... is it possible to ask Esben to post a small simple article for posterity and as a point of reference @ http://blog.phaseone.com/category/tech_talk/ ?
That will be a nice thing !
-
You can try the ceiling if you like, but you might have more luck if you scroll up to Post #63
Down actually... What I see is: Anyways, the thing is that we actually do most of the work in the native camera space. In fact, we can pretty much work in the native camera space all the way to the output file.
What IS this so called native camera color space you're assuming?
The gamut you can see in the camera profile does not limit the gamut used for internal processing in Capture One.
Confused. The camera doesn't have a color gamut yet we're told you do most of the work in the native camera space who's 'gamut' isn't limited in the sentence above.
-
However, the conversion from the camera space (the “colorimetric interpretation” if you will) is based on ICC profiles.
I'm asking about this colorimetric interpretation which has a gamut (the camera doesn't). What is the gamut of your colorimetric interpretation? We're told it's based on an ICC Profile so it should rather easy to plot this (ideally in ColorThink), maybe provide a gamut volume. Then we have an apples to apples method of considering the processing gamut and our options for encoding this into a working space.
-
What I see is: What IS this so called native camera color space you're assuming?Confused. The camera doesn't have a color gamut yet we're told you do most of the work in the native camera space.
what David is referring to is similar to what RPP does = demosaick, WB, curves, exposure correction, levels, you name it (including "Luma" curve - this is not with L from Lab as far as I can guess) etc, etc are done with camera RGB numbers (what some people call "camera color space" albeit it is not a proper colorimetric color space like for example Prophoto coordinates with gamma = 1 or something else)... color transform (based on whatever data in icc/icm containter serving as C1 camera profile) is used at the very last stage in the C1 data pipeline - when you display the preview, calculate RGB numbers for color readout, output to .TIFF/.JPG (unless with special provision for camera profiling) or /as we were told today/ possibly start using C1 Color Editor to create C1 layers for "local" color adjustments (this is some kind of deviation).
my $0.02 based on interpretation of Esben's words passed by David (and Esben did 1-2 short postings before directly)
-
What IS this so called native camera color space you're assuming?
it is different (individual) for every single camera...
The gamut you can see in the camera profile does not limit the gamut used for internal processing in Capture One.
Confused. The camera doesn't have a color gamut yet we're told you do most of the work in the native camera space who's 'gamut' isn't limited in the sentence above.
should be easy to understand for a wise guy like you: the (individual) camera profile is not as large as C1's internal (working) space. It's basically the same as in Adobe software: there's a large working space (ProPhoto primaries) but so called camera profiles limit the actual colors to create a decent, "neutral" look.
I'm asking about this colorimetric interpretation which has a gamut (the camera doesn't). What is the gamut of your colorimetric interpretation?
again, different for every single camera...
We're told it's based on an ICC Profile so it should rather easy to plot this (ideally in ColorThink), maybe provide a gamut volume. Then we have an apples to apples method of considering the processing gamut and our options for encoding this into a working space.
this is exactly what you can do ... all "camera profiles" are available as icc profiles and you can load it in the gamut viewer of your choice.
Can you, vice versa, show me the "gamut" of any Adobe "camera profile" (so "input profile")?
-
the (individual) camera profile is not as large as C1's internal (working) space.
based on Esben's words C1 does not work in any proper colorimetric color space till the last stage of the pipeline (output to...) - it simply works/manipulates with camera's RGB numbers, color transform (that's where camera profiles are used) is not applied yet at all when you for example do exposure correction or use RGB curve in C1 UI... as to the order of most basic operations : demosaick, WB, raw converter curves (transfer function and .fcrv curves like film, linear, linear scientific, etc) that is unknown vs exposure correction for example... one can assume they happen first, then UI operations like exposure correction, contrast, saturation (again on camera's RGB numbers)
-
it is different (individual) for every single camera...
Absolutely! Hence my question about the colorimetric processing color space. Are you suggesting it is different for each camera?
should be easy to understand for a wise guy like you: the (individual) camera profile is not as large as C1's internal (working) space.
We (you) know that how? Again, what IS the C1 internal working space's gamut?
It's basically the same as in Adobe software: there's a large working space (ProPhoto primaries) but so called camera profiles limit the actual colors to create a decent, "neutral" look.
So it is or isn't (basically?) the same as in Adobe software which is clearly defined: ProPhoto RGB primaries? We know this how?
Can you, vice versa, show me the "gamut" of any Adobe "camera profile" (so "input profile")?
I can show you the gamut of images processed though the Adobe engine. I can tell you want the designers of the product tell us what the colorimetric gamut of the processing engine is. I could shoot an image as a JPEG with the camera set to Adobe RGB (1998) and plot that too. But I don't know how any of that is pertinent in answering a simple question about the gamut of the processing color space from C1.
-
Absolutely! Hence my question about the colorimetric processing color space. Are you suggesting it is different for each camera?
C1 does not use any colorimetric processing color space at the stages you mean (or I assume you mean)... again based on Esben's words interpretation
We (you) know that how? Again, what IS the C1 internal working space's gamut?
I guess it was established that it is wrong to use the word gamut for an input device like digital camera (till the color transform performed and it is not yet - see above), no ? lengthy topics were created about camera's "color spaces"
-
Hi,
The descriptions given sound like a mess.
Common sense say that camera RGBs should be converted into a well specified and sufficiently large color space early on the process.
Best regards
Erik
it is different (individual) for every single camera...
Confused. The camera doesn't have a color gamut yet we're told you do most of the work in the native camera space who's 'gamut' isn't limited in the sentence above.should be easy to understand for a wise guy like you: the (individual) camera profile is not as large as C1's internal (working) space. It's basically the same as in Adobe software: there's a large working space (ProPhoto primaries) but so called camera profiles limit the actual colors to create a decent, "neutral" look.
again, different for every single camera...
this is exactly what you can do ... all "camera profiles" are available as icc profiles and you can load it in the gamut viewer of your choice.
Can you, vice versa, show me the "gamut" of any Adobe "camera profile" (so "input profile")?
-
Common sense say that camera RGBs should be converted into a well specified and sufficiently large color space early on the process.
no, it does not... for example RPP does as much as possible before any color transform and moreover as much of what is done before color transform is done before demosaicking... however Adobe does differently (and may be one of the reasons was {historically} / is simply the need to show adjustments in close to real time on average Joe's computer) - post initial raw data read : demosaick first, apply WB+initial color transform (the part of dcp profiles that goes before the UI driven exposure correction), then what user does in UI is processed (exceptions naturally are in what you see in "Camera Calibration" tab in ACR and WB - as WB is mixed with color transform application in Adobe's realm /that btw is why ACR/LR can do identical conversion with original raws and linear DNGs obtained from them without any differences in output if linear /non lossy/ DNG was made first with the same release of ACR/LR/Adobe DNG converter/)... that allows for smoother UI reaction.
-
I guess it was established that it is wrong to use the word gamut for an input device like digital camera (till the color transform performed and it is not yet - see above), no ?
Agreed.
-
based on Esben's words C1 does not work in any proper colorimetric color space till the last stage of the pipeline (output to...) - it simply works/manipulates with camera's RGB numbers, color transform (that's where camera profiles are used)
that's not correct. There is always an input profile working in C1. You can choose to choose whatever input profile you prefer ... but you can not set no input profile at all. Therefore - as long as you embed the input profile on output - you are always working within the gamut of the input profile.
-
Absolutely! Hence my question about the colorimetric processing color space. Are you suggesting it is different for each camera?
yes, it is.
We (you) know that how? Again, what IS the C1 internal working space's gamut?
I don't know. Since C1 can produce colors that exceed ProPhoto-RGB it must be larger than ProPhoto. But personally I don't see any benefit of knowing the internal color space of C1 anyway...
I can show you the gamut of images processed though the Adobe engine.
:-)
I can tell you want the designers of the product tell us what the colorimetric gamut of the processing engine is.
what for?
-
that's not correct. There is always an input profile working in C1.
the question is totally different - when (at which stage of the C1 pipeline) the color transform guided by the data in that profile is applied... not if, but when... so, for example, when you use a "saturation" slider in C1 "exposure" tool, you work with camera's RGB numbers ___before__ that color transform... RGB data altered by C1 code as a result of your operations with that slider are not yet color coordinates in any proper colorimetric color space... they will be later down the pipeline (for example when you see the image on your monitor or color readout sticker will display you RGB in some proof color space)
-
Since C1 can produce colors that exceed ProPhoto-RGB it must be larger than ProPhoto.
camera native RGB is not larger or smaller than any proper color space - they are simply different animals, so depending on how you do a color transform you can end up within or outside at the end of the pipeline... consider this - if C1 camera RGB numbers are {r1, g1, b1} before saturation slider operation and {r2, g2, b2} after how do you know at that moment in C1 code - before the color transform /a pair : first input profile - which is as Esben fro P1 says applied at the end of the pipeline and then, for example at the next stage, proof, output profiles/ where you are going to end up ?
-
the question is totally different - when (at which stage of the C1 pipeline) the color transform guided by the data in that profile is applied... not if, but when... so, for example, when you use a "saturation" slider in C1 "exposure" tool, you work with camera's RGB numbers ___before__ that color transform... RGB data altered by C1 code as a result of your operations with that slider are not yet color coordinates in any proper colorimetric color space... they will be later down the pipeline (for example when you see the image on your monitor or color readout sticker will display you RGB in some proof color space)
ah, okay - I did get you wrong. Makes sense - thanks!
-
Updated a bit…
Hi,
This is a bit of a nonsense. ProPhoto RGB encompasses all visible colours ProPhoto RGB encompasses nearly all visible colours and more importantly all colours in the Pointons gamut. So, a gamut may be larger but that just means it is less efficient.
Not saying that ProPhoto RGB is the most perfect or most efficient RGB, but it has been defined by a company called Eastman Kodak who used to know what they used to be doing, once upon the time.
Best regards
Erik
yes, it is.
I don't know. Since C1 can produce colors that exceed ProPhoto-RGB it must be larger than ProPhoto. But personally I don't see any benefit of knowing the internal color space of C1 anyway...
:-)
what for?
-
yes, it is.
I don't know. Since C1 can produce colors that exceed ProPhoto-RGB it must be larger than ProPhoto. But personally I don't see any benefit of knowing the internal color space of C1 anyway...
:-)
what for?
I explained to David the reason it's useful to know the color gamut of the processing below (or above) :D
Here's what I think we know from PhaseOne thus far (since it came from them):
Capture One works in a very large color space, similar to that captured by camera sensors.
I believe many of us here agree cameras and their sensors do not have a color gamut.
The gamut you can see in the camera profile does not limit the gamut used for internal processing in Capture One.
AR: That appears to dismiss?: The Raw camera RGB is profiled, and that can be expressed as a gamut by plotting the hull and calculating the size.
However, the conversion from the camera space (the “colorimetric interpretation” if you will) is based on ICC profiles.
AR: again, if this is a colorimetric interpretation, shouldn’t it be possible to examine the gamut and it's size?
While it allows us to extract just about everything provided in the file, it also means that we need a significant effort to get the best possible quality for a camera. However, it does mean we do not limit ourselves to standardize on a specific internal color space.
AR: so the colorimetric interpretation varies from camera to camera? You are saying it does, I have no reason to doubt that (I'm here to learn). That would appear to indicate some profile, supplied or under the hood for each camera could be examined for it's gamut size. I'm not referring to a profile built from shooting a target of course, I'm referring to what I believe is a profile or some description we can interrupt a gamut size from: the conversion from the camera space (the “colorimetric interpretation” if you will) is based on ICC profiles.
I think we agree that this gamut is indeed a “colorimetric interpretation”
Seem fair?
-
camera native RGB is not larger or smaller than any proper color space - they are simply different animals, so depending on how you do a color transform you can end up within or outside at the end of the pipeline...
while this is true I am talking about processed images ... and these of course contain the result of color transforms etc.
-
ah, okay - I did get you wrong. Makes sense - thanks!
that's why presence and some comments from P1 technical guys are most welcome - a lot can be clarified w/o disclosing any actual secrets and competition (like Adobe developers) in any case is very much capable know more than that anyways...
-
while this is true I am talking about processed images
sure,
I am mostly about what happens before that - that's most intriguing part !
-
AR: so the colorimetric interpretation varies from camera to camera? You are saying it does, I have no reason to doubt that (I'm here to learn). That would appear to indicate some profile, supplied or under the hood for each camera could be examined for it's gamut size. I'm not referring to a profile built from shooting a target of course, I'm referring to what I believe is a profile or some description we can interrupt a gamut size from: the conversion from the camera space (the “colorimetric interpretation” if you will) is based on ICC profiles.
I think we agree that this gamut is indeed a “colorimetric interpretation”
Just to digress, briefly ... most cameras have a menu option of either sRGB or aRGB.
I shoot in RAW and convert to a jpeg or tiff through a raw converter (when necessary, which is not too often) and have always ignored that input, leaving it on the default sRGB - believing it had no impact (shooting raw) on the capture and is only relevant for in-cam jpeg or tiff conversions.
Is that correct ?
-
Just to digress, briefly ... most cameras have a menu option of either sRGB or aRGB.
I shoot in RAW and convert to a jpeg or tiff through a raw converter (when necessary, which is not too often) and have always ignored that input, leaving it on the default sRGB - believing it had no impact (shooting raw) on the capture and is only relevant for in-cam jpeg or tiff conversions.
Is that correct ?
Yes. All you're telling the camera is how you wish the raw data you will not get, to be encoded (sRGB or Adobe RGB (1998)).
-
Thanks, Andrew.
-
This is a bit of a nonsense. ProPhoto RGB encompasses all visible colours. So, a gamut may be larger but that just means it is less efficient.
No nonsense. Read correctly: you can produce colors that exceed ProPhoto. To do this you can increase global saturation in the Advanced Color Editor. But by default - so without any color edits - the input profiles are typically somwhere between Adobe-RGB and ProPhoto-RGB ... attached the default input profile of your camera compared to ProPhoto-RGB...
-
No nonsense. Read correctly: you can produce colors that exceed ProPhoto.
Colors that we can't see?
-
That would appear to indicate some profile, supplied or under the hood for each camera could be examined for it's gamut size. I'm not referring to a profile built from shooting a target of course, I'm referring to what I believe is a profile or some description we can interrupt a gamut size from: the conversion from the camera space (the “colorimetric interpretation” if you will) is based on ICC profiles.
I think we agree that this gamut is indeed a “colorimetric interpretation”
yes, we agree. And said profiles are all supplied so that you can ... for instance ... examine them in a gamut viewer software.
-
Colors that we can't see?
yes... just like the full blue of ProPhoto-RGB ... that shows L=0, so no luminosity at all and therefore is pure black... :-)
AGAIN: you can - artificially/technically - boost the colors (the input profiles to be precise) in a way so that they exceed ProPhoto. But of course you would never do this with a real world image.
-
yes... just like the full blue of ProPhoto-RGB ... that shows L=0, so no luminosity at all and therefore is pure black... :-)
Not on my printed output it doesn't. And those are colors I can see.
AGAIN: you can - artificially/technically - boost the colors (the input profiles to be precise) in a way so that they exceed ProPhoto. But of course you would never do this with a real world image.
You can artificially/technically - boost the device values of course.
-
Colors that we can't see?
Yes, they're called imaginary colors (https://en.wikipedia.org/wiki/Impossible_color#Imaginary_colors), but you know that. According to Bruce Lindbloom, ProPhoto RGB has a coding efficiency of 87.3% which means that it allows to encode 12.7% of imaginary colors on top of the 'real colors' (humanly visible, on average).
Those imaginary colors are mathematically usable and may still be relevant when one e.g. locally shrinks the saturation so that these colors become 'real colors'.
Cheers,
Bart
-
Yes, they're called imaginary colors (https://en.wikipedia.org/wiki/Impossible_color#Imaginary_colors), but you know that.
Indeed. FWIW, there are some (I'm not lumping myself into either camp) that suggest Imaginary Colors isn't kosher. I'll leave this well know and respected color scientist's name undefined by he stated:
Coordinate in a "colorspace" outside the spectrum locus is not a
color. We often refer to these as "imaginary colors" but this is by
and large also erroneous (you can't map an imaginary color from one
colorspace to another as the math (and experimental data) for each
colorspace breaks down outside the spectrum locus.
Hence, I prefer to use Device Value ala Steve Upton and the discussions here on LuLa last year.
-
Not on my printed output it doesn't. And those are colors I can see.
I wonder what your printed blue has to do with the working space of your RAW-software. But while we're at it: the table based input icc profiles in C1 are all very much aimed at real world devices. ProPhoto-RGB on the other hand is just an imaginary "monitor" ... and due to its matrix design it is much larger than needed. Doesn't matter when you know how to work with such an unreal working space, sure. But it's somewhat strange that it is you who is talking about colors we can see...
-
I wonder what your printed blue has to do with the working space of your RAW-software.
Depending on what blue you're referring to, possibility nothing.
But while we're at it: the table based input icc profiles in C1 are all very much aimed at real world devices.
Whatever that means... examine the very first post here by the OP who specifically wants to encode into ProPhoto RGB.
ProPhoto-RGB on the other hand is just an imaginary "monitor" ... and due to its matrix design it is much larger than needed.
We've been over this already: it's the price one pays for an RGB working space who's gamut is large enough to also encode 'real world' colors we can capture and output.
Doesn't matter when you know how to work with such an unreal working space, sure. But it's somewhat strange that it is you who is talking about colors we can see...
I'm simply pointing out the language could be better defined. Had you said Imagery Colors as Bart did, no issue. Better, had you said Device Values. The language here has been a bit iffy, starting with: Capture One works in a very large color space, similar to that captured by camera sensors.
-
examine the very first post here by the OP who specifically wants to encode into ProPhoto RGB.
which is very easy to accomplish ... simply set ProPhoto as "output" space. Done...
I'm simply pointing out the language could be better defined. Had you said Imagery Colors as Bart did, no issue. Better, had you said Device Values.
agreed. Although I was only talking about "colors" a profile may contain. Visible or imaginary... the term "color" is not completely misleading (at least if you take language barriers into account :-) ...)
-
which is very easy to accomplish ... simply set ProPhoto as "output" space. Done...
Going full circle, getting back to the question that started us down this path, should he?
-
Going full circle, getting back to the question that started us down this path, should he?
the problem with the initial question was the question itself: "how can I set ProPhot as input profile?". While there is indeed a workaround to do so it doesn't make sense at all. It's like asking: "how can I use the icc Input profile of my P45 in Lightroom?"
-
the problem with the initial question was the question itself: "how can I set ProPhot as input profile?". While there is indeed a workaround to do so it doesn't make sense at all. It's like asking: "how can I use the icc Input profile of my P45 in Lightroom?"
Perhaps, I fully admit my ignorance in how this product works. But I did read the OP asking: Can I import ProPhoto RGB and make it an option to edit in?
-
Perhaps, I fully admit my ignorance in how this product works. But I did read the OP asking: Can I import ProPhoto RGB and make it an option to edit in?
again wrong question. To edit in ProPhoto you don't have to import the profile into C1. As long as it is installed on the system so that you can set it as output space in C1 you are effectively editing in ProPhoto-RGB! You are always editing in the color space selected as output ... you can even edit in a CMYK color space. And I tell you what: C1 will display the corresponding CMYK values for color read outs! Lightroom?
-
AGAIN: you can - artificially/technically - boost the colors (the input profiles to be precise) in a way so that they exceed ProPhoto. But of course you would never do this with a real world image.
to illustrate this a bit further ...
Attached a Granger Rainbow image loaded in Color Think - a.) processed with sRGB assigned and b.) processed with saturation boosted by 200% in C1's Advanced Color Editor. And c.) - for comparision - also a ProPhoto-RGB profile (opaque white).
Whatever this tells about C1's real "internal working space" ... it is pretty clear that C1 can produce images containing a gamut that exceeds ProPhoto.
Whether this is useful or not is another question ... but whatever you want to do in C1 is certainly not limited by a certain "internal color space".
-
...
for as long as we do not use input and output profiles that clamp the data during color transforms (and both profiles are used sequentially at the end of the pipeline in C1) we can... it seems nothing internally in C1 by itself does such clamping before a final stage where a color transform guided by some input profile (camera profile) is applied, then followed by a color transform guided by some output profile... with a fine print also that we can also actually alter the color transfer guided by an input profile through C1 color editor for as long as that input profile conforms to P1 rules - LAB PCS and A2B0 table...
-
again wrong question. To edit in ProPhoto you don't have to import the profile into C1. As long as it is installed on the system so that you can set it as output space in C1 you are effectively editing in ProPhoto-RGB!
I can't speak for the OP, that bit of course makes sense to me. I don't know that's what he's referring to. As I read it, he's saying he's bringing in a rendered image (?) in ProPhoto RGB (Can I import ProPhoto RGB and make it an option to edit in?) and then, use that working space for editing. But that's just a guess. I then asked, does the processing color space match somewhat or exceed ProPhoto RGB as it would be pointless to ask or need it if the color space were significancy smaller. That got us into this long but useful discussion. If I'm to believe what I've read (much of it from those outside PhaseOne), the answer is yes, whatever processing color space gamut is going on under the hood, it isn't a 'waste' (as it would be in say Aperture) to be wanting to edit existing ProPhoto RGB data.
-
I can't speak for the OP, that bit of course makes sense to me. I don't know that's what he's referring to. As I read it, he's saying he's bringing in a rendered image (?) in ProPhoto RGB (Can I import ProPhoto RGB and make it an option to edit in?) and then, use that working space for editing.
My reading of the initial question was different since he started with asking how to set the "Base Characteristics" (which is where you can [but don't have to!] choose the input profile). So to me it was clear he was asking how to set ProPhoto-RGB as input profile... but of course I might be wrong ...
However, you bring up a very weak point of C1. Editing of TIFs and JPEGs. When you load ("import") e.g. a TIF file into C1 the embedded profile of the image gets ignored. Instead C1's internal generic "neutral" color space gets assigned. While visually identical in so far the image does not contain colors that exceed C1's "neutral" color space all colors outside of C1's neutral color space get desaturated. This is - at best - a half backed solution and it's clearly better NOT to use C1 for editing TIFs/JPEGs!
-
Hi,
I have rechecked and it is clear that ProPhoto RGB does indeed not cover all visible colours, but it nicely encloses a colour space called Pointer's Gamut. "The Pointer’s gamut is (an approximation of) the gamut of real surface colors as can be seen by the human eye, based on the research by Michael R. Pointer (1980). What this means is that every color that can be reflected by the surface of an object of any material is inside the Pointer’s gamut."
http://www.tftcentral.co.uk/articles/pointers_gamut.htm
To make a fine point, what is the benefit of the advanced colour editor pushing colours outside the colour gamut of any monitor or any printing device. Those are colours that cannot be represented by any output device? Also the colours cannot be observed as the display will clip them.
I have actually observed this in one of my experiments with C1, it pushes deep blues that are perfectly inside Adobe RGB wide outside Adobe RGB, causing a large colour reproduction error although it is not visible on a screen with Adobe RGB as it is clipped to Adobe RGB in visualisation.
This example was taken from a P45+ image of an IT-8 test chart with all samples inside Adobe RGB and processed with Capture One v7 without any colour editing.
Best regards
Erik
No nonsense. Read correctly: you can produce colors that exceed ProPhoto. To do this you can increase global saturation in the Advanced Color Editor. But by default - so without any color edits - the input profiles are typically somwhere between Adobe-RGB and ProPhoto-RGB ... attached the default input profile of your camera compared to ProPhoto-RGB...
-
To make a fine point, what is the benefit of the advanced colour editor pushing colours outside the colour gamut of any monitor or any printing device. Those are colours that cannot be represented by any output device? Also the colours cannot be observed as the display will clip them.
Oh my god. Erik - I could boost global saturation of a real world image by 200% - but why should I do so?
It seems, the "Advanced Color Editor" is aimed at advanced users...
It is certainly not desinged to produce imaginary colors (altough it could/can - just as Adobe software with the huge color space ProPhoto).
Think of a certain very, very desaturated color that you want to push... maybe even by 200% ... got it?
The capabilities of a certain tool do not dictate how to use this very tool ... it's always the end-user that has to make the most out of it.
Again: the gamut of C1's input profiles is typically somewhere between Adobe-RGB and ProPhoto-RGB ... and normally there's no need to push the Advanced Color Editor to its limits. Normally you do very subtle edits (at least I do).
-
Could the internal color space be so large as to fully contain all supported input and output color spaces? Realistically, a color space only a little larger than ProPhoto should do this - very little of value is outside ProPhoto, although Joseph Holmes' DCam 5 is even larger, and is supposed to fully encompass human vision. No monitor I know of can display any color outside of ProPhoto, and no printer can print one... Some monitors CAN display a few colors outside of Adobe RGB, and 11-12 ink printers can print substantially outside of Adobe RGB, but neither can hit the edges of ProPhoto. Can some weird, reflective color we see on occasion (a brand-new traffic cone?) get outside of ProPhoto? I don't know. Can a flower display colors outside of ProPhoto to a bee? Almost for sure - some flowers reflect UV, and bees can see it. That could even be outside of DCam 5, but since we can't see it or print it, why worry about it unless you are hanging a show in an apiary...
If C1 worked internally in something like DCam 5, why would it clip when converting to (or from) anything? As long as it's always 16 bits/channel, quantization errors are unlikely (and might it be 32 bits/channel, eliminating them entirely)? That would more or less allow it to claim to be space-neutral internally - it imports images in in the camera space, displays them in monitor space, exports in a selected export space and prints in printer space, all of which fit within the huge internal space. Lightroom almost does this with MelissaRGB (it's very hard, but not impossible, to find a color outside of that space). What if C1's space were even larger? Could that make it truly neutral internally (although highly dependent on rendering intent as it converted)?
-
Could the internal color space be so large as to fully contain all supported input and output color spaces? Realistically, a color space only a little larger than ProPhoto should do this - very little of value is outside ProPhoto, although Joseph Holmes' DCam 5 is even larger, and is supposed to fully encompass human vision. No monitor I know of can display any color outside of ProPhoto, and no printer can print one... Some monitors CAN display a few colors outside of Adobe RGB, and 11-12 ink printers can print substantially outside of Adobe RGB, but neither can hit the edges of ProPhoto. Can some weird, reflective color we see on occasion (a brand-new traffic cone?) get outside of ProPhoto? I don't know. Can a flower display colors outside of ProPhoto to a bee? Almost for sure - some flowers reflect UV, and bees can see it. That could even be outside of DCam 5, but since we can't see it or print it, why worry about it unless you are hanging a show in an apiary...
If C1 worked internally in something like DCam 5, why would it clip when converting to (or from) anything? As long as it's always 16 bits/channel, quantization errors are unlikely (and might it be 32 bits/channel, eliminating them entirely)? That would more or less allow it to claim to be space-neutral internally - it imports images in in the camera space, displays them in monitor space, exports in a selected export space and prints in printer space, all of which fit within the huge internal space. Lightroom almost does this with MelissaRGB (it's very hard, but not impossible, to find a color outside of that space). What if C1's space were even larger? Could that make it truly neutral internally (although highly dependent on rendering intent as it converted)?
did you actually read the topic, specifically the quote from P1 developer ?
-
At least as I'm reading it, it's entirely consistent - they keep the camera space, but have it WITHIN something huge, so that "the gamut you can see in the camera space does not limit the gamut used for internal processing". If this weren't true, you could never do highly saturated HDR (no camera can record some of those colors). Since C1 can convert to ProPhoto for output, and, from the developer's post, it sounds like it can do it without clamping, the internal processing gamut (maybe it's a gamut, not a true space) has to contain ProPhoto...
-
Hi,
I wouldn't say god is involved in this…
In the experiments I made I found that Capture One pushes deep blues well inside Adobe RGB into well outside Adobe RGB blues. Now, most computer screens used sRGB which are based on REC 709 RGB. High end wide gamut devices are close to Adobe RGB. But neither colour space includes all colours occuring in nature, which is often referred to as Pointer's RGB.
So if colours are pushed outside Adobe RGB, colour differences will not be visible on a computer monitor.
Check the enclosed figures at the bottom of this page:
The first figure shows how colours are shifted when an IT-8 produced by chromogenic printing is reproduced by a P45+ back and interpreted in Capture One. As you can see the colours have a significant shift.
The second figure shows that the colours are pushed well outside Adobe RGB.
The third figure shows that although colour error is pretty large, about Delta E = 17, the difference is barely noticeable on screen, for the simple reason that Adobe RGB cannot correctly show the real colour.
The forth figure demonstrates that a much smaller colour error is very much visible if both the reference and sampled colour lie within the gamut visible within Adobe RGB.
Now, there is a new colour space defined for 4K called Rec 2020. It is possible that the colours produced by Capture One default processing would be visible in Rec 2020. I don't know, because I have no Rec 2020 screen.
---------------------------------
Another issue which may be related or not was found when I made a test looking at reproduction of greens. To a great part because I had some communication with Tim Parkin, publisher of OnLandscape. Tim indicated that he and his friend Joe Cornish had issues with colour reproduction on the P45+, with greens being pushed towards yellows. I had no communication with Joe Cornish directly but Tim said that they both found that P45+ images needed massive corrections for realistic colour. Tim and Joe also found that the later generation DALSA based backs delivered better colour.
What I wanted to find out how much that issue was related to profiles and how much related to sensor. One of the experiments I set up was a blush purple flower with green blades. I have chosen this because I knew these colours were sensitive to reproduction errors. Illumination was with Elinchrome studio flash.
Capture One gave these colours:
(http://echophoto.dnsalias.net/ekr/Articles/OLS_OnColor/SimpleCase/20150107-CF046070_C1_vsmall.jpg)
While other alternatives essentially yielded these colours:
(http://echophoto.dnsalias.net/ekr/Articles/OLS_OnColor/SimpleCase/20150107-CF046070_AdobeStandard_vsmall.jpg)
Now, I measure the colours on the flower with a spectrometer and found the colours were these:
(http://echophoto.dnsalias.net/ekr/Articles/OLS_OnColor/SimpleCase/Violet_vsmall.jpg)
With the green blades it was a bit different, a lot more variation between samples.
(http://echophoto.dnsalias.net/ekr/Articles/OLS_OnColor/SimpleCase/GreenBlade_spectrum_vsmall.jpg)
So, Capture One essentially reproduced bluish purple flowers as blue. This may or may not correspond to the blue colour shift mentioned above.
I did not really come up with a clear conclusion. One thing I observed the IR content on both green and the purple flowers was very high. So the amount of IR filtering may affect colour reproduction and that may be hard to correct in processing.
Finally, if we look at colour reproduction from a Sony Alpha 99 the colour from C1 is still very blue:
(http://echophoto.dnsalias.net/ekr/Articles/OLS_OnColor/SimpleCase/20150107-_DSC6397_C1_vsmall.jpg)
While Lightroom reproduction is close to original:
(http://echophoto.dnsalias.net/ekr/Articles/OLS_OnColor/SimpleCase/20150107-_DSC6397_AdobeStandard_vsmall.jpg)
Now, I am perfectly aware that the colour can be easily adjusted in the Capture One colour editor, but I feel that a good raw converter should deliver decent colours by defaults.
A more comprehensive posting is here: http://echophoto.dnsalias.net/ekr/Articles/OLS_OnColor/SimpleCase/
A draft of the article I was writing for On Landscape is here: http://echophoto.dnsalias.net/ekr/Articles/OLS_OnColor/OnColor.pdf
The article never got published, I guess that both I and Tim run out of steam and now clear conclusion could be drawn. An interesting observation may be that Tim Parkin is also a painter. Painters work on location and try to reproduce what they see using available paints. I think that kind of viewing produces an awareness of colour that we photographers shooting in landscape and processing in the digital darkroom will not see.
Anders Torger, a frequent poster here, has developed a new tool called DCamprof which can generate both DNG profiles for Lightroom and ICC profiles for Capture One. It is described here: http://www.ludd.ltu.se/~torger/dcamprof.html . Those pages offer a lot of insight in both profiles and interpretation of colour.
Best regards
Erik
Oh my god. Erik - I could boost global saturation of a real world image by 200% - but why should I do so?
It seems, the "Advanced Color Editor" is aimed at advanced users...
It is certainly not desinged to produce imaginary colors (altough it could/can - just as Adobe software with the huge color space ProPhoto).
Think of a certain very, very desaturated color that you want to push... maybe even by 200% ... got it?
The capabilities of a certain tool do not dictate how to use this very tool ... it's always the end-user that has to make the most out of it.
Again: the gamut of C1's input profiles is typically somewhere between Adobe-RGB and ProPhoto-RGB ... and normally there's no need to push the Advanced Color Editor to its limits. Normally you do very subtle edits (at least I do).
-
Yes, they're called imaginary colors (https://en.wikipedia.org/wiki/Impossible_color#Imaginary_colors), but you know that. According to Bruce Lindbloom, ProPhoto RGB has a coding efficiency of 87.3% which means that it allows to encode 12.7% of imaginary colors on top of the 'real colors' (humanly visible, on average).
Those imaginary colors are mathematically usable and may still be relevant when one e.g. locally shrinks the saturation so that these colors become 'real colors'.
Cheers,
Bart
Lindbloom also lists values for Lab gamut efficiency, which is the percentage of the Lab gamut that a given space can encode. The value for ProPhotoRGB is 91.2%, which means that ProPhotoRGB can not encode 8.8% of visible colors. This is partially illustrated by the shown figure, which is taken from the paper (http://www.tftcentral.co.uk/articles/pointers_gamut.htm) regarding Pointer's work that Erik Kaffehr has cited.
That said, ProPhotoRGB does encode all of the real world surface colors (shown by the irregular space shown within the ProPhoto triangle) by a comfortable margin, whereas AdobeRGB does not. This is why many prefer ProPhotoRGB as one's working space.
Bill
-
Hi Bill,
Thanks for your lucid explanation!
It would be interesting to see a gamut plot of the Rec 2020 RGB compared to the ProPhoto RGB, as Rec 2020 is around the corner. But I have not found a Rec 2020 profile to plot.
My understanding is that imaginary primaries are needed to enclose a large part of the visible colours. The full range of colours can not reproduced with three primaries with spectral colours. It would take quite a few spectral colour primaries to enclose the visible colours. The pointer's gamut is enclosed in Prophoto RGB and just somewhat clipped by Rec 2020, which uses three real world primaries.
Best regard
Erik
Lindbloom also lists values for Lab gamut efficiency, which is the percentage of the Lab gamut that a given space can encode. The value for ProPhotoRGB is 91.2%, which means that ProPhotoRGB can not encode 8.8% of visible colors. This is partially illustrated by the shown figure, which is taken from the paper (http://www.tftcentral.co.uk/articles/pointers_gamut.htm) regarding Pointer's work that Erik Kaffehr has cited.
That said, ProPhotoRGB does encode all of the real world surface colors (shown by the irregular space shown within the ProPhoto triangle) by a comfortable margin, whereas AdobeRGB does not. This is why many prefer ProPhotoRGB as one's working space.
Bill
-
But I have not found a Rec 2020 profile to plot.
\Argyll\ref\Rec2020.icm
-
\Argyll\ref\Rec2020.icm
Sorry, but that does not appear to be a valid URL. At least, it doesn't produce results with my system.
Bill
-
Sorry, but that does not appear to be a valid URL. At least, it doesn't produce results with my system.
Bill
it is not an url , it is a location of that profile when you install argyll suite.
-
Interesting that the problem colors seem to be violet-colored flowers, and many flowers have high UV reflectivity. How much can cameras "see" into the ultraviolet? Could C1 and Lightroom be responding to ultraviolet or near-UV differently?
-
Thanks!
Erik
it is not an url , it is a location of that profile when you install argyll suite.
-
It would be interesting to see a gamut plot of the Rec 2020 RGB compared to the ProPhoto RGB, as Rec 2020 is around the corner. But I have not found a Rec 2020 profile to plot.
If you have the spec's (chromaticity values for RGB, white point, gamma), you can build it in Photoshop's Color Settings.
-
If you have the spec's (chromaticity values for RGB, white point, gamma), you can build it in Photoshop's Color Settings.
That's right for the Rec. 2020 colorimetry (https://en.wikipedia.org/wiki/Rec._2020#System_colorimetry). There is also a tone curve adjustment needed to get even closer to the recommendation. Plenty of bits per channel are also seriously recommended.
Cheers
Bart
-
That's right for the Rec. 2020 colorimetry (https://en.wikipedia.org/wiki/Rec._2020#System_colorimetry). There is also a tone curve adjustment needed to get even closer to the recommendation.
True, PS can't create a TRC, just a simplified gamma value, but if the idea is to examine the gamut and one doesn't have access to the actual profile (for whatever reason), it's a decent start. I just did this today in Photoshop to get a better idea of how Apple's new displays which are based on DCI-P3 compare to Adobe RGB (1998).
-
Which is rendered in wireframe and which is rendered in shaded mode?
Thx
PP
-
Which is rendered in wireframe and which is rendered in shaded mode?
Wireframe is Adobe RGB (1998)
-
Wireframe is Adobe RGB (1998)
Thank you, sir. Maybe I'll have to take a look at the new model...
pp