Luminous Landscape Forum
Raw & Post Processing, Printing => Digital Image Processing => Topic started by: Robert Ardill on March 15, 2016, 02:41:42 pm
-
Hi,
I'm a Lightroom user normally, but having changed from Canon to Sony recently I decided to have a look at Capture One as CO is the free raw converter for Sony cameras. Also, because so many people say that CO is WAY better than LR at raw conversion.
I've done some tests between LR and CO, doing nothing but white balance, white point, black point and color noise reduction. Comparing a number of images I see no advantage to either detail-wise. There is some color difference and slight contrast difference which is better with one converter on some images and better with the other converter on other images, but the differences are easily adjusted in the raw converters themselves, or in post-processing.
With some structure added in CO there is a marked improvement detail-wise, but this is easily compensated on the LR tiff with Topaz Detail3 (for example).
Which leads me to my question. Does anyone know what are the adjustments that absolutely should be done in the raw converter, and which are just as well done in post processing?
My assumption has been that the only adjustments that should be done in the raw converter are white balance and white/black point, and that everything else (noise reduction, sharpening, color adjustments, chromatic aberration, color fringing etc.,) can all be left to post-processing. I have no other reasons to believe that this is correct except that my tests seem to bare out the assumption. For example, opening an image in ACR with tonal adjustments and comparing it to the same image that has been opened without tonal adjustments (save for white point / black point) but then processed using the Camera Raw filter with exactly the same settings, shows only very slight differences, only just visible at 1:1 (very slight sharpness difference, slight contrast difference, slight color differences).
This isn't a Capture One v Lightroom question as clearly each has strengths. If my assumption that only basic tonal adjustments should be done in the raw converter is wrong then I would probably use CO for the raw conversion and other basic adjustments, retaining Lightroom for all the other features. On the other hand, if the bulk of adjustments can be left to post-processing, then I would stick to LR as I can do pretty much everything I want with LR + PS (and plug-ins).
I appreciate your advice!
Robert
Robert
-
Hi Robert,
If by raw conversion you mean just opening the raw file into a 16-bit TIFF, imho the most critical parameters are EC (easy as pie), white balance (most can do a decent job), CA corrections (not hard but some do it better than others), choice of color profile (fiendishly hard) and demosaicing algorithm (some give you options, some don't). Every raw converter knows (or should know) how to subtract the correct black level from the raw data. And you don't need to touch the 'white point' before rendering. Some purport to perform magic under the hood (noise reduction etc.), but 99% of that stuff can just as well be performed on the 16-bit TIFF.
Jack
-
Hi,
I'm a Lightroom user normally, but having changed from Canon to Sony recently I decided to have a look at Capture One as CO is the free raw converter for Sony cameras. Also, because so many people say that CO is WAY better than LR at raw conversion.
I've done some tests between LR and CO, doing nothing but white balance, white point, black point and color noise reduction. Comparing a number of images I see no advantage to either detail-wise. There is some color difference and slight contrast difference which is better with one converter on some images and better with the other converter on other images, but the differences are easily adjusted in the raw converters themselves, or in post-processing.
With some structure added in CO there is a marked improvement detail-wise, but this is easily compensated on the LR tiff with Topaz Detail3 (for example).
Which leads me to my question. Does anyone know what are the adjustments that absolutely should be done in the raw converter, and which are just as well done in post processing?
My assumption has been that the only adjustments that should be done in the raw converter are white balance and white/black point, and that everything else (noise reduction, sharpening, color adjustments, chromatic aberration, color fringing etc.,) can all be left to post-processing. I have no other reasons to believe that this is correct except that my tests seem to bare out the assumption. For example, opening an image in ACR with tonal adjustments and comparing it to the same image that has been opened without tonal adjustments (save for white point / black point) but then processed using the Camera Raw filter with exactly the same settings, shows only very slight differences, only just visible at 1:1 (very slight sharpness difference, slight contrast difference, slight color differences).
This isn't a Capture One v Lightroom question as clearly each has strengths. If my assumption that only basic tonal adjustments should be done in the raw converter is wrong then I would probably use CO for the raw conversion and other basic adjustments, retaining Lightroom for all the other features. On the other hand, if the bulk of adjustments can be left to post-processing, then I would stick to LR as I can do pretty much everything I want with LR + PS (and plug-ins).
I appreciate your advice!
Robert
Robert
Hi Robert,
First let's get some commercial stuff out of the way. The version of C1 that Sony advertises as "free" is a very basic application called "C1 Express for Sony". It isn't nearly as full-featured as other version of C1 or LR. The next step up in C1 is a $50 upgrade of C1 Express for Sony which gives you a few more features. Beyond that you pay another $299 for the fully featured C1 application. None of these applications - the three versions of C1 or LR yet provide support for the new Sony A6300 - which I discovered much to my regret after buying the camera. No regret buying the camera - it's great - but to see the raw files, heaven forbid, one must download the Sony Image Converter application which is nothing much to write home about - but at least it demosaics the files, lets you enlarge the raw files on display and has a range of very basic adjustments.
I believe both C1 and LR are fine raw converter applications. As far as I'm concerned the choice depends on work flow preferences, and those preferences are often determined by what one knows how to use best. Personally, I find I can do a lot more much better and faster in Lightroom than I can in Photoshop, but having reasonably good integration between Photoshop and Lightroom provides with considerable ease that huge pack of tools for certain things LR can't do. That said, LR has become such a fully-featured capable application for a high percentage of what many users need, that for a proficient Lightroom user recourse to Photoshop may well be limited. Most of my work, for example, starts and finishes within LR - from camera to print. This provides for a huge saving of hard drive space and is so convenient. (For example, yesterday I converted a Sony raw file of 24 MB into a TIFF for further work in PS. By the time I finished and saved the file with the Layers, it was 499 MB. If I could have done the same adjustments in LR (a) it would have taken less time, (b) the file size would have remained 24 MB, and (c) everything is undoable thereafter without the need for saving space-hogging Layers. Doing as much as possible in the raw converter means getting to know the application well enough to extract maximum performance from it, and in so doing provides excellent results.
-
All things being the same in the workflow you describe which of the two is the easiest and fastest to deal with seeing you seem to nail the intended look of the image during capture.
Just out of curiosity could you post an image unedited out of the newer camera and post the same image but with the minimal edits you think all it needs. What is your idea of finish is what I'm getting at.
I've been using an old 2006 DSLR for years shooting Raw by exposing to preserve highlights and I have to apply a lot more than minor adjustments on every one of them, but I don't know if in your situation it's on account of the camera and/or the newer editing software.
-
Hi Robert,
If by raw conversion you mean just opening the raw file into a 16-bit TIFF, imho the most critical parameters are EC (easy as pie), white balance (most can do a decent job), CA corrections (not hard but some do it better than others), choice of color profile (fiendishly hard) and demosaicing algorithm (some give you options, some don't). Every raw converter knows (or should know) how to subtract the correct black level from the raw data. And you don't need to touch the 'white point' before rendering. Some purport to perform magic under the hood (noise reduction etc.), but 99% of that stuff can just as well be performed on the 16-bit TIFF.
Jack
So really what you're saying is that all you really need to tell the raw converter is:
- white balance
- CA correction (could this not be done as well in post-processing?)
- color profile (do you mean the camera profile, or the tiff image profile, or both?)
- demosaicing algorithm, assuming the raw converter gives you this choice (which neither LR nor CO one do)
Then the rest can just as well be done in post-processing (for example in Photoshop). Correct?
Robert
-
First let's get some commercial stuff out of the way. The version of C1 that Sony advertises as "free" is a very basic application called "C1 Express for Sony". It isn't nearly as full-featured as other version of C1 or LR. The next step up in C1 is a $50 upgrade of C1 Express for Sony which gives you a few more features. Beyond that you pay another $299 for the fully featured C1 application. None of these applications - the three versions of C1 or LR yet provide support for the new Sony A6300 - which I discovered much to my regret after buying the camera. No regret buying the camera - it's great - but to see the raw files, heaven forbid, one must download the Sony Image Converter application which is nothing much to write home about - but at least it demosaics the files, lets you enlarge the raw files on display and has a range of very basic adjustments.
Yes, I used Capture One Pro 9, full version, for the tests. I don't think you're right about the Sony versions though. Capture One Express for Sony is free and is very limited. The $50 upgrade gives you Capture One Pro 9 (for Sony) which has all of the features of Capture One Pro 9, but only supports Sony cameras.
"The feature sets of the two upgrade options are the same, and the only differences are the supported camera brands and the price. Capture One Pro (for Sony) only offers file support for selected Sony cameras while Capture One Pro 9 offers file support for more than 400 leading cameras."
I believe both C1 and LR are fine raw converter applications. As far as I'm concerned the choice depends on work flow preferences, and those preferences are often determined by what one knows how to use best. Personally, I find I can do a lot more much better and faster in Lightroom than I can in Photoshop, but having reasonably good integration between Photoshop and Lightroom provides with considerable ease that huge pack of tools for certain things LR can't do. That said, LR has become such a fully-featured capable application for a high percentage of what many users need, that for a proficient Lightroom user recourse to Photoshop may well be limited. Most of my work, for example, starts and finishes within LR - from camera to print. This provides for a huge saving of hard drive space and is so convenient. (For example, yesterday I converted a Sony raw file of 24 MB into a TIFF for further work in PS. By the time I finished and saved the file with the Layers, it was 499 MB. If I could have done the same adjustments in LR (a) it would have taken less time, (b) the file size would have remained 24 MB, and (c) everything is undoable thereafter without the need for saving space-hogging Layers. Doing as much as possible in the raw converter means getting to know the application well enough to extract maximum performance from it, and in so doing provides excellent results.
Yes, as I said, I'm not trying to measure one raw converter against another, simply to try to find out what can be safely left to post processing and what should be done prior to demosaicing.
My own rather limited tests seem to indicate that you can leave most everything to post processing (should you prefer to do things in post-processing, obviously). Jack reckons white balance and CA. Obviously you need to specify what output color profile to use. I would have thought that you would be well advised to set the black and white points first, but as one would be going from 12 or 14 bits to 16 bits perhaps that isn't necessary either.
Of course I do accept that there are benefits for doing a lot more (or everything) in the raw converter of choice, but that isn't always possible. For example, in my case I do absolutely want to use Lightroom for all of the image organisation, selection, previewing, web output, geo-coding etc., etc., because it does it so well; but if I find that C1 is really much better at the raw conversion and decide to use C1 for that purpose then I will have no choice but to render to tiff because the integration with LR (and Photoshop) is so poor (shockingly so in my opinion).
Cheers,
Robert
-
Your not saying anything very different from what I said about the available versions for C1. But I do think (from the little I could make out in their description) the full application has yet more editing capabilities than the 50 dollar upgrade of the version for Sony. Exactly what I don't know.
If you find using C1 is so much better than LR, why not just do as much of your image editing as possible in C1 and only convert it to TIFF if there is something you need that C1 can't do?
-
Which leads me to my question. Does anyone know what are the adjustments that absolutely should be done in the raw converter, and which are just as well done in post processing?
My assumption has been that the only adjustments that should be done in the raw converter are white balance and white/black point, and that everything else (noise reduction, sharpening, color adjustments, chromatic aberration, color fringing etc.,) can all be left to post-processing.
I think your assumptions are correct, but I would add that those operations that are best performed on linear scene referred data are best done in the raw converter. Certainly this applies to white balance. The author of Noiseware once stated that NR is best done in the raw converter as the noise characteristics are changed by gamma encoding, exposure adjustments and a tone curve. One can perform inverse gamma encoding later on, but changes related to a tonal adjustments would be undocumented in most cases.
Regards,
Bill
-
Just out of curiosity could you post an image unedited out of the newer camera and post the same image but with the minimal edits you think all it needs. What is your idea of finish is what I'm getting at.
Hi tim,
Here is an image which is pretty out-of-kilter, mostly very underexposed but slightly overexposed for the lamp. In this case I would do more than just basic black/white point and white balance, as I show in the second image:
(http://www.irelandupclose.com/customer/LL/basictone.jpg)
However, if I only do the most basic tone correction and then post-correct (using the Camera Raw filter in Photoshop) then I get this (the post-processed version is on top with the pre-processed version below it for comparison):
(http://www.irelandupclose.com/customer/LL/posttone.jpg)
As you can see there is little visual difference although the pre-processed version histogram does look a bit better (the shadows need to be pushed up a bit, which would be easy enough to correct).
Robert
-
If you find using C1 is so much better than LR, why not just do as much of your image editing as possible in C1 and only convert it to TIFF if there is something you need that C1 can't do?
I don't know if C1 is better or not ... it really depends on whether it's important to do things like color adjustments, adding structure, things like that, before demosaic. If it doesn't matter then C1 boils down to whether or not the raw conversion is better than LR's (with just basic tonal adjustment). From my tests I would say that it isn't for sharpness (but it's as good) and it's image-dependent for things like color fidelity. So it wouldn't be worth the trouble to use both packages for me.
There is a whole lot that C1 doesn't do well for me (or at least that LR does much better, IMO). I could list plenty, but just for one thing alone, take Photoshop integration. So C1 is not an option for me on its own. It would only be useful just for the raw conversion and I would then always have to go to tiff (which is OK for me because I do that anyway ... disk is very cheap nowadays, so I'm not worried about big files).
To try to clarify, it's like this:
- if it is important to make as many adjustments as possible pre-demosaic, then I would use C1 as the raw converter (even though it's a pain using both LR and C1)
- if only basic tonal adjustments are required pre-demosaic then I would stick with LR (because I can make all the adjustments I want either in LR or in Photoshop and plug-ins).
-
I think your assumptions are correct, but I would add that those operations that are best performed on linear scene referred data are best done in the raw converter. Certainly this applies to white balance. The author of Noiseware once stated that NR is best done in the raw converter as the noise characteristics are changed by gamma encoding, exposure adjustments and a tone curve. One can perform inverse gamma encoding later on, but changes related to a tonal adjustments would be undocumented in most cases.
That's the crux of it really. It seems to me that at this stage things like noise reduction and deblur /sharpening are not done very well in either LR or C1, so we pretty much have to do them post-processing if we want the best results. So the answer may be that at this point it's down to whether we think the raw conversion in C1 is better than the raw conversion in LR (or vice versa); however that could well change (and hopefully will), when the raw converters get decent deconvolution and noise reduction features.
Would you agree?
Robert
-
That's the crux of it really. It seems to me that at this stage things like noise reduction and deblur /sharpening are not done very well in either LR or C1, so we pretty much have to do them post-processing if we want the best results. So the answer may be that at this point it's down to whether we think the raw conversion in C1 is better than the raw conversion in LR (or vice versa); however that could well change (and hopefully will), when the raw converters get decent deconvolution and noise reduction features.
Would you agree?
Robert
Robert,
Yes, I agree mostly. However, since I started using the Nikon D800e, my need for noise reduction is much less than previously. Even at ISO 3200, properly exposed images need little NR. I do have Noiseware, one of the better reviewed NR programs, but I use it infrequently. However, LR/ACR could benefit from better deconvolution/sharpening. It is not that bad, but for my more important images I bring them into Photoshop and sharpen on a layer with the luminosity blend mode using Focus Magic or Topaz detail. I hope Bart van der Wolf will enter into the discussion, since he is well regarded in this area.
Bill
-
Thanks for the image samples, Robert. Those do look finished. Not much else you can do to improve them other than the fireplace shadow definition and lift.
So which is easier to accomplish the same between C1 and ACR.
I'm also a bit perplexed by the ACR filter in photoshop in why it must be used over just launching ACR from Bridge.
-
Yes, I agree mostly. However, since I started using the Nikon D800e, my need for noise reduction is much less than previously. Even at ISO 3200, properly exposed images need little NR. I do have Noiseware, one of the better reviewed NR programs, but I use it infrequently. However, LR/ACR could benefit from better deconvolution/sharpening. It is not that bad, but for my more important images I bring them into Photoshop and sharpen on a layer with the luminosity blend mode using Focus Magic or Topaz detail. I hope Bart van der Wolf will enter into the discussion, since he is well regarded in this area.
Hi Bill ... for sure the new cameras are hugely improved noise-wise. I have a Sony A7RII and the dynamic range and very low noise at high ISO is fantastic. In the image I posted above there is essentially no noise even though the exposure is boosted by over 3EV on an ISO 250 image. Still, there will be times when some noise reduction is going to be needed, especially color noise reduction. ACR/LR isn't bad - but it's a pity there isn't masking as in Sharpening.
I hope Bart joins it too -- especially as he uses C1, if I recall.
Cheers
Robert
-
Thanks for the image samples, Robert. Those do look finished. Not much else you can do to improve them other than the fireplace shadow definition and lift.
So which is easier to accomplish the same between C1 and ACR.
I'm also a bit perplexed by the ACR filter in photoshop in why it must be used over just launching ACR from Bridge.
I find LR/ACR easier, but that's no doubt because I'm so used to it. C1 is very nice though, once you get over the rather confusing workspace, and it as features that are missing in LR, for example adjustment layers.
I just used the ACR filter because I wanted to apply the adjustments to the tiff file. I could have saved the tiff and opened in using Bridge just as well.
Robert
-
Here is a crop of an image comparing C1 and LR with only the following adjustments:
- white balance on the same spot
- exposure
- color noise reduction
- all other adjustments off or zeroed
(http://www.irelandupclose.com/customer/LL/LRvC1-1.jpg)
To my eye there is nothing at all between them detail-wise. (You can right-click and download the image if you're interested).
However ... there are huge color differences. Look at the neon sign for example, the wall behind the neon sign, the shop sign, the yellows, the reds. I don't know which one is the more accurate although I would guess that C1 is.
In C1 I used the SonyA7RMII STANDARD profile, in LR I used a DNG profile for the camera.
So I'll need to do some further checking.
Robert
-
Here is a crop of an image comparing C1 and LR with only the following adjustments:
- white balance on the same spot
- exposure
- color noise reduction
- all other adjustments off or zeroed
(http://www.irelandupclose.com/customer/LL/LRvC1-1.jpg)
To my eye there is nothing at all between them detail-wise. (You can right-click and download the image if you're interested).
However ... there are huge color differences. Look at the neon sign for example, the wall behind the neon sign, the shop sign, the yellows, the reds. I don't know which one is the more accurate although I would guess that C1 is.
In C1 I used the SonyA7RMII STANDARD profile, in LR I used a DNG profile for the camera.
So I'll need to do some further checking.
Robert
Robert,where are you going with this thread? You wrote this in your first post.
This isn't a Capture One v Lightroom question as clearly each has strengths
-
I really wonder how much mileage there is trying to assess the quality differences between raw converters by looking at out of the box colour differences between the originating renderings, when you consider that neither is likely colour accurate and most of these differences are anyhow adjustable. I think the far more important factor to look for is whether either converter produces artifacts once the image is magnified to more or less replicate the size at which it would be printed. As for what adjustments to do where, previous advice from experts who tested these alternatives rather carefully suggest that the cleanest editing is performed on the raw data in the raw converter application to the extent it allows.
-
Robert,where are you going with this thread? You wrote this in your first post.
This isn't a Capture One v Lightroom question as clearly each has strengths
Quite true :)
What I'm looking at is the effect of applying the very basic adjustments to the two converters and then seeing the result. If, for example, I found that certain colors were incorrectly rendered in one or other converter, with these basic adjustments only, then I would conclude that it would be advantageous to apply some further basic color corrections pre-rendering.
Robert
-
Quite true :)
What I'm looking at is the effect of applying the very basic adjustments to the two converters and then seeing the result. If, for example, I found that certain colors were incorrectly rendered in one or other converter, with these basic adjustments only, then I would conclude that it would be advantageous to apply some further basic color corrections pre-rendering.
Robert
How do you judge that .... colors were incorrectly rendered? Surely you aren't trying to remember the colors of the scene you shot? The colors are subjective and trying for "reality" is futile and ultimately time wasting.
-
I really wonder how much mileage there is trying to assess the quality differences between raw converters by looking at out of the box colour differences between the originating renderings, when you consider that neither is likely colour accurate and most of these differences are anyhow adjustable.
Well it's true that accurate color rendering is a big stretch - but if a converter renders some colors inaccurately then it would be a minus for that converter, or it would point to the need to have a better profile (if the converter supports this) or to make some canned color corrections before rendering the image.
Here is a test, again with C1 and LR:
(http://www.irelandupclose.com/customer/LL/LRvC1-2.jpg)
I've compared the colors to the Lab standard after color balance first in the raw converter, then with fine-tuning on the middle gray. If I found that one converter was significantly closer to the correct color I put a tick for that converter, with L at the top, a in the middle, and b at the bottom.
C1 is significantly more accurate on the orange and red, while LR is significantly better on the brown and cream.
So my conclusion is that for very accurate color rendering (given a particular lighting condition) that one of the things that would be advantageous would be to fine tune the colors pre-rendering, either by making a better camera profile than the canned one (C1) or by tweaking the camera calibration (LR).
I think the far more important factor to look for is whether either converter produces artifacts once the image is magnified to more or less replicate the size at which it would be printed. As for what adjustments to do where, previous advice from experts who tested these alternatives rather carefully suggest that the cleanest editing is performed on the raw data in the raw converter application to the extent it allows.
Yes, well my conclusion is that between LR and C1 there is nothing to choose from a detail/artifact point of view (unless one starts to use clarity, structure, sharpening, noise reduction adjustments). Which does get back to my original question, which is whether or not there is an advantage in making these additional adjustments pre-rendering; but as it becomes very difficult and time-consuming to gauge the benefits or otherwise, I'm hoping that someone who has a better technical understanding of raw conversion than me can shed some light on this.
-
How do you judge that .... colors were incorrectly rendered? Surely you aren't trying to remember the colors of the scene you shot? The colors are subjective and trying for "reality" is futile and ultimately time wasting.
Well in many cases it's reasonable to say that colors are subjective and the best thing is to adjust to taste. But if you're trying to accurately reproduce a painting, for example (which is something that I do need to do), then getting the colors as right as possible is very important. Which, after all, is the whole purpose of color management.
Robert
-
The benefits of Raw data are in that no irreversible assumptions are made with regards to image detail and color, e.g. until demosaiced we can still improve the radial alignment of lateral CA (which improves the demosaicing result), and while we are in linear gamma it's much easier to adjust things like Exposure and Color, deconvolution Capture sharpening, and noise reduction.
Technically, if we were to process our images in floating-point accuracy, it would be possible (but not necessarily easier) to convert back to linear gamma for those operations that benefit from linear gamma blending/adjustment. But once rendered in a gamma pre-compensated integer number data file, we lose precision, especially for stronger adjustments, due to rounding errors that can accumulate.
The benefit of Raw processor engines such as used in C1 or LR, is that they are pretty much parametric processors, and that internally the image data stays in linear gamma space until rendered/exported.
As for differences in color rendering, that's more of a profiling issue, not a pre-/post-Raw processing issue, as long as colors are blended/interpolated in linear gamma and tonal adjustments are done in luminosity and not chromaticity. As soon as we start with non-linear adjustments, then all bets are off, especially in integer number gamma adjusted space and with chromaticity.
Cheers,
Bart
-
The benefits of Raw data are in that no irreversible assumptions are made with regards to image detail and color, e.g. until demosaiced we can still improve the radial alignment of lateral CA (which improves the demosaicing result), and while we are in linear gamma it's much easier to adjust things like Exposure and Color, deconvolution Capture sharpening, and noise reduction.
Technically, if we were to process our images in floating-point accuracy, it would be possible (but not necessarily easier) to convert back to linear gamma for those operations that benefit from linear gamma blending/adjustment. But once rendered in a gamma pre-compensated integer number data file, we lose precision, especially for stronger adjustments, due to rounding errors that can accumulate.
The benefit of Raw processor engines such as used in C1 or LR, is that they are pretty much parametric processors, and that internally the image data stays in linear gamma space until rendered/exported.
As for differences in color rendering, that's more of a profiling issue, not a pre-/post-Raw processing issue, as long as colors are blended/interpolated in linear gamma and tonal adjustments are done in luminosity and not chromaticity. As soon as we start with non-linear adjustments, then all bets are off, especially in integer number gamma adjusted space and with chromaticity.
Cheers,
Bart
Excellent Bart ... exactly the information I hoped to get (asuuming I understand you, that is, not a given by any means :)).
So, if I understand you correctly, the following should ideally be done before demosaicing:
- Tonal adjustments
- CA
- Color adjustments
- Deblur (do any of the raw converters currently offer this? I guess not or else you wouldn't be using Focus Magic)
- Color noise reduction
- Luminosity noise reduction (if the raw converter does a decent job of it, which LR doesn't IMO, don't know about C1)
Correct?
As for differences in color rendering, surely the right place to fix this is in the raw converter - not because of technical reasons perhaps, but because the raw converters automatically apply a camera profile on the way to the monitor color space. Perhaps converters like dcraw are more flexible in that regard, but as far as I can see, with LR and C1 there's no choice.
So is it fair to say that when we evaluate one raw converter against another (leaving aside whether or not their adjustments are parametric, the user interface, how well they fit in to your workflow, etc) we need to look at pretty much all aspects of the image: tone, color, CA, noise, sharpness? Also, in the same way that the color rendition of one lens may be significantly better than that of another lens, in your experience, have you found that one raw converter gives better color 'rendition' than another?
Cheers,
Robert
-
To pick up the original question, there is one area where there is at least a definite theoretical benefit from being done in the raw processor, and that's highlight recovery. This is because the very different channel sensitivities provide the opportunity to do clever things. For a similar reason, there may be benefits as regards noise reduction. Maybe. The rest - not so much. IMHO. Results in any given raw converter may or may not conform to theory, spending on implementation.
-
To pick up the original question, there is one area where there is at least a definite theoretical benefit from being done in the raw processor, and that's highlight recovery. This is because the very different channel sensitivities provide the opportunity to do clever things. For a similar reason, there may be benefits as regards noise reduction. Maybe. The rest - not so much. IMHO. Results in any given raw converter may or may not conform to theory, spending on implementation.
I was just reading Capture One Color (http://help.phaseone.com/en/CO9/Editing-photos/Working-with-colors/Colors-in-Capture-One.aspx) and the point is made strongly that the color corrections in the raw converter are carried out in a very large color space (similar to the camera's) and this means that a lot of corrections can be made without too much risk of clipping. So, as the page says:
"This is why it is paramount to perform color corrections and optimizations to images before processing to a smaller color space".
This would be a good reason to do as much of the color adjustments as possible in the raw converter. I've chosen to work in Adobe RGB largely because my monitor has a 100% Adobe RGB space - even though I know that my printer color space does extend beyond this in places. Any conversions from one color space to another will potentially cause clipping, color shifts etc., so going from raw to ProPhoto, say, and then converting that to a smaller color space (which is automatic for viewing, clearly) is a bad idea IMO. So I would make as much of the color adjustments in the raw converter as possible and then go to Adobe RGB, and only make color tweaks in the tiff if necessary.
Robert
-
Hi,
Much of the information coming from Phase One does not make any sense to me. I don't even think that it is correct to talk about a camera colour space.
There is something called "Pointer's gamut" that includes all non spectacular colours in nature, and I see little benefit of an ill defined colour space describing non existing colours. Prophoto RGB does contain the whole Pointer's colour space.
In addition, camera sensors don't really have a colour space in the traditional sense. According to Bruce Fraser, they are sort of colour mixing devices.
Think a little bit of an RGB colour sensor, it has three humps of sensitivity for channels called 'B', 'G' and 'R'. So any signal you get out of that sensor is an integrated value of those three humps. That integrated signal does not give any information of the sampled colour.
Check the image below, any read signal between 630 and 750 nm would give a single integrated value and it would not be possible to deduce the actual colour of the red. Between 560 and 630 nm we would have a signal in both the green and red channels, so we could deduce some information about colour in that range by looking at the ratio of the green signal and the red signal.
This is just a very simple demo of the colour space being a pretty fuzzy, talking about a well defined camera colour space does just makes very little sense.
Best regards
Erik
(http://forum.luminous-landscape.com/index.php?action=dlattach;topic=108530.0;attach=140198;image)
I was just reading Capture One Color (http://help.phaseone.com/en/CO9/Editing-photos/Working-with-colors/Colors-in-Capture-One.aspx) and the point is made strongly that the color corrections in the raw converter are carried out in a very large color space (similar to the camera's) and this means that a lot of corrections can be made without too much risk of clipping. So, as the page says:
"This is why it is paramount to perform color corrections and optimizations to images before processing to a smaller color space".
This would be a good reason to do as much of the color adjustments as possible in the raw converter. I've chosen to work in Adobe RGB largely because my monitor has a 100% Adobe RGB space - even though I know that my printer color space does extend beyond this in places. Any conversions from one workspace to another will potentially cause clipping, color shifts etc., so going from raw to ProPhoto, say, and then converting that to a smaller color space (which is automatic for viewing, clearly) is a bad idea IMO. So, for me I would make as much of the color adjustments in the raw converter and then go to Adobe RGB, and only make color tweaks in the tiff if necessary.
Robert
-
Hi,
Much of the information coming from Phase One does not make any sense to me. I don't even think that it is correct to talk about a camera colour space.
There is something called "Pointer's gamut" that includes all non spectacular colours in nature, and I see little benefit of an ill defined colour space describing non existing colours. Prophoto RGB does contain the whole Pointer's colour space.
In addition, camera sensors don't really have a colour space in the traditional sense. According to Bruce Fraser, they are sort of colour mixing devices.
I think they mean that they use a very large color space in the same way that LR does, not that they use a camera color space.
-
I have read on a few occasions, here at this forum, that noise reduction would best be performed prior to demosaicing. The idea sure seems compelling.
Is there any application that actually lets you do this or is it currently just a hope that someday there will be?
Thank you.
-
I think they mean that they use a very large color space in the same way that LR does, not that they use a camera color space.
Correct, and that may be a better approach than restricting oneself to a fixed working space such as ProPhoto RGB or variation thereof. Even ProPhoto RGB may be inadequate if one increases saturation or shifts to a significantly different White/Color-Balance.
The way I interpret the info from PhaseOne, they use a coordinate space that is flexible, just large enough to accommodate the Raw processing, until the result is exported to a fixed colorspace.
Whether one can call the cameraspace a colorspace is not that relevant to me, but since they use ICC scene referred camera color profiles one could say that the input profile characterizes the colors that the Raw data represents, a sort of colorspace. Since each scene has a different palette of colors, it makes sense to use a camera/color space that is large enough to encode those color coordinate values but if saturation is boosted can adapt to the larger space coordinates that are required. Using a space that is small (but just large enough to encode available color data) will give the highest numerical precision. A very large colorspace wastes precision by unnecessarily large integer coordinate intervals. One in large gamut space steps is a larger absolute difference than one in in a smaller gamut space.
Cheers,
Bart
-
Excellent Bart ... exactly the information I hoped to get (asuuming I understand you, that is, not a given by any means :)).
So, if I understand you correctly, the following should ideally be done before demosaicing:
- Tonal adjustments
- CA
- Color adjustments
- Deblur (do any of the raw converters currently offer this? I guess not or else you wouldn't be using Focus Magic)
- Color noise reduction
- Luminosity noise reduction (if the raw converter does a decent job of it, which LR doesn't IMO, don't know about C1)
Correct?
I think tonal and color adjustments are easier to do after demosaicing (there is no 'color' before that data conversion), but still in linear gamma space. Of course, assigning an input profile is also something of an adjustment, but it just takes whatever the demosaicing will output.
Do note that 'ideally' and 'more practical' can be two different approaches. While something would ideally be done before demosaicing, it may be much easier to implement after demosaicing (and maybe with measurable but insignificant losses). As an analogy, it may be more accurate to disassemble an engine's transmission-block for cleaning, but draining the warmed up oil and letting gravity do most of the work is more practical/efficient.
So is it fair to say that when we evaluate one raw converter against another (leaving aside whether or not their adjustments are parametric, the user interface, how well they fit in to your workflow, etc) we need to look at pretty much all aspects of the image: tone, color, CA, noise, sharpness? Also, in the same way that the color rendition of one lens may be significantly better than that of another lens, in your experience, have you found that one raw converter gives better color 'rendition' than another?
A Raw converter's Color rendition of a given Raw data file, depends very much on profiling and the built-in 'look' of the Raw converter's profiles. I happen to prefer the CaptureOne look (also the less intrusive and more predictable tonality adjustments), and the level of control to adjust it to my liking (with the Color Editor that can create a modified profile for future use or as default) if needed.
Cheers,
Bart
-
Much of the information coming from Phase One does not make any sense to me. I don't even think that it is correct to talk about a camera colour space.
There is something called "Pointer's gamut" that includes all non spectacular colours in nature, and I see little benefit of an ill defined colour space describing non existing colours. Prophoto RGB does contain the whole Pointer's colour space.
Hi Erik,
But after assigning the camera profile to the Raw data demosaicing result, one can boost (or reduce) saturation and even the total color balance of the colors in "Pointer's gamut". The color/working space that Capture One uses internally apparently adapts to match the requirements. It then doesn't waste coordinate precision on non-existing colors, or assign too little space for larger gamuts. I wouldn't call that flexibility ill defined, it's purposely not fixed but flexible, that's how I interpret the info.
In addition, camera sensors don't really have a colour space in the traditional sense. According to Bruce Fraser, they are sort of colour mixing devices.
While correct strictly speaking, after assignment of a given color profile it does have a colorspace and scene referred gamut.
Check the image below, any read signal between 630 and 750 nm would give a single integrated value and it would not be possible to deduce the actual colour of the red.
Well, the absence of Blue of Green channel info in that specific sensor response gives a clue that it is Red, just not which/how Red. But that changes with capture (which blurs some of the signal to neighboring photosites) and demosaicing. If those neighboring photosites also detect no signal, then apparently it was very deep Red. An OLPF makes it even easier to map to the correct color.
But this is a bit off-topic for the question at hand, Raw- or post-processing.
Cheers,
Bart
-
[quote author=ErikKaffehr link=topic=108832.msg897382#msg897382 date=1458162365
In addition, camera sensors don't really have a colour space in the traditional sense. According to Bruce Fraser, they are sort of colour mixing devices.
[/quote]
Bruce Fraser's opinion on whether or not a raw fill has a color space is not agreed upon by such authorities as Thomas Knoll, Eric Walowit, and Chris Murphy. See this link (http://forum.luminous-landscape.com/index.php?topic=22471.msg168050#msg168050). The entire thread appears here (http://forum.luminous-landscape.com/index.php?topic=22471.msg168050#msg168050).
Doug Kerr has an excellent post (http://dougkerr.net/Pumpkin/articles/Sensor_Colorimetry.pdf) explaining why the camera does not have a strictly defined colorimetric color space.
It all depends on how one defines a color space.
Regards,
Bill
-
I have read on a few occasions, here at this forum, that noise reduction would best be performed prior to demosaicing. The idea sure seems compelling.
Is there any application that actually lets you do this or is it currently just a hope that someday there will be?
I think you would have to look at the better astronomy software applications (e.g. PixInsight (http://pixinsight.com/)), but they require a lot of calibration and statistical noise modeling and large datasets to do an accurate job, and the resulting differences may be small. In astronomy the small differences are often all they've got, so they tend to delve deep and make each photon (of which there are few) count.
Some of the noise reduction can already be done in hardware (sensor cooling, correlated double readout, multiple signal read outs, etc), but some of the noise is just caused by Photon statistics and residual electronic noise and multiple image averaging or more elaborate statistical distribution mapping is necessary. Often the software needs to allow calculations with high precision floating-point numbers to not waste precision or introduce quantization noise. It is often necessary to treat individual scene shots slightly different, making it a very laborious process.
And research is ongoing, so who knows what the future has in store. Hang on to your Original camera Raws, they may allow even better conversions in the future.
Cheers,
Bart
-
I think tonal and color adjustments are easier to do after demosaicing (there is no 'color' before that data conversion), but still in linear gamma space. Of course, assigning an input profile is also something of an adjustment, but it just takes whatever the demosaicing will output.
I think I'm using terms a bit too loosely. What I meant is that ideally it is better (if I understand you correctly) to do as many of the adjustments as possible in the raw converter, and as few as possible after conversion to tiff. There are a few reasons from an image quality point of view:
- larger color space (pros and cons here)
- linear mode (used internally by the raw processor)
- better CA and fringe correction (resulting in less artifacts in the image)
- better for color noise correction
- potentially better for deblur (assuming a good deblur tool in the raw converter)
- potentially better for noise reduction (assuming a good denoise tool in the raw converter)
- ... ?
This assumes that the raw converter actually makes the adjustments on the sensor data directly where at all possible.
Which does lead to another question: what image adjustments/corrections are typically done on the sensor data, pre-demosaic? I would have thought not too many (CA and color noise possibly?). Would the other adjustments not then be made on the linear, demosaiced image? If so then the only advantage of doing something like a saturation adjustment in the raw converter is that the image is still linear and in a large color space.
And how big an advantage is it? As you point out, it may be measurable but not noticeable ... and against this is the risk of making adjustments that will clip when the image is converted to a working space (aRGB etc) and to posterisation because of the large color space used.
Which all goes back to my original question. It makes sense (to me) to make tonal adjustments in the raw converter. But it makes much less sense that it is necessarily better to make color adjustments in the raw converter. It might possibly be better to convert to the intended final working space and to make corrections in that color space, because a smaller color space will lead to less posterisation.
Of course if C1 is in fact using a dynamic, image-dependent color space, that would be very good. But it would have to leave elbow room for the possible adjustments ... or it would have to grow as required. This enlarging would cause degradation I would have thought (but maybe C1 are working in 32-bit or more?).
It would be good to do some actual comparisons between pre and post conversion to working space ... which is what I tried to do earlier in this topic. But it isn't an easy thing to do, which is why I'm looking for a theoretical answer :)
Cheers
Robert
-
... which is what I tried to do earlier in this topic. But it isn't an easy thing to do, which is why I'm looking for a theoretical answer
The theoretical (practical) answer is the one I gave you earlier :)
PS By color profile I mean how the neutral raw data gets converted to a colorimetric color space. And the answer to your other question is: Correct, in 16 bits for most intents and purposes.
-
Googled RAW noise reduction and made my way to downloading DxO Optics Pro 10 to try out its Prime noise reduction. It takes a long time to process but the results seem very nice.
The DxO marketing seems to suggest that the process is working on the RAW data, and I am trying to figure out if I am wishful thinking and misinterpreting the product description or if it really is using the RAW data prior to demosaicing.
Are there any other apps that run noise reduction on the RAW data?
-
The theoretical (practical) answer is the one I gave you earlier :)
PS By color profile I mean how the neutral raw data gets converted to a colorimetric color space. And the answer to your other question is: Correct, in 16 bits for most intents and purposes.
Hi Jack ... yes, yes :); but you and Bart don't seem to be in agreement on this. Or perhaps you are in that the benefits of, say, making chromaticity changes before rendering to the chosen working space is generally too small to be noticeable.
What might change that view though is if there are repeated changes. In the raw converter these are presumably all applied at once (perhaps in the same way that multiple layers in Photoshop (may) result in one cumulative change (??)) whereas on the tiff (if the changes are not made using adjustment layers) the repeated changes may well result in a noticeable degradation.
BTW ... when you said that the choice of color profile is fiendishly difficult ... what did you mean? If you meant that it's hard to choose whether to use ProPhoto or BetaRGB or AdobeRGB or sRGB then surely this isn't so hard?
Robert
-
Googled RAW noise reduction and made my way to downloading DxO Optics Pro 10 to try out its Prime noise reduction. It takes a long time to process but the results seem very nice.
The DxO marketing seems to suggest that the process is working on the RAW data, and I am trying to figure out if I am wishful thinking and misinterpreting the product description or if it really is using the RAW data prior to demosaicing.
I've tried DxO Prime on a VERY noisy image(taken at ISO 20,000 and +3EV) and (with the caveat that I've only use Prime once) the results are not exactly impressive, compared to Topaz DeNoise, as you can see here:
(http://www.irelandupclose.com/customer/LL/TOPvDXO-Noise.jpg)
A you can see the DxO image appears to have a skin disease, whereas the Topaz image is still noisy, but very clean otherwise. Ignore the colors as I didn't color balance the Topaz image and just applied a saturation boost post DeNoise to more or less make like with like. You may need to right-click and download the image to view it properly.
Robert
-
I compared with a back lit photo of a deer standing in saw grass which I made at 3200 ISO moments before the sun came over the horizon and turned it into a silhouette. I pushed the exposure 2/3rds of a stop in the RAW conversions.
I was fairly impressed with the DxO results.
In this instance I had already prepared a finished picture, based on using Topaz Denoise as a first step after conversion, that I thought I was satisfied with. The new DxO version has replaced it in my master files.
I wasn't as pleased with the color rendition of DxO for my camera and had to use Photoshop to get what I wanted to see, so the dialog about when and where to work with color has been interesting.
-
I compared with a back lit photo of a deer standing in saw grass which I made at 3200 ISO moments before the sun came over the horizon and turned it into a silhouette. I pushed the exposure 2/3rds of a stop in the RAW conversions.
I was fairly impressed with the DxO results.
In this instance I had already prepared a finished picture, based on using Topaz Denoise as a first step after conversion, that I thought I was satisfied with. The new DxO version has replaced it in my master files.
I wasn't as pleased with the color rendition of DxO for my camera and had to use Photoshop to get what I wanted to see, so the dialog about when and where to work with color has been interesting.
I've had another go at the image I posted above and DxO did a much better job this time (or rather I didn't do as bad a job :) ). For some reason, reset leaves Smart Lighting on and this distorted the results. In fact DxO did a better job than Topaz (both under my non-expert guidance admittedly). The residual noise is very fine whereas with Topaz it is blotchy. The black level is held much better (even with black level adjustment in Topaz). However it does tend to see small details like ripple in the water as noise and so the resultant image is flatter than the Topaz image. That could probably be improved on, but as DxO is very slow it's a bit of a pain. If the preview was full-size as in Topaz it would help a lot.
For anyone who's interested, here is a crop comparison. DxO V Topaz DeNoise (http://www.irelandupclose.com/customer/LL/DxO-v-Topaz.tif)
Robert
-
Hi Jack ... yes, yes; but you and Bart don't seem to be in agreement on this. Or perhaps you are in that the benefits of, say, making chromaticity changes before rendering to the chosen working space is generally too small to be noticeable.
We agree (or at least mostly I agree with Bart). As for chromaticity, it shouldn't change if using the correct color profile.
What might change that view though is if there are repeated changes. In the raw converter these are presumably all applied at once (perhaps in the same way that multiple layers in Photoshop (may) result in one cumulative change (??)) whereas on the tiff (if the changes are not made using adjustment layers) the repeated changes may well result in a noticeable degradation.
The fact is unless you plan to butcher the image 16 bits is aplenty for anything one can throw at it in a normal workflow. And floating point is subliminally more and more part of PP.
BTW ... when you said that the choice of color profile is fiendishly difficult ... what did you mean? If you meant that it's hard to choose whether to use ProPhoto or BetaRGB or AdobeRGB or sRGB then surely this isn't so hard?
The color profile is what makes or breaks color, that's why there is something to be said for using a manufacturer's crappy software. It is intimately connected to white balance and EC. Most people underestimate this, Anders Torger docet.
The working color space is an order of magnitude less critical for 99% of us. Choose whatever makes sense for your output medium.
Jack
-
The fact is unless you plan to butcher the image 16 bits is aplenty for anything one can throw at it in a normal workflow. And floating point is subliminally more and more part of PP.
What is PP? If it's ProPhoto then I don't see how floating point would in any way apply to it and not to all other workspaces (which it does not).
The color profile is what makes or breaks color, that's why there is something to be said for using a manufacturer's crappy software. It is intimately connected to white balance and EC. Most people underestimate this, Anders Torger docet.
The working color space is an order of magnitude less critical for 99% of us. Choose whatever makes sense for your output medium.
OK, I was just checking on what you meant by color profile because there are quite a few at play in the raw to tiff process. I would have thought that companies like Adobe, Phase One and DXO would have the knowledge by now to create camera profiles as good as the manufacturer's. But, if you're right, then this would be a good reason to stick to the proprietary raw file and not use DNG.
As a check I processed an A7RII image using Sony's raw convert and ACR. The Sony tiff was considerably punchier than the ACR image with the camera profile as Adobe Standard or Camera Standard. However, with the profile selected as one I created with DNG Profile Editor, using the Color Checker target, the two were to all intents and purposes identical (which surprised me quite a bit).
Here is a crop of the image.
(http://www.irelandupclose.com/customer/LL/Sony-v-ACR.jpg)
With the images layered above each other in Photoshop, and the top layer blend mode set to Difference, the only differences (without applying a strong levels adjustment) are due to less purple fringing in the ACR version because I removed more in it (I used a non-achromatic closeup lens).
I must say that I have been very impressed with the job that DNG Profiler does - and so incredibly easily. To me this is probably the single most important step in the raw conversion as it makes a huge difference to color fidelity.
Cheers
Robert
-
What is PP? If it's ProPhoto then I don't see how floating point would in any way apply to it and not to all other workspaces (which it does not).
Post Processing. As in any advanced plug-in.
I must say that I have been very impressed with the job that DNG Profiler does - and so incredibly easily. To me this is probably the single most important step in the raw conversion as it makes a huge difference to color fidelity.
There's your color profile. I think we have closure.
Jack
-
Following my interest with DxO's Prime noise reduction I tested with some landscapes I had photographed using ETTR exposure ideas.
I found that I could not replicate the color rendition I get with Adobe Camera RAW, and I slowly realized through reading that DxO's Color Rendering dialog is offered on this premise: "You can choose to give images shot with a DxO Optics Pro supported camera the look and feel of any other DxO Optics Pro supported camera." ( from http://www.dxo.com/us/color-rendition-profiles ).
I am disappointed to conclude that DxO has prioritized OpticsPro's internal camera/lens identification and automated decision making to the extent that it seems limited in its ability to render color when compared with Adobe Camera RAW and the custom dual illuminant camera profile that I use.
I can get acceptable, even good results with some photos with DxO Optics Pro but I can't get match the good results I get with ACR with the full variety of exposures I make and process.
I did find a work around of sorts where I disengaged almost all of OpticsPros parameters and simply run the Prime noise reduction through an "Export to Photoshop/Process as DNG and export" process. This launches Adobe Camera RAW and lets me do all the color work there. This may be be an option for me when working with noisy images, but it has soured the optimistic thought that I had perhaps learned about a superior workflow for RAW conversion.
DxO's lack of suitable color profiling for my camera makes it seem
As a reminder, my interest in learning about DxO OpticsPro was sparked by Bart's mentions that noise reduction performed before demosaicing can have benefits. I still find that idea very interesting.
-
I can get acceptable, even good results with some photos with DxO Optics Pro but I can't get match the good results I get with ACR with the full variety of exposures I make and process.
As a reminder, my interest in learning about DxO OpticsPro was sparked by Bart's mentions that noise reduction performed before demosaicing can have benefits. I still find that idea very interesting.
I've had another go at DxO noise reduction on a very high ISO image and again I got very poor results, even though I was super careful and am a bit more familiar with the package. Like you I keep going back to Lightroom and Photoshop as they are really very hard to beat, assisted with some plug-ins.
If you haven't done so, try Topaz DeNoise. It does the best job for me with high noise images. Lightroom itself isn't bad (excellent for color noise), especially if the image isn't too noisy.
I've no doubt that Bart is right that it is theoretically better to denoise before demosaic (which DxO claims to do, I think), but Jack's comment about advanced plug-ins using floating point (and possibly processing the image in linear space) most likely gets over quite a bit of this potential advantage. As Bart also mentioned, the ease of use is an important factor too, and if the differences between doing something early in the process are very minor or not noticeable, then the easier option is probably the better one. I find that DxO is painfully slow and I just couldn't see myself using it in the long run (in fact, the very slowness makes it bad because it is so time-consuming to tweak the settings and then re-render that one might well put up with a sub-optimal result rather than go through the whole process again). On the other hand, Lightroom is very fast and Topaz DeNoise is reasonably fast - and the whole suite of Lightroom, Photoshop and Topaz works perfectly and seemlessly together.
Every now and then I try other raw converters, but I have always gone back to Lightroom, because I think it's the best overall program and the claims that people make about the superiority of other raw converters doesn't stack up with my tests.
Cheers
Robert
-
Any conversions from one color space to another will potentially cause clipping, color shifts etc., so going from raw to ProPhoto, say, and then converting that to a smaller color space (which is automatic for viewing, clearly) is a bad idea IMO. So I would make as much of the color adjustments in the raw converter as possible and then go to Adobe RGB, and only make color tweaks in the tiff if necessary.
Best Practise when working with Capture One is to embed the "camera profile" when processing. This will effectively prevent clipping (by design!... since you leave your files in the source profile). And this way you'll store your TIFs in a color space that is not too large (like ProPhotoRGB).
The term "camera profile" in C1 is a bit misleading. The so called "camera profiles" are actually camera-specific table based "working spaces" (providing a neutral grey axis). Therefore you can also leave your files in the embedded "camera profiles" for further editing in Photoshop (unless you do compositings containing image content from different devices/color spaces) and first convert to any other color space with regard to specific targets (print, web, whatever...).
-
Best Practise when working with Capture One is to embed the "camera profile" when processing. This will effectively prevent clipping (by design!... since you leave your files in the source profile). And this way you'll store your TIFs in a color space that is not too large (like ProPhotoRGB).
The term "camera profile" in C1 is a bit misleading. The so called "camera profiles" are actually camera-specific table based "working spaces" (providing a neutral grey axis). Therefore you can also leave your files in the embedded "camera profiles" for further editing in Photoshop (unless you do compositings containing image content from different devices/color spaces) and first convert to any other color space with regard to specific targets (print, web, whatever...).
Are you sure about that? This C1 technical article seems to say otherwise: C1 Color Spaces (http://help.phaseone.com/en/co6/output/learn-more-about-file-formats/colors-in-capture-one.aspx?p=1)
-
Are you sure about that?
yes, I am
-
So, if I understand you correctly, the following should ideally be done before demosaicing:
- Tonal adjustments
- CA
- Color adjustments
- Deblur (do any of the raw converters currently offer this? I guess not or else you wouldn't be using Focus Magic)
- Color noise reduction
- Luminosity noise reduction (if the raw converter does a decent job of it, which LR doesn't IMO, don't know about C1)
Correct?
Robert
To this I would add, if the raw converter is correcting lens distortions such as barreling or pincushioning, perspective corrections, so that pixels are being remapped only once instead of remapping remapped pixels.
-
yes, I am
to elaborate a bit further …
Capture One’s „internal Color Space“ is actually able to produce ALL mathematically possible RGB colors … so it’s not limited to ProPhotoRGB or any other synthetical color space.
But C1 works with icc input profiles that effectively limit the gamut utilized for a given camera when editing in C1. The shape and the volume of those input profiles („camera profiles“) is very different… depending on the camera model. Some are similarly sized as AdobeRGB … some are much larger.
The thing is you will always effectively work within the boundaries of the input profile (unless you do boost the saturation in the Advanced Color Editor).
Here’s an example of a Leica M9 file (from the imaging resource site).
First the file and the respective settings in C1.
In the Base Characteristics tab you’ll see „Leica M9 Generic“ which is the input profile (the so called „camera profile“).
In the Process Recipies tab you’ll see „Embed Camera Profile“ selected.
(Attachment 01).
I’ve processed the image and opened the TIF in Chromix Color Think together with the actual „camera profile“.
The wireframe shows the Leica M9 Generic profile and the dots the colors utilized in this particular image.
(Attachment 02).
I’ve then boosted the saturation to 100% (in the „Exposure“ tab) and also applied a steep curve to intentionally oversaturate the image. The respective screenshot shows the resulting colors and again the Leica M9 Generic profile.
As you can see all colors stay within the gamut of the Leica M9 generic profile (not only in my short exercise … you can play around with any settings of your choice… and you will see that you will never exceed the gamut of the input profile).
(Attachment 03).
So… as far as clipping goes best practise is to avoid any color space conversion unless it’s really needed (for instance when you apply Color Edits on layers … in this case you have to select an output space that is suited to contain all colors utilized in the image. Personally I try to avoid using ProPhotoRGB ... Rec2020 for instance is a much better choice, IMHO).
-
to elaborate a bit further …
Capture One’s „internal Color Space“ is actually able to produce ALL mathematically possible RGB colors … so it’s not limited to ProPhotoRGB or any other synthetical color space.
But C1 works with icc input profiles that effectively limit the gamut utilized for a given camera when editing in C1. The shape and the volume of those input profiles („camera profiles“) is very different… depending on the camera model. Some are similarly sized as AdobeRGB … some are much larger.
The thing is you will always effectively work within the boundaries of the input profile (unless you do boost the saturation in the Advanced Color Editor).
So… as far as clipping goes best practise is to avoid any color space conversion unless it’s really needed (for instance when you apply Color Edits on layers … in this case you have to select an output space that is suited to contain all colors utilized in the image).
This is an important decision when going from raw to RGB, so it's worth thinking about it a bit. The logical choices are to use the camera's color space (as you suggest with C1 ... but not possible in Lightroom, say), to use a standard RGB matrix-based working space, or to use an output color space.
The matrix-based working space has obvious advantages in terms of size and smoothness and simplicity, and translates well to our (linear) monitor color spaces, so this would be the first obvious choice.
The camera color space seems to me to make little or no sense because you will never output back to your camera and its gamut may lie significantly outside that of our output devices (mainly printers and monitors).
So if you want to use a color space that absolutely maximises the printable or displayable colors then you should choose:
- sRGB if the intended output is to Web or if you know (from soft-proofing, say) that your image colors are within sRGB and will stay within sRGB.
- Adobe RGB if your monitor is near 100% Adobe RGB and you are satisfied that there are no printable colors in your image that you absolutely want (even if you can't see them on your monitor). Again you can tell this by soft-proofing.
- The output device ICC profile if you want to maximise the printable colors (bearing in mind that you need to make sure that this is a very good profile based on a large swatch, and you make sure you are working in 16 bits). Again you can make this decision with soft-proofing.
- Some generic table-based ICC profile that covers all printing devices if you don't know what your output profile will be (with the same proviso as the output device profile).
I personally think that for most images that Adobe RGB is a good choice if a simple workflow is wanted. Then for very specific images (for example reproductions of paintings with very saturated colors) the output ICC profile for the specific printer/paper could be used.
Robert
-
If you haven't done so, try Topaz DeNoise.
Thank you Robert. Yes, Topaz Denoise is the tool I usually use for denoise processing.
-
This is an important decision when going from raw to RGB
no, it is not. Going from RAW to RGB takes place in the RAW Converter. In Lightroom for example the internal color space is "Melissa-RGB" (ProPhoto-RGB primaries), in Iridient Developer the internal Color Space is ACES and in Capture One you can choose whatever you want your camera specific "internal" color space to be (by default it's the input profile provided for each camera model but you can change and/or edit the input profile). So when you talk about AdobeRGB or sRGB or so you are talking about a second conversion from RGB to RGB (from the internal Color Space of the RAW software to any other RGB color space).
So the only thing to decide is WHEN to convert to any working space (or output space). I feel much better keeping the initial RGB color space (ProPhoto-RGB in Lightroom, ACES in Iridient Developer and the "camera profile" in Capture One) as a kind of 1:1 16bit TIF copy of the processed RAW file and first convert to any other color space when need is (with regard to a specific application). I see no reason to choose a "working space" without knowing what the final target is (or what kind of editing I will apply to the file in question).
-
no, it is not. Going from RAW to RGB takes place in the RAW Converter. In Lightroom for example the internal color space is "Melissa-RGB" (ProPhoto-RGB primaries), in Iridient Developer the internal Color Space is ACES and in Capture One you can choose whatever you want your camera specific "internal" color space to be (by default it's the input profile provided for each camera model but you can change and/or edit the input profile). So when you talk about AdobeRGB or sRGB or so you are talking about a second conversion from RGB to RGB (from the internal Color Space of the RAW software to any other RGB color space).
How many times must we point out that Mellisa is not the working space in ACR/LR. Mellisa has ProPhoto primaries and an sRGB TRC and is used to compute the color readouts and histograms. The working space is unnamed and uses ProPhoto primaries and a linear TRC.
So the only thing to decide is WHEN to convert to any working space (or output space). I feel much better keeping the initial RGB color space (ProPhoto-RGB in Lightroom, ACES in Iridient Developer and the "camera profile" in Capture One) as a kind of 1:1 16bit TIF copy of the processed RAW file and first convert to any other color space when need is (with regard to a specific application). I see no reason to choose a "working space" without knowing what the final target is (or what kind of editing I will apply to the file in question).
I use ACR/LR for most of my work and agree that one should render into 16 bit ProPhotoRGB with ACR rather than trying to fit the gamut of the image into the working space (usually sRGB, Adobe RGB, or ProphotoRGB). With LR the image stays in the linear space until printing or export and, short of soft proofing, there is no good way to determine if the editing parameters place the image in the gamut of sRGB or AdobeRGB. It is true that editing may result in color that can not bee seen on the monitor or printed with available printers, but LR does have a monitor gamut warning and the Digitaldog has pointed out that if saturation adjustments produce no visible change on the monitor, one has exceeded the gamut of the monitor. Later on, you may get a better printer or monitor, so why limit your options?
Bill
-
How many times must we point out that Mellisa is not the working space in ACR/LR. Mellisa has ProPhoto primaries and an sRGB TRC and is used to compute the color readouts and histograms. The working space is unnamed and uses ProPhoto primaries and a linear TRC.
sorry for the confusion! At least the part regarding ProPhoto Primaries was correct... ;-)
-
How many times must we point out that Mellisa is not the working space in ACR/LR. Mellisa has ProPhoto primaries and an sRGB TRC and is used to compute the color readouts and histograms. The working space is unnamed and uses ProPhoto primaries and a linear TRC.
I use ACR/LR for most of my work and agree that one should render into 16 bit ProPhotoRGB with ACR rather than trying to fit the gamut of the image into the working space (usually sRGB, Adobe RGB, or ProphotoRGB). With LR the image stays in the linear space until printing or export and, short of soft proofing, there is no good way to determine if the editing parameters place the image in the gamut of sRGB or AdobeRGB. It is true that editing may result in color that can not bee seen on the monitor or printed with available printers, but LR does have a monitor gamut warning and the Digitaldog has pointed out that if saturation adjustments produce no visible change on the monitor, one has exceeded the gamut of the monitor. Later on, you may get a better printer or monitor, so why limit your options?
Bill
If you do most of your color adjustments in Lightroom then you can always go back to your raw file and do whatever tweaks you want at any time, so you won't be limiting your options and will be able to make full use of your new monitor or printer.
If you don't want to lose your Photoshop adjustments then you can use a smart object, which means you can render into any working space or output space you want, whenever you want.
I agree that if you are working in 16-bit that the choice of working space is less critical, but the wrong working space can potentially result in clipping or posterisation. I'm sure you've all seen this tutorial (and Bill, I know you know all this already (and I am not being sarcastic)), but it is nevertheless a very clear and useful summary of the issues: Cambridge In Color sRGB v ARGB (http://www.cambridgeincolour.com/tutorials/sRGB-AdobeRGB1998.htm).
At any rate, what color space you use is entirely up to you, of course. But I remember not so very long ago thinking that ProPhoto had to be better because it was larger and that Lab was even better because it was much larger still, not having a clue that I was doing all sorts of horrible things to my image.
So I think that it's a good discipline to ask oneself, before rendering an image to a color space, or converting to another color space, what the destination of this particular variant of the image is and whether or not the image gamut will fit into the intended space. For example, if the destination is going to be the web and we ask ourselves this question, then we will almost automatically do a soft-proof with gamut-warning to check that it does fit and we will be sensitive to the color shifts and clipping that may occur on the conversion if it doesn't fit (and find ways to make these less intrusive). If we do not ask ourselves the question then we are more likely to blindly convert and forget or not realize that we may end up with a poorer result than we could have done.
Of course it depends on one's workflow. In my case I will (now that I understand the issues a bit better) make the decision: web or printer, in Lightroom. If I can't then I will wait until I know what I want to do with the image, or I'll use a smart object. I think that the processing of the image is very dependent on the destination. For example, noise reduction and output sharpening will not be the same for a small web image as for a very large print on a wide-gamut printer. Other things are common, for example the bulk of tonal and color adjustments, deblur, geometric distortion, chromatic aberration correction etc. Which strongly suggests (to me) that these should be done in the raw converter if at all possible.
The Lightroom virtual copy feature is particularly nice for this because we can have a variant for each intended destination very easily. The bulk of the adjustments can be made on the master and then we can have a virtual copy for the web and one for print and we can make the final tweaks there while keeping our master intact. Then, if at a later stage we get a wonderful new printer with a much larger gamut ... well we can just make another virtual copy or modify our print virtual copy.
Which really goes back to my original topic question (which was, by the way, triggered by an article by Michael Reichmann who said "The major steps which I take in Capture One are to choose the appropriate camera profile, do a white balance, and then set black point and white point. These are the critical steps that need to be done in raw mode (my bolding). I then export the file to Lightroom for further processing. I send the file as a 16 bit TIFF. "). So I wondered if he was right or not ... and based on our discussion here I wouldn't say that he was wrong, exactly, but then again I don't think he was right either. These probably are the essential steps, but they are certainly not the only steps that would benefit (in some cases significantly) from being done pre-rendering to TIFF. Of course the choice of profile for the TIFF is itself an essential choice to be made prior to render (unless one uses C1 and chooses (unwisely IMO) to use the camera profile).
So for me it's still going to be sRGB first, Adobe RGB second, Beta RGB third ... depending on the image and the destination ... and then if I absolutely need it, ProPhoto RGB (or perhaps the printer profile if I know precisely what the printer and paper are going to be). I know that the digitaldog vehemently disagrees with this ... but it's a free country fortunately, so each of us can do what he wills :)
Robert
-
Hi,
I would perhaps think that a natural colour space may be XYZ…
On a serious note, I would say that working in a linear space is essential in order of keeping tonality changes consistent with colour, that is a change in density should not introduce a change in colour.
A nice feature in Lightroom is that we can change colour display to Lab. It is very more useful than three RGB numbers. Foremost, it decouples luminance from colour.
Best regards
Erik
How many times must we point out that Mellisa is not the working space in ACR/LR. Mellisa has ProPhoto primaries and an sRGB TRC and is used to compute the color readouts and histograms. The working space is unnamed and uses ProPhoto primaries and a linear TRC.
I use ACR/LR for most of my work and agree that one should render into 16 bit ProPhotoRGB with ACR rather than trying to fit the gamut of the image into the working space (usually sRGB, Adobe RGB, or ProphotoRGB). With LR the image stays in the linear space until printing or export and, short of soft proofing, there is no good way to determine if the editing parameters place the image in the gamut of sRGB or AdobeRGB. It is true that editing may result in color that can not bee seen on the monitor or printed with available printers, but LR does have a monitor gamut warning and the Digitaldog has pointed out that if saturation adjustments produce no visible change on the monitor, one has exceeded the gamut of the monitor. Later on, you may get a better printer or monitor, so why limit your options?
Bill
-
I would say that working in a linear space is essential in order of keeping tonality changes consistent with colour, that is a change in density should not introduce a change in colour.
is there any RAW-Converter that does NOT work in a linear space?
-
(http://)Quote "I would perhaps think that a natural colour space may be XYZ…
https://www.flickr.com/photos/baxter43/5355713456/in/album-72157625678052039/On a serious note, I would say that working in a linear space is essential in order of keeping tonality changes consistent with colour, that is a change in density should not introduce a change in colour." end quote.
I have worked with several different raw converters and each and every one including ACR / LR; SilkPix; Capture One; DxO Labs; Olympus Viewer (my cameras software); DC Raw etc all produce different colour renditions. i.e. do a test shot with a GreyTag Macbeth Colour target and do a WB on the neutral patch then check the other colour patches and you will not see that none match. i.e. each and every raw conversion software applies their own colour profile (recipe).
-
So for me it's still going to be sRGB first, Adobe RGB second, Beta RGB third ... depending on the image and the destination ... and then if I absolutely need it, ProPhoto RGB (or perhaps the printer profile if I know precisely what the printer and paper are going to be).
on the one hand you are asking what's essential in RAW-processing ... on the other hand you won't use the full potential of a RAW processor by choosing totally irrelevant and dated icc Profiles that also may be too small to contain the all information contained in the RAW file.
sRGB refers to the gamut of TV-Monitors. However, it has its justification even today as you can regard it as the smallest denominator of color management... and images converted to sRGB do look "reasonable" on most computers even in applications without color management since many computer monitors have a gamut similar to sRGB (yet). AdobeRGB once was intended as a prepress color space but the color space actually has nothing to do with the gamut of real printers (it's a pure academic color space) and above all the Gamma 2.2 is the worst choice of an TRC with regard to a prepress workflow (at least in 8bit). Now, and BetaRGB was a very good concept for a working space encompassing the colors of different film types and all printable colors but I suspect the profile will never be updated to ICC-V4 specs. Too, its gamut is very similar to Rec2020 and therefore I would use Rec2020 as it's more common.
There are soooo many applications images may be used in today that it doesn't make sense to process an image with regard to a certain target in the first place. It makes much more sense to process a photo so that it contains all relevant data (a processed 1:1 copy of the adjusted RAW-file, if you want so...). And then convert to a certain color space with the help of gamut warning and the Info-Platte in Photoshop (or elswhere).
Just for reference... here's a recommendation of the ICC: http://www.color.org/prmg_gamutwarning.xalter ->
The ICC recommends the use of the ISO22028-2_ROMM-RGB.icc profile as the PRM working space and exchange encoding, and the PRMG_RGB-sRGB_based.icc profile as a gamut warning profile to check for the use of ROMM RGB colors outside the PRMG.
If you think about it I would say a reasonable advise is to use a color space for "original photos" that does at least encompass the Perceptual Reference Medium Gamut. You don't have to use ProPhoto-RGB (said ISO22028-2_ROMM-RGB profile is a ICC-V4 version of ProPhoto-RGB)... but AdobeRGB will certainly not do... If I would work with Lightroom (or ACR) I would defenitely process to ProPhoto-RGB and would convert the "original file" to any other color space in Photoshop (again: with the help of the gamut warning tool and the Info-Platte).
-
So I think that it's a good discipline to ask oneself, before rendering an image to a color space, or converting to another color space, what the destination of this particular variant of the image is and whether or not the image gamut will fit into the intended space.
In an Adobe raw workflow, doesn't matter! Use ProPhoto RGB:
sRGB urban legend Part 1
In this 30 minute video I'll cover:
Is there benefit or harm using a wider color gamut working space than the image data?
Should sRGB image data always be encoded into sRGB?
What are RGB working spaces and how do they differ?
What is Delta-E and how we use it to evaluate color differences.
Color Accuracy: what it really means, how we measure it!
Using Photoshop to numerically and visually see color differences when using differing working spaces.
Using ColorThink Pro and BableColor CT&A to show the effects of differing working space on our data and analyzing if using a smaller gamut working space is necessary.
Appendix: testing methodology, how differing raw converters encode into working spaces, capturing in-camera JPEG data and color accuracy.
Low resolution (YouTube): https://www.youtube.com/watch?v=1w0zUIl-dzY (https://www.youtube.com/watch?v=1w0zUIl-dzY)
High resoution: http://digitaldog.net/files/sRGBMyths.mp4 (http://digitaldog.net/files/sRGBMyths.mp4)
-
In an Adobe raw workflow, doesn't matter! Use ProPhoto RGB:
sRGB urban legend Part 1
In this 30 minute video I'll cover:
Is there benefit or harm using a wider color gamut working space than the image data?
Should sRGB image data always be encoded into sRGB?
What are RGB working spaces and how do they differ?
What is Delta-E and how we use it to evaluate color differences.
Color Accuracy: what it really means, how we measure it!
Using Photoshop to numerically and visually see color differences when using differing working spaces.
Using ColorThink Pro and BableColor CT&A to show the effects of differing working space on our data and analyzing if using a smaller gamut working space is necessary.
Appendix: testing methodology, how differing raw converters encode into working spaces, capturing in-camera JPEG data and color accuracy.
Andrew,
I looked at your video and found it well done and informative. Thanks for producing it. Without reviewing the video, I am not sure if your tests were done in 8 bit or 16 bit (15+1 in Photoshop). One would expect greater rounding errors in 8 bit. You do advise rendering into 16 bit ProPhoto, but what happens if you render into 8 bit? Some gurus say the differences between the larger and smaller color spaces could be exaggerated with drastic edits, even if clipping is avoided. Of course, a drastic edit would produce ΔEs from the reference image, so an accuracy criterion would no longer be applicable even if reference values were available.
Some gurus advocate editing in 32 bit floating point in specialized software. As far as I know PS, ACR, and LR edit internally in 16 bit, and does this make any practical difference.
These topics are interesting, but for practical work I find using 16 bit ProPhotoRGB is very satisfactory and this is what I use.
Regards,
Bill
-
(http://)Quote "I would perhaps think that a natural colour space may be XYZ…
https://www.flickr.com/photos/baxter43/5355713456/in/album-72157625678052039/On a serious note, I would say that working in a linear space is essential in order of keeping tonality changes consistent with colour, that is a change in density should not introduce a change in colour." end quote.
I have worked with several different raw converters and each and every one including ACR / LR; SilkPix; Capture One; DxO Labs; Olympus Viewer (my cameras software); DC Raw etc all produce different colour renditions. i.e. do a test shot with a GreyTag Macbeth Colour target and do a WB on the neutral patch then check the other colour patches and you will not see that none match. i.e. each and every raw conversion software applies their own colour profile (recipe).
Which is pretty bad in this day of nearly end-to-end color management. It should be possible to photograph a color checker, say, in defined, controlled lighting conditions with a specified lens, ISO, raw ... and get pretty much identical results from all raw converters. At least then we would be starting from a known point.
I can understand that for JPEGs that the conversion should reasonably aim for a pleasing rather than an accurate look, but surely one of the advantages of raw should be that we can get more color accuracy.
The XRite Color Checker Passport and Adobe DNG Profile Editor do a fairly decent job (but on a very small target, so not very accurate). One could use Argyll CMS for example to create a proper icc file - but then one would have to use a raw converter that supports icc profiles. I'm not sure it's worth the bother, but I haven't tried it ... it would be interesting to get some feedback from someone who has.
Robert
-
Which is pretty bad in this day of nearly end-to-end color management. It should be possible to photograph a color checker, say, in defined, controlled lighting conditions with a specified lens, ISO, raw ... and get pretty much identical results from all raw converters. At least then we would be starting from a known point.
Hi Robert,
And that would be possible if the profiles were made for 'accurate' color, which they aren't in general. Profiles are a compromise, because the camera sensor CFAs see color different from how our eyes see color. In that translation/compromise, usually a kind of 'look' is used by the various producers, and that produces generally pleasing colors with somewhat smooth transitions, but not colorimetrically accurate.
I can understand that for JPEGs that the conversion should reasonably aim for a pleasing rather than an accurate look, but surely one of the advantages of raw should be that we can get more color accuracy.
And we can, but we then need to create specific profiles for specific goals.
Cheers,
Bart
-
Hi Robert,
And that would be possible if the profiles were made for 'accurate' color, which they aren't in general. Profiles are a compromise, because the camera sensor CFAs see color different from how our eyes see color.
Isn't that the whole idea behind color management, to translate between different devices and their foibles and to end up with an image that looks right to our eyes, on screen or printer ... and which is colorimetrically correct if we choose a colorimetric profile?
I suppose one thing we could do with raw converters that do not support icc profiles is to make an icc profile and assign it to the image once in TIFF. But that would mean that all color adjustments would have to be done post raw.
Cheers,
Robert
-
Out of interest I made a matrix camera profile using ArgyllCMS and used this in DxO Optics Pro with very good results. Admittedly this was based on the 24-patch colorchecker, so it can't be very accurate. Still, here's the colorchecker with the profile applied:
(http://www.irelandupclose.com/customer/LL/cc-profile.jpg)
and here is an image processed using C1 with the Argyll profile:
(http://www.irelandupclose.com/customer/LL/C1-Argyll .jpg)
Certainly every bit as good as Lightroom with a DNG profile.
I basically used the process here (simplified): SteveHuff-Camera-Profiling (https://stephenstuff.wordpress.com/2012/07/06/digital-camera-profiling-with-raw-therapee-and-argyll-cms/)
with these commands:
scanin -v -a -G1 -dipn A7RIICC.tif ref\ColorChecker.cht ref\ColorChecker.cie
colprof -v -A“Sony” -M“A7RII” -D“Sony A7RII Overcast Matrix” -qm -am -nc -U1.47 A7RIICC
So this makes either C1 or DxO much more interesting for me.
Robert
-
In an Adobe raw workflow, doesn't matter! Use ProPhoto RGB:
sRGB urban legend Part 1
In this 30 minute video I'll cover:
Is there benefit or harm using a wider color gamut working space than the image data?
Should sRGB image data always be encoded into sRGB?
What are RGB working spaces and how do they differ?
What is Delta-E and how we use it to evaluate color differences.
Color Accuracy: what it really means, how we measure it!
Using Photoshop to numerically and visually see color differences when using differing working spaces.
Using ColorThink Pro and BableColor CT&A to show the effects of differing working space on our data and analyzing if using a smaller gamut working space is necessary.
Appendix: testing methodology, how differing raw converters encode into working spaces, capturing in-camera JPEG data and color accuracy.
Low resolution (YouTube): https://www.youtube.com/watch?v=1w0zUIl-dzY (https://www.youtube.com/watch?v=1w0zUIl-dzY)
High resoution: http://digitaldog.net/files/sRGBMyths.mp4 (http://digitaldog.net/files/sRGBMyths.mp4)
Hi Andrew. As usual, a nice video and useful if you are someone who believes whoever it is who said that colors in one color space are colorimetrically more accurate than in another.
Of course that isn't the issue at all ... it is because a wider gamut, given the same image bit-depth, will have greater interpolation errors. That's a simple mathematical fact. So if the image gamut fits into a smaller color space, then all things being equal it's preferable to use the smaller color space. Admittedly this isn't so much of an issue with 16 bits.
Also, if your destination is for the web then you will sooner or later have to convert to sRGB. If you are working in a color space with a much larger gamut there is a very real risk of clipping (which can be adjusted for with soft-proofing, but the potential need for adjustment will always be present). So if you know that your image is going to the web then you are better rendering it to sRGB than going to the wider-gamut color space first. In addition, every time you convert an image from one color space to another you will introduce color shifts.
Again, if your monitor is 100% (or thereabouts) Adobe RGB, you are better being in Adobe RGB or sRGB as wider color spaces allow you to make adjustments to your image that are not visible (or rather, they will be automatically mapped to monitor RGB).
If your image has colors which are beyond Adobe RGB (easily seen by soft-proofing in Lightroom, for example) but are capable of being printed (again, you can see this with soft-proofing), well then by all means use a larger color space like Beta RGB or ProPhoto. But then you do need to know what you are doing to avoid (potentially) ugly results on print.
So it's a question of using the right tools for the job. If the desire is to simplify the workflow and to minimize the risk of artifacts then Adobe RGB is probably the best choice (at this point in time) for most of us with our Adobe RGB monitors. If our images are always going to go to the web and not to print then we would be well advised to stick to sRGB. If we typically have quite saturated images and wish to get the most saturated colors from our printer, well then a working space like ProPhoto might be the best choice for us. If, like me, you're quite happy to process images differently for different output ... well then use all three.
Cheers,
Robert
-
Out of interest I made a matrix camera profile using ArgyllCMS and used this in DxO Optics Pro with very good results. Admittedly this was based on the 24-patch colorchecker, so it can't be very accurate.
it is not like LUT profile, so 1000 patches will not give a magnitude better quality level vs a properly done process with CC Classic Mini.
-
it is not like LUT profile, so 1000 patches will not give a magnitude better quality level vs a properly done process with CC Classic Mini.
No, that's not correct (although for sure a badly done profile with lots of patches may well be worse than a well done profile with few patches). 24 patches just doesn't have enough colors (only two blues, for example). It's just OK because digital cameras are essentially linear (as far as I know, that is).
-
No, that's not correct (although for sure a badly done profile with lots of patches may well be worse than a well done profile with few patches). 24 patches just doesn't have enough colors (only two blues, for example). It's just OK because digital cameras are essentially linear (as far as I know, that is).
"Alter Ego's" post was not so much about the number of patches but primarily about matrix based vs. table based profiles ...
Again, if your monitor is 100% (or thereabouts) Adobe RGB, you are better being in Adobe RGB or sRGB as wider color spaces allow you to make adjustments to your image that are not visible (or rather, they will be automatically mapped to monitor RGB).
when the monitor gamut is the reason to choose a color space for editing... why don't you just use your monitor profile as working space?
-
Of course that isn't the issue at all ... it is because a wider gamut, given the same image bit-depth, will have greater interpolation errors. That's a simple mathematical fact.
Fortunately the math also illustrates the differences are not visible.
-
24 patches just doesn't have enough colors (only two blues, for example). It's just OK because digital cameras are essentially linear (as far as I know, that is).
sure, if you want to start accounting for various nonlinear possibilities then even 3 x 1D TRCs, per channel (in matrix profiles) will not be enough (as you deal with raw data after demosaicking) and you will need 3D LUT to account fully... so no, you will not get a magnitude better matrix profile with CCSG or CCDC or custom made target vs CC24 for 3x3 matrix and if you want to account for exposure-based non linearities in you might as well try do bracketing when shooting CC24 ;) but you still get restricted by just 3x3 matrix part that stays the same... too few degrees of freedom
-
Fortunately the math also illustrates the differences are not visible.
in your particular test, yes. Might be different if you did the same experiment with high saturated colors in a large color space. Who knows...
The "higher precission" of smaller color spaces comes into play when editing... IMHO. In a smaller color space you can make more subtle edits. On the other hand I have yet to see any limitations when editing in a larger color space in 16bit. So the debate whether larger color spaces are less precise or not is pretty academic to me personally... Much more important is workflow-discipline when working with large color spaces (especially those containing imaginary colors) - if you use a certain color space as a gamut warning profile when editing (PRMG, PhotogmutRGB or, if you whish, sRGB) nothing can go really wrong... IMHO...
-
it is not like LUT profile, so 1000 patches will not give a magnitude better quality level vs a properly done process with CC Classic Mini.
Have you actually tried this? You may be right, but I would have thought that the CC Mini just doesn't have enough colors to give the 3 primaries accurately .. or to compute the TRC accurately (unless it is valid to assume that the camera response is entirely linear, which this article suggests that it is not Camera Linearity (http://www.ncbi.nlm.nih.gov/pmc/articles/PMC3832603/)).
-
when the monitor gamut is the reason to choose a color space for editing... why don't you just use your monitor profile as working space?
Because my monitor is not linear and uses a LUT - a working space like ProPhoto or Adobe RGB should give me smoother gradients.
-
Fortunately the math also illustrates the differences are not visible.
True, providing we work in 16 bits, of course. It's also true that for photos that are not highly saturated that the differences between sRGB, say, and ProPhoto will not be visible either.
Do you see an advantage in working in ProPhoto because it uses a D50 white point? I would have thought so as there would be no need to transform from the raw converter white point (in most cases D50, I guess). Which reminds me that this was one of the reasons I used Beta RGB: it has a D50 white point and is big enough for most photos without being over-bloated like ProPhoto.
The choice to me is that if I had to pick one and only one working space then I would most likely pick Beta RGB (or possibly ProPhoto as it's more widely used). But I don't have to pick one working space and so if I'm developing a photo for the Web, say, I think it makes sense to use sRGB. For print I will go back to Beta RGB (although I have been using Adobe RGB recently, mainly because it avoids me having to worry about colors that are not visible on my monitor)
-
Have you actually tried this? You may be right, but I would have thought that the CC Mini just doesn't have enough colors to give the 3 primaries accurately
with matrix profile you can't get a better precision in 3x3 matrix just by throwing more patches, more so by throwing more patches of the similar hues... you add more patches you change 3x3 matrix and as a result for some colors dE-whatever metric will get better and for some will actually get worse 8) ... so you want to select actually just few important colors and find a good compromise between errors when building the matrix...
-
in your particular test, yes. Might be different if you did the same experiment with high saturated colors in a large color space. Who knows...
Might be different, doubtful considering the dE report of the thousands upon thousands of pixel (device values) who's dE differences in using either end of the working space gamut spectrum (sRGB vs. ProPhoto RGB) are tiny and invisible. Of course, you're encouraged to provide example images and dE reports that show otherwise.
-
True, providing we work in 16 bits, of course.
That's the only way I fly and the only way my raw converters provide data from raw when correctly setup for rendering the data!
It's also true that for photos that are not highly saturated that the differences between sRGB, say, and ProPhoto will not be visible either.
Exactly, so just stick with ProPhoto RGB! It's no worse and often far better WHEN the data exceeds sRGB (which is pretty often in these parts).
-
The choice to me is that if I had to pick one and only one working space then I would most likely pick Beta RGB (or possibly ProPhoto as it's more widely used). But I don't have to pick one working space and so if I'm developing a photo for the Web, say, I think it makes sense to use sRGB. For print I will go back to Beta RGB (although I have been using Adobe RGB recently, mainly because it avoids me having to worry about colors that are not visible on my monitor)
There are soooo many applications images may be used in today that it doesn't make sense to process an image with regard to a certain target in the first place. It makes much more sense to process a photo so that it contains all relevant data (a processed 1:1 copy of the adjusted RAW-file, if you want so...). And then convert to a certain color space with the help of gamut warning and the Info-Platte in Photoshop (or elswhere).
Robert and Tho_mas use two different approaches. If one is performing a simple rendering without much editing, then it could make sense to do a rendering suitable for the intended use of the image. However, if one is going to spend considerable time working with the image, it makes sense to render it with maximal quality so as to make a master image and then adapt the master image to any intended purpose. 16 bit ProPhotoRGB would be a good choice for the master image, and sRGB would be too limited.
If one is using a parametric editor such as Lightroom, the editing is done in a wide gamut space and one is in effect working on the master image. Choice of the output space and resizing and output sharpening are deferred until export.
Bill
-
Might be different, doubtful considering the dE report of the thousands upon thousands of pixel (device values) who's dE differences in using either end of the working space gamut spectrum (sRGB vs. ProPhoto RGB) are tiny and invisible. Of course, you're encouraged to provide example images and dE reports that show otherwise.
I was just thinking out loud. As said above I have no reservations working with large color spaces nor do I have the desire to provide evidence for irrelevant deviations... Quite the opposite I've repeatedly suggested to output to the respective "internal" color space RAW converters are effectively working in...
-
However, if one is going to spend considerable time working with the image, it makes sense to render it with maximal quality so as to make a master image and then adapt the master image to any intended purpose. 16 bit ProPhotoRGB would be a good choice for the master image, and sRGB would be too limited.
If one is using a parametric editor such as Lightroom, the editing is done in a wide gamut space and one is in effect working on the master image. Choice of the output space and resizing and output sharpening are deferred until export.
Exactly! Plus the LR/ACR engine uses ProPhoto RGB (Primaries, color gamut).
-
if one is going to spend considerable time working with the image, it makes sense to render it with maximal quality so as to make a master image and then adapt the master image to any intended purpose.
isn't that exactly what a RAW-workflow is all about? Of course "maximal quality" has little to do with high saturation. In fact a lot of real world photos would fit into sRGB. But "maximal quality" of course has to do with avoiding any color clipping... and the best way to avoid clipping is to avoid color space conversions... so to keep the initial color space.
As far as conversions to smaller gamuts go there are some pretty decent profiles that allow an almost "automated" workflow... the ICC PRMG profile, PhotogamutRGB and the ICC sRGB-Appearance profile for example...
16 bit ProPhotoRGB would be a good choice for the master image, and sRGB would be too limited.
16bit ProPhoto is the obvious choice for an Adobe workflow. Basically: The internal color space of the respective RAW converter is preferable.
As a general "working space" personally I do favor a "device independant" working space that is large enough to contain all theoretically printable colors but that does not contain imaginary colors... Rec2020 with an LStar-TRC for example (which is what I use... if I use a "working space" at all...).
-
As a general "working space" personally I do favor a "device independant" working space that is large enough to contain all theoretically printable colors but that does not contain imaginary colors... Rec2020 with an LStar-TRC for example (which is what I use... if I use a "working space" at all...).
Rec2020 primaries are reasonable and cover the Pointer gamut. A LStar-TRC is reasonable, but offers little advantage over the sRGB TRC as Bruce Lindbloom demonstrated in his post describing his BetaRGB. Rec2020 uses a white point of 6500K, which necessitates WB conversions with many profiles using 5K as the white point.
Is a Rec2020 profile with your characteristics available for download and use with Photoshop? Personally, I am satisfied with ProPhotoRGB for my own work and see little reason to change.
Regards,
Bill
PS
Here is a good link (https://forums.adobe.com/thread/1419036?start=0&tstart=0) regarding the Rec2020 gamut.
-
That's the only way I fly and the only way my raw converters provide data from raw when correctly setup for rendering the data!
Exactly, so just stick with ProPhoto RGB! It's no worse and often far better WHEN the data exceeds sRGB (which is pretty often in these parts).
You wouldn't have shares in ProPhoto by any chance?
BTW ... what is 'incorrect' about setting up the raw converter to render to 8 bits? If there is indeed something fundamentally wrong then perhaps you should tell Adobe as they offer this option in Lightroom.
-
Hi,
That would be shares in Eastman Kodak. Pretty worthless these days, I would guess.
Best regards
Erik
You wouldn't have shares in ProPhoto by any chance?
-
Robert and Tho_mas use two different approaches. If one is performing a simple rendering without much editing, then it could make sense to do a rendering suitable for the intended use of the image. However, if one is going to spend considerable time working with the image, it makes sense to render it with maximal quality so as to make a master image and then adapt the master image to any intended purpose. 16 bit ProPhotoRGB would be a good choice for the master image, and sRGB would be too limited.
Exactly, we are using different approaches and it would be incorrect to say that one approach is right while the other is wrong.
There is absolutely nothing wrong with doing final editing in workspace x rather than workspace y, assuming that the only difference between them is the gamut, and providing the image gamut (plus editing adjustments) fits into the workspace (or we are content to shrink it to fit). But even if these do not hold, all one could say is that workspace x may be preferable to workspace y.
What is wrong is to recommend a very large workspace like ProPhoto without being VERY clear on the things to watch out for. A novice user is very likely to blow the output device gamut and end up with an ugly image with banding or other artifacts and not know why.
Expert users know what they are doing and so they can make an informed choice and take the appropriate precautions (and know how to).
Equally, if you intend to make a great deal of adjustments to your image but you know that the image gamut will never exceed sRGB, say, then what is wrong with using sRGB? If at a later stage you decide to make a collage, for example, with another highly saturated image ... well then move over to ProPhoto or BetaRGB, or whatever floats your boat.
There may be advantages in a D50 color space if the intended output is to print and one's monitor is calibrated to D50 ... but then again, if the intended output is to web then there may be an advantage in using sRGB and calibrating your monitor to D65 and sRGB. But, by and large, I think color management deals with issues pretty well so I for one won't lose too much sleep over it.
Cheers
Robert
-
Hi,
That would be shares in Eastman Kodak. Pretty worthless these days, I would guess.
Best regards
Erik
hmmm ... I guess I'll give ProPhoto a miss then. Pity :)
-
If there is indeed something fundamentally wrong then perhaps you should tell Adobe as they offer this option in Lightroom.
They've taken care of this for all of us:
(http://digitaldog.net/files/Lightroom_Edit_In.jpg)
-
They've taken care of this for all of us:
(http://digitaldog.net/files/Lightroom_Edit_In.jpg)
I hope you're not printing at 240ppi!!
-
Hi,
I'm a Lightroom user normally, but having changed from Canon to Sony recently I decided to have a look at Capture One as CO is the free raw converter for Sony cameras. Also, because so many people say that CO is WAY better than LR at raw conversion.
I've done some tests between LR and CO, doing nothing but white balance, white point, black point and color noise reduction. Comparing a number of images I see no advantage to either detail-wise. There is some color difference and slight contrast difference which is better with one converter on some images and better with the other converter on other images, but the differences are easily adjusted in the raw converters themselves, or in post-processing.
With some structure added in CO there is a marked improvement detail-wise, but this is easily compensated on the LR tiff with Topaz Detail3 (for example).
Which leads me to my question. Does anyone know what are the adjustments that absolutely should be done in the raw converter, and which are just as well done in post processing?
My assumption has been that the only adjustments that should be done in the raw converter are white balance and white/black point, and that everything else (noise reduction, sharpening, color adjustments, chromatic aberration, color fringing etc.,) can all be left to post-processing. I have no other reasons to believe that this is correct except that my tests seem to bare out the assumption. For example, opening an image in ACR with tonal adjustments and comparing it to the same image that has been opened without tonal adjustments (save for white point / black point) but then processed using the Camera Raw filter with exactly the same settings, shows only very slight differences, only just visible at 1:1 (very slight sharpness difference, slight contrast difference, slight color differences).
This isn't a Capture One v Lightroom question as clearly each has strengths. If my assumption that only basic tonal adjustments should be done in the raw converter is wrong then I would probably use CO for the raw conversion and other basic adjustments, retaining Lightroom for all the other features. On the other hand, if the bulk of adjustments can be left to post-processing, then I would stick to LR as I can do pretty much everything I want with LR + PS (and plug-ins).
I appreciate your advice!
Robert
Robert
Late to this party, but IMHO, you generally want to get the image as close to finished as possible in the RAW conversion process. That said, there are times when it is just easier or more practical or only possible, depending on the image correction that needs addressed, to do it post conversion.
-
Is anyone using the lovely spaces created by Joseph Holmes? I had used his Ekta Space for years, a gig recently had me revisit and discover his DCam spaces with bespoke tone curve. I have been using since and find them exceptional – his chroma variants are genius. Welcome any thoughts with others experiences… Have never understood why in the ACR pipeline I can render out to whatever I like, but in the LR pipeline I am limited to only three spaces.
http://www.josephholmes.com/propages/AboutRGBSpaces.html
-
Rec2020 primaries are reasonable and cover the Pointer gamut. A LStar-TRC is reasonable, but offers little advantage over the sRGB TRC as Bruce Lindbloom demonstrated in his post describing his BetaRGB. Rec2020 uses a white point of 6500K, which necessitates WB conversions with many profiles using 5K as the white point.
Is a Rec2020 profile with your characteristics available for download and use with Photoshop? Personally, I am satisfied with ProPhotoRGB for my own work and see little reason to change.
Regards,
Bill
PS
Here is a good link (https://forums.adobe.com/thread/1419036?start=0&tstart=0) regarding the Rec2020 gamut.
Hi Bill,
re TRCs:
I guess we are in agreement that in a high bit RGB workflow we can work with and exchange different TRCs without encountering banding issues...
However, when we think about TRCs and keep in mind the device-dependend origin of the different TRCs (Gamma 2.2 comes from TV/CRT monitors, Gamma 1.8 is more similar to the distribution of luminance in offset prints etc.) there are two TRCs that match the needs of color managed image editing better than the others (IMHO!):
- a linear TRC as it is the only TRC that assures error-free color blending
- LStar as it is perceptually uniform – see attachment – and that reduces rounding errors to the mathematically possible minumum (since it uses the distribution of luminance of Lab)
Again... I think all TRCs work fine in a high bit workflow... but I've been using LStar ("ECI-RGB V2") for years and also my monitor is calibrated to LStar for image editing. So this is simply what I personally prefer... and what makes so the most sense to me...
re D65:
As far as the white point goes I think as photographers we don't use absolut colormetric but perceptual and relative colormetric intends for conversions. Too, the ICC-V4 specs require chromatic adaption to D50 for dislayclass profiles ... this is why V4- monitor profiles are actually specified as being D50. Also doesn't matter when softproofing. So I don't think the D65 WP of Rec2020 is a disadvantage... or comes into play at all in any workflow.
A great source for different sets of ICC Profiles (all in V2 and V4 specs) is here:
http://ninedegreesbelow.com/photography/lcms-make-icc-profiles.html
The guy is just about to release a new set of profiles with revised rec709-TRCs, V2-profiles will be „true“ V2 profiles and all profile sets will contain all TRCs (linear, 1.8, 2.0. 2.2, sRGB, rec709, LStar [„labl“]). So there you also get for instance ProPhotoRGB („Large RGB“) with an sRGB-TRC and an LStar-TRC ...
P.S.: another informative site about Rec2020 and the so called "Pointer's Gamut": http://www.tftcentral.co.uk/articles/content/pointers_gamut.htm
-
What is wrong is to recommend a very large workspace like ProPhoto without being VERY clear on the things to watch out for. A novice user is very likely to blow the output device gamut and end up with an ugly image with banding or other artifacts and not know why.
100% agree!
Equally, if you intend to make a great deal of adjustments to your image but you know that the image gamut will never exceed sRGB, say, then what is wrong with using sRGB?
nothing is wrong - that's perfectly fine! Now, let's say you have an image that fits into sRGB except for some slightly higher saturated cyan tones. Then you'll process and store it in, say, AdobeRGB. That's fine, too! Next image fits into sRGB except for some slightly higher saturated cyan tones and some slightly higher saturated red tones. Then you'll process and store it in, say, ECI-RGB. That's fine, too! The next image has overall a slightly higher saturation and so you'll process and store it in, say, Hasselblad-RGB. The next image in Rec2020. And the next image in ProPhoto-RGB. And the next image in ACES. That's all fine!
So you have to watch out for every single image that you process in what intermediate color space it may fit. Why?
The other way around...: you make a great deal of adjustments to your image and you know that the image gamut will never exceed sRGB - why not still store it in the actual color space of your RAW-software (where it comes from in any case!) and save it as 1:1 copy of your "original" adjusted RAW-file? Keeping the source profile doesn't hurt :-) And you will store all your "originals" in the very same source-colorspace and first convert to something else by application.
-
nothing is wrong - that's perfectly fine! Now, let's say you have an image that fits into sRGB excpet for some slightly higher saturated cyan tones. Then you'll process and store it in, say, AdobeRGB. That's fine, too! Next image fits into sRGB excpet for some slightly higher saturated cyan tones and some slightly higher saturated red tones. Then you'll process and store it in, say, ECI-RGB. That's fine, too! The next image has overall a slightly higher saturation and so you'll process and store it in, say, Hasselblad-RGB. The next image in Rec2020. And the next image in ProPhoto-RGB. And the next image in ACES. That's all fine!
So you have to watch out for every single image that you process in what intermediate color space it may fit. Why?
I think you're exaggerating a bit :). Three workspaces would be entirely enough and so would be two (sRGB and BetaRGB would be my choices).
There is no reason to use this workflow if you don't want to. The reason I use it is because I aim my workflow to the destination. So I don't (in general) process my images in the same way for print and web. It also keeps me focused on the image gamut and where it is going to end up. If I go straight to a very large workspace, after a while I find that I get lazy and just press buttons and don't even bother to soft-proof. If I constantly keep the destination in mind then this doesn't happen, and I find that my images end up being better.
What makes this relatively easy is that so much can be done in the raw converter - and of course I will always keep my raw images with their develop settings. It is true that if I know that I need to do a lot of editing of the image in Photoshop + plug-ins that I will go for the larger gamut working space and then target the destination, simply to avoid having to do the work twice. However there are things that do (or may) need to be done twice anyway, for example denoise and output sharpen.
You have to remember that I use smart objects, so that I can open the image from LR to Photoshop as a smart object, do things like capture sharpen and some basic corrections that I couldn't do in LR (some adjustment layers say), and then convert to my destination. As this involves setting the profile in ACR I have the advantage of being able to choose any profile I want (which I cannot do in LR). So I can even convert to my printer profile if I wish (and of course in that case turn of color management in the print driver).
Alternatively I can use virtual copies in Lightroom if that makes more sense for a particular set of images as I've mentioned before.
Whatever you do, if you want to optimize your colors you will need to keep color management in mind constantly. If you always go to ProPhoto, say, then you should really have soft-proofing turned on all the time, pretty much, unless you are prepared to make corrections right at the very end of your workflow, prior to output to web or printer (which really is far too late IMO). And if you are targetting both web and print then you will need to constantly flip your soft-proofing from sRGB to your print profile. If that's how you want to work then that's totally fine ... there's nothing wrong with it and there's no reason why an image processed using your workflow would be any better or worse than one processed by my workflow. It's just a question of preference and what works best for you.
The other way around...: you make a great deal of adjustments to your image and you know that the image gamut will never exceed sRGB - why not still store it in the actual color space of your RAW-software (where it comes from in any case!) and save it as 1:1 copy of your "original" adjusted RAW-file? Keeping the source profile doesn't hurt :-) And you will store all your "originals" in the very same source-colorspace and first convert to something else by application.
I take it you mean the camera profile, in the case of Capture One or DxO, say? You can't do this if Lightroom is your raw processor as I'm sure you know. If the camera profile is matrix-based and is a good one ... well there would be no fundamental reason that I can think of. It wouldn't suit me because I work towards the destination but it would be fine for your workflow. If the camera profile is table-based then you would need to make sure that it's a very good profile based on a large swatch or you will likely get interpolation errors. Cheers,
Robert
-
Whatever you do, if you want to optimize your colors you will need to keep color management in mind constantly. If you always go to ProPhoto, say, then you should really have soft-proofing turned on all the time, pretty much
I do have gamut warning turned on all the time! I do activate the gamut warning for my monitor profile by default (I don't edit to match my monitor profile, of course, but I want to "see" what I can't see on my monitor :-) ... ) ... and towards finishing I do activate the gamut warning for the PRMG (again just to check... not to edit everything into the PRMG).
I take it you mean the camera profile, in the case of Capture One or DxO, say? You can't do this if Lightroom is your raw processor as I'm sure you know.
I am absolutely sure that the internal color space of ACR/Lightroom is ProPhoto primaries ... so this is what you are effectively editing in all the time in these two softwares! Setting sRGB for the output does not (!) map everything into sRGB - it's just a relative colormetric conversion from ProPhoto (-primaries) to sRGB! And exactly this is the reason why I would do any colorspace conversion in Photoshop (as it provides more control). Okay, in Lightroom you could process to the sRGB Appearance profile (http://color.org/profiles/srgb_appearance.xalter) using perceptual intend - in this case everything would be mapped into sRGB ... but I suspect this is not what you are doing...
If the camera profile is matrix-based and is a good one ... well there would be no fundamental reason that I can think of. It wouldn't suit me because I work towards the destination but it would be fine for your workflow. If the camera profile is table-based then you would need to make sure that it's a very good profile based on a large swatch or you will likely get interpolation errors.
In Capture One all "camera profiles" are table based. And the RAW data gets not converted into these color spaces - the color spaces get assigned to RAW-data! Therefore - by design - it is technically impossible to get clipping in C1 as long as you don't exhaust the color space by unleashed editing (but you would see it in the histogram) and as long as you embed the "camera profile" on export. The design-idea of C1 is very different to Lightroom/ACR... however, the relation of "internal color space" and output color space is basically the same in all RAW converters...
-
Hi,
Regarding the colour space, what you see is limited by the colour space of your monitor. Colours outside that gamut will not be correctly rendered on screen. I don't know if ICC profiles have perceptual rendering intent for display. As far as I know V2 display profiles clip, but V4 may have a rendering intent for displays. Someone may chime in to clarify.
So, what colours that can be viewed depends on the monitor used. Rec 2020 is the recommended standard for 4K as far as I know.
Anyway, working in a wide colour space means that there will be colours that you can manipulate but not observe. Using soft proof in Lightroom will indicate such colours.
Best regards
Erik
-
Hi,
Using Capture One 9.0.2 I try to export a TIFF with embedded camera profile, so I can check it out in ColorThink but it embeds Adobe RGB.
Any way to embed the Camera ICC? I am working with an IQQ file from my P45+
Best regards
Erik
-
Regarding the colour space, what you see is limited by the colour space of your monitor.
to be more precise: colors are limited by the actual hardware (the monitor) ...
Colours outside that gamut will not be correctly rendered on screen.
to be more precise: colors outside of the monitor's gamut will not be displayed at all ...
;-)
Using Capture One 9.0.2 I try to export a TIFF with embedded camera profile, so I can check it out in ColorThink but it embeds Adobe RGB.
First, check the settings - both "PROCESS RECIPES" and "PROCESS RECIPE" - see attachment. ANd also make sure that only one of the "PROCESS RECIPES" is selected (the one outputting the camera profile).
By default C1 applies AdobeRGB to a process recipe. Under "ICC Profile" in the "PROCESS RECIPE" tab you have to select "embed camera profile".
Too, check the layers tab - see attachment.
When you've applied Color Edits (basic or advanced color editor) on layers it is impossbile to embed the camera profile (because C1 would have to merge two profiles). When working with color edits on layers you have to select a working space for output...
Alternatively... post me a screenshot of your process recipes (both) and of your layer tab ... and I'll guide you to set everything correctly ...
-
In Capture One all "camera profiles" are table based.
I've created a matrix-based camera profile using ArgyllCMS and used this in Capture One. I then exported the image using Embedded Camera Profile and the file was rendered as a 16-bit TIFF with this profile correctly. So it would appear that you are mistaken.
Cheers
Robert
-
Hi,
Using Capture One 9.0.2 I try to export a TIFF with embedded camera profile, so I can check it out in ColorThink but it embeds Adobe RGB.
Any way to embed the Camera ICC? I am working with an IQQ file from my P45+
Best regards
Erik
Yes, you created a new process recipe and for the ICC Profile you select Embed Camera Profile.
Cheers
Robert
-
""Quote from: ErikKaffehr on Today at 06:34:10 PM
Colours outside that gamut will not be correctly rendered on screen.""
to be more precise: colors outside of the monitor's gamut will not be displayed at all ...
No, colors outside the monitor's gamut will be mapped to the monitor gamut. So they are displayed but shifted. To say that they are not displayed at all implies that they are simply chopped (leaving black). How it gets mapped depends on the monitor profile, but it will in general be a relative colorimetric mapping, in which case the color is mapped to the closest displayable color (which is why you get banding or flat areas).
Robert
Robert
-
In Capture One all "camera profiles" are table based.
I've created a matrix-based camera profile using ArgyllCMS and used this in Capture One. I then exported the image using Embedded Camera Profile and the file was rendered as a 16-bit TIFF with this profile correctly. So it would appear that you are mistaken.
all camera profiles included in / provided by Capture One are table based ...
On Mac...: go to application -> right click on application -> show package content -> Contents -> Framworks -> AppCore.framework -> Versions -> A -> Resources -> Profiles -> Input
... of course you can also select matrix based input profiles as long as the profile class is tagged correctly in the profile header ("scnr").
You can't use the Color Editor with those profiles, though ...
-
No, colors outside the monitor's gamut will be mapped to the monitor gamut.
Colors that a certain hardware can't display... can't be displayed.
"Mapping" is what the "perceptual" rendering intend does.
In rel.col colors that are higher saturated in the source than in the target profile get clipped. While the colors that do fit within the target gamut appear to be the same as in the source ... so RGB values change, but Lab values stay the same (again, the Lab values of the colors that fit into the target color space stay the same ... everything outside of the target gamut is simply non-existent in the target).
Hmh ...
to double check reversed: make an image in Photoshop in ProPhotoRGB containing squares with the highest saturated RGB patches (so R 255/0/0 - G 255/0/0 - B 255/0/0).
Now convert to your monitor profile using rel.col & BPC. If everything is parameterized accurately you will not see the least bit of a change in the resulting image ...
-
Colors that a certain hardware can't display... can't be displayed.
"Mapping" is what the "perceptual" rendering intend does.
In rel.col colors that are higher saturated in the source than in the target profile get clipped. While the colors that do fit within the target gamut appear to be the same as in the source ... so RGB values change, but Lab values stay the same (again, the Lab values of the colors that fit into the target color space stay the same ... everything outside of the target gamut is simply non-existent in the target).
Hmh ...
to double check reversed: make an image in Photoshop in ProPhotoRGB containing squares with the highest saturated RGB patches (so R 255/0/0 - G 255/0/0 - B 255/0/0).
Now convert to your monitor profile using rel.col & BPC. If everything is parameterized accurately you will not see the least bit of a change in the resulting image ...
We're probably saying the same thing. The image data is not changed but the colors are mapped to the destination using the monitor profile (in the case that the destination is the monitor). If a color is outside of the display gamut then it will be mapped to the nearest displayable color, assuming that the mapping is colorimetric. So the reality is that you cannot see the out-of-gamut color, but what you do see is the nearest color to it which is in gamut.
Of course, if you convert your image to your monitor color space then the image data is mapped and the information is now burnt in to the image. As far as you can see there will be no difference between this converted image and the one that is mapped on the fly, because the displayed data will be the same. However in one case the image data is not changed, whereas in the other case it is.
I guess your point was that if you stay in the camera color space then you avoid any further change to the image data, which is valid. But on the other hand, there are advantages to using matrix-based working spaces and if all C1-supplied camera profiles are table-based this would certainly imply that the camera responses are not linear. So there may be a benefit in converting from the camera profile to a working space in terms of smoothness of interpolation for post-raw editing.
But I'm certainly open to being convinced otherwise. Have you done any tests to show that there is a benefit in staying in the camera profile compared to converting to ProPhoto, say?
Cheers
Robert
-
We're probably saying the same thing.
okay, now I’ve got it - yes, we agree!
I guess your point was that if you stay in the camera color space then you avoid any further change to the image data, which is valid.
exactly. I also do store unedited 16bit TIFs of my "originals" along with the respective RAW files; and here I definitely want to keep a 1:1 copy of my adjusted RAW (in the respective "camera profile").
But on the other hand, there are advantages to using matrix-based working spaces and if all C1-supplied camera profiles are table-based this would certainly imply that the camera responses are not linear. So there may be a benefit in converting from the camera profile to a working space in terms of smoothness of interpolation for post-raw editing.
As in any other RAW converter in Capture One the non-linearity of the camera's sensor gets linearized by correction tables "under the hood". The "camera profiles" - that get assigned later in the processing pipeline - provide a neutral grey axis (reproducing Gamma 1.8 ). Therefore you can use them as "working spaces" for further editing. Only downside is you can't use them for compositings containing image content from different color spaces as you can't convert into an input profile (at least not into table based input profiles only containing an A2B0 table).
But I'm certainly open to being convinced otherwise. Have you done any tests to show that there is a benefit in staying in the camera profile compared to converting to ProPhoto, say?
ProPhoto RGB does not really encompass all colors the camera profiles may contain. See attachment - these are 4 of the profiles I use regularly (2x P45, P21+ and Sony A7R2) compared to ProPhoto (Red profile). While overall smaller than ProPhoto there are certain colors that fall outside of ProPhoto. Since I don't want to think about color conversions when working with RAW files I simply embed the camera profile and check the colors actually utilized in the respective image later in Photoshop (with regard to a specific target) or in Chromix Color Think. Mostly (certainly 90% of the time) I do post-raw-editing in the camera profile. When there is a reason to convert to a matrix based working space I select an appropriate profile. Mostly that has been ECI-RGB or Hasselblad-RGB in my case (and Rec2020 recently).
As a side note: I don't think that I ever shot / created an image that would need ProPhotoRGB to avoid clipping... the colors actually contained in most of my photos fit in much smaller color spaces. If there is any clipping it's mostly in the middle or the lower section of the luminance scale as matrix based color spaces - by the "triangle" design - get pretty small towards the blacks.
-
In Capture One all "camera profiles" are table based. And the RAW data gets not converted into these color spaces - the color spaces get assigned to RAW-data! Therefore - by design - it is technically impossible to get clipping in C1 as long as you don't exhaust the color space by unleashed editing (but you would see it in the histogram) and as long as you embed the "camera profile" on export. The design-idea of C1 is very different to Lightroom/ACR... however, the relation of "internal color space" and output color space is basically the same in all RAW converters...
Some users prefer to use the smallest space that will cover the gamut of the image so as to decrease the spacing between adjacent levels and avoid banding. With a 16 bit matrix file, there are 2^16 or 65536 levels. I don't know the size of the C1 tables, but many table based profiles contain around 2^10 or 1024 levels. People who worry about banding in a 16 bit ProPhoto file (gamut volume 2,897,221 ΔE^3) readily accept 1024 levels in an sRGB table based sRGB profile (gamut volume 832,870 ΔE^3).
The real question regarding the necessary precision is the resolution of the human visual system. If a combed histogram has gaps that are not resolved by the eye, there will be no banding. The Digitaldog's ΔE calculations show no significant difference between 16 bit sRGB and 16 bit ProPhotoRGB. With 16 bit gamma encoded files, precision is not a significant factor except for HDR files, where precision does limit the DR of the space. For details on HDR precision see Greg Ward (http://www.anyhere.com/gward/hdrenc/hdr_encodings.html).
Bill
-
profiles may contain. See attachment - these are 4 of the profiles I use regularly (2x P45, P21+ and Sony A7R2) compared to
As a side note: I don't think that I ever shot / created an image that would need ProPhotoRGB to avoid clipping... the colors actually contained in most of my photos fit in much smaller color spaces. If there is any clipping it's mostly in the middle or the lower section of the luminance scale as matrix based color spaces - by the "triangle" design - get pretty small towards the blacks.
As Bruce Fraser and Jeff Schewe (both proponents of ProPhotoRGB) point out there are many real world scenes that exceed the gamut of AdobeRGB. Although digital cameras do not have a gamut, the gamut of their recorded images is quite wide. Spectral response studies show that current digital sensors are sensitive to the wavelengths of the human visual response, so their "gamut" likely is near that of CIE L*a*b.
Here is an image of come colorful tulips taken with the Nikon D800e and rendered with Adobe Camera raw using the Adobe Standard profile and default parameters with no saturation adjustments. The image is shown in sRGB for web display.
(https://bjanes.smugmug.com/GamutStudy/i-D7q9kmR/0/O/_DSC8869_small.jpg)
Now, let's look at how ACR renders the image into ProPhotoRGB, AdobeRGB, and sRGB.
The image fits well in ProPhotoRGB
(https://bjanes.smugmug.com/GamutStudy/i-MQw4q5v/0/L/ACR_ProPhoto-L.png)
However, saturation clipping is present both in highlights and shadows of the sRGB and AdobeRGB renderings.
(https://bjanes.smugmug.com/GamutStudy/i-rW2pWjN/0/L/ACR_sRGB-L.png)
(https://bjanes.smugmug.com/GamutStudy/i-sxQF5VK/0/L/ACR_AdobeRGB-L.png)
Colorthink plots of the gamuts are informative. The image extends very near the gamut limits of ProPhotoRGB in the reds, oranges, yellows, and some mid-luminance greens.
(https://bjanes.smugmug.com/GamutStudy/i-Qkps7mM/0/L/CTPro_ProPhoto-L.png)
These colors exhibit severe clipping in AdobeRGB and sRGB.
(https://bjanes.smugmug.com/GamutStudy/i-SWKjtrv/0/L/CTPro_AdobeRGB-L.png)
(https://bjanes.smugmug.com/GamutStudy/i-TfMqNcB/0/L/CTPro_sRGB-L.png)
This image should be rendered into ProPhotoRGB. Although some of the colors are out of the gamut of even a wide gamut monitor and can not be properly shown on the screen, some of the colors will fit into the gamut of a wide gamut inkjet printer. If some of the printed colors are blocked up, one could perform some saturation editing. However, with this image, I get the best results with no further editing of saturation when printed with my Epson 3880 on glossy paper.
Regards,
Bill
ps: edited 10:37 a.m. cst on 3/23/2016 to correct duplicate images.
-
Some users prefer to use the smallest space that will cover the gamut of the image so as to decrease the spacing between adjacent levels and avoid banding. With a 16 bit matrix file, there are 2^16 or 65536 levels. I don't know the size of the C1 tables, but many table based profiles contain around 2^10 or 1024 levels. People who worry about banding in a 16 bit ProPhoto file (gamut volume 2,897,221 ΔE^3) readily accept 1024 levels in an sRGB table based sRGB profile (gamut volume 832,870 ΔE^3).
The real question regarding the necessary precision is the resolution of the human visual system. If a combed histogram has gaps that are not resolved by the eye, there will be no banding. The Digitaldog's ΔE calculations show no significant difference between 16 bit sRGB and 16 bit ProPhotoRGB. With 16 bit gamma encoded files, precision is not a significant factor except for HDR files, where precision does limit the DR of the space. For details on HDR precision see Greg Ward (http://www.anyhere.com/gward/hdrenc/hdr_encodings.html).
Bill
I'm not sure that the volume of a color space is particularly useful in calculating the required resolution.
But using a very crude approach, if you have 8 bit then it can resolve 256/256 = 1 (on the a* axis say). This is a dE which is not noticeable to most of us, but there is the potential that this could grow with repeated adjustments to something that is, so 8 bits is really not enough.
With 16 bits you would have 256/65535 = .004 which is absolutely not noticeable and even with multiple adjustments is unlikely to ever cause a problem even when using the full Lab space.
For HDR images 32 bits are normally used so I don't see why there should be a resolution problem there either.
So I think it's entirely fair to say that with a matrix-based profile that the color space is irrelevant as far as resolution is concerned. Use ProPhoto with impunity, if you wish.
With a table-based profile we have a different problem because it is not continuous. A translation from one space to another then requires interpolation and this will inevitably introduce errors - more with 8 bits than 16 bits, but errors nevertheless. So we need to make sure that we have a very large table if we want reasonable accuracy. But, at any rate, this is why it is generally better to use a matrix-based profile as a working space, especially if the destination is also going to be matrix-based.
So the issue, if there is one, with using large-gamut matrix-based working spaces is not one of resolution really, providing we work in 16 bits. It has much more to do with the fact that we will not be able to see the whole of our image if some of it is beyond what our monitor can display or printer print.
If we are happy to work with this situation (using soft-proofing to see where there are potential problems, if we are wise) then that's fine. Personally I am not fine with that as I want to be able to see what I am doing and not just have a warning that these bits of the image are not displayable, or printable. As my monitor is 100% Adobe RGB, Adobe RGB is the natural choice for any image that is going to print (unless I know that there are particular colors that I absolutely want printed and I know that my printer can print them, in which case I will probably use ProPhoto ... but this is a very rare situation for me). For the same reason, if I am preparing an image for the web I prefer to work in sRGB and set my monitor to sRGB at 6500K because then I am working in my target color space.
But at any rate, it seems to me that if you know what you are doing then one color space isn't better than another: it may be more suitable for a particular image and workflow, but that is all. If you don't know what you are doing then the advice really has to be sRGB because that is the color space least likely to cause problems at the destination, whether this is the web or a home-printer.
Cheers,
Robert
-
This image should be rendered into ProPhotoRGB. Although some of the colors are out of the gamut of even a wide gamut monitor and can not be properly shown on the screen, some of the colors will fit into the gamut of a wide gamut inkjet printer. If some of the printed colors are blocked up, one could perform some saturation editing. However, with this image, I get the best results with no further editing of saturation when printed with my Epson 3880 on glossy paper.
Excellent! So you've checked the image and you've found that it doesn't fit into sRGB or Adobe RGB and sensibly you have decided to go for a larger color space because you want to print it with the most saturated colors that you can (and you are happy to do a print, knowing that there could possibly be color shifts if you use a perceptual intent, or banding if you use a relative colorimetric intent, which might then lead you to having to correct the image and reprint if you are fussy about such things). However, if you only wanted to display it to us, knowing as you do that you cannot guarantee that our browsers will have anything but sRGB support, well then you would have made the sensible choice of using sRGB (I hope).
-
Excellent! So you've checked the image and you've found that it doesn't fit into sRGB or Adobe RGB and sensibly you have decided to go for a larger color space because you want to print it with the most saturated colors that you can (and you are happy to do a print, knowing that there could possibly be color shifts if you use a perceptual intent, or banding if you use a relative colorimetric intent, which might then lead you to having to correct the image and reprint if you are fussy about such things). However, if you only wanted to display it to us, knowing as you do that you cannot guarantee that our browsers will have anything but sRGB support, well then you would have made the sensible choice of using sRGB (I hope).
No, I rendered the image into 16 bit ProPhotoRGB, since that is my default workflow. The argument that one should use the smallest space that covers the image and obtain greater precision is bogus, since ProPhoto 16 bit has plenty of precision and banding is not an issue. This is what the Digitaldog's 30 minute video demonstrated.
For this particular image, no complex editing is needed, but if I am going to spend considerable time working with an image in PhotoShop I won't limit my options by using sRGB and I don't want to take the time to use multiple color spaces according to the gamut of the image. If sRGB is needed, one may convert using one of the profiles for that purpose. For this particular image I merely converted to sRGB using relative colorimetric.
Rrgards,
Bill
-
As Bruce Fraser and Jeff Schewe (both proponents of ProPhotoRGB) point out there are many real world scenes that exceed the gamut of AdobeRGB.
there are also colors captured by digital cameras that are outside of ProPhoto-RGB (real world blues & violet blues and some high saturated yellow tones) so even ProPhoto is not a panacea for everything...
-
Hi,
Are you sure? There is something called "pointer's gamut" that it said to contain all nonspecular reflective colours, and those colours are well contained within Adobe Prophoto RGB.
On the other hand, there may be natural colours that are shifted outside a given RGB containing pointers gamut in processing.
But I may be wrong on that, of course.
Best regards
Erik
there are also colors captured by digital cameras that are outside of ProPhoto-RGB (real world blues & violet blues and some high saturated yellow tones) so even ProPhoto is not a panacea for everything...
-
Are you sure? There is something called "pointer's gamut" that it said to contain all nonspecular reflective colours, and those colours are well contained within Adobe RGB.
first: no, I am not sure. I am not a scientist and don't do colormetric measurments of digital sensors. So I have to trust the findings of experts. Albeit I can't remember where I've read about captured real world colors outside of ProPhoto... I do know, however, that also many Capture One camera profiles exceed ProPhotoRGB in these very colors...
"AdobeRGB" in your quote is a typo, isn't it? AdobeRGB doesn't encompass the Pointer's Gamut...
Back to ProPhoto: it is a dated colorspace and back then was primarly developped with regard to analog film based workflows. It has no real relevance for digital capture (other than being pretty large and being the internal color space of Adobe's RAW processors). Iridient Developer moved from ProPhotoRGB to ACES as the internal color space last year for that very reason.
re ACES: http://www.tftcentral.co.uk/articles/content/pointers_gamut.htm#_Toc380197974
-
Getting back to the topic question, more or less, has anyone experience and knowledge of creating camera profiles?
I came across this useful article Steve Huff Camera Profiling (https://stephenstuff.wordpress.com/2012/07/06/digital-camera-profiling-with-raw-therapee-and-argyll-cms/) and made a profile for a Sony A7RII which I then used in Capture One. I didn't attempt to optimize the profile and it was based on the colorchecker 24-patch target.
I am particularly interested to find out if a really well prepared profile based on a suitable target can in fact give better results than the DNG Profiler in Lightroom/ACR. If so, how did you verify your results?
Thanks
Robert
-
Hi,
Thanks for pointing out my error! Corrected!
The Aces stuff is interesting, thanks a lot!
Best regards
Erik
first: no, I am not sure. I am not a scientist and don't do colormetric measurments of digital sensors. So I have to trust the findings of experts. Albeit I can't remember where I've read about captured real world colors outside of ProPhoto... I do know, however, that also many Capture One camera profiles exceed ProPhotoRGB in these very colors...
"AdobeRGB" in your quote is a typo, isn't it? AdobeRGB doesn't encompass the Pointer's Gamut...
Back to ProPhoto: it is a dated colorspace and back then was primarly developped with regard to analog film based workflows. It has no real relevance for digital capture (other than being pretty large and being the internal color space of Adobe's RAW processors). Iridient Developer moved from ProPhotoRGB to ACES (with a sRGB-TRC) as the internal color space last year for that very reason.
re ACES: http://www.tftcentral.co.uk/articles/content/pointers_gamut.htm#_Toc380197974
-
Hi,
Here is a raw file from P45+ back. In all conversions I make yellows in the blade go to the extreme limit of the RGB used:
http://echophoto.dnsalias.net/ekr/Articles/ColourSpaces/20150502-CF046583.iiq
Would be interesting what you find.
Enclosed screen dump:
- ProPhoto RGB (wireframe)
- Capture One camera profile (P45+ flash) (transparent solid)
- Capture One conversion at default settings (dots)
Best regards
Erik
-
Digital cameras don't have a colorimetric color gamut. ICC profiles do. The targets used to build the profile play a role in this resulting gamut too!
-
Getting back to the topic question, more or less, has anyone experience and knowledge of creating camera profiles?
I came across this useful article Steve Huff Camera Profiling (https://stephenstuff.wordpress.com/2012/07/06/digital-camera-profiling-with-raw-therapee-and-argyll-cms/) and made a profile for a Sony A7RII which I then used in Capture One. I didn't attempt to optimize the profile and it was based on the colorchecker 24-patch target.
I am particularly interested to find out if a really well prepared profile based on a suitable target can in fact give better results than the DNG Profiler in Lightroom/ACR. If so, how did you verify your results?
Thanks
Robert
there is a topic about dcamprof here ... forum.luminous-landscape.com/index.php?topic=100015
-
better
standard question = define "better" ?
-
Thanks!
Erik
Yes, you created a new process recipe and for the ICC Profile you select Embed Camera Profile.
Cheers
Robert
-
You can't use the Color Editor with those profiles, though ...
you can translate matrix + trc profile into LUT based though where the LUT will be doing the same color transform and then you can use color editor...
I am totally not Matlab expert, but something like this :
Pmat = iccread('SonyA7RM2-CC24(M+TRC^TF).icm'); % profile after rawdigger + makeinputicc/argyll
Plut = iccread('xxx.icc'); % using a template, some OEM profile from C1 distribution, to fill with our data and the rest will be from OEM profile - put the proper name instead of xxx.icc
Plut.AToB0.InputTables = {Pmat.MatTRC.RedTRC, Pmat.MatTRC.GreenTRC, Pmat.MatTRC.BlueTRC};
Plut.AToB0.OutputTables = {[0 65535], [0 65535], [0 65535]}; % linear curve
Plut.AToB0.PreMatrix = [[1,0,0];[0,1,0];[0,0,1];[0,0,0]]'; % last column = 0,0,0
m_rgb2xyz = [ Pmat.MatTRC.BlueColorant; Pmat.MatTRC.GreenColorant; Pmat.MatTRC.RedColorant ]; % 3x3 in this order = BlueColorant is the top row, RedColorant is the bottom row
n_3Dlut_Size = 33; % C1 uses something like 33x33x33 LUT
m_3Dlut_Points = linspace(0, 32767, n_3Dlut_Size); % get even spacing for points from 0 to __32767__ (not 65535!) for cieXYZ luts
for i = 1:n_3Dlut_Size
for j = 1:n_3Dlut_Size
for k = 1:n_3Dlut_Size
m_RGB2XYZ_3Dlut(i,j,k,:) = round( [ m_3Dlut_Points(i), m_3Dlut_Points(j), m_3Dlut_Points(k) ] * m_rgb2xyz );
end;
end;
end;
Plut.AToB0.CLUT = m_RGB2XYZ_3Dlut; % replace 3Dlut converting RGB to cieLAB with 3Dlut converting RGB to cieXYZ
Plut.Header.ConnectionSpace = 'XYZ';
Plut.MediaWhitePoint = Pmat.MediaWhitePoint;
Plut.MediaBlackPoint = Pmat.MediaBlackPoint;
iccwrite(Plut, 'SonyA7RM2-CC24(3Dlut^XYZ).icm');
-
as long as the profile class is tagged correctly in the profile header ("scnr").
no, you don't need to have "scnr" for matrix input profiles (camera profiles)...
-
as long as the profile class is tagged correctly in the profile header ("scnr").
no, you don't need to have "scnr" for matrix input profiles (camera profiles)...
Long ago I've played around with matrix profiles (monitor profiles) and one way to make C1 read the profiles as "input" profiles was simply to rename "mntr" to "sncr" in the profile header. Maybe there is another solution making C1 recognize certain profiles as input profiles, I don't know ... but on my system (Mac) only "sncr" profiles are recognized by C1 as input profiles.
-
Here is a raw file from P45+ back. In all conversions I make yellows in the blade go to the extreme limit of the RGB used:
http://echophoto.dnsalias.net/ekr/Articles/ColourSpaces/20150502-CF046583.iiq
Would be interesting what you find.
I don't understand what you actually did ... and also can't really decode the graph of color think.
Looks like you've massively boosted saturation of the greens in the Advanced Color Editor? This would explain the confusing shape of the (edited!) P45+ Flash profile.
As far as the actual (unedited) P45+ Flash profile goes attached you'll see a comparison to ProPhoto-RGB (top view and bottom view) which shows the areas where the P45+ Flash profile exceeds ProPhoto (bright blues and violets and dark, high saturated yellows and greens). ProPhoto is the colored profile, of course...
-
Hi,
I just opened the file in C9 and exported it with embedded profile. No manipulation at all, at least as far as I know.
After that I opened the file in ColorThink 2.3 and exported the embedded profile, so I could read it into ColourThink. The image shows the following:
- Colour patches from the TIFF files
- The embedded ICC file in the TIFF image
- ProPhoto GRB
I have posted the raw image, and it can be worth a look. As far as I can see it is very close to the gamut limits and violently outside Adobe RGB. That applies to both LR 6.5 and C9.0.2.
ColorThink is by the way the tool that Andrew (the Digital Dog) uses. But this is the light version.
Best regards
Erik
I don't understand what you actually did ... and also can't really decode the graph of color think.
Looks like you've massively boosted saturation of the greens in the Advanced Color Editor? This would explain the confusing shape of the (edited!) P45+ Flash profile.
As far as the actual (unedited) P45+ Flash profile goes attached you'll see a comparison to ProPhoto-RGB (top view and bottom view) which shows the areas where the P45+ Flash profile exceeds ProPhoto (bright blues and violets and dark, high saturated yellows and greens). ProPhoto is the colored profile, of course...
-
Hi,
This is what I see in ColorSync. The first plot shows the Capture One P45 profile in /Library/ColorSync/Profiles/Phase One P 45 Flash.icm
The other one is the "camera profile" I have exported from Capture 9.0.2.
The wireframe volumes show the two Phase One Capture One profiles, while the translucent volume is Prophoto RGB. In this case I would say Prophoto RGB fully encloses the C1 profile for the P45/P45+.
I don't think colour spaces matter that much on the input side, as long that the input volume fully contains "Pointer's gamut". After all, a colour volume defines the RGB primaries and the white point and there are perfectly good mathematical conversions from one set of primaries to another set of primaries.
With output profiles the situation is different. In input profiles the XYZ values are really integrals of reflected colour multiplied with the spectral response curve for each channel, this is really what metamerism is about. With displays we have a set of well defined, narrow spectrum, primaries corresponding to "phosphors" or colour filters.
Best regards
Erik
I don't understand what you actually did ... and also can't really decode the graph of color think.
Looks like you've massively boosted saturation of the greens in the Advanced Color Editor? This would explain the confusing shape of the (edited!) P45+ Flash profile.
As far as the actual (unedited) P45+ Flash profile goes attached you'll see a comparison to ProPhoto-RGB (top view and bottom view) which shows the areas where the P45+ Flash profile exceeds ProPhoto (bright blues and violets and dark, high saturated yellows and greens). ProPhoto is the colored profile, of course...
-
I don't think colour spaces matter that much on the input side, as long that the input volume fully contains "Pointer's gamut". After all, a colour volume defines the RGB primaries and the white point and there are perfectly good mathematical conversions from one set of primaries to another set of primaries.
With 3D LUT profiles it's pretty different than just 3 primaries and a white point. Table based you can create profiles with - for instance - relatively high saturation in the midtones without the need to define too high saturated primaries. Table based you are not limited to the "triangle" - design of matrix profiles...
-
Are you not mixing up gamut volumes, input profiles and output profiles?
Best regards
Erik
With 3D LUT profiles it's pretty different than just 3 primaries and a white point. Table based you can create profiles with - for instance - relatively high saturation in the midtones without the need to define too high saturated primaries. Table based you are not limited to the "triangle" - design of matrix profiles...
-
Are you not mixing up gamut volumes, input profiles and output profiles?
Best regards
Erik
not that I know of...
-
For anyone who has i1Publish and is interested in camera profiling, I got this information from X-Rite (it's not an officially supported solution, but they say it works):
"Creating Camera Profiles for Capture One
Phase One’s Capture One software is rightly very widely used by photographers for processing their images. Its colour management has always been excellent and the built-in camera profiles are accurate enough for many types of photography. However, I have had a few customers in the fashion and fine art reproduction areas who needed to improve upon the standard level of accuracy and get results closer to the original garment or art work. Capture One’s own Color Editor module allows you to edit the supplied profiles and save them under new names but this tutorial will take you through the steps you need to create a completely new custom camera profile for your camera and lighting set up.
Camera Profiling Requirements
In order to create camera profiles you need a special test target and profile creation software. I used a X-Rite ColorChecker Passport and X-Rite i1 Profiler software. You could also use the larger ColorChecker or other target and there are plenty of alternative software packages. The ColorChecker Passport does come with its own profiling software but the profiles it creates are only compatible with Adobe Photoshop and Lightroom. Whichever target you use you need to photograph it under the lighting that you intend to use for the rest of the shoot. It needs to be lit evenly and exposed correctly. It also makes it easier if it is reasonably large in the frame and straight.
Processing the Raw File
Camera profiling applications generally require 8-bit TIFF files and so you will need to process the image through Capture One before you create the camera profile. However, this needs to be done in a very specific way if you want to get a good profile. Flick to the Color tab and under ICC Profile select Show All at the bottom of the drop down menu. Then go back into the ICC Profile menu and choose Effects/No color correction. This disables the default profiles. You will also need to set the correct Curve. Choosing the camera Linear curve usually gives the best results. Don’t worry if the image looks awful. That shows you how much work the camera profile does in creating a decent image.
Click on the Output tab and start by choosing TIFF 8-Bit Full Size (Adobe RGB) as the Process Recipe. But then change the ICC Profile to Embed camera profile. You can now set the destination and process the file.
Creating Camera Profiles for Capture One
The process of creating the camera profile in i1 Profiler is pretty quick and easy. You select Scanner Profiling and select your target type, in the case X-Rite ColorChecker 24. You can then drag and drop the Tiff file you processed out of Capture One. If the exposure, cropping etc is good it should automatically find the 24 colour patches in the image. If it doesn’t you can manually set the target cropping. It will warn you if it thinks the exposure is out of the acceptable range. Then click Next. The Reference file for the ColorChecker target is included in the i1 Profiler software so you can just click Next again. Give the profile a sensible name; include camera model, lighting, location and anything else that will help you identify exactly what situation the profile was created for. Choose ICC Profile Version 2 and either User level (Mac) or System level (Windows) and click Create and save profile. i1 Profiler will then create the profile and give you a report on the profile. It lists a series of delta E values. Delta E is a measurement of colour difference. The lower the numbers are the better the profile. You can experiment with different exposures or film curves to get you lower numbers. In my test I got an average delta E (CIE 1976) of 0.03 with 100% of the patches in gamut.
Applying a Custom Profile in Capture One
Capture One reads which profiles are on your system when it launches. So if you want it to see the new profile you will have to Quit and then start the application again. In the Color tab you should be able to find your new profile under ICC Profile/Other. The supplied ICC profiles tend to made to give pleasing results as are the curves other than linear so you may see the image is a bit flatter than you were used to but you can now adjust the image using the Exposure tab as normal. Camera profiles are about getting the colours right, not necessarily the exposure. Any adjustments you make and the profile can be applied to the rest of the images in the series by using Copy and Apply adjustments commands.
Creating camera profiles for Capture One, or any other software, can mean a little experimentation and testing of different settings. Some camera profiling software offers choices for how the profile is made and what is prioritised – accuracy or a more “pleasing” result. I suggest that you put some test shots through the built-in profiles and then compare the results to the custom profiles. Don’t forget when you process shots out of Capture One you will want to choose a destination colour space, such as Adobe RGB, sRGB or ProPhoto. Once you get a good camera profile you may be very pleased how much more colour accurate the images are
"
Cheers
Robert
-
For anyone who has i1Publish and is interested in camera profiling
I think better to procure the old ProfileMaker (v5.x.x) though, rather then the current software X-Rite has
-
I think better to procure the old ProfileMaker (v5.x.x) though, rather then the current software X-Rite has
Why is that? Are there features in it that are not in i1Publish? Or does it give better quality profiles? I have to say that I've been very happy with the printer profiles made with i1Publish.
There is also the option (free) of ArgyllCMS if you don't mind a command-line tool.
Robert
-
standard question = define "better" ?
Well I'm not talking about 'more pleasing' because that is something that I want to control myself by making the adjustments that I want.
I am talking about maximizing the quality of the image, in other words to retain as much of the image information as possible with as little distortion as possible. After all, there isn't much point in buying expensive lenses if all of the potential richness is thrown away in raw processing.
And I am also therefore talking about color fidelity. Without getting bogged down in all of the techno-speak, what I mean by that is that if I take a photo of a scene and I have a well-calibrated output device, I want the image of the scene to be as close as possible to the scene. So I want the blue of the sky to be the same blue, the green of the leaves to be the same green etc., all within reason and the limits of the technology,of course.
I know that this is a lot to ask and I'm sure it isn't easy to achieve (after all, matching print to monitor isn't easy either), but it does seem to me to be a worthwhile objective.
Cheers
Robert
-
Why is that?
is "click Create" is the only option for tuning the profiles for cameras in i1Publish ?
-
I am talking about maximizing the quality of the image, in other words to retain as much of the image information as possible with as little distortion as possible.
And I am also therefore talking about color fidelity. Without getting bogged down in all of the techno-speak, what I mean by that is that if I take a photo of a scene and I have a well-calibrated output device, I want the image of the scene to be as close as possible to the scene. So I want the blue of the sky to be the same blue, the green of the leaves to be the same green etc., all within reason and the limits of the technology,of course.
so you want profiles that are essentially reproduction profiles and the whole conversion to be reproduction work like... very good - do you haul spectrophotometer (or better yet - lab grade spectroradiometer) with you when you are shooting ? you want to record the spectral data ;D of your leaves then... people do that
-
http://www.basiccolor.de/basiccolor-input-en/
-
so you want profiles that are essentially reproduction profiles and the whole conversion to be reproduction work like... very good - do you haul spectrophotometer (or better yet - lab grade spectroradiometer) with you when you are shooting ? you want to record the spectral data ;D of your leaves then... people do that
People also photograph a colorchecker or similar target that gives them a reference.
Why would you think that the aim of color fidelity is stupid? We may not achieve it, but we may go quite a long way towards it. White-balance for example gets us quite a long way in the right direction ... is this something you think is a waste of time?
-
http://www.basiccolor.de/basiccolor-input-en/
Thanks ... have you tried it and if so how successful have you been at creating high quality camera profiles?
Cheers
Robert
-
People also photograph a colorchecker or similar target that gives them a reference.
and ?
Why would you think that the aim of color fidelity is stupid?
I think that "fidelity" is the wrong word here - you want reproduction
-
Thanks ... have you tried it and if so how successful have you been at creating high quality camera profiles?
I think we shall rather concentrate on providing the high quality input data first... that is (if you shoot a target) how you measure it, position it, illuminate it, measure illumination, average data, bracket and combine into synthetic target data, etc... otherwise guano in = guano out
-
I think that "fidelity" is the wrong word here - you want reproduction
I think you're splitting hairs and wasting our time.
-
I think we shall rather concentrate on providing the high quality input data first... that is (if you shoot a target) how you measure it, position it, illuminate it, measure illumination, average data, bracket and combine into synthetic target data, etc... otherwise guano in = guano out
What makes you think that when we calibrate our instruments we don't take all the care we possibly can to make sure that the measurement conditions and the measurements and the processing of the measurements and the validation of the results isn't as good and thorough as we can ensure or achieve?
If you've tried basicColor perhaps you could tell us if you have managed to make 'good' camera profiles ... and perhaps you would share these with us?
Cheers
Robert