Luminous Landscape Forum
Raw & Post Processing, Printing => Printing: Printers, Papers and Inks => Topic started by: mstevensphoto on September 19, 2014, 10:32:11 am
-
Hi all, I'm reading my literature and see that the ipf8400 has a 5-6% wider gamut but I don't see any comparison of the printer to the sRGB space. Does anyone know if it is able to print more colors than are in srgb (thus making me work in adobe98) or how the two line up?
-
Sure, even AdobeRGB wastes some of iPFx400 colours
(https://dl.dropboxusercontent.com/u/19059944/IPFx400)
-
Hi all, I'm reading my literature and see that the ipf8400 has a 5-6% wider gamut but I don't see any comparison of the printer to the sRGB space. Does anyone know if it is able to print more colors than are in srgb (thus making me work in adobe98) or how the two line up?
Well actually you need to be careful as the gamut will be wider in places and smaller in others. For example, even with high gloss papers you won't get the blacks that are present in sRGB. On matte papers you will definitely not get anywhere near the full sRGB gamut, especially in saturated reds, yellow, purples.
Here is an example of a gamut on an HP Z3100 (which won't be much different to the iPF8400) on Canson Hi Gloss Premium (as good a paper as you can get), compared to sRGB (sRGB is the wireframe):
(http://www.irelandupclose.com/customer/LL/gamuthigloss.jpg)
As you can see, the gamut volumes are about the same - but the printer is much wider in the saturated cyans, but significantly smaller in the saturated greens, blues and purples.
Robert
-
given that info and focusing on differences one can *actually see*, which colorspace would you work in? I DO have a monitor capable of working in adobe98.
-
given that info and focusing on differences one can *actually see*, which colorspace would you work in? I DO have a monitor capable of working in adobe98.
We had a long discussion about this here: http://www.luminous-landscape.com/forum/index.php?topic=91514.0. Your printer gamut will be larger than both Adobe RGB and sRGB in places, and smaller in others. If you use sRGB then you really will be limiting the printer's potential a lot, with Adobe RGB much less. The advantage of Adobe RGB is that your monitor will be close to it, so if everything is set up correctly you will be in a reasonable wysiwyg situation.
If you go for a larger working space like ProPhoto you are really asking for trouble (this is entirely my opinion!) as there will be large areas of color that you cannot see on your monitor and which you will not be able to print either. An intermediate color space like Beta RGB is better as it will pretty well fully encompass both your monitor and printer gamuts - but the problem with it is that again it will contain colors that cannot be seen on your monitor.
So it really depends on your images. If you're trying to squeeze the last bit of saturated colors out of your printer then I would suggest Beta RGB. If you're happy to live without a few of the most saturated colors, then I would go for Adobe RGB, as I mostly do.
That way you can turn on Gamut Warning in Lightroom or Photoshop and you will be able to see what colors your printer will not be able to print. Then it will be up to what rendering intent you use to determine how these out-of-gamut colors are handled.
Robert
-
If you go for a larger working space like ProPhoto you are really asking for trouble (this is entirely my opinion!) as there will be large areas of color that you cannot see on your monitor and which you will not be able to print either.
A common misconception. In fact colors used in the working space are never seen on a monitor. Just because a monitor is "adobeRGB" only means it gamut is similar to AdobeRGB, but that doesn't mean you use aRGB as the profile for the display. So the colors in an image are always converted via a profile to the device space.
Spaces such as sRGB, AdobeRGB and ProPhotoRGB are theoretical spaces that are used as containers. If your container is smaller than the colors in the image, then the colors are clipped into that working space (and lost). If the colors exceed the device space, the profile is designed to handle that in a way the preserves the visual relationship of colors ... this is what the monitor profile is doing. WYSIWIG doesn't mean exact match, it's about a visual match, and visually matching is more about relationships of colors and tones, not exact numbers. Devices with remarkable different spaces can still look visually very similar.
Since most high end printers exceed sRGB, as well as AdobeRGB in some colors, using either of these as your working space means you will clip and lose colors (forever). If printers or other output devices come along that increase the colors, won't do you any good.
A working space is nothing magic, and it really doesn't matter that it's too large. It's just the bucket that holds the data and can be used by the CMS as the base for the conversions. The only caveat is an 8 bit file really can't manage very well with all the colors available in ProPhotoRGB. Using ProPhotoRGB with an 8 bit file is asking for trouble.
It seems many get hung up about gamuts and how large they are and how they compare and seem to draw some conclusions about matching "gamuts" in the color management process.
Adobe Lightroom is a perfect example of how it all can work seamlessly and without much user involvement ... a good display profile built to match the output profile, everything in the middle handled internally (in a version of ProPhotoRGB 16bit). Same thing works equally well with Photoshop if you just trust the CMS to do it's job, and built solid profiles for all your devices (including learning how to build an appropriate displayl profile that will provide a visual match) it just works.
-
In fact colors used in the working space are never seen on a monitor. Just because a monitor is "adobeRGB" only means it gamut is similar to AdobeRGB, but that doesn't mean you use aRGB as the profile for the display. So the colors in an image are always converted via a profile to the device space.
You're right of course ... the working spaces are always converted to the output device (or converted from the input device).
A working space is nothing magic, and it really doesn't matter that it's too large. It's just the bucket that holds the data and can be used by the CMS as the base for the conversions.
Adobe Lightroom is a perfect example of how it all can work seamlessly and without much user involvement ... a good display profile built to match the output profile, everything in the middle handled internally (in a version of ProPhotoRGB 16bit). Same thing works equally well with Photoshop if you just trust the CMS to do it's job, and built solid profiles for all your devices (including learning how to build an appropriate displayl profile that will provide a visual match) it just works.
Quite right ... there's nothing magical about a working space. HOWEVER ... to say that all you need are good profiles to overcome the mismatch between device gamuts is not at all true. If you edit in a large working space like ProPhoto you will inevitably at times have colors that cannot be viewed on your monitor and cannot be printed. What happens to these colors depends on your profiles and rendering intents, and it is very unlikely that what is rendered on your monitor will be the same as that on your printer. So you will be well away from WYSIWYG, especially if you use a Perceptual mapping for print since most monitor profiles will be Relative Colorimetric.
On the other hand, if you use Adobe RGB and your monitor covers most of Adobe RGB, what you see on your monitor will be as close as you can get to the actual colors (providing of course you have a good monitor and a good monitor profile). So at least you will be starting off from a (relatively) known point: the remaining issue of the printer gamut can be dealt with (but not necessarily that easily!) by using soft proofing and gamut warning, providing, again, that you have a good printer profile and well-calibrated printer.
Here is a comparison between my own monitor (an Eizo CG277) and Adobe RGB:
(http://www.irelandupclose.com/customer/LL/cg277-argb-gamut.jpg)
As you can see, the monitor gamut is slightly larger than Adobe RGB (the monitor is the wireframe).
(http://www.irelandupclose.com/customer/LL/cg277-argb-density.jpg)
And as you can see here, the density response of the monitor and Adobe RGB are almost identical.
So I can be quite confident that what I'm seeing on my monitor are colors that have not been modified by the CMM (or at least minimally modified). I also know from the profile analysis that the colors will be within a dE of 1.2 or better, so I can be reasonably confident in the colors. After that it's down to my eyes and the working environment ... all of which are variable and subjective.
So it's a tradeoff. If you have too large a working space you are likely to be, at least partly, working outside of reproducible colors. If you are using too small a working space you may lose some of the vibrance in your prints. The best compromise, IMO, is to use Adobe RGB since the best monitors currently match this space. If you want to squeeze that extra bit from your printer then Beta RGB is a good choice as it's big enough to cover the gamut of most printers and not too much bigger than the (Adobe RGB) monitor gamut.
Robert
-
I don't want to get into a big debate here and not going to spend a lot of time on this. It has been discussed and argued ad nauseum, and there is little point in spending a lot of time rehashing all of this.
However I do believe you are making some assumptions that are not accurate, and I would submit that if your practice was best practice it would be preached by many experts, when in fact they do not. Rather than get into a debate I would just like to make a couple of points for the sake of the OP and others who stumble across this thread, and encourage them to do some research. And to be clear, it's not that your approach won't offer great results, but the assumption that using a prophotoRGB/16bit workflow is looking for trouble is just not true.
Your assumption is that because a display is similar in gamut size to AdobeRGB the CMS will have to make little to no changes and you will see the colors as they are by using AdobeRGB as the working space offers such superior results that it is worth doing despite having to clip out colors that are outside of AdobeRGB that exist in the file as well as lose colors that the printer is able to print but are outside of aRGB (which with some printers are not insignificant). This is supposed to be more "wysiwyg" and thus is worth sacrificing the the colors out of the AdobeRGB space.
First I don't know whether you can verify by the 2 graphs you display that there isn't a lot more going on in the conversion process. Second, I don't see much difference between the argument that you should use AdobeRGB over sRGB because the printer can print colors outside of sRGB than it would be applying the same logic to using ProPhotoRGB over AdobeRGB, because with some current printers the color advantages over AdobeRGB are pretty large. (the z3100 isn't one of those, it's pretty old technology and is pretty weak in the reds compared to the z3200 as well as the ipf8400 and epson x900 printers.)
But more importantly, I'm not sure how mapping and clipping the colors into the AdobeRGB space and then to the display space will offer any advantage over leaving the colors as they were and just mapping the colors into the display space dynamically, and into any other output space as needed. This goes against the very premise of a good color management system. In fact I would bet that two appropriately setup and profiled systems side by side, one where a file is forced into the AdobeRGB space before being opened, the other which leaves the file in a ProPhotoRGB/16bit space will be virtually identical, the only difference might be very subtle tonal gradations that are maintained by the system using ProPhotoRGB - most likely so subtle many people wouldn't even be able to see them upon close examination. You state how well your system works for this ... I don't think it's any better than what I'm doing which offers me an almost perfect visual match to my output, and rarely do I have to tweak or change anything after printing out a file.
As far as using a space other than ProPhotoRGB that is smaller, again I'm not sure why this is relevant. It doesn't really matter that the container is larger than the colors in the file .. it's not like the unused colors change anything. The only issue with ProPhotoRGB is the available number of colors in an 8bit file isn't sufficient, so you have to stay in 16bit mode to avoid banding. I suppose if a perfect space existed that only contained colors needed it might be small enough that working with 8 bit files would be adequate. But then again, it seems that everything is moving past this anyway, with 10bit workflows on the horizon which will require working with 16bit files.
I as said, this doesn't mean great results can't be obtained by using AdobeRGB, because the results are more about user skill and quality profiles, but anyone using a ProphotoRGB/16bit workflow and getting into trouble because of it needs to look somewhere other than blaming ProPhoto for their problem. Certainly restricting things to AdobeRGB might seem to fix it, but it's more likely applying a bandage rather than really fixing whatever the underlying problem might be.
-
One reason we need big RGB working spaces is that they are based on theoretical emissive devices (ProPhoto being very theoretical when you look at what falls outside human vision). Necessary because of their simple and predicable shapes. So while there are many more colors that can be defined in something like ProPhoto RGB than you could possibly print, we have to deal with a significant disconnect between these simple shapes of RGB working space and the vastly more complex shapes of an output color space. Simple RGB working space matrix profiles when plotted 3 dimensionally illustrate that they reach their maximum Chroma at high luminance levels which makes sense since they are based on increased Chroma by the addition of more light. The opposite is seen with print (output) color spaces where this is accomplished by adding ink: a subtractive color model. One reason we need such big RGB working space like ProPhoto RGB is due to its simple size and to counter the disconnect between mapping to the output space without potentially clipping colors. There can be issues where very dark colors of intense Chroma (which do occur in nature and we can capture with many devices) don’t map properly with a smaller working space. Many of these darker colors fall outside Adobe RGB (1998). When you encode using a smaller color space, you clip the colors to the degree that smooth gradations become solid blobs in print, again due to the dissimilar shapes and differences in how the two spaces relate to luminance. I suspect this is why Adobe picked ProPhoto RGB primaries for the processing color space in their raw converters.
When I get back from location, I'll be finishing up this video on the subject (URL for rough cut below):
http://digitaldog.net/files/WideGamutPrintVideo.mov
And fix the title typo <g>.
I think part 3 illustrates this idea of color clipping.
-
In addition, a serious study by the US museums , I forgot the acronym, showed that the encoding in color spaces like aRGB op propohtotrgb has insignificant impact on quality of the color itself, how the encoding was done (ie what tools used) does matter though.
-
I have nothing against ProPhoto and do use it at times, if the image warrants it. However most of our images don't, with the colors falling naturally within smaller spaces like aRGB or even sRGB. It makes sense to use a very wide working space at the capture stage since our cameras are capable of capturing a wide gamut, and if you can only pick one working space (as is the case for Lightroom), then pick a wide one.
Our problem is not in the wideness of ProPhoto - it's that ProPhoto allows us to do edits that fall outside of both human vision and our current monitor gamuts. So unless we're careful when editing (for example by always turning on soft-proofing and checking both monitor and output device out-of-gamut while we are editing) we can quite easily end up with colors that look great on screen, but only look great because the mapping to the monitor is OK. That doesn't mean that the same (unviewable and unprintable) color will also print well ... that depends entirely on the output profile, and if you choose a perceptual mapping the chances are quite high that there will be a significant shift in all the colors on your print (might look fine, but it will be different to what is intended).
The advantage of using aRGB is that to the extent that the monitor is capable of doing so, it will show the colors as they are ... and aRGB will prevent us from going outside of the monitor gamut. We then only need to concern ourselves with the printer gamut.
If you're printing from Lightroom from the raw file then there is no option: you have to print from ProPhoto and so you need to be quite careful.
If you go into Photoshop first (as I always do) then there is a choice at the time of opening the image of choosing ProPhoto or aRGB. If the image is within aRGB at that stage then I doubt that there is any damage done to the image in choosing one over the other. So my recommendation would be aRGB at that point. If the image is NOT within aRGB, then the choice IMO is either to bring it back into aRGB-line, or open it in ProPhoto. The decision for me is based on whether the OOG colors are within my printer gamut or not: if they are then I will use ProPhoto, if they are not then I will bring the image back into line.
All of our editing is done using our monitor: that is the controlling device effectively. If we go outside of its gamut we are asking for trouble. We may well get away with it, but we may not ... it's a matter of chance. If we want to be safe (but a little more limited) then we would be wise to stay within the monitor gamut.
I don't personally worry about what will happen when a much wider gamut monitor or printer becomes available - because I always keep my raw files so I can always go back, if I feel that it might improve the image, and make the little tweaks that will get me that extra bit of sparkle that has become possible.
My last monitor had an sRGB gamut (more or less) and I processed my images in sRGB. When I go back and view them on my now aRGB (more of less) monitor, the vibrance of the image has so far never been an issue for me and I have not reprocessed any image for that reason. What I have done is to reprocess images because I now have better sharpening tools, my own skills have improved (I think :)) and I have better papers.
But anyway ... there are swings and roundabouts and as we said on another thread, what we are trying to do is to fit a round peg into a square hole ...
Robert
-
I think sometimes there is a disconnect with the concept of “color” when we are talking about working spaces and output spaces. Perhaps to some the use of the word color inherently implies some bright vivid color. But in my workflow these aren’t the colors I’m worried about.
The idea that because ProPhotoRGB deals with colors outside of human perception means you can end up editing colors you can’t “see”, while theoretically true, doesn’t seem to be true from a practical use point of view. By the time you get to those colors, even if your display is a sRGB display the colors will be garish and obviously not right (unless that’s what you want). So while logically it’s easy to believe this to be a problem, it really isn’t.
But as Andrew mentioned, the more important colors which can be affected, the colors that your printer can print that are sacrificed if you force your image into an AdobeRGB working space are in the midrange and darker tones - especially shadows. And if you clip those into AdobeRGB, you are sacrificing potential shadow detail and may even block up some of those shadows. And we’re not talking about a small amount of colors. AdobeRGB wasn’t developed with reflective output in mind ... it was developed for emissive devices. So as a working space in a workflow whose primary purpose printed output on high end inkjet printers, it’s really isn’t a great choice.
A workflow that leaves colors alone, then can dynamically map them into an output space as needed, using a different rendering intent to preserve relationships between colors when necessary, to me is a much preferred workflow. While I have many clients and students in my color management classes that state these same worries, I’ve never really seen anyone that finds it a problem if they have their system setup correctly and use good technique.
Attached are 2 colorthink graphs showing the colors that are achievable from an Epson 9900 printer on Epson Premium Luster and a Canon ipf8400 using Canon Premium Glossy paper that are outside of AdobeRGB ... .
-
Our problem is not in the wideness of ProPhoto - it's that ProPhoto allows us to do edits that fall outside of both human vision and our current monitor gamuts.
Not a major issue if you edit carefully. As I outline in my video, you have to decide what's more important: contain colors you can't see on the display but exist in the capture and can be printed OR funnel into a smaller color space so you can see it all and not use it all. If print is your final output, using a smaller gamut working space can reduce the qualities of said output as I explained below.
Going back to the raw if fine IF you haven't spent hours editing the master image after raw rendering but prior to printing.
-
turning on soft-proofing and checking both monitor and output device out-of-gamut while we are e.
If you're printing from Lightroom from the raw file then there is no option: you have to print from ProPhoto and so you need to be quite careful.
Do not understand this statement. I use LR both for developing and for printing. Softproof allows me to see where colors in an image are out of gamut for given destin profile, so i can do that also for sRGB or aRGB .
Unless you are radically upping the saturation, i cannot see a problem.
-
Do not understand this statement. I use LR both for developing and for printing. Softproof allows me to see where colors in an image are out of gamut for given destin profile, so i can do that also for sRGB or aRGB .
Unless you are radically upping the saturation, i cannot see a problem.
Yes, actually if you stick to Lightroom and you do use the soft-proof feature with gamut warning then you are being very careful and won't get into problems: the softproof shows both out-of-gamut monitor colors and also out-of-gamut destination colors.
If you're working from Photoshop it's more difficult as you can't see both at the same time (but of course it's pretty easy to set up a script to toggle from monitor to destination, so it's not that difficult).
There's nothing wrong with using ProPhoto or other wide working space ... as long as we know what we're doing, and we are consistently careful. If we want a workflow that is quick and easy and doesn't require careful checking ... then there is an advantage in using a smaller working space because it reduces the risk of inadvertently going badly out of gamut.
There is also nothing wrong, IMO, in using several working spaces. If we know that an image is well within sRGB - then why not use sRGB? For example, if our images are monochrome or nearly so then we won't be using a fraction of sRGB. On the other hand, if we have a particular image that has a very saturated sunset that we want to print - well then we may need to go to ProPhoto.
It's like ... use your bicycle to go down to the village and your 4x4 to go up the mountains. Neither is better than the other but each has its particular strengths.
I would think that the best solution is to buy GamutVision or Chromix and then the decision as to which color space to use becomes quite easy.
Robert
-
One reason we need big RGB working spaces is that they are based on theoretical emissive devices (ProPhoto being very theoretical when you look at what falls outside human vision). Necessary because of their simple and predicable shapes. So while there are many more colors that can be defined in something like ProPhoto RGB than you could possibly print, we have to deal with a significant disconnect between these simple shapes of RGB working space and the vastly more complex shapes of an output color space. Simple RGB working space matrix profiles when plotted 3 dimensionally illustrate that they reach their maximum Chroma at high luminance levels which makes sense since they are based on increased Chroma by the addition of more light. The opposite is seen with print (output) color spaces where this is accomplished by adding ink: a subtractive color model. One reason we need such big RGB working space like ProPhoto RGB is due to its simple size and to counter the disconnect between mapping to the output space without potentially clipping colors. There can be issues where very dark colors of intense Chroma (which do occur in nature and we can capture with many devices) don’t map properly with a smaller working space. Many of these darker colors fall outside Adobe RGB (1998). When you encode using a smaller color space, you clip the colors to the degree that smooth gradations become solid blobs in print, again due to the dissimilar shapes and differences in how the two spaces relate to luminance. I suspect this is why Adobe picked ProPhoto RGB primaries for the processing color space in their raw converters.
When I get back from location, I'll be finishing up this video on the subject (URL for rough cut below):
http://digitaldog.net/files/WideGamutPrintVideo.mov
And fix the title typo <g>.
I think part 3 illustrates this idea of color clipping.
Hi Andrew,
I had a look at your video ... very well done as usual! In general I think your recommendations are fair, however comparing ProPhoto to sRGB is not really. It gives the impression that the wider the better, which is not necessarily true.
Here is a gamut map of Adobe RGB and the Epson 9900 with Canson Photo Hi Gloss paper (about as good a combination as one can get at this stage, gamut-wise):
(http://www.irelandupclose.com/customer/LL/aRGB-ep9000.jpg)
It is clear that even with Adobe RGB there is some possibility of clipping/shifting in the darker regions (as well as the lighter ones). However the clipping is minimal in the darker regions and certainly will not clip to black. There is of course considerably more clipping using sRGB and it makes no sense to have a printer like the 9900 and then printing saturated images from sRGB. With aRGB it's a judgement call, as you say in your video: have colors that you can't see but can print, or see what you are going to print and take the hit on some of the saturated colors.
What you don't really say in your video is what things look like with ProPhoto. Here it is:
(http://www.irelandupclose.com/customer/LL/pRGB-ep9000.jpg)
No clipping admittedly :). But look at all of the colors that are entirely unprintable and unviewable! So ProPhoto needs to come with a very big warning. If you print using a perceptual mapping you will, in all probability, get a serious color shift when printing from ProPhoto. Depending on the profile this could even happen if NONE of your colors are outside of the printer gamut (because some profiles compress the whole of ProPhoto into the destination gamut ... and they do this because they have no way of knowing at the time the profile is made what colors will be outside the destination gamut).
So it's one of these things: if you want to squeeze the utmost from your images then sure, go for a wider gamut than Adobe RGB (Beta RGB would be a better choice than ProPhoto) ... but if you don't fully understand what is happening and don't know how your printer profiles have been built you could end up with unintended colors on your print; if you are willing to sacrifice a bit of the most saturated colors and be safe then you would be better off staying in Adobe RGB; if you want a compromise between these two then an intermediate working space like Beta RGB would be a good choice.
IMO, at any rate :)
Robert
-
It gives the impression that the wider the better, which is not necessarily true.
No, it absolutely IS true with those images from raw, printed to an Epson! That's the point of the video in part. To allow you or anyone to run the tests themselves with my images or yours. With my images, to my printer, it is without question that the ProPhoto encoding is vastly superior when viewing the print compared to sRGB.
It is clear that even with Adobe RGB there is some possibility of clipping/shifting in the darker regions (as well as the lighter ones).
Clear on the gamut map or the print? Kind of a big difference no?
-
So ProPhoto needs to come with a very big warning. If you print using a perceptual mapping you will, in all probability, get a serious color shift when printing from ProPhoto.
I guess I'm not quite sure how you arrive at this. Using a perceptual intent happens when you map the colors from where they are into an output space. The container and it's size doesn't really affect the actual colors that are in the image. Even if the image starts out with colors contained in lowly sRGB and you work in the ProPhotoRGB space, the colors are still the colors. Just because the space is bigger, nothing is mapped into all those unused colors - you don't use a perceptual intent to map those colors into ppRGB. And when you map them into an output space, it is that space that determines where they end up. If the output space isn't large enough to contain them, at that point they need to be adjusted into the space. So the working space has no affect on that. You aren't going to get some weird result because you have an image whose colors are all contained in sRGB, and you are working in ProPhotoRGB and then want to output to some device. Now you might get into trouble if you are working with an sRGB image and then change your working space into ppRGB ... but even this is pretty unlikely, and once you start in sRGB or aRGB there isn't much point in moving to ppRGB.
But there is a risk of losing quality/shadow detail if you original data is contained within sRGB so that's where you start, but needing to modify it to the point (especially when pulling shadows open) that will require colors outside of sRGB. True it won't be dramatic, but I guess that's the concern I have with your earlier statement of using sRGB or aRGB when you can. I can't see an efficient workflow where I can predetermine whether or not I will only need colors inside of sRGB or aRGB so I can choose those for a working space instead of ppRGB. You can't easily tell this visually, and in fact many more image than you realize can take advantage of printer colors outside of aRGB.
I have a hard time seeing anyone with an image whose data is contained within sRGB stretching it to the point it ends up in the colors of ppRGB anyway ... this is a big stretch so most likely whoever would do this would kill the image even if they were in sRGB If they are really that unskilled using aRGB or sRGB may be sort of a safety net, but I still think if they are at that level it won’t turn out great most of the time no matter what space they use. (and i see sRGB images come into my shop every day to be printed that really are poorly done).
I really think your logical thought process (and the idea the ppRGB is "so big") has you creating problems that really aren't there. And while ppRGB has colors outside of human perception, out of the 3 color spaces it is the only one created specifically with photography in mind. The goal when created by Kodak was a space that could contain all the colors that naturally occur in the world ... not a space that is to be used when working with emissive computer displays and CMYK printing processes. Yes this means you end up with some "colors" that aren't colors, but it's really not as problematic as you believe.
-
I really think your logical thought process (and the idea the ppRGB is "so big") has you creating problems that really aren't there.
Based on what have to be million's if not more images, run through that space (and through Adobe raw converters), I think you're absolutely correct!
-
Robert, i am lost as to what you try to prove. Would like to see some serious proof of all these theories of colorshifts. I have not such experiences.
-
Robert, i am lost as to what you try to prove. Would like to see some serious proof of all these theories of colorshifts. I have not such experiences.
That would be useful (proof of concept) with outlined methodology we can try on our end. At least that was what I attempted to do with the ProPhoto vs. sRGB to print demo. As such, there's no question in my mind, with the raw images with large chroma I used, out to my 3880, ProPhoto RGB is the right answer for an encoding color space.
-
That would be useful (proof of concept) with outlined methodology we can try on our end. At least that was what I attempted to do with the ProPhoto vs. sRGB to print demo. As such, there's no question in my mind, with the raw images with large chroma I used, out to my 3880, ProPhoto RGB is the right answer for an encoding color space.
So do i andrew. I am getting tired of these posts on how big prophotorgb is, for me i t means the person has no clue as to what a color space is. But i want to learn, so a reproducable concept yes. P.S. still need to digest your video.
-
Robert, i am lost as to what you try to prove. Would like to see some serious proof of all these theories of colorshifts. I have not such experiences.
Hi JR,
I'm not trying to prove anything ... I just don't agree with the notion that, effectively, the larger the working space gamut the better, and that using a smaller gamut will necessarily cause banding, clipping or shifting of colors, especially low luminosity colors. I'm happy with how I do things and if you're also happy with how you do things then we're all happy.
But if you want to follow through on the question of color shifts in perceptual mappings, have a look here: http://www.argyllcms.com/doc/iccgamutmapping.html. And if you want to get a more thorough explanation ask Graham Gill who is the author of ArgyllCMS. If he doesn't know what he's talking about then we're all in trouble!
Essentially it works like this: when a profile developer creates a perceptual mapping table he/she does not know what colors will be in the source space (say in ProPhoto RGB) because these colors are only known for individual images. With some images all of the colors may be within the destination space, with other images some of the colors may be at the edges of the source space. So the profile developer can either a) assume the worse case that the general case is that image colors will be on the source boundary, or b) assume that the image colors will be in a smaller space than the source space.
If a) is assumed then for a (perceptual) mapping, the mapping table will need to compress the whole of the source space (ProPhoto, say) into the destination space. The table will attempt to minimize the color shifts that lie within the destination space, but the whole idea behind perceptual mappings is to preserve the relationship between colors: in order to do that the mapping will have to shift the colors that lie within the destination space.
If b) is assumed then the profile will be a mix of a relative and perceptual mapping. The same will happen as in a), but for the smaller source space; and the colors outside of the smaller source space will effectively be mapped using a relative-type mapping. In other words the colors will be clipped to the smaller source space boundary before being shifted. This will result in banding for colors that are outside of the smaller source space, but it will give less of an overall color shift.
The only way around this problem is for the mapping table to be constructed immediately prior to the conversion from source to destination. Unfortunately this is a very compute-intensive task. However, if you want to do this then ArgyllCMS does provide a mechanism to do so - and this will ensure that the sort of color shifts I'm talking about will be minimized (but only that: the color shifts will still occur if there are colors that are outside of the destination space). What you do is to create a profile for each image. This sounds complicated, and it is a bit, but not so much. What you need to do is to run the profile mapping against the image using the tables you've already generated from your spectrophotometer and use this image-specific profile to convert to the destination space.
Most of us aren't such perfectionists that we'll do this: a half-way-house solution is to use relative mappings (which result in clipping but not in the same color shifts) or to use smaller working spaces in order to minimize the shifting.
At any rate, as I said, you don't need to take my word for this: Graham Gill is a really nice guy and he will answer your questions if you post them here: argyllcms@freelists.org.
Robert
-
Hi JR,
I'm not trying to prove anything ... I just don't agree with the notion that, effectively, the larger the working space gamut the better, and that using a smaller gamut will necessarily cause banding, clipping or shifting of colors, especially low luminosity colors.
The proof is in the output. Tests can be preformed to educate each person as to the most effective workflow. There is zero question in my mind that with raw data, using the converter I use, (which processes in ProPhoto gamut), with the images I selected (very saturated), ProPhoto is the right answer going out to my printer. The gamut maps are interesting but don't prove anything over what the print shows me! The gamut maps actually show me why IMHO the larger gamut produces a superior print (which has nothing to do with clipping alone). If I were using an image with a much lower gamut, and there are areas of this in my Gamut Test File, I see nothing the larger space provides that is better than the smaller gamut space. But nothing worse either!
I can attempt to view each image and decide what encoding color space they best fit into, or I can pick a really big one seeing that bigger IS better upon output and not worse than smaller on the same output. I suppose if I only had to process a few images, I could pick and choose but with high bit, wide gamut data in a raw processing using a wide gamut high bit processing color space, I don't see any benefit to doing this. Maybe you can provide some data to suggest otherwise. That's all we're asking.
-
That would be useful (proof of concept) with outlined methodology we can try on our end. At least that was what I attempted to do with the ProPhoto vs. sRGB to print demo. As such, there's no question in my mind, with the raw images with large chroma I used, out to my 3880, ProPhoto RGB is the right answer for an encoding color space.
Well, Andrew, if the image you start off with has colors that are well outside of sRGB, as is the case with your ProPhoto test image, then when you convert to sRGB you are immediately clipping all of the OOG colors to the sRGB space using a relative intent. You don't need to print to see that - you will see the effect on your monitor since your monitor has a near aRGB gamut. Since your printer gamut will mostly be wider than the sRGB gamut, little or no further damage will be done when you map to the print profile: the damage has already been done.
It's like taking a pint glass full of water and pouring it into a half-pint glass ... and then saying: "Jeez! I only have a half-pint left! The action of converting to the half-pint glass has clearly resulted in a massive loss of water!".
The fact is that your printer is a 3/4 pint glass so don't convert to a 1/2 pint glass before filling it.
Robert
-
Well, Andrew, if the image you start off with has colors that are well outside of sRGB, as is the case with your ProPhoto test image, then when you convert to sRGB you are immediately clipping all of the OOG colors to the sRGB space using a relative intent.
So what? It's like saying if you start with a 21 megapixel file and sample for the web, you lose pixels. Yes you do, so what? If you have an sRGB output need (which I would suggest is only to the internet or non color managed devices), you have to use sRGB and converting clips the colors and they look fine.
It's like taking a pint glass full of water and pouring it into a half-pint glass ... and then saying: "Jeez! I only have a half-pint left!
IF you have a pint of water and the recipe calls for a half pint, you follow the recipe, so what? If the 2nd recipe calls for more water, you've got it in the first place. Clipping is a fact of life, there's nothing wrong with it. It has to be done. The question is, do you start with less when you may often need more or start with more when you need it and end up with less when you need it? I makes no sense to me, others I suspect and clearly the people who built the Adobe raw engine to start off with less.
You've as yet provided nothing in terms of a testing methodology that suggests it is better to start with less than start with more (color gamut). That's where I suggest you focus the efforts.
-
If I were using an image with a much lower gamut, and there are areas of this in my Gamut Test File, I see nothing the larger space provides that is better than the smaller gamut space. But nothing worse either!
If you are using a relative mapping then the colors that are both within your source profile and destination profile won't be affected, so you gain / lose nothing. If you're using a perceptual mapping there will be larger color shifts with the larger source space - but you may not notice these if you have a good profile that succeeds in maintaining the relationship between the colors well (not an easy task as I understand it!).
I can attempt to view each image and decide what encoding color space they best fit into, or I can pick a really big one seeing that bigger IS better upon output and not worse than smaller on the same output. I suppose if I only had to process a few images, I could pick and choose but with high bit, wide gamut data in a raw processing using a wide gamut high bit processing color space, I don't see any benefit to doing this. Maybe you can provide some data to suggest otherwise. That's all we're asking.
That's absolutely the whole point of the discussion. What we're trying to do is to squeeze the most out of our images, which is why we buy really expensive cameras, lenses, software, monitors and printers. If we don't care all that much or process so many images that we simply don't have the time then the quality will suffer: we won't sharpen as well, compose the shot as well, develop as well, print as well. Then it makes sense to have as simple and as efficient a workflow as possible ... and accept the probable quality-hit.
If, on the other hand, we want the best that we can achieve from each of our images ... well then we will take the shot with a tripod and mirror lock-up, make sure the exposure is right ... etc., etc., ... to include the best working space for this image and the best rendering intent using the best profile and best paper.
My only real issue with what you say is that you are making the claim that 'ProPhoto is best'. It is not. It's a compromise like all the other workspaces. The ICC should not have defined a triangular working space when the output devices are non-linear ... but it has and that is what we are currently stuck with. Hopefully we will be moving towards on-the-fly profile mapping which will improve things quite a lot, but right now you are better off using a working space that fits your image.
Robert
-
If you are using a relative mapping then the colors that are both within your source profile and destination profile won't be affected, so you gain / lose nothing.
Great, losing nothing is terrific when I can have the best of both worlds!
If you're using a perceptual mapping there will be larger color shifts with the larger source space - but you may not notice these if you have a good profile that succeeds in maintaining the relationship between the colors well (not an easy task as I understand it!).
You simply can't make blanket statements about perceptual rendering because they all differ. It is probably why the canned Epson profile for Glossy did a worse job than my custom profile on the Blue Balls (referenced in the forum post about color management misconceptions). A perceptual mapping my be better or worse based on the profile and how it was built and the image. That is why we soft proof before we make such decisions. Profiles only understand a solid color going from one color space to the other, it has zero idea about colors in context.
That's absolutely the whole point of the discussion. What we're trying to do is to squeeze the most out of our images, which is why we buy really expensive cameras, lenses, software, monitors and printers. If we don't care all that much or process so many images that we simply don't have the time then the quality will suffer: we won't sharpen as well, compose the shot as well, develop as well, print as well. Then it makes sense to have as simple and as efficient a workflow as possible ... and accept the probable quality-hit.
IF that's the whole point of the discussion, then ProPhoto RGB, certainly with Adobe raw converters is the right answer for the encoding color space with the images I used. You are welcome to test other images in that converter and show us where encoding in a smaller working space is better.
If, on the other hand, we want the best that we can achieve from each of our images ... well then we will take the shot with a tripod and mirror lock-up, make sure the exposure is right ... etc., etc., ... to include the best working space for this image and the best rendering intent using the best profile and best paper.
That's fine too. That's why people should test differing workflows, to decide what it is they are willing to do for presumed or expected image quality.
My only real issue with what you say is that you are making the claim that 'ProPhoto is best'. It is not.
I never said that. With the raw images and converter, with the printer and methodology I used, it's the best (better) than sRGB by a long shot. Hugely better. You've got the same file and instructions for the methodology I used. You can add your own image. You can try a different raw converter (Aperture uses Adobe RGB gamut for processing, so YMMV). You can use a different printer or profile. When you do this, show us when and where sRGB produces a better print than ProPhoto RGB.
-
So what? It's like saying if you start with a 21 megapixel file and sample for the web, you lose pixels. Yes you do, so what? If you have an sRGB output need (which I would suggest is only to the internet or non color managed devices), you have to use sRGB and converting clips the colors and they look fine. IF you have a pint of water and the recipe calls for a half pint, you follow the recipe, so what? If the 2nd recipe calls for more water, you've got it in the first place. Clipping is a fact of life, there's nothing wrong with it. It has to be done. The question is, do you start with less when you may often need more or start with more when you need it and end up with less when you need it? I makes no sense to me, others I suspect and clearly the people who built the Adobe raw engine to start off with less.
You've as yet provided nothing in terms of a testing methodology that suggests it is better to start with less than start with more (color gamut). That's where I suggest you focus the efforts.
You know Andrew, I have the greatest respect for you and your teaching is of real benefit to us photographers and printers. You clearly know a lot about the subject and have given it a lot of thought. But I think you have nailed your flag to the ProPhoto mast and cannot unnail it.
I have not suggested, at any stage, that it is best to start with less. What I have suggested is that it is better to start off with the right sized container for your image. If you only need a teacup then don't use a boat. If you need a boat, use a boat.
The best way I know of testing this question is to look at the profiles because they tell you exactly what is happening to the image as it is being converted from one color space to another. Doing it visually is very difficult because it is subjective and depends on the image, the profile, the printer, the paper ... and on our eyes and the viewing conditions. It's easy to demonstrate clipping from ProPhoto to sRGB for colors that are outside of sRGB: you've already done that very effectively. It is much more difficult to visually demonstrate the shifting of colors that can occur when compressing a large gamut into a smaller one. But by looking at the profiles it is quite easy to see, at least in general terms, what is going to happen.
If I did spend a lot of time devising a test to demonstrate the shifting of colors you would almost certainly disagree with my conclusions. But if I was bothered about it (which I'm not because I don't need any convincing), what I would do is to pick a spectrum of color spots going from the edges of ProPhoto to grayscale, note the Lab value of each of the color spots, print to your 3880 with your profile and then, using my i1Pro2, I would measure the Lab value of each of the printed spots. I would then enter all of this data into an Excel spreadsheet and plot the shift in colors. I would then repeat the test with sRGB and compare its plot to the ProPhoto plot. Providing your printer gamut is larger than sRGB I would expect to see a curve for the ProPhoto plot and a straight line for the sRGB plot.
But it is a lot easier just to inspect the mapping!
Robert
-
But I think you have nailed your flag to the ProPhoto mast and cannot unnail it.
I've done the testing which I believe is based on sound methodology of which you've as yet haven't disproved. If and when you can and do, I'll re-examine things. On the other hand, you've done nothing to suggest that with the workflow I'm using, ProPhoto isn't the best answer. So the ball is in your court.
What I have suggested is that it is better to start off with the right sized container for your image.
Define right, tell us how a raw image falls into that container especially when the processing color space is a fixed, wide gamut based on ProPhoto.
The best way I know of testing this question is to look at the profiles because they tell you exactly what is happening to the image as it is being converted from one color space to another.
That's kind of absurd considering that the images don't have a gamut until processed from raw and encoded (at which time, it's all water under the bridge).
Doing it visually is very difficult because it is subjective and depends on the image, the profile, the printer, the paper ... and on our eyes and the viewing conditions.
Yes it is subjective and useful when the final result IS THE PRINT itself!
It's easy to demonstrate clipping from ProPhoto to sRGB for colors that are outside of sRGB: you've already done that very effectively. It is much more difficult to visually demonstrate the shifting of colors that can occur when compressing a large gamut into a smaller one.
It is actually very easy; look at the prints side by side. You're making this far more complex and difficult than it needs to be. But by looking at the profiles it is quite easy to see, at least in general terms, what is going to happen.
Looking at the print tells me exactly what's happening!
If I did spend a lot of time devising a test to demonstrate the shifting of colors you would almost certainly disagree with my conclusions.
OK, that's not useful. But if I was bothered about it (which I'm not because I don't need any convincing), what I would do is to pick a spectrum of color spots going from the edges of ProPhoto to grayscale, note the Lab value of each of the color spots, print to your 3880 with your profile and then, using my i1Pro2, I would measure the Lab value of each of the printed spots.
Why would one need to measure anything? Just view the print (in differing illuminants if you so desire). The proof is in the print. That's the final process for many of us. It's pointless to measure anything, especially when at this point, the working space is a far removed step in the process to make the print.
You do realize that by the time you've gone from RGB working space to output profile, there's a step in between that has zero idea what the working space was. By the time the profile connection space comes into play, the RGB working space is history and gone from the scene.
But it is a lot easier just to inspect the mapping!
It is even easier just to look at the damn print!
-
You simply can't make blanket statements about perceptual rendering because they all differ. It is probably why the canned Epson profile for Glossy did a worse job than my custom profile on the Blue Balls (referenced in the forum post about color management misconceptions). A perceptual mapping my be better or worse based on the profile and how it was built and the image. That is why we soft proof before we make such decisions. Profiles only understand a solid color going from one color space to the other, it has zero idea about colors in context.
Absolutely correct - and I made this very point in an earlier post. The mapping table is dumb (well pretty dumb): it has no knowledge of the image. However the profile does 'know' the context: it is source to destination. The skill in creating a really good perceptual profile is to preserve the relationship between the colors as closely as possible while minimizing the color shifts. And so it is possible to make a statement about perceptual mappings ... to the extent that they conform to the ICC recommendations (pretty vague). The fact is that you cannot squeeze a peach into a grape without compressing the fruit.
[/quote]
IF that's the whole point of the discussion, then ProPhoto RGB, certainly with Adobe raw converters is the right answer for the encoding color space with the images I used.
Totally - you started off with an image with a very wide gamut so you should use a wide working space. No argument there.
Robert
-
The fact is that you cannot squeeze a peach into a grape without compressing the fruit.
And there is nothing wrong with that if you need a peach the size of a grape. If you don't, stick with the larger peach size.
-
Define right, tell us how a raw image falls into that container especially when the processing color space is a fixed, wide gamut based on ProPhoto. That's kind of absurd considering that the images don't have a gamut until processed from raw and encoded (at which time, it's all water under the bridge).
It's very easy to define the best working space post Lightroom. You just soft-proof with sRGB ... OOG. Then aRGB ... OOG. Then Beta RGB ... OK. So you either pick Beta RGB (or ProPhoto if you must) or adjust your image so that it comes within aRGB. If the image is not OOG in sRGB then pick that. If, while editing in Photoshop, you find that you are going OOG in sRGB then move up to aRGB or adjust your edit.
Yes it is subjective and useful when the final result IS THE PRINT itself! It is actually very easy; look at the prints side by side. You're making this far more complex and difficult than it needs to be. Looking at the print tells me exactly what's happening!
OK, that's not useful. Why would one need to measure anything? Just view the print (in differing illuminants if you so desire). The proof is in the print. That's the final process for many of us. It's pointless to measure anything, especially when at this point, the working space is a far removed step in the process to make the print.
You do realize that by the time you've gone from RGB working space to output profile, there's a step in between that has zero idea what the working space was. By the time the profile connection space comes into play, the RGB working space is history and gone from the scene. It is even easier just to look at the damn print!
I don't think I'm making it complex Andrew. I'm entirely convinced that your image is better left in ProPhoto than being converted to sRGB. I absolutely do not need to print to know that: it's self-evident because the image has very saturated colors well outside of sRGB, and your printer gamut is considerably larger than sRGB. Converting it to sRGB is doing it a serious injustice.
I also do not need to print to know that an image that is within sRGB will in no way benefit from being converted to ProPhoto before printing. If you really want to prove the point by printing (I don't) then take an image that is saturated in sRGB, convert it to ProPhoto and then print both using a perceptual mapping (WITHOUT reconverting the image to sRGB before printing).
This reminds me that I had another issue with your video: you converted the wide-gamut image to a small color space before printing. To compare like with like from a printing point of view, you should have converted the ProPhoto image to sRGB, then converted it back to ProPhoto and printed that image together with the sRGB image. Otherwise what you are doing is altering the image BEFORE printing and comparing this to the print of the unaltered image.
That's almost as bad as applying a gaussian blur to a copy of an image, printing it along with the original and saying: "Look ... the blurred image is blurred!".
Robert
-
And there is nothing wrong with that if you need a peach the size of a grape. If you don't, stick with the larger peach size.
Then we're in agreement :)
Robert
-
It's very easy to define the best working space post Lightroom. You just soft-proof with sRGB ... OOG. Then aRGB ... OOG. Then Beta RGB ... OK.
You'll never see OOG with ProPhoto so based on the above, that's always the right answer. Why go smaller, that's what you've failed to provide.
This reminds me that I had another issue with your video: you converted the wide-gamut image to a small color space before printing. To compare like with like from a printing point of view, you should have converted the ProPhoto image to sRGB, then converted it back to ProPhoto and printed that image together with the sRGB image.
Why on earth would I or anyone do that? It buys you nothing! I take the pint container and pour half of it out into the half pint container. Then I pour that half pint back to the larger container for what? Otherwise what you are doing is altering the image BEFORE printing and comparing this to the print of the unaltered image.
Yup, and that's proper color management! The idea is to show what you gain and lose by picking either ProPhoto OR sRGB for a working space before sending it thought the output profile. That's almost as bad as applying a gaussian blur to a copy of an image, printing it along with the original and saying: "Look ... the blurred image is blurred!".
But if the original was in need of blurring and the blurred print looked better, then the blur was the right answer. The proof again is in the print. Using sRGB produced an inferior print compared to using Prophoto RGB. Simple. I think you've missed the point entirely based on your 'convert to sRGB and back to ProPhoto' comment.
-
Actually I was about to stop before we all go completely gaga, but there is one point that keeps coming up that I would like to address. And that is, to paraphrase: “Adobe picked ProPhoto for Lightroom, they didn’t do it for a silly reason, so this means that ProPhoto is the best working space”.
If I was picking a working space for Lightroom I also would probably pick ProPhoto – simply because there is no way to predict what the gamut of every image will be. But it is quite easy to predict that the union of all of the gamuts of all the images that have been and will be processed will be very large. So the developer of a raw converter needs to pick a working space with a large gamut.
That does not mean that a large gamut is the best gamut for each individual image.
If the gamut of the image can be contained in a smaller working space then there is no loss of quality in converting it to the smaller working space.
So using a large working space as the (initial) container for the raw image is correct. (I’m sure Adobe will be relieved to hear me say that :)).
Robert
-
That does not mean that a large gamut is the best gamut for each individual image.
If the gamut of the image can be contained in a smaller working space then there is no loss of quality in converting it to the smaller working space.
Why do this? Produce a test whereby the final is output to a print where you can prove that after using the wide gamut processing within ACR or LR, encoding into something smaller is better. That's all you need to do. At that point, you've validated that one should if possible, view the image and compare it to the encoding space from raw. Otherwise you haven't.
I've got to go raw to some RGB working space after which I plan to work on it so I need a master image and working space that I can move forward with to ALL output needs. What encoding working space should I use?
-
Why on earth would I or anyone do that? It buys you nothing! I take the pint container and pour half of it out into the half pint container. Then I pour that half pint back to the larger container for what? ck to ProPhoto' comment.
If the prints are identical then you will have proved me wrong ... that is what it will prove (or disprove).
Using sRGB produced an inferior print compared to using Prophoto RGB.
Quite correct - I have already agreed and are happy to do so again: you damage an image by squeezing it into a smaller space before outputting it to a larger space. Of course the sRGB print will look worse: you've chopped the legs off it.
Robert
-
Why do this? Produce a test whereby the final is output to a print where you can prove that after using the wide gamut processing within ACR or LR, encoding into something smaller is better. That's all you need to do. At that point, you've validated that one should if possible, view the image and compare it to the encoding space from raw. Otherwise you haven't.
Andrew ... this has been fun but I think we've hacked this one to death. I really have answered your question several times already on this very page. Answering it again is going to drive us loopy :)
Robert
-
I really have answered your question several times already on this very page. Answering it again is going to drive us loopy :)
I know you think you did, anyone else here agree?
-
I know you think you did, anyone else here agree?
Before everyone jumps on the bandwagon and disagrees I seriously suggest you look at the ArgyllCMS information and ask Graham Gill for his views on the subject.
Robert
-
Before everyone jumps on the bandwagon and disagrees I seriously suggest you look at the ArgyllCMS information and ask Graham Gill for his views on the subject.
How will that change the processing of my images in ACR/LR and output to my printer using a profile that wasn't a mile from ArgyllCMS? All I (and at least one other person) is asking for is proof of concept using our tools and workflow that suggest your idea of using a smaller gamut than ProPhoto RGB is going to produce a better print.
-
How will that change the processing of my images in ACR/LR and output to my printer using a profile that wasn't a mile from ArgyllCMS? All I (and at least one other person) is asking for is proof of concept using our tools and workflow that suggest your idea of using a smaller gamut than ProPhoto RGB is going to produce a better print.
ArgyllCMS is not relevant ... I use both Argyll and i1Profiler and the same issues are present with both. What is relevant is that Graham Gill, who, as I said, is the author of ArgyllCMS and is a recognized expert in the area is really worth listening to. He has forgotten more about profiles that either you or I know Andrew (I'm making an assumption here about your knowledge, which may not be entirely fair, but I base the comment on what you've been saying).
Robert
-
ArgyllCMS is not relevant ...
Neither is the link you provided (in terms of not using ProPhoto RGB for a smaller gamut working space).
-
OK, well I’ve devised a test that does demonstrate at least to some extent the issue we’ve been discussing.
I took a file with a sort of Granger Rainbow that I constructed myself in sRGB in 16-bit mode.
(http://www.irelandupclose.com/customer/LL/Granger-sRGB.jpg)
I then converted a duplicate of this image to ProPhoto.
I then converted both images to a destination profile (I used a Canson profile so it’s entirely 3rd-party and out of my control). The conversion was perceptual with BPC on in both cases. This is the data that would be sent to the printer: the job of the CMM is done.
I then placed one image above the other as layers in Photoshop and set the upper layer to Difference. I applied a Levels adjustment above the two layers to make the difference more apparent. This is what it looks like:
(http://www.irelandupclose.com/customer/LL/Difference-PP-sRGB.jpg)
The test is not conclusive as the differences could be due to rounding errors … or they could be due to the compression of the ProPhoto space to the smaller printer space. My guess is that the noise-like differences are due to rounding and the bands and lines and swirls due to compression. I don't think it's a coincidence that the biggest differences are at the dark end as the saturated dark colors have to be squeezed into a small volume.
The only conclusive way of doing this, to my mind, is to look at the mapping algorithm … or at the profile mapping using GamutVision or Chromix. This is a bit like asking to see a Black Hole … you can show the maths, you can show the stars twirling around seemingly nothing … but you can’t show the Black Hole. Or at least I can’t for this particular black hole :).
Robert
-
Neither is the link you provided (in terms of not using ProPhoto RGB for a smaller gamut working space).
You're a hard man to convince Andrew :). Here is a quote from the link I provided: "The typically expected behaviour of perceptual intent gamut mapping, is to compress any areas of the source gamut that lie outside the destination gamut, but for areas that fall within the destination gamut, change them as little as possible, consistent with keeping smooth and proportional with respect to the compressed colors. This preserves the source "look" as much as possible, while ensuring that out of gamut colors are smoothly brought within the destination gamut." (underline is mine).
That is the problem: you can't maintain smooth and proportional colors within the destination gamut if you have had to compress from a much larger color space without also compressing the colors inside the destination gamut. There are plenty of sophisticated algorithms that minimize this compression ... and the more successful ones probably do a good enough job that we can use ProPhoto and perceptual mapping without having to worry too much ... but then we are depending on very good profiles. There's no reason to assume that the profiles supplied by paper manufacturers, for example, would be this good.
Robert
-
That is the problem: you can't maintain smooth and proportional colors within the destination gamut if you have had to compress from a much larger color space without also compressing the colors inside the destination gamut. There are plenty of sophisticated algorithms that minimize this compression ... and the more successful ones probably do a good enough job that we can use ProPhoto and perceptual mapping without having to worry too much ... but then we are depending on very good profiles. There's no reason to assume that the profiles supplied by paper manufacturers, for example, would be this good.
And again, none of this has any bearing on the output, nor the options we have for mapping OOG to smaller colors using matrix profiles, or going from raw to an encoding color space using an Adobe raw conveter. Show us where the larger ProPhoto gamut from ACR/LR is an issue, and if possible, doing so such we can output the results and see this for ourselves. The Granger Rainbow doesn't work in that respect either. It didn't come from raw data or was processed from ACR/LR who's internal color space is processed using ProPhoto gamut.
You saw the video. Short of providing the raws, the Gamut Test File has all the data I can push out of the ACR pipeline. I can go smaller. And I can print both iterations. What can you provide in a similar fashion that supports your hypnosis that a smaller encoding from raw is going to produce a better master that can be printed and then converted to other color spaces for whatever need might arise.
You either don't want to see the workflow or can't. I've got raw data. I've want to process it with a product that uses ProPhoto gamut. I want all the color and tone available for all images so I can edit them in a working space then print them. I can pick ProPhoto or something smaller. Why should I pick smaller gamut from the raw processor? Illustrate that when I also need a wide gamut print output (any modern Epson will do), the smaller encoding space you suggest I pick produces a better print.
-
And again, none of this has any bearing on the output, nor the options we have for mapping OOG to smaller colors using matrix profiles, or going from raw to an encoding color space using an Adobe raw conveter. Show us where the larger ProPhoto gamut from ACR/LR is an issue, and if possible, doing so such we can output the results and see this for ourselves. The Granger Rainbow doesn't work in that respect either. It didn't come from raw data or was processed from ACR/LR who's internal color space is processed using ProPhoto gamut.
You saw the video. Short of providing the raws, the Gamut Test File has all the data I can push out of the ACR pipeline. I can go smaller. And I can print both iterations. What can you provide in a similar fashion that supports your hypnosis that a smaller encoding from raw is going to produce a better master that can be printed and then converted to other color spaces for whatever need might arise.
You either don't want to see the workflow or can't. I've got raw data. I've want to process it with a product that uses ProPhoto gamut. I want all the color and tone available for all images so I can edit them in a working space then print them. I can pick ProPhoto or something smaller. Why should I pick smaller gamut from the raw processor? Illustrate that when I also need a wide gamut print output (any modern Epson will do), the smaller encoding space you suggest I pick produces a better print.
As I've already said, Andrew, I'm not interested in doing prints to try to demonstrate this. I'm one of these people who believes the maths, especially when the maths is nothing more than a computer algorithm. If you look at a perceptual ProPhoto to Destination mapping with mapping vectors you will see how the data is being shifted. If you do the same thing with a smaller space like Adobe RGB you will see that the shifting is less. If you don't believe this then what can I say?
If you want your image to be in a state that it can, at a later stage, be output to any device you choose, not knowing at this stage what this device might be or how large its gamut might be, well then stay in ProPhoto ... of course. Keep your options open. But if you know what your output devices will be (web and printer with specific papers for me) and you want the best result then I think you would be wise to keep your image gamut/s as close to the output device/s as possible. But it's a free world out there (sort of) so why don't you stick to ProPhoto and I'll wander around picking the workspace that I think is best?
Robert
-
As I've already said, Andrew, I'm not interested in doing prints to try to demonstrate this.
Well then all you need to deal with is sRGB or Adobe RGB if screen output is your only goal. A lot of us here need a much wider gamut output. In fact, isn't this post about printing? Isn't the topic the gamut of a Canon printer?
If you look at a perceptual ProPhoto to Destination mapping with mapping vectors you will see how the data is being shifted.
I don't care (as long as the image appears as I desire). Color management isn't perfect (far from it). The proof is in the output. Show us where and how, going from ProPhoto to even Adobe RGB is an issue to the display (as long as we're using a wide gamut display system).
If you do the same thing with a smaller space like Adobe RGB you will see that the shifting is less.
OK, provide a raw image where I can process using both options and I'll let you know what I see on-screen.
Keep your options open.
Exactly WHY I use ProPhoto RGB and not Adobe RGB (1998) (the later is too small for output to my printer, something you say you don't care about. I do).
But if you know what your output devices will be (web and printer with specific papers for me) and you want the best result then I think you would be wise to keep your image gamut/s as close to the output device as possible.
Prove it! That's all I'm asking. And is this methodology now for print too (something you say you are not interested in testing)? Make up your mind. Again, for the 4th time. I've got a slew of raw images. Some very saturated. Some not. Some will be printed. Some will not. I've got a raw processor using ProPhoto gamut for all processing. I've got to pick an encoding color space. You seem to be suggesting ProPhoto is sometimes the wrong answer. Show us. Simple as that.
-
I tested some of this stuff years ago when using ppRGB was just coming into it’s own, (at the time I actually felt the size of the space was problematic because of issues I would see, only to discover it was from working in 8bit - a big deal back then because hard drive storage was immensely more expensive). I actually tried to find circumstances where files and prints would look better converted directly to sRGB and worked in Photoshop vs ppRGB. It just doesn’t happen. I tried 20 or 30 different shots, and the end results were virtually identical.
Certainly if you wreak havoc on your file in Photoshop in ppRGB the results will be ghastly. But for photographers who do that, forcing them into a smaller space won’t help ... they’ll come out bad anyway.
As far as the math, as a photographer I”m interested in the results. Just assuming the math may show a problem doesn’t mean it will in practical use. This doesn’t. In fact far more photographers get into trouble working in sRGB space on their files than they do prophotoRGB ... I print them every day here in my store.
To Andrews point, it’s clear that not using ppRGB can sometimes cost you in print quality and also limits potential future options. Is there an example in a photographer workflow where using ppRGB instead of a smaller space will result in a worse print/image? (other than circumstances I mentioned 2 paragraphs up)
-
I'll answer both of you (Wayne and Andrew) at the same time to save typing and since you're pretty well on the same page.
Firstly, of course I'm interested in printing. Almost all of the money I make from photography and painting comes from my prints and I print all of my images personally and with great care. What I'm not interested in doing is trying to demonstrate to you by doing prints what I can understand in theory and see in the profile mappings: I am one of these people who trusts logic and visual tools; clearly you are not, so it's up to you to do the demonstration, if you care to. If you don't, well then some people will believe you (probably most :)) and some may think that there is something in what I'm saying. For those who are undecided ... why don't you post a question to Graham Gill on argyllcms@freelists.org?
Secondly, I have not at all suggested that sRGB is a better working space for print than ProPhoto! That would be absurd. It's better for some images that have a very small gamut ... but of course it's much worse for images with a large gamut. But, fellas, there are intermediate workspaces out there ... and perhaps they are there for a good reason.
The example, in a photographer workflow, where using ProPhoto will result in a worse print (not necessarily a worse display) than a smaller workspace that fully (or nearly fully) covers the image gamut is, as I keep saying: the case where you print using a perceptual mapping. But you need to define what 'worse' is. It may look absolutely fine and you may be entirely delighted with it. By 'worse' I mean that the colors will have been shifted more, so, for example, the match to the display image (not the soft-proofed image as this will also have the shifted colors) will be worse. If your objective is to get a print that as closely as possible matches your monitor (not soft-proofed) image, then you may see greater differences with the large working spaces.
I fully accept and always have that using too small a workspace is even worse ... because then you will almost certainly get clipped colors if your image has saturated colors. Just to be clear.
As for proving my point, as Andrew is insisting I do :), no, I'm not interested in taking this any further. I've given you the information and I think it is correct (but I may be wrong!) and I think I have explained the logic as well as I can. If you don't trust logic ... well then we're never going to agree. Certainly Andrew's video has demonstrated that if you take an image with a wide gamut and scrunch it into sRGB you get flattening and banding etc. Of course, that's exactly what logic says you will get: a relative mapping will do just that, whack the head down into the shoulders. It doesn't in any way prove that ProPhoto is a better choice for all images: only that a) it is a better choice for this particular image, and b) don't convert to a smaller working space if your image gamut is wider than the smaller space.
Robert
-
Secondly, I have not at all suggested that sRGB is a better working space for print than ProPhoto! That would be absurd. It's better for some images that have a very small gamut ... but of course it's much worse for images with a large gamut. But, fellas, there are intermediate workspaces out there ... and perhaps they are there for a good reason.
Such as? The question of the day which remains unanswered.
The example, in a photographer workflow, where using ProPhoto will result in a worse print (not necessarily a worse display) than a smaller workspace that fully (or nearly fully) covers the image gamut is, as I keep saying: the case where you print using a perceptual mapping.
Not seeing that, not with my images sorry. I know you may feel this is true based on what you've read and that's fine. It's not what I'm seeing. And again, the proof is in the print. If I don't like the Perceptual mapping, I don't use it. Simple as that.
But you need to define what 'worse' is.
That's subjective but then so is a color print.
You've got this idea about smaller than ProPhoto gamut working space being beneficial and that may be true, but you've failed to provide a way to backup that claim I can see. You seem somewhat more interested in gamut maps and what authors of color management software say than what the output looks like which is fine. But I'm a photographer first, a color geek 2nd and what the print or display looks like takes the prize before any gamut map. You kind of remind me of the photographer more interested in the image histogram than the image itself in terms of evaluating image quality. And unless the gamut plotter you use acts like ColorThink, I don't trust it at all for this evaluation. But even if it does behave the same way, the rubber hits the road when solid pixels map in context and we view them, either on-screen or on a print. So if you have some basis to back up your ideas that we can use to evaluate what you're suggesting, and do so with images we can look at, you're entitled to that opinion but it may not be shared by others!
As for proving my point, as Andrew is insisting I do :), no, I'm not interested in taking this any further.I've given you the information and I think it is correct (but I may be wrong!) and I think I have explained the logic as well as I can. If you don't trust logic ... well then we're never going to agree.
I trust what I can see to judge the qualities of an image workflow and you haven’t provided any means to do that. Certainly Andrew's video has demonstrated that if you take an image with a wide gamut and scrunch it into sRGB you get flattening and banding etc. Of course, that's exactly what logic says you will get: a relative mapping will do just that, whack the head down into the shoulders.
You don't have to know squat about rendering intents or color management to conduct my test and see the differences. That's where what you and I propose differ. It's not necessary to understand anything about what happens under the hood, just take one file, convert to another working space and make two prints. View, decide what looks best. Easy breazy. That's all we're asking of you but at this point, I don't think that's going to happen so let's move on.
-
Firstly, of course I'm interested in printing. Almost all of the money I make from photography and painting comes from my prints and I print all of my images personally and with great care. What I'm not interested in doing is trying to demonstrate to you by doing prints what I can understand in theory and see in the profile mappings: I am one of these people who trusts logic and visual tools; clearly you are not, so it's up to you to do the demonstration, if you care to.
As I mentioned, been there done that. And I could not demonstrate it. It's great you trust "logic", but logic doesn't always equate to reality. And I don't know why it's up to anyone else to demonstrate your point of view (and in fact I don't think it can be done ... well, never say never but if so the circumstances would probably be extremely rare and unique.)
Secondly, I have not at all suggested that sRGB is a better working space for print than ProPhoto! That would be absurd. It's better for some images that have a very small gamut ... but of course it's much worse for images with a large gamut. But, fellas, there are intermediate workspaces out there ... and perhaps they are there for a good reason.
Well, the reasons the for the existence of sRGB and AdobeRGB have nothing to do with a photographers workflow and providing an "intermediate option. They were created for specific purposes that have nothing to do with a photographers workflow and current technology. (as opposed to ProPhotoRGB which was specially created for digital capture/printing technologies to be future proof, so the main goal was to try and make sure all naturally occurring colors could be defined).
The example, in a photographer workflow, where using ProPhoto will result in a worse print (not necessarily a worse display) than a smaller workspace that fully (or nearly fully) covers the image gamut is, as I keep saying: the case where you print using a perceptual mapping. But you need to define what 'worse' is. It may look absolutely fine and you may be entirely delighted with it. By 'worse' I mean that the colors will have been shifted more, so, for example, the match to the display image (not the soft-proofed image as this will also have the shifted colors) will be worse.
Again, while perhaps theoretically true, but not demonstrable. It just doesn't happen - we're not cramming the entire ppRGB space into an output space. The mapping is relative to the distance the colors are out of gamut which is rarely that extreme. And I think most photographers don't use perceptual that often ... guessing I use it only about 5% of the time. And when I do, starting over in a smaller space which may contain the gamut of the file doesn't equate in a better image (tried that a few times over the years as well and I've never seen a visual difference)
If your objective is to get a print that as closely as possible matches your monitor (not soft-proofed) image, then you may see greater differences with the large working spaces.
Why would that be my goal? My goal is a perfect print, and I want the display help me arrive there and provide some predictability and ease the workflow. But a perfect match to a display is never what I'm after. If my print has a little more "color" in a region because the printer gamut is larger there, I've never seen that cause a problem, and I certainly don't want to throw that data away. Now certainly there are some workflows that have other priorities, but my final judgement/edits/tweaks come from examining prints. Now I don't have to do much tweaking from the initial test print too often, so the system is working nicely.
I fully accept and always have that using too small a workspace is even worse ... because then you will almost certainly get clipped colors if your image has saturated colors. Just to be clear.
Yes we know that. And we've never disagreed that using a smaller space if it will contain all the data and modified data doesn't work as well. And when you mentioned "clipped" colors because they are saturated, the colors we are talking about are extremely important because they help you pull open the shadows. To me that's the most important aspect of what the current printers offer in expanded gamut. But you can't do that in aRGB.
The discussion really boils down to two points. From your first post "If you go for a larger working space like ProPhoto you are really asking for trouble (this is entirely my opinion!)". I don't believe that opinion is shared by many, and I believe is very misleading. Anyone who will get into trouble with this workflow with modern raw processors and photoshop will get into trouble anyway. Secondly, whether or not using ppRGB for files which can be contained in smaller spaces is detrimental to the final image, and working in a space closer to the size of the data will deliver a better result (print). And perhaps while theoretically true, I"ve never seen anyone be able to demonstrate this. This second point is really where the main discussion has ensued, and I'm not sure why we should accept your opinion (and perhaps that of a few others) when empirically through printing hundreds of images over the years we've never seen any evidence to support the idea.
As for proving my point, as Andrew is insisting I do :), no, I'm not interested in taking this any further.
Agreed no point in taking this any further. Great you trust logic, but logic and even scientific evidence don't always equate to something that matters. That's where I think we disagree the most, you believe that this is an issue, where most would feel it's not anything to be concerned with because you just can't see the difference. As far as demonstrating it, you are the one who is challenging current thinking and practice and telling others your way is better, wanting people to accept it on "logic" and some theoretical math. But if you can't show it, then is it really an issue to be concerned with? Maybe it is there, but if it were a problem, you would think it would confound and frustrate many people over the years that would cause us to rethink our workflows (as using ppRGB instead of theses other spaces did at one point in time).
If there were an easy way to do it, maybe it would be worth doing (still doubting it). But I just can't see any reason to muck up the workflow trying to figure out if my image needs to be in ppRGB, or whether sRGB or aRGB might be enough. No point, because just staying in ppRGB isn't a problem.
-
After reading through this thread here is my conclusion:
1) It is theoretically possible that using a color space that is too large may result in a print that is suboptimal compared to using a color space that is the right size
2) Experienced printers have not been able to find a practical example of this in spite of looking for it
3) The poster advancing the theory is not interested in finding even a single image where the differences in prints support his hypothesis, making one wonder whether he would be able to do it
4) Using a working color space that is smaller than the gamut of the output device (in this case, the printer) will definitely cause important color information to be lost, and for images of nature it is easy to find such cases (e.g., poppies)
Conclusion: I will continue using Prophoto as my working color space for all images until at least one example is provided that a better print (i.e., truer to the colors in the image) comes from using a smaller color space.
PS I like theory as much as the next guy, but we are talking about perceptible visual differences in prints as the gold standard. If a discerning eye can't see it, then it really doesn't matter.
-
If there were an easy way to do it, maybe it would be worth doing (still doubting it). But I just can't see any reason to muck up the workflow trying to figure out if my image needs to be in ppRGB, or whether sRGB or aRGB might be enough. No point, because just staying in ppRGB isn't a problem.
And this is the crux of the matter...is there a "better" wide gamut RGB working space? Maybe, but if you are using ACR/LR, you're already working in ProPhoto RGB (albeit with gamma 1). Is it worth going from PP RGB into some other working space? If you are trying to eeek out the most of your working space, maybe, but, what does the image look like? Are there colors that are critical for the image to succeed that will be better handled by ARGB or Beta RGB? Really? Is it worth turning your workflow upside down (meaning breaking your workflow in order to eeek out some additional color rendering based on various perceptual rendering intent capabilities)?
Penny wise, pound foolish...what you think you might be gaining is wasted by spending unnecessary steps in the workflow in order to gain theoretical improvements that may or may not show up in the final print.
You have a large gamut output device...you have a large gamut capture device. It behooves you to use a working space that contains both...PP RGB does and has been chosen by one of the smartest imaging scientists I know as the working space of ACR & LR–Thomas Knoll. So far, none of the arguments have risen to the level to making me willing to change my workflow. It's all fools gold...
-
Such as? The question of the day which remains unanswered. Not seeing that, not with my images sorry. I know you may feel this is true based on what you've read and that's fine. It's not what I'm seeing. And again, the proof is in the print. If I don't like the Perceptual mapping, I don't use it. Simple as that. That's subjective but then so is a color print.
Agreed - I also almost never use perceptual for the very reason that it causes color shifts (the whole reason behind it is to maintain the relationship between colors, not to retain the Lab values of the colors). I always use Relative unless Perceptual really does look better, which is rare but some canned profiles I've used with fine art matte seem better in Perceptual. At any rate, to the extent possible it is really much better not to print images that are OOG for our printer/paper: the biggest issue with very wide gamut working spaces is that it makes it relatively easy to go OOG (for the print), without realizing it because we can't see the OOG on our monitors without turning gamut warning on (which is something I always do, btw); smaller working spaces limit the extent to which we can inadvertently go OOG, as well as making the job of the CMS easier.
This brings us to another point which has been hijacked by the Perceptual issue: and that is what happens when you have a large gamut image that is mapped using Relative to the smaller print gamut: well, as you demonstrated in your video, Andrew, what you get is clipping, flattening and banding. I hope that you will agree especially as this is really the main point of your video.
So, here is a test which is a much fairer test (even though it is absurd to be scrunching an image with such a wide gamut into a small sRGB gamut):
(http://www.irelandupclose.com/customer/LL/sr-v-pp.jpg) Right-click to view full size.
What I've done here is first of all to convert the image to the destination print space using a perceptual mapping (relative would be fine too). What this does is limit the gamut to the destination (no disagreements I hope!). I then converted the left copy back to ProPhoto and the right image to sRGB using a perceptual mapping. So the ProPhoto image should have essentially little change from the print mapped image as it has a much wider color space, whereas the sRGB image will be scrunched down somewhat.
I think you will see that there is now very little difference between the images, even though one is back in ProPhoto and the other now in sRGB. The main reason why there is such a huge difference between these images and the ones on Andrew's video ... is NOT the conversion to the print space: it is that, by doing it this way, I have avoided the Relative Colorimetric head-chopping act of converting the image from ProPhoto to sRGB.
OK, I know, I know ... you're going to say 'show it to me on print'. Well, I can't, but here they are soft-proofed using Relative Colorimetric, BPC, Simulate Paper:
(http://www.irelandupclose.com/customer/LL/sr-v-pp.jpg)
Not a hell of a lot in the difference, is there?
You've got this idea about smaller than ProPhoto gamut working space being beneficial and that may be true, but you've failed to provide a way to backup that claim I can see. You seem somewhat more interested in gamut maps and what authors of color management software say than what the output looks like which is fine. But I'm a photographer first, a color geek 2nd and what the print or display looks like takes the prize before any gamut map. You kind of remind me of the photographer more interested in the image histogram than the image itself in terms of evaluating image quality. And unless the gamut plotter you use acts like ColorThink, I don't trust it at all for this evaluation. But even if it does behave the same way, the rubber hits the road when solid pixels map in context and we view them, either on-screen or on a print. So if you have some basis to back up your ideas that we can use to evaluate what you're suggesting, and do so with images we can look at, you're entitled to that opinion but it may not be shared by others! I trust what I can see to judge the qualities of an image workflow and you haven’t provided any means to do that. You don't have to know squat about rendering intents or color management to conduct my test and see the differences. That's where what you and I propose differ. It's not necessary to understand anything about what happens under the hood, just take one file, convert to another working space and make two prints. View, decide what looks best. Easy breazy. That's all we're asking of you but at this point, I don't think that's going to happen so let's move on.
The problem with what you suggest, Andrew, is that every image is different, so to prove your point by printing is very time-consuming and expensive ... and seeing as how we're on different sides of the Atlantic it makes it difficult for us to view the same prints. But returning to the color geek v. real life photographer: the reason I became interested in looking to see what is under the hood is that when I started off I had no idea about color management and I made very stupid mistakes - like, for example, using the very widest color space I could get because bigger naturally seemed better ... only to find that my prints were way more muted than they should have been, or the colors were just wrong. So you then go through the process of trying to figure out: is it the printer, the monitor, the image ... what's going wrong? And you find out that if you have an sRGB monitor (which I did at the time) and you edit in ProPhoto ... well the image might look great on screen (after all, you've edited it so that it does look fine) ... but there are bunches of colors there you can't see. When you then print you're then at the mercy of the CMS - and what can it do but the best of a bad situation?
As for the Gamut Plotter I use (it is a lot more than just a gamut plotter), it's GamutVision from Imatest. It has features that Chromix does not and vice versa, but Imatest is a serious company in the image testing business, as I'm sure you know, so I think it's reasonable to assume that GamutVision is reasonably reliable.
Robert
-
As I mentioned, been there done that. And I could not demonstrate it. It's great you trust "logic", but logic doesn't always equate to reality. And I don't know why it's up to anyone else to demonstrate your point of view (and in fact I don't think it can be done ... well, never say never but if so the circumstances would probably be extremely rare and unique.)
I really don't care if you or anyone else attempts to prove or disprove me ... it's just that Andrew keeps on at me to PROVE my point. I feel no need to do so beyond what I've already done. I also agree with you that demonstrating the issues with prints is very difficult ... which is why it's a very good idea to understand what is happening under the hood.
Well, the reasons the for the existence of sRGB and AdobeRGB have nothing to do with a photographers workflow and providing an "intermediate option. They were created for specific purposes that have nothing to do with a photographers workflow and current technology. (as opposed to ProPhotoRGB which was specially created for digital capture/printing technologies to be future proof, so the main goal was to try and make sure all naturally occurring colors could be defined).
Funny you should say that when Adobe RGB was created by Adobe, specifically to address photographic needs that went beyond the (hardware-driven) sRGB space.
And you should know, surely, that ProPhoto does NOT define all naturally occurring colors (or more correctly, all colors that we can see). Here is a simple demonstration of that:
(http://www.irelandupclose.com/customer/LL/pp.jpg)
ProPhoto is the triangle, the horseshoe is the typical extent of human vision. ProPhoto not only does not cover all of human vision, but it goes beyond to what (probably) no-one can see. The reason for it is to cover a large chunk of human vision ... but why did they stop where they did? Why not go the whole hog and cover the whole of human vision, accepting that with a triangular gamut this will (as does ProPhoto) include colors outside our vision? Seems to me that if you want big, ProPhoto just isn't big enough!
The mapping is relative to the distance the colors are out of gamut which is rarely that extreme.
Well, with Perceptual the mapping is relative to the gamuts (unless the profile maker cheats a bit and does a mix of relative/perceptual).
And I think most photographers don't use perceptual that often ... guessing I use it only about 5% of the time. And when I do, starting over in a smaller space which may contain the gamut of the file doesn't equate in a better image (tried that a few times over the years as well and I've never seen a visual difference)
Your images are probably not very saturated so you should be fine (you will be making very limited use of the additional gamut in ProPhoto). But there are photographers (or graphic designers and painters) who do use very saturated colors ... and for these perceptual may be better as it does attempt to preserve the relationship between the colors, whereas relative will clip the OOG colors (which may look much worse).
But a perfect match to a display is never what I'm after.
Admittedly a perfect match is pretty much impossible because we are dealing with fundamentally different devices. However the goal should surely be to see what you are going to print and for your print to be as close as possible to what you saw. In my case I can say that (having spent quite some time coming to grips with it) that I can get an almost perfect match between my prints and my display. It's a revelation when you achieve that because you can then be confident that when you hit the button you'll get the print you want.
It is of course true that this matching will only be correct for a particular viewing condition. However, fortunately our eyes adapt to different lighting and compensate to a large extent automatically, so on the whole if the print looks good under one light it will most likely look good under another.
And when you mentioned "clipped" colors because they are saturated, the colors we are talking about are extremely important because they help you pull open the shadows. To me that's the most important aspect of what the current printers offer in expanded gamut. But you can't do that in aRGB.
Of course if you've clipped the colors you aren't going to get them back! If you want to pull open the shadows you should absolutely do this at the raw conversion stage ... don't even wait to have your image in ProPhoto because at that point you've lost data already.
The discussion really boils down to two points. From your first post "If you go for a larger working space like ProPhoto you are really asking for trouble (this is entirely my opinion!)". I don't believe that opinion is shared by many, and I believe is very misleading. Anyone who will get into trouble with this workflow with modern raw processors and photoshop will get into trouble anyway. Secondly, whether or not using ppRGB for files which can be contained in smaller spaces is detrimental to the final image, and working in a space closer to the size of the data will deliver a better result (print). And perhaps while theoretically true, I"ve never seen anyone be able to demonstrate this. This second point is really where the main discussion has ensued, and I'm not sure why we should accept your opinion (and perhaps that of a few others) when empirically through printing hundreds of images over the years we've never seen any evidence to support the idea.
If you know what you're doing then ProPhoto is fine. My original response was to this post by mstevensphoto who asked: "Hi all, I'm reading my literature and see that the ipf8400 has a 5-6% wider gamut but I don't see any comparison of the printer to the sRGB space. Does anyone know if it is able to print more colors than are in srgb (thus making me work in adobe98) or how the two line up?" With all due respect to mstevensphoto, he, like a great many photographers, clearly doesn't know much about working spaces or he would not have asked the question. The fact is that the iPF6400 has a much bigger space than Adobe RGB and also a much smaller space than sRGB ... depending on what papers you print on and what part of the image you are looking at (for example, the printer doesn't come close to sRGB at the dark end on a matte paper).
So, if you are responding to someone who doesn't really understand the pros and cons of workspaces ... would you recommend ProPhoto? Not me. Or at least if I did I would accompany the recommendation with information on what to do to make sure that he doesn't unknowingly ruin his images by going way out of gamut.
Agreed no point in taking this any further. Great you trust logic, but logic and even scientific evidence don't always equate to something that matters.
Are you a member of the Flat Earth Society? :)
That's where I think we disagree the most, you believe that this is an issue, where most would feel it's not anything to be concerned with because you just can't see the difference.
All you can say here is that YOU can't see the difference. Our eyes vary hugely in their ability to detect subtle color differences.
As far as demonstrating it, you are the one who is challenging current thinking and practice and telling others your way is better, wanting people to accept it on "logic" and some theoretical math.
Whose 'current thinking and practice', and is this the best practise? Andrew's, yes ... who else who considers themselves experts in color management? Bruce Linbloom, maybe (makes you wonder why he created Beta RGB! http://www.brucelindbloom.com/index.html?BetaRGB.html).
I don't want people to accept what I say. I'm a scientist by training and I firmly believe that we should all come to our own conclusions based on the evidence we are presented with. And yes, I do think that logic and maths is one of the best ways of cutting through the bullshit. It's not like we're talking theoretical physics and sub-atomic particles here ... we are talking in the realms of 2+2=4, and there is no arguing with CMS mapping algorithms: these are computer programs and they are cast in concrete, so to speak. As Jeff Schewe said in one of his post or essays or something, GIGO! Garbage in Garbage Out. If you send garbage to your printer, expect a less than optimal result. Looking at the profile and seeing how well this encompasses your image gamut is one very good test of the integrity of what you will be sending to your printer.
The problem we have is that we don't know (at least I don't) XRite's algorithms (for example). However we can totally know ArgyllCMS's algorithms because Graham Gill has very generously made his software open-source. I think few people would argue that his algorithms are inferior to XRite's (unless the person is an XRite employee, perhaps). On the contrary, a bit like RawTherapee, ArgyllCMS has a wealth of options that are simply not available with XRite and which, for example, give us the possibility of generating image-specific profiles. There are very few systems out there at the moment that have that level of sophistication.
But if you can't show it, then is it really an issue to be concerned with? Maybe it is there, but if it were a problem, you would think it would confound and frustrate many people over the years that would cause us to rethink our workflows (as using ppRGB instead of theses other spaces did at one point in time).
If there were an easy way to do it, maybe it would be worth doing (still doubting it). But I just can't see any reason to muck up the workflow trying to figure out if my image needs to be in ppRGB, or whether sRGB or aRGB might be enough. No point, because just staying in ppRGB isn't a problem.
I think I have shown that there is an issue, or at least a potential one. A very simple case was very nicely demonstrated by Andrew when he (very unkindly) did a relative colorimetric conversion of a ProPhoto image to sRGB (in his video): he chopped the top off the poor image's head and ended up with something that looked as flat as a pancake. Where he went wrong is in blaming sRGB for that: the fault was his, not sRGB's.
If you're happy with ppRGB then totally fine ... I have ABSOLUTELY NO problem with that. I am NOT trying to convince you, or anyone, else to change. I am just attempting to correct what I think is misinformation.
Robert
-
After reading through this thread here is my conclusion:
1) It is theoretically possible that using a color space that is too large may result in a print that is suboptimal compared to using a color space that is the right size
2) Experienced printers have not been able to find a practical example of this in spite of looking for it
3) The poster advancing the theory is not interested in finding even a single image where the differences in prints support his hypothesis, making one wonder whether he would be able to do it
4) Using a working color space that is smaller than the gamut of the output device (in this case, the printer) will definitely cause important color information to be lost, and for images of nature it is easy to find such cases (e.g., poppies)
Conclusion: I will continue using Prophoto as my working color space for all images until at least one example is provided that a better print (i.e., truer to the colors in the image) comes from using a smaller color space.
PS I like theory as much as the next guy, but we are talking about perceptible visual differences in prints as the gold standard. If a discerning eye can't see it, then it really doesn't matter.
2) That's a very generalized and unfounded statement. Could you give us a breakdown of how many experienced printers (and who these are) who've done this massive investigation? And could we see their published results please?
3) I've given a demonstration in one of my earlier posts where I showed what happens when you convert an image from sRGB to ProPhoto and then convert both of these to the print output. What more do you want? If you think it's easy to prove by printing that larger color spaces causes more shifting when using a perceptual mapping (especially when we are all separated by thousands of kilometers) ... well, think again.
4) Totally untrue. Using a working space that is smaller than the gamut of the image will result in a loss of colors, using a working space that is smaller than the printer's gamut will result in no loss of colors. Yes, if your image has poppies then I would recommend ProPhoto as a working space (but make sure you turn on your printer-space gamut warning!!).
Showing ONE example of an image that suffers from too large a working space isn't going to change your views ... you will want another and another and another, and I for one do not have the time or inclination to do this work for you since I do not need this sort of proof myself. If you're happy with your workflow then that's fine, really, I mean it ... I'm not a color management evangelist like Andrew and I'm not trying to convince anyone that they should change their working practices or that they should agree with me. But I will certainly defend myself and if I think there is misinformation being broadcast then I won't be too shy to point it out, as I have here.
Robert
-
And this is the crux of the matter...is there a "better" wide gamut RGB working space? Maybe, but if you are using ACR/LR, you're already working in ProPhoto RGB (albeit with gamma 1). Is it worth going from PP RGB into some other working space? If you are trying to eeek out the most of your working space, maybe, but, what does the image look like? Are there colors that are critical for the image to succeed that will be better handled by ARGB or Beta RGB? Really? Is it worth turning your workflow upside down (meaning breaking your workflow in order to eeek out some additional color rendering based on various perceptual rendering intent capabilities)?
Penny wise, pound foolish...what you think you might be gaining is wasted by spending unnecessary steps in the workflow in order to gain theoretical improvements that may or may not show up in the final print.
You have a large gamut output device...you have a large gamut capture device. It behooves you to use a working space that contains both...PP RGB does and has been chosen by one of the smartest imaging scientists I know as the working space of ACR & LR–Thomas Knoll. So far, none of the arguments have risen to the level to making me willing to change my workflow. It's all fools gold...
Well, you're not working in ProPhoto RGB in Lightroom: you're working on the raw data. ProPhoto is being used to render the image, but we do have the choice of workspaces when we export the image or open it into Photoshop. And as you well know, none of our monitors can display ProPhoto, so how can we be working on something that we can't see? Lightroom wouldn't have soft-proofing and gamut warnings if we could. The reason for using ProPhoto in Lightroom is obvious, as I've already pointed out: the working space has to cover all possible images, past and future, from all possible photographers, covering all possible subjects, for all possible output devices. Only a large working space can hope to do that (and ProPhoto is not large enough to do so, as you know).
A good workflow will ALWAYS check for OOG. If you do not then you are not following good practice and as a result you will at some point hit some ugly results. Once you've checked for OOG you already know the gamut extent of your image. The choice of working space is then trivial. It might add a few seconds to your work, but compared to the time you spend editing the image it's NOTHING. Just pick a working space that comfortably contains your image ... what's so hard about that?
Eking out the last drop of quality out of images is really important to a lot of us. Whether that is composition, capture technique, sharpening or detail recovery, processing, printing ... they are all important. It may be that choosing a very large working space as your standard working space is pretty OK - if you are careful and know what you are doing. Andrew himself has said that the bitch is the monitor: it can't display saturated colors that can be captured and printed. So, we have a choice: we accept that we won't be able to see some of the colors in the image until we print so that we may well then need to do at least one proof print, and perhaps several; or we try to keep things within the monitor gamut so that we can have a high degree of confidence that we will only need to do one print, accepting that we will for some images sacrifice some colors; or we do both depending on the image. If I'm going to print poppies then I will use ProPhoto and accept that I may have to do a couple of prints before I get the colors right and get rid of the banding; if I'm going to print a general landscape (that almost always falls well withing Adobe RGB) then I'll use Adobe RGB. If I was a portrait photographer then I would definitely use Adobe RGB (unless the bride had a poppy in her hair :)).
So by all means Jeff, do stick to ProPhoto: it seems to be serving you well and I think you do know all about OOG etc., so you won't be doing stupid things with your image.
Robert
-
Funny you should say that when Adobe RGB was created by Adobe, specifically to address photographic needs that went beyond the (hardware-driven) sRGB space.
Funny you should think that since Adobe RGB (1998) was a typo based on preliminary specs of SMPTE 240M (a proposed editing space for HD video). Seems Mark Hamburg was surfing the web one day for RGB editing spaces and found the spec. Unfortunately, there were typos in two the the color coordinates listed. Course, Adobe didn't find that out till AFTER Photoshop 5 actually shipped. So, Adobe changed the the name from SMPTE 240M to Adobe RGB (1998).
See, Adobe didn't create the color space to address photographic needs...it created Adobe RGB (1998) by accident.
On the other hand, PP RGB was created by Kodak after a lots of research specifically meant to address the needs of editing photographs.
See the folly here?
-
Funny you should think that since Adobe RGB (1998) was a typo based on preliminary specs of SMPTE 240M (a proposed editing space for HD video). Seems Mark Hamburg was surfing the web one day for RGB editing spaces and found the spec. Unfortunately, there were typos in two the the color coordinates listed. Course, Adobe didn't find that out till AFTER Photoshop 5 actually shipped. So, Adobe changed the the name from SMPTE 240M to Adobe RGB (1998).
See, Adobe didn't create the color space to address photographic needs...it created Adobe RGB (1998) by accident.
On the other hand, PP RGB was created by Kodak after a lots of research specifically meant to address the needs of editing photographs.
See the folly here?
Yes, it's really a crazy world! Then you have people like Bruce Lindbloom creating Beta RGB specifically to address the editing of photographs ... and what do you know? he comes up with a smaller space than ProPhoto! Makes you wonder, doesn't it. Perhaps we should cut the b-s and use Lab seeing as how that, at least, covers human vision and is device independent. Maybe your friend Thomas Knoll can get things moving in that direction :).
Robert
-
Yes, it's really a crazy world! Then you have people like Bruce Lindbloom creating Beta RGB specifically to address the editing of photographs ... and what do you know?
And you got that data point where? It's simply another RGB editing space, nothing more.
As for the Gamut Plotter I use (it is a lot more than just a gamut plotter), it's GamutVision from Imatest. It has features that Chromix does not and vice versa, but Imatest is a serious company in the image testing business, as I'm sure you know, so I think it's reasonable to assume that GamutVision is reasonably reliable.
Specifically I'm only interested in how it plots gamuts, not other features:
http://www.colorwiki.com/wiki/Color_Management_Myths_26-28#Myth_26
Even if the product you use does this, it's no proof of anything you've written about using a smaller encoding from ProPhoto in an Adobe raw processor that uses it in the first place.
Carl Sagan: "Extraordinary claims require extraordinary evidence.
Your claim isn't extraordinary but it has no evidence either.
-
Hi Robert,
I have mentioned this before to you. Maybe you should look into it again. My good friend Joseph Holmes has designed 5 RGB working spaces specifically for digital capture, which are input centric. You can read more about them here: http://www.josephholmes.com/profiles.html
Dcam 3 might be of interest to you, since it encompasses more real world colors than Adobe RGB.
Dcam 5 does include all of the human visual gamut (per Xxy D50 space, according to Joseph Holmes).
-
And you got that data point where? It's simply another RGB editing space, nothing more. Specifically I'm only interested in how it plots gamuts, not other features:
http://www.colorwiki.com/wiki/Color_Management_Myths_26-28#Myth_26
Even if the product you use does this, it's no proof of anything you've written about using a smaller encoding from ProPhoto in an Adobe raw processor that uses it in the first place.
Carl Sagan: "Extraordinary claims require extraordinary evidence.
Your claim isn't extraordinary but it has no evidence either.
Well Andrew, I don't think a ColorWiki article by Steve Upton is going to sway me right, left, up or down as I hardly think that it is unbiased. However ... here is what he says:
Why would anyone ever want to choose a working space that is larger than you can print?
Input Centric
This is where people want to capture as much of the original film (or scene) as possible. They choose large working spaces (much larger than the monitor gamut) and archive high-bit images for the day when printers catch up with their desires. Monitors, printers and presses are necessary evils that all degrade the appearance of their work. If they have the ability they will fill a whole CD with one scanned image. You might guess that this is where photographers often reside.
Output Centric
This is where the final print is the deciding factor in workflow decisions. Working spaces like ColorMatch are considered plenty big enough to contain all the colors one would want to print. So working spaces are chosen that will contain the gamut of a press and nothing more. Much of their work is done in CMYK (in-gamut by definition) and they wonder why anyone would bother capturing color that can't be printed. As you can imagine, prepress and printing folks are in this group.
Display-Centric
This is where people just want what's printed to match what's on the screen. Computer artists, 3D artists, video editors and consumers tend to fall into this group.
and his recommendations are:
In color management there is often no single correct way to do things. What we do suggest is a few things that will apply to all:
- Choose a working space that is just large enough to contain your imagery; any bigger and you're wasting space.
- If you can, choose a standard working space like sRGB or AdobeRGB. It makes file exchange and discussions easier
- Avoid converting between working spaces as the conversions don't deal with out-of-gamut colors well
- If the entire world used sRGB PROPERLY, color quality would go up significantly. What this means is that many color problems are not due to working space choices.
So perhaps you should choose your quotes more carefully when you are attempting to defend your own position.
As for Bruce Lindbloom and Beta RGB: just read http://www.brucelindbloom.com/index.html?BetaRGB.html. In this Bruce says:
One important characteristic would be that the working space is suffiently large that it can properly encode (or contain) all colors that are important to an application. This implies "larger is better."
Another attribute, which conflicts with the above, is that the working space should be as small as possible, so that quantization errors may be minimized. This implies "smaller is better."
What I would add to that, needless to say, is that quantization issues are only a minor part of the problem, gamut compression and clipping being a far greater issue. However, I think Bruce is a serious heavyweight in the color management area, and one who has no axes to grind or vested interests in what he says, as far as I know, so it isn't unreasonable to pay some attention to what he says (and to be fair, he does not appear to be someone much given to opinion).
The problem with our discussion is that, every time I try to answer one of your points, you ignore what I have said or go back to your original 'Prove It!' stance. Why don't you go back on some of the posts I've made and address these, instead of simply repeating yourself? I have done my best to show that what I am saying regarding working spaces is not just hot air; I am certainly not making 'extraordinary claims' (even Steve Upton appears to agree with me!) ... but I just get the same old song back from you. I'm sorry if I have to some extent torpedoed your video - but I'm sure you will agree that if the end result is a better balanced recommendation that it will have been worth putting up with the pain.
Robert
-
Hi Samuel,
Yes, thanks, I did have a look and Joseph seems to make some good, balanced points (although I have to say I haven't carefully read all of his articles). For example, he says:
When a space is designed, the gamut of the colors being mapped into it is more important to take into account than the gamut of the space into which colors will later be mapped for output. Also, it is important that even colors which will ultimately prove to be outside of your printer's gamut are not clipped first (by having entered a too-small working space), because those clipped colors will print worse than they would if merely mapped inward by the printer profile. They will tend to be more lacking in detail and shifted in hue. It's also the case that the working space has to give you room to work — to let you edit your images without clipping them avoidably, although giving yourself too much room to work can also backfire because printer profiles have a hard time moving colors a long ways to bring them into gamut. Care should always be taken to avoid both clipping and pushing colors way too far out of your printers' gamuts.
Which, like Steve Upton, seems to be pretty much what I'm saying: make sure your working space is big enough to hold your image's colors (and give yourself some elbow room for further editing) but don't go too big because that has its dangers and downsides, for example, as Joseph says (and as I've been repeating ad nauseum throughout this thread) that squeezing a big space into a smaller one can and often does cause problems.
Nice to have at least one voice who's not entirely against me :)
Robert
-
I'm actually totally with you on this Robert.
I knew Joseph long before I met him. For the longest time I didn't dare email him because I thought so highly of him. There is a saying that one should not meet one's idols, because they will disappoint you. Quite the opposite - Joseph Holmes is the most amazing and incredible person I have ever known. I flew from Singapore to San Francisco to meet him. You will find all of his articles laden with invaluable information, which must be read many times to glean all the vital bits. You can definitely trust what he says. Joe's color variants are the best kept secret in digital imaging.
Printer profiles are a funny business. It's all about the gamut mapping. Most still do not have truly excellent gamut mapping. If I were knowledgeable enough I would build my own profiling software like Ethan Hansen did. I found critical flaws in all the leading color management software.
There is an interesting article (http://cias.rit.edu/~gravure/tt/pdf/cm/TT5_Jorge01.pdf) that shows Perceptual rendering intent to have less hue shifts than the colorimetric rendering, when black point compensation is used (it should be used).
Also interesting to note is that for Perceptual tables to be computed, some sort of source gamut space must be assumed. I'm sure you know this from a previous thread where you pointed out how Argyll profiles can be built by selecting a source space. I notice that going from ProPhoto RGB to any matte paper profile (built in i1Profiler) causes dark blues to get printed almost black (big luminance shift) for the perceptual rendering intent, but starting from a smaller space like sRGB, Adobe RGB and DCam3 resulted in the dark blues reproducing as expected, not so dark. I short email chat with the color engineer from CoPrA revealed the nature of different ways to map source to destination gamut - the reason for my observation.
My preference is actually to have a working space gamut that morphs perfectly to fit any given digital capture, to perfectly encompass its range of color and no more. Since we are still in the age of dumb color management, that's not going to happen. Joseph's Dcam spaces are carefully designed with that in mind, after thousands of experiments and looking at digital capture color massaged in all the general various ways we move them around in our favourite image editing software. Hence the 5 choices of Dcam spaces, and the set of color variants to increase (or decrease) working headroom. Nearly infinitely variable. They are a labor of love.
If this is getting too off topic and controversial, I would like to continue this conversation with you privately Robert. I have some questions about some of your discoveries (http://www.luminous-landscape.com/forum/index.php?topic=91514.msg746328#msg746328). :-)
-
Well Andrew, I don't think a ColorWiki article by Steve Upton is going to sway me right, left, up or down as I hardly think that it is unbiased. However ... here is what he says:
Actually the bit you were supposed to read was the part about how the gamut maper in CT works:
The ONLY way to show the actual gamut of the device is to use the Absolute Colorimetric intent when calculating.
Moving on...
As for Bruce Lindbloom and Beta RGB: just read http://www.brucelindbloom.com/index.html?BetaRGB.html. In this Bruce says...:
...nothing about photography. You claim the RGB working space is designed for that task, there is no evidence of that I can find.
The problem with our discussion is that, every time I try to answer one of your points, you ignore what I have said or go back to your original 'Prove It!' stance
Simply because you've failed to do so. The reason I suggested we move on. You've got your own belief system and I'm fine with that. Other's, myself included are not buying into it blindly and based on our own experiences and testing. If and when you have a means of providing evidence that alters what we've been seeing over the years, let us know.
-
On the other hand, PP RGB was created by Kodak after a lots of research specifically meant to address the needs of editing photographs.
Jeff,
I was told (don't remember who told me) that Prophoto RGB was created as a sum of all the gamuts of photographic film (negative and positive). Do you know if that is true?
-
I was told (don't remember who told me) that Prophoto RGB was created as a sum of all the gamuts of photographic film (negative and positive). Do you know if that is true?
http://www.imaging.org/IST/store/epub.cfm?abstrid=1637
A new color encoding specification known as Reference Output Medium Metric RGB (ROMM RGB) is defined. This color encoding is intended to be used for storing, interchanging and manipulating images that exist in a rendered image state without imposing the gamut limitations normally associated with device-specific color spaces. ROMM RGB was designed to provide a large enough color gamut to encompass most common output devices, while simultaneously satisfying a number of other important criteria. It is defined in a way that is tightly linked to the ICC profile connection space (PCS) and is suitable for use as an Adobe Photoshop™ working color space. A companion color encoding specification, known as Reference Input Medium Metric RGB (RIMM RGB), is also defined. This encoding can be used to represent images in an unrendered scene image state.
-
The ProPhoto RGB primaries were also chosen in order to minimize hue rotations associated with non-linear tone scale operations.
http://en.wikipedia.org/wiki/ProPhoto_RGB_color_space#cite_note-1
Interesting, don't remember reading that before.
-
Jeff,
I was told (don't remember who told me) that Prophoto RGB was created as a sum of all the gamuts of photographic film (negative and positive). Do you know if that is true?
Actually I think ProPhoto was chosen to encompass pretty much 100% of colors likely to occur in the real world (forgetting about some oversaturated butterflies, perhaps :)). Beta RGB was chosen pretty much as you say.
This link has some useful information: http://www.brucelindbloom.com/index.html?BetaRGB.html
And this link (following page), is also very interesting. It compares the different working spaces. In particular have a look at the last table 'Color Set Evaluations'. If our interest is in real-world colors, as opposed to HDR-type oversaturation, then a working space like Beta RGB seems pretty ideal.
Robert
-
I'm actually totally with you on this Robert.
I knew Joseph long before I met him. For the longest time I didn't dare email him because I thought so highly of him. There is a saying that one should not meet one's idols, because they will disappoint you. Quite the opposite - Joseph Holmes is the most amazing and incredible person I have ever known. I flew from Singapore to San Francisco to meet him. You will find all of his articles laden with invaluable information, which must be read many times to glean all the vital bits. You can definitely trust what he says. Joe's color variants are the best kept secret in digital imaging.
Printer profiles are a funny business. It's all about the gamut mapping. Most still do not have truly excellent gamut mapping. If I were knowledgeable enough I would build my own profiling software like Ethan Hansen did. I found critical flaws in all the leading color management software.
There is an interesting article (http://cias.rit.edu/~gravure/tt/pdf/cm/TT5_Jorge01.pdf) that shows Perceptual rendering intent to have less hue shifts than the colorimetric rendering, when black point compensation is used (it should be used).
Also interesting to note is that for Perceptual tables to be computed, some sort of source gamut space must be assumed. I'm sure you know this from a previous thread where you pointed out how Argyll profiles can be built by selecting a source space. I notice that going from ProPhoto RGB to any matte paper profile (built in i1Profiler) causes dark blues to get printed almost black (big luminance shift) for the perceptual rendering intent, but starting from a smaller space like sRGB, Adobe RGB and DCam3 resulted in the dark blues reproducing as expected, not so dark. I short email chat with the color engineer from CoPrA revealed the nature of different ways to map source to destination gamut - the reason for my observation.
My preference is actually to have a working space gamut that morphs perfectly to fit any given digital capture, to perfectly encompass its range of color and no more. Since we are still in the age of dumb color management, that's not going to happen. Joseph's Dcam spaces are carefully designed with that in mind, after thousands of experiments and looking at digital capture color massaged in all the general various ways we move them around in our favourite image editing software. Hence the 5 choices of Dcam spaces, and the set of color variants to increase (or decrease) working headroom. Nearly infinitely variable. They are a labor of love.
If this is getting too off topic and controversial, I would like to continue this conversation with you privately Robert. I have some questions about some of your discoveries (http://www.luminous-landscape.com/forum/index.php?topic=91514.msg746328#msg746328). :-)
Hi Samuel,
I'm quite happy to continue the discussion on this thread ... but if it gets too messy please send me an email and we can carry on offline.
I'll have a read of the links you've suggested ... thank you! I just noticed that one of the links http://www.luminous-landscape.com/forum/index.php?topic=91514.msg746328#msg746328 is quite relevant to the discussion going on here. We are definitely on well-trodden ground once again :)
Robert
Robert
-
There is an interesting article (http://cias.rit.edu/~gravure/tt/pdf/cm/TT5_Jorge01.pdf) that shows Perceptual rendering intent to have less hue shifts than the colorimetric rendering, when black point compensation is used (it should be used).
Ho! Very interesting all right! BPC is one of these mysterious (to me) things that you just turn on because you've been told that it helps to preserve the shadow detail. Which may be true. However, what isn't mentioned is that to do this Photoshop (or LR, or whatever) has to shift the luminance of the image up (so equivalent to applying a levels or curves adjustment to boost the shadows). Of course this will shift all the colors. I assume Adobe would only shift luminance, which wouldn't be so bad. But it's giving control over to a black-box algorithm ... and it is also duplicating the work of the profile.
I need to read the article carefully, but it certainly raises the point as to whether we should blindly turn BPC on ... or make the correction using an adjustment layer prior to print, with the layer blend mode set to luminance.
I suppose it's not too bad as we can see the effect in soft-proofing ... still, another little addition to the arsenal :)
Robert
-
Are you a member of the Flat Earth Society? :)
All you can say here is that YOU can't see the difference. Our eyes vary hugely in their ability to detect subtle color differences.
Whose 'current thinking and practice', and is this the best practise? Andrew's, yes ... who else who considers themselves experts in color management? Bruce Linbloom, maybe (makes you wonder why he created Beta RGB! http://www.brucelindbloom.com/index.html?BetaRGB.html).
I don't want people to accept what I say. I'm a scientist by training and I firmly believe that we should all come to our own conclusions based on the evidence
I try extremely hard to be non-confrontational ... my mantra when posting is if I ‘m not willing to say something to someone’s face I shouldn’t write it. Despite the deep convictions of posters this thread has been pretty good about not going there, so I’m not sure why you would throw a derogatory comment like this, and the smiley doesn’t make it better.
No I”m not a scientist, I’m a career photographer who’s company has printed millions of prints, been printing custom work since the 70’s for myself and others and have been involved in digital printing technologies as well as capture since the mid 90’s, including a close relationship with Kodak and buying bleed edge capture and output devices for excessive sums of money to try learn (how about a 2mp Kodak DCS 560 camera for $22,000? ouch, what was I thinking). I’ve been working with inkjet since well before the Epson 9600 came out which sort of made it main stream, and spent years of testing and working with workflows. I have consulted with 100’s of struggling photographers who are trying to get good output from their work, and have many times had them bring me raw files so I could offer them a print far better than the file they submitted, often time the main issue being they chose to work in sRGB while in Photoshop and ended up mucking up their colors and blocking up their detail. I only offer this to show where I’m coming from what I base my practices on.
So I come from the school of hard knocks and practical experience, Bottom line while there is some logic and perhaps even some technical evidence of your position, that doesn’t make it important enough to complicate a workflow. If the difference isn’t visible, then why bother. and my eyes are pretty damn good ... as well as my experience as a printer. But to be honest this thread isn’t about me, it’s about a workflow you are promoting ... one that it seems most question is worth the effort because it won’t yield valuable enough difference in the final output.
As far as current thinking and practice, I’m surprised you don’t know this. You are the only person I know who preaches this ... and there is a pretty long list of photographers who use ppRGB as their only working space.
I think science is replete with examples of things that can be demonstrated and proven beyond what human perception is capable of discerning. That seems to me the crux of this issue.
And you should know, surely, that ProPhoto does NOT define all naturally occurring colors (or more correctly, all colors that we can see)
Well, if we can’t see it, is it a color? I’ve always thought that one of the basic fundamentals of color science is that color is something in the visible human spectrum, outside of that it’s another form of electromagnetic radiation. But that’s neither here nor there ..
But I never said ppRGB did encompass all naturally occurring colors, I said "so the main goal was to try and make sure all naturally occurring colors could be defined”
Good luck to you Robert. I’m done with this thread. Despite what you think, I think most reading this thread will agree you are the one who is offering an alternative to accepted practice, and as such it really is up to you to offer some evidence as well as alternative workflows. (I’m still unclear as to an easy way to predetermine before going into PS whether or not I can contain my colors inside of a smaller space). And I know if you offer something, there will be plenty who will test it. I personally have been spending the past month testing many different ways to output my large prints with alternative sharpening methods because of the things that Bart has offered on this forum. I remember Jeff Schewe changing his position on the use of 720ppi printing from an Epson printer, despite Epsons claim it was only for vector graphics and non photographic output from discussion here on LuLa about when and why it can help. I would love to have you post some files I could use that would validate your point, and at that point even be willing to test ideas as to how to make it practical in a workflow.
But until then, John summed up this thread extremely well …
After reading through this thread here is my conclusion:
1) It is theoretically possible that using a color space that is too large may result in a print that is suboptimal compared to using a color space that is the right size
2) Experienced printers have not been able to find a practical example of this in spite of looking for it
3) The poster advancing the theory is not interested in finding even a single image where the differences in prints support his hypothesis, making one wonder whether he would be able to do it
4) Using a working color space that is smaller than the gamut of the output device (in this case, the printer) will definitely cause important color information to be lost, and for images of nature it is easy to find such cases (e.g., poppies)
Conclusion: I will continue using Prophoto as my working color space for all images until at least one example is provided that a better print (i.e., truer to the colors in the image) comes from using a smaller color space.
PS I like theory as much as the next guy, but we are talking about perceptible visual differences in prints as the gold standard. If a discerning eye can't see it, then it really doesn't matter.
-
There's nothing that should be mysterious about BPC. It either doesn't do anything because it doesn't have to, or it does fix a mapping issue from source to destination (from incorrectly created profiles). I haven't seen such profiles this century but back when BPC was introduced, they did exist and BPC fixed the issues nicely.
-
I try extremely hard to be non-confrontational ... my mantra when posting is if I ‘m not willing to say something to someone’s face I shouldn’t write it. Despite the deep convictions of posters this thread has been pretty good about not going there, so I’m not sure why you would throw a derogatory comment like this, and the smiley doesn’t make it better.
No I”m not a scientist, I’m a career photographer who’s company has printed millions of prints, been printing custom work since the 70’s for myself and others and have been involved in digital printing technologies as well as capture since the mid 90’s, including a close relationship with Kodak and buying bleed edge capture and output devices for excessive sums of money to try learn (how about a 2mp Kodak DCS 560 camera for $22,000? ouch, what was I thinking). I’ve been working with inkjet since well before the Epson 9600 came out which sort of made it main stream, and spent years of testing and working with workflows. I have consulted with 100’s of struggling photographers who are trying to get good output from their work, and have many times had them bring me raw files so I could offer them a print far better than the file they submitted, often time the main issue being they chose to work in sRGB while in Photoshop and ended up mucking up their colors and blocking up their detail. I only offer this to show where I’m coming from what I base my practices on.
So I come from the school of hard knocks and practical experience, Bottom line while there is some logic and perhaps even some technical evidence of your position, that doesn’t make it important enough to complicate a workflow. If the difference isn’t visible, then why bother. and my eyes are pretty damn good ... as well as my experience as a printer. But to be honest this thread isn’t about me, it’s about a workflow you are promoting ... one that it seems most question is worth the effort because it won’t yield valuable enough difference in the final output.
As far as current thinking and practice, I’m surprised you don’t know this. You are the only person I know who preaches this ... and there is a pretty long list of photographers who use ppRGB as their only working space.
I think science is replete with examples of things that can be demonstrated and proven beyond what human perception is capable of discerning. That seems to me the crux of this issue.
Well, if we can’t see it, is it a color? I’ve always thought that one of the basic fundamentals of color science is that color is something in the visible human spectrum, outside of that it’s another form of electromagnetic radiation. But that’s neither here nor there ..
But I never said ppRGB did encompass all naturally occurring colors, I said "so the main goal was to try and make sure all naturally occurring colors could be defined”
Good luck to you Robert. I’m done with this thread. Despite what you think, I think most reading this thread will agree you are the one who is offering an alternative to accepted practice, and as such it really is up to you to offer some evidence as well as alternative workflows. (I’m still unclear as to an easy way to predetermine before going into PS whether or not I can contain my colors inside of a smaller space). And I know if you offer something, there will be plenty who will test it. I personally have been spending the past month testing many different ways to output my large prints with alternative sharpening methods because of the things that Bart has offered on this forum. I remember Jeff Schewe changing his position on the use of 720ppi printing from an Epson printer, despite Epsons claim it was only for vector graphics and non photographic output from discussion here on LuLa about when and why it can help. I would love to have you post some files I could use that would validate your point, and at that point even be willing to test ideas as to how to make it practical in a workflow.
But until then, John summed up this thread extremely well …
Wayne I absolutely did not intend any disrespect and I apologize for offending you. I was simply being funny (seems not!) in reply to your comment "Great you trust logic, but logic and even scientific evidence don't always equate to something that matters.". You're right, quite often logic and science tell us things that are of no practical value (at least not right now).
However the profile mapping algorithms are very much of practical interest. If a color management engineer tells you that a relative colorimetric profile essentially maps all out of gamut colors to the gamut boundary then that is very useful information. It tells you, without having to print, that if you convert a saturated image from a wide-gamut working space to a smaller-gamut working space you will get effects like flattening and banding and desaturation. This is what Andrew demonstrated in his video when he converted the image from ProPhoto to sRGB. The fault is not with sRGB ... it's with the conversion, which should not be done.
You and Andrew keep asking me to show it, prove it ... and I do, but you both seem to ignore every attempt I make. Look back here http://www.luminous-landscape.com/forum/index.php?topic=93576.msg764493#msg764493, for example. I am showing here that if you convert the image to sRGB via the print profile which a) is a larger profile, and b) uses a perceptual mapping in this case, that the net effect on the image is minimal compared to the image mapped directly to the print space from ProPhoto. Go ahead and print the images and you will see for yourself ... I don't need to print them because I know that they will be OK. Actually, I tell you what, would you like me to prepare the images for you full-size and you can then print them yourself? Just send me the print profile you're going to use and I'll do that for you.
Regarding a Perceptual mapping to a smaller gamut. Again, I know because I have spoken to Graham Gill, who is the developer of ArgyllCMS and also because I've looked at the code (which is open-source so you can look at it yourself) that unlike a Relative mapping, the Perceptual mapping effectively squeezes the whole of the source space into the destination space, while attempting to preserve the relationship between the colors. The effect of this is a) that all the colors get shifted, and b) there is the possibility of a loss of saturation in some colors. Again, I have covered this in another thread, here: http://www.luminous-landscape.com/forum/index.php?topic=91514.msg746328#msg746328. If you like I can make this image available to you and you can repeat the tests yourself ... but you can use one of your images, there's nothing special about the image I chose.
If you don't care about this shifting/desaturation ... well fine. I do, so I'm prepared to go this extra few yards to avoid it if I can.
You say that I am proposing a radically different working practice that very few if any photographers follow. Actually, what I am doing is attempting to correct misinformation in Andrew's video. However it isn't true that I am the only person who thinks that the choice of workspace is important and that bigger is not always better ... by no means. In an earlier post I quote Steve Upton (who appears to be highly regarded by Andrew, who directed me to the page where I got the quote from) and to requote him, he says:
In color management there is often no single correct way to do things. What we do suggest is a few things that will apply to all:
Choose a working space that is just large enough to contain your imagery; any bigger and you're wasting space.
If you can, choose a standard working space like sRGB or AdobeRGB. It makes file exchange and discussions easier
Avoid converting between working spaces as the conversions don't deal with out-of-gamut colors well
If the entire world used sRGB PROPERLY, color quality would go up significantly. What this means is that many color problems are not due to working space choices.
So here is one of your own (or at least Andrew's) gurus who is telling you just what I've been saying, but in a much more concise way. Admittedly I am adding some further information, but the point here is that Steve Upton also seems to think that you are best fitting your image to a smaller space but one which still gives you some elbow room for further editing.
Which leads to your comment: "I’m still unclear as to an easy way to predetermine before going into PS whether or not I can contain my colors inside of a smaller space". It's very easy to do this. I assume you are using an (effective) aRGB monitor, so then just soft proof the image in Lightroom. If you get no monitor OOG warnings (click on the monitor icon at the top left of the histogram to turn this on) then you can safely open the image into Photoshop in aRGB. If you want to go a step further set the soft-proofing to sRGB and turn on the OOG warnings (click on the document icon at the top right of the histogram to turn this on). If you get no gamut warnings then you can safely open the image in sRGB. You can do the same with other working spaces if you wish (for example Beta RGB), but it's a little trickier opening the image as anything but sRGB, aRGB or ppRGB from Lightroom to Photoshop (but only a little bit trickier, so if you would like to know the easiest way to do this just let me know).
So that's it, no magic to it, just a bit of information from people who develop these things.
Again, let me say that I really do apologize for my flippant remark and hope you won't remain too offended by it.
Robert
-
There's nothing that should be mysterious about BPC. It either doesn't do anything because it doesn't have to, or it does fix a mapping issue from source to destination (from incorrectly created profiles). I haven't seen such profiles this century but back when BPC was introduced, they did exist and BPC fixed the issues nicely.
Does it fix the issue due to incorrectly created profiles, or does it bump up the dark-end luminance when it sees that the print black point is higher than the document black point? It looks to me that it does the latter, judging from a Canson Baryta profile (which is a pretty good profile). And actually what it did with my test image wasn't good because it opened up dark areas that I didn't want opened up ... so it shouldn't be one of these tick boxes that one just ticks automatically.
Robert
-
Does it fix the issue due to incorrectly created profiles, or does it bump up the dark-end luminance when it sees that the print black point is higher than the document black point?
It fixes an incorrect mapping of source to destination black IF the profile isn't doing this properly. Or if the profile is mapping black correctly, it doesn't do anything. Just leave it on. And note that BPC doesn't do anything IF you ask for an Absolute Colorimetric rendering. The absolute colorimetric rendering intent reproduces the exact color that existed in the source—absolutely.
-
It fixes an incorrect mapping of source to destination black IF the profile isn't doing this properly. Or if the profile is mapping black correctly, it doesn't do anything. Just leave it on. And note that BPC doesn't do anything IF you ask for an Absolute Colorimetric rendering. The absolute colorimetric rendering intent reproduces the exact color that existed in the source—absolutely.
Thanks Andrew. However if I toggle BPC on/off with soft-proofing set to RC I see a shifting in the dark regions. ??
Robert
-
Thanks Andrew. However if I toggle BPC on/off with soft-proofing set to RC I see a shifting in the dark regions. ??
http://www.color.org/AdobeBPC.pdf
See page 3.
Further, that's why one soft proofs using the simulate paper and ink check boxes (the Schewe: Make my image look like crap button):
•Simulate Paper Color and Simulate Black Ink Off: Convert using the relative colorimetric intent with Black Point Compensation.
•Simulate Black Ink: Convert using the relative colorimetric intent without Black Point Compensation.
•Simulate Paper Color: Convert using the absolute colorimetric intent (no Black Point Compensation).
If Simulate black is OFF, you're seeing the black incorrectly on-screen, it is the display's black hole you are viewing. So you should see a visual difference with the check box on or off but the bottom line is, mapping of black for the output is correct.
-
Many thanks Andrew ... I'll have a read of the paper.
Cheers
Robert
-
Maybe your friend Thomas Knoll can get things moving in that direction :).
Thomas made a specific decision to NOT use Lab and chose PP RGB instead.
He knew about Beta RGB...back then everybody and their brother was producing their own RGB working spaces including Bruce Fraser (Bruce RGB), Don Hutchinson (Don RGB & Best RGB), Joe Holmes (Ekta RGB) as well as Lindbloom's Beta RGB.
Guess what? Thomas chose PP RGB. And, since it's the basis of ACR/LR's color rendering, you're gonna be using PP RGB regardless of what you choose to output.
Personally, I choose to keep my images in the color space they were processed in and not make a side trip to other color spaces until I have a known destination...the less color transforms, the better ya know?
-
Thomas made a specific decision to NOT use Lab and chose PP RGB instead.
He knew about Beta RGB...back then everybody and their brother was producing their own RGB working spaces including Bruce Fraser (Bruce RGB), Don Hutchinson (Don RGB & Best RGB), Joe Holmes (Ekta RGB) as well as Lindbloom's Beta RGB.
Guess what? Thomas chose PP RGB. And, since it's the basis of ACR/LR's color rendering, you're gonna be using PP RGB regardless of what you choose to output.
Personally, I choose to keep my images in the color space they were processed in and not make a side trip to other color spaces until I have a known destination...the less color transforms, the better ya know?
Sure, whatever rocks your boat. In my case I only process an image when I know the destination, so I don't need to worry about what-ifs.
As for LR and ppRGB, as I said it makes sense to have chosen a very large working space because it is impossible for the raw engine to know all the possible images that will be processed and how wide the sum total of all the gamuts will be: so it has to cater for very wide. I suppose Adobe could have made LR so that it automatically picked the best working space based on the image gamut ... but this would have made the coding much more difficult and would no doubt have confused people. At any rate, I may be wrong, but I don't think there is any quality hit in opening an image from Lightroom to Photoshop in sRGB, say, providing the image gamut is smaller than sRGB (if there is then Adobe needs to fix it, because there should not be: it should be a straight raw -> sRGB conversion (with the parametric adjustments applied).
I also think that the decision to go to ppRGB rather than Lab had probably more to do with the fact that we have gotten used to working in RGB and because most of the tools (like Photoshop) are really tuned around RGB rather than Lab. Which is a pity in many ways because Lab is a very intuitive working space once you get the hang of it, and one that matches our visual system far better than RGB (just think of how easy it is to adjust the color balance of an image using the LR Temperature and Tint sliders (nothing more than Lab really).
Robert
Robert
-
I also think that the decision to go to ppRGB rather than Lab had probably more to do with the fact that we have gotten used to working in RGB and because most of the tools (like Photoshop) are really tuned around RGB rather than Lab. Which is a pity in many ways because Lab is a very intuitive working space once you get the hang of it, and one that matches our visual system far better than RGB (just think of how easy it is to adjust the color balance of an image using the LR Temperature and Tint sliders (nothing more than Lab really).
Actually, I'm pretty sure the reason why he chose not to use Lab is some of the problems Lab can cause with certain colors and perceptual uniformity issues. Also, Lab wouldn't be as useful for dealing with issues such as camera color to RGB (CIE XYZ>PP RGB works very well).
Also, correcting white balance is nothing like color corrections in Lab...not sure where you got that idea...read this: Color Temperature (http://en.wikipedia.org/wiki/Color_temperature). Correcting for white balance is NOT like the ab channels of Lab. The white balance in ACR/LR is actually rather brilliant using a dual illuminate DNG profile. Course, Thomas is nothing if not brilliant. Remember, he started this whole revolution when he created Photoshop.
-
It fixes an incorrect mapping of source to destination black IF the profile isn't doing this properly.
Hi Andrew, it was never in the profile's business to map the source black to destination black properly for the colorimetric intent. It is not about the profile doing it properly or not, neither is it about poorly made profiles. Quoted from page three of Adobe's published document of BPC (http://www.color.org/AdobeBPC.pdf):
Although ICC profiles specify how to convert the lightest level of white from the source device to the destination device, the profiles do not specify how black should be converted. The user observes the effect of this missing functionality in ICC profiles when a detailed black or dark space in an image is transformed into an undifferentiated black or dark space in the converted image. The detail in dark regions (called the shadow section) of the image can be lost in standard color conversion.
Unless one is interested in getting blocked up densities from your measured paper black (anywhere from low dmax matte papers exhibiting L*16 to some of the highest dmax glossy paper exhibiting L*2) to RGB 0,0,0 or L*0, black point compensation should be used to scale the density values to maintain separation down to output black when converting to a printer profile using the Relative Colorimetric intent.
So - BPC does not just map source black to destination black, it also moves all density values so luminosity of all colors graduate smoothly from white to black.
Because of this, BPC does not only lighten the dark areas - sometimes it may darken certain regions, to ensure the luminosity transitions are smooth.
BPC, just like gamut mapping, is a dumb operation. The maths published in Adobe's article is available for all to see. If the perceptual tables are poorly mapped, it sometimes causes a shift even for the perceptual rendering intent. For some reason Adobe did not implement the shift to only affect the luminosity of colors, without shifting them in hue or chroma. In that respect, the perceptual rendering intent may be a better bet.
Robert, you might find Norman's webpage (http://www.gamutvision.com/docs/blackpoint.html) on BPC interesting too. Note the emphasis. He says:
BPC is always on for perceptual rendering intent, i.e., the checkbox setting has no effect.
BPC can be turned on or off for (Relative) Colorimetric and Saturation rendering intents.
BPC is always off for Absolute (Colorimetric) rendering intent. Unresolved issue: I've been told that BPC should work with Colorimetric intents, i.e., Relative and Absolute. Perhaps Absolute and Saturation have been swapped somehow.]
-
Hi Andrew, it was never in the profile's business to map the source black to destination black properly for the colorimetric intent. It is not about the profile doing it properly or not, neither is it about poorly made profiles. Quoted from page three of Adobe's published document of BPC (http://www.color.org/AdobeBPC.pdf):
Unless one is interested in getting blocked up densities from your measured paper black (anywhere from low dmax matte papers exhibiting L*16 to some of the highest dmax glossy paper exhibiting L*2) to RGB 0,0,0 or L*0, black point compensation should be used to scale the density values to maintain separation down to output black when converting to a printer profile using the Relative Colorimetric intent.
So - BPC does not just map source black to destination black, it also moves all density values so luminosity of all colors graduate smoothly from white to black.
Because of this, BPC does not only lighten the dark areas - sometimes it may darken certain regions, to ensure the luminosity transitions are smooth.
BPC, just like gamut mapping, is a dumb operation. The maths published in Adobe's article is available for all to see. If the perceptual tables are poorly mapped, it sometimes causes a shift even for the perceptual rendering intent. For some reason Adobe did not implement the shift to only affect the luminosity of colors, without shifting them in hue or chroma. In that respect, the perceptual rendering intent may be a better bet.
Robert, you might find Norman's webpage (http://www.gamutvision.com/docs/blackpoint.html) on BPC interesting too. Note the emphasis. He says:
Very good. Seems like BPC is not quite as straightforward after all, as I suspected. It's interesting that Norman Koren is never quoted in these discussions: he's quite an expert on lens and system testing and knows a lot about color management too. Perhaps it's the Chromix/ColorWiki v GamutVision that's at play here.
Robert
-
Actually, I'm pretty sure the reason why he chose not to use Lab is some of the problems Lab can cause with certain colors and perceptual uniformity issues. Also, Lab wouldn't be as useful for dealing with issues such as camera color to RGB (CIE XYZ>PP RGB works very well).
Also, correcting white balance is nothing like color corrections in Lab...not sure where you got that idea...read this: Color Temperature (http://en.wikipedia.org/wiki/Color_temperature). Correcting for white balance is NOT like the ab channels of Lab. The white balance in ACR/LR is actually rather brilliant using a dual illuminate DNG profile. Course, Thomas is nothing if not brilliant. Remember, he started this whole revolution when he created Photoshop.
Jeff, could you ask your good friend Thomas if he believes that ppPhoto is the best post-LR working space in all cases? And if so for what reasons? Perhaps you could get a quote from him? I would like to hear from the guru himself and as I don't play at his elevated levels like you do I'm not in a position to ask him the question.
On my side I paraphrase Graham Gill who said in one of his posts (I could go back to find it but it would take time): "ppPhoto is a crazy wide working space" ... and he wasn't using 'crazy' meaning good. He comes from the gamut-mapping maker's side of things, so his comment is about the relative unsuitability of very wide working spaces from a gamut-mapping point of view.
As for the LR temperature and tint sliders ... sure, of course they correspond to the ab sliders in Lab. I didn't say that the LR sliders do not do more, which I know they do, as indeed they do less than the ab sliders (for good reason) ... but what they do is to shift the colors in the blue/yellow and cyan/magenta directions just as the the ab sliders do.
Robert
-
Hi Andrew, it was never in the profile's business to map the source black to destination black properly for the colorimetric intent. It is not about the profile doing it properly or not, neither is it about poorly made profiles.
Well there's this:
I have got to tell you, as a color scientist and Chairman of the ICC, the entire industry IS Molehill Central ( I am assuming here that you are implying that we are constantly playing "Whack a mole"). The problem with the whole ICC concept is that the fundamental implementations are always way ahead of the science and the science is always in transition as well.
Black Point compensation is an unfortunate response to a fundamental flaw in the initial ICC specification: the lack of a defined black point assumption. Many people took note of this early on, but the organization had a rather restrictive view on input from the outside world and we live with that legacy with a prolification of V2 profiles. I would always recommend using BPC.
Tom Lianza
And there is this data point too:
Dear Andrew, Dear all,
Here is a clarification of the BPC (Black Point Compensation) issue from the ICC model perspective.
When you perform a Device to Device color convesion (RGB2RGB, RGB2CMYK, CMYK2CMYK etc...) using ICC device profiles, input device values are translated into input profile PCS (Profile Connection Space) values, CIELAB in most cases, and then these CIELAB values are translated from output profile PCS into output device values using the chosen RI (rendering intent) table and CMM (Color Management Module).
For more information about the ICC model and mechanism you can may wish to take a look at the following public document:
"Introduction to ICC profiles and color quality assessment pdf"
on the following www page :
http://www.alwancolor.com/english/products/colorpursuit.html
In many situations, the input profile BP do not coincide with output device BP.
This may be due to 2 reasons:
1- input device profile PCS black point is different from output device profile PCS black point.
This situation may arise when using v2 profiles because ICC v2 spec did specify PCS white point, but not PCS Black Point. So some profile builders were able to adopt a different BP for their profile PCS than others.
This issue has been clarified with v4 profiles with which this situation should not occur anymore.
2- input device DR (dynamic range) - ie BP -> MWP (Media White Point) Lightness (CIE L) range - can be different for output device profile DR.
This situation may arise when you are converting colors from a device to another device having a noticeable different gamut.
Ex1- If we consider an input device with a PCS BP that is darker than the output device PCS BP:
Even with Perceptual RI some input blacks will be clipped in the output profile transformation because they do not exist there.
Ex2- If we consider an input device having a wide DR and an output device having a smaller DR:
If you perform a colorimetric RI transformation, input blacks will be clipped in the output profile transformation because they do not exist there.
In these cases, BPC allows you to map input profile BP into output profile BP hence avoiding the loss of shadow details in your images and in the black tints.
The inverse situation may happen too:
If input profile DR is smaller than output profile DR, using BPC allows you in this case to benefit from your output device DR by mapping your input black into your output black.
This is particularly useful for repurposing for example, by performing CMYK2CMYK transformations improving shadow details and avoiding your input blacks turning dark grays on your output device printout.
Adobe have done a great job in offering a BPC option which is consistent in all their product range and which is not a secret sauce.
Some color management products have implemented this very useful option.
Ours do (Alwan LinkProfiler and CMYK Optimizer: this is for the example not an ad :-) as well as many others on the market today.
The ICC (International Color Consortium) is working on this issue since a while now and maybe will find a way soon to specify and document BPC so it may become part of a standard ICC transformation and not an application option which is the case now.
I hope this helps,
Elie KHOURY
Lastly, as to should it be on, from a respected color geek extraordinaire:
Wilma,
Thee are two classic uses for Relative WITHOUT Black Point Cimpensation.
1. Converting CMYK for proofing when stock colors match between simulation device and simulator.
2. Converting an RGB reflection scan to CMYK when the dynamic range of the original is equal to or less than that of the CMYK device, and the most faithful reproduction is needed.
In virtually all other cases BPC should always be on.
Don Hutcheson
-
I also think that the decision to go to ppRGB rather than Lab had probably more to do with the fact that we have gotten used to working in RGB and because most of the tools (like Photoshop) are really tuned around RGB rather than Lab.
No capture device produces Lab. So you have to convert from RGB to Lab, then back to RGB again which is time consuming and data damaging. The fewer conversions, the better (hence another reason why sticking with ProPhoto primaries from the ACR engine makes sense). It IS recommended by Adobe in the LR preferences! Now you can have Lab controls over the RGB data as you point out with the Tint/Temp sliders. Heck, the old LinoColor scanners and software gave full-on Lab controls but again, the data was RGB and if you asked for Lab out the back end, you converted the data to Lab from RGB. There are more problems with Lab than advantages in terms of using it as an encoding color space.
-
No capture device produces Lab. So you have to convert from RGB to Lab, then back to RGB again which is time consuming and data damaging. The fewer conversions, the better (hence another reason why sticking with ProPhoto primaries from the ACR engine makes sense). It IS recommended by Adobe in the LR preferences! Now you can have Lab controls over the RGB data as you point out with the Tint/Temp sliders. Heck, the old LinoColor scanners and software gave full-on Lab controls but again, the data was RGB and if you asked for Lab out the back end, you converted the data to Lab from RGB. There are more problems with Lab than advantages in terms of using it as an encoding color space.
Well we're in a somewhat pointless discussion at this stage because the fact is that LR and PS (mostly) uses RGB and talking isn't going to change that. I agree with you about minimizing conversions, but you have to remember that the PCS is usually in Lab (and if it is in XYZ there is a straightforward mapping to Lab) and in all CMM conversions the intermediate color space is always Lab/XYZ. So with the working space in RGB we have Input (RGB) -> PCS (Lab) -> WS (RGB) -> PCS( Lab) -> Output(RGB/CMYK); if the working space had been Lab we would have Input (RGB) -> WS (Lab) -> Output (RGB/CMYK). So having a Lab working space would not (necessarily) result in more conversions.
I don't know enough about the problems that may be associated with Lab as a working space (as you say there is) to comment on what you say ... but certainly one major problem that I see is that Lab is way too big for our monitors and output devices at this stage, so there would need to be a mechanism to constrain it.
What I like about Lab is that it's more how we think: shift to blue/yellow, shift to magenta/cyan. We don't think in terms of adding red or blue or green to an image in order to adjust it, so we end up with lots of adjustment filters like Selective Color, Hue/Saturation, Color Balance, Brightness, Contrast etc., that can all be done with a Levels adjustment in Lab. The separation of luminance from chrominance is also excellent and removes the need for things like Fade Color and having to change the Blend mode of an adjustment layer to Luminosity etc, when applying filters or adjustments that have the side-effect of changing the color as well as the luminance.
Still, as I say, not a very productive line of discussion as it is what it is :)
On another more relevant (to this topic) issue: you have not commented on my criticisms of your ProPhoto to sRGB video.
- Do you agree that the main problem with the flat-looking sRGB image in your video has more to do with the fact that you converted an image with saturated colors in ProPhoto to the very much smaller sRGB working space (a conversion that is inevitably a Relative Colorimetric conversion) rather than to sRGB itself?
- Do you agree that if such a conversion is a requirement (for example if you are preparing the image for the web) that doing a Perceptual conversion to an intermediate profile and then converting to sRGB will to a large extent avoid the problems you highlighted? I used a print profile to do this, but a better one would be a table-based monitor profile as this would not cause color shifts/desaturation to the same extent.
- Do you agree with Steve Upton's recommendations:
Choose a working space that is just large enough to contain your imagery; any bigger and you're wasting space.
If you can, choose a standard working space like sRGB or AdobeRGB. It makes file exchange and discussions easier
Avoid converting between working spaces as the conversions don't deal with out-of-gamut colors well
If the entire world used sRGB PROPERLY, color quality would go up significantly. What this means is that many color problems are not due to working space choices.
In other words, do you agree that there is nothing inherently bad about sRGB or aRGB, providing that these encompass the gamut of the image?
If we could agree to these points then I think we would have moved forward significantly.
Robert
-
I agree with you about minimizing conversions, but you have to remember that the PCS is usually in Lab (and if it is in XYZ there is a straightforward mapping to Lab) and in all CMM conversions the intermediate color space is always Lab/XYZ.
AFAIK, there's a difference between converting all pixles to and from Lab versus using a PCS to come up with values for the conversion. An old urban legend is that Photoshop converts to and from Lab to do all it's conversions and other editing operations. Not necessary, way too slow. What happens and has always happened since Photoshop started using ICC profiles is that when you ask for a conversion, Photoshop builds a conversion table and to do so, it uses LAB to find the equivalents from source to destination in cases where it needs to translate such color spaces, using 20-bit precision so you get less quantization errors than you would actually converting the pixels to LAB.
I don't know enough about the problems that may be associated with Lab as a working space (as you say there is) to comment on what you say ... but certainly one major problem that I see is that Lab is way too big for our monitors and output devices at this stage, so there would need to be a mechanism to constrain it.
CIELAB was 'recommended' by the CIE in 1976, to address a specific problem, namely, while identical XYZ values could tell you when two stimuli would be experienced as the same 'color' by most observers, it did not tell you how 'close' two colors were if they were not exactly the same XYZ value. Where Lab is useful is for predicting the degree to which two sets of tristimulus values will match under defined conditions thus it is not anywhere close to being an adequate model of human color perception. It works well as a reference space for colorimetrically defining device spaces, but as a space for image editing, it has many problems. There are a slew of other perceptual effects that Lab ignores. Lab assumes that hue and chroma can be treated separately, but numerous experimental results indicate that our perception of hue varies with the purity of color. Mixing white light with a monochromatic light does not produce a constant hue, but Lab assumes it does! This is seen in Lab modelling of blues. It's the cause of the dreaded blue-magenta color issues or shifts. Lab is no better, and in many cases can be worse than a colorimetrically defined color space based on real or imaginary primaries.
- Do you agree that the main problem with the flat-looking sRGB image in your video has more to do with the fact that you converted an image with saturated colors in ProPhoto to the very much smaller sRGB working space (a conversion that is inevitably a Relative Colorimetric conversion) rather than to sRGB itself?
- Do you agree that if such a conversion is a requirement (for example if you are preparing the image for the web) that doing a Perceptual conversion to an intermediate profile and then converting to sRGB will to a large extent avoid the problems you highlighted? I used a print profile to do this, but a better one would be a table-based monitor profile as this would not cause color shifts/desaturation to the same extent.
- Do you agree with Steve Upton's recommendations:
Choose a working space that is just large enough to contain your imagery; any bigger and you're wasting space.
If you can, choose a standard working space like sRGB or AdobeRGB. It makes file exchange and discussions easier
Avoid converting between working spaces as the conversions don't deal with out-of-gamut colors well
If the entire world used sRGB PROPERLY, color quality would go up significantly. What this means is that many color problems are not due to working space choices.
1. Yes of course (in terms of bigger going smaller gamut)! The images have a gamut that greatly surpasses sRGB so sRGB is the wrong encoding working space to use for these images (all images unless you can show otherwise) from raw processed using the ACR engine. The rendering intent is a red herring you continue to obsess upon.
2. No, no problems. In my workflow, and many others, it's scan once, use many (or capture raw, render once, use many). I have no idea what output device my images will go to today or a year from now. And I want to retain all the data I can in the master to use it. So the answer is simple: encode in the largest color space I can. At such a point I'm going to output that data to a known device and have a profile, I'll examine what rendering intent makes the image look best (IF I even have such an option, output to web isn't one of them and it doesn't matter a bit to me considering the huge inconsistencies of output devices and lack of color management for so many). So again, you're obsessing about rendering intents and I've seen nothing thus far in my work or anything you've shown that illustrates I should be concerned and just use a smaller gamut working space instead.
3. I agree that I should use the biggest working space that doesn't clip color I captured which is WHY I use ProPhoto RGB. I'm far, far less concerned wasting space than wasting color data.
I don't know what a standard working space like sRGB or AdobeRGB means, seems like something someone made up. For me, ProPhoto RGB is a standard working space, my standard working space! I really don't care what some think the entire world is using, and no, if everyone used sRGB, they would have the same poor output to their Epson's as I see to mine using that working space (compared to ProPhoto RGB, even Adobe RGB (1998) which I just tested and found produced an inferior print to the 3880 compared to ProPhoto RGB.
IF anything, the recent testing I did with my Gamut Test File (from raw and some synthetics) has strengthened my opinion that ProPhoto RGB is a vastly better working space to use based on how I capture my data, in the converter I use and the output device I print to today.
-
Sure, whatever rocks your boat. In my case I only process an image when I know the destination, so I don't need to worry about what-ifs.
You know the destination today and in the future? Or you output today and will never again? Because unless that's the case, you could be painting yourself in a corner with your data assuming the gamut and conditions of output devices today will not change in the future. You can go back and reprocess the raw, kind of a huge waste of time if like some of us, you may spend many hours after rendering to work on that file. Scan once, use many. It's a very flexible workflow for those who may desire to repropose all the possible data they captured and edited into the future.
Or you can just say you don't care which is fine, got no problem with that. It isn't a workflow I'd encourage among other's seeking optimal output, but it isn't any worse and maybe a lot better than the "just use sRGB" mindset.
-
You know the destination today and in the future? Or you output today and will never again? Because unless that's the case, you could be painting yourself in a corner with your data assuming the gamut and conditions of output devices today will not change in the future. You can go back and reprocess the raw, kind of a huge waste of time if like some of us, you may spend many hours after rendering to work on that file. Scan once, use many. It's a very flexible workflow for those who may desire to repropose all the possible data they captured and edited into the future.
Or you can just say you don't care which is fine, got no problem with that. It isn't a workflow I'd encourage among other's seeking optimal output, but it isn't any worse and maybe a lot better than the "just use sRGB" mindset.
No, of course I don't know what possible destinations there might be in the future ... I'm not a fortune-teller. But until I do know the output I leave the image in raw (processed in Lightroom, which goes a long way, as you know). Once I know that the image is going to, say, a matte paper with a limited gamut, I then create a virtual copy in Lightroom and soft-proof the image for that output. I will then do any further processing in Photoshop. If I need to reprocess the image for a much wider gloss paper then I go through this process again. The image being sent to the matte paper has to be processed differently to the one being sent to the gloss paper, so IMO there is no choice but to redo the final processing for output. To minimize the reprocessing required I normally hold the image as a raw smart object in Photoshop, which means that a lot of the post-lightroom editing does not need to be redone (but only tweaked). I simply make two copies of the image, one for the matte paper and one for the gloss paper. I know that this is wasteful in terms of disc space, but I don't care because I don't process tens of thousands of images, and disc space is now very cheap. So I'm perfectly well future-proofed without pinning my mast to a workspace like ProPhoto ... that may well die a death (hopefully) in the future.
So you could say that I hold my base image in a very wide gamut space ... the raw file ... but for the reasons that I've gone over I don't use the widest commonly available workspace (ProPhoto) in Photoshop - I'll use a much more efficient wider-gamut workspace like Beta RGB, or if the image gamut is smaller I'll go to Adobe RGB or sRGB.
You know very well that I've never suggested that everyone should just use sRGB. But I don't entirely disagree with Steve Upton (for whom you seem to have a great regard): most people would be better off sticking to sRGB because most people don't know (or care) about what can happen to their images when they start to mess with them in a wide-gamut workspace. Of course, Adobe hasn't seen fit to provide this option in Lightroom, except for jpegs..
I expect that this is one of the reasons why most smart phones and consumer grade cameras default to sRGB and jpg: the camera does the work and leaves little to the user to cause damage to. It's a common interchange format that works without alteration to the web, office applications, all web browsers, photo viewers etc.
Robert
-
1. Yes of course (in terms of bigger going smaller gamut)! The images have a gamut that greatly surpasses sRGB so sRGB is the wrong encoding working space to use for these images (all images unless you can show otherwise) from raw processed using the ACR engine. The rendering intent is a red herring you continue to obsess upon.
2. No, no problems. In my workflow, and many others, it's scan once, use many (or capture raw, render once, use many). I have no idea what output device my images will go to today or a year from now. And I want to retain all the data I can in the master to use it. So the answer is simple: encode in the largest color space I can. At such a point I'm going to output that data to a known device and have a profile, I'll examine what rendering intent makes the image look best (IF I even have such an option, output to web isn't one of them and it doesn't matter a bit to me considering the huge inconsistencies of output devices and lack of color management for so many). So again, you're obsessing about rendering intents and I've seen nothing thus far in my work or anything you've shown that illustrates I should be concerned and just use a smaller gamut working space instead.
3. I agree that I should use the biggest working space that doesn't clip color I captured which is WHY I use ProPhoto RGB. I'm far, far less concerned wasting space than wasting color data.
I don't know what a standard working space like sRGB or AdobeRGB means, seems like something someone made up. For me, ProPhoto RGB is a standard working space, my standard working space! I really don't care what some think the entire world is using, and no, if everyone used sRGB, they would have the same poor output to their Epson's as I see to mine using that working space (compared to ProPhoto RGB, even Adobe RGB (1998) which I just tested and found produced an inferior print to the 3880 compared to ProPhoto RGB.
IF anything, the recent testing I did with my Gamut Test File (from raw and some synthetics) has strengthened my opinion that ProPhoto RGB is a vastly better working space to use based on how I capture my data, in the converter I use and the output device I print to today.
You would have made a good politician Andrew.
-
No, of course I don't know what possible destinations there might be in the future ... I'm not a fortune-teller.
OK, it is just that you said quite clearly: In my case I only process an image when I know the destination, so I don't need to worry about what-ifs.
But until I do know the output I leave the image in raw (processed in Lightroom, which goes a long way, as you know). Once I know that the image is going to, say, a matte paper with a limited gamut, I then create a virtual copy in Lightroom and soft-proof the image for that output. I will then do any further processing in Photoshop.
So IOW, ProPhoto RGB (at least with respect to the raw processing).
You know very well that I've never suggested that everyone should just use sRGB.
I never said you do. There are plenty of others who do however. It's a workflow concept. But I don't entirely disagree with Steve Upton (for whom you seem to have a great regard): most people would be better off sticking to sRGB because most people don't know (or care) about what can happen to their images when they start to mess with them in a wide-gamut workspace.
If you don't care, it doesn't matter if you use color management or not. I expect that this is one of the reasons why most smart phones and consumer grade cameras default to sRGB and jpg: the camera does the work and leaves little to the user to cause damage to.
Has nothing to do with damage and everything to do with the audience. Good enough color is good enough for a lot of people. Going back to the 'just use sRGB' workflow.
-
You would have made a good politician Andrew.
Well at least conclusions are based on testing and viewing of images. And I've provided a means for anyone else who cares to do so. After that, whatever they decide to do workflow wise is AOK with me. It's the people who have predetermined ideas about color and workflows, or those that have read stuff by people like Rockwell, Fong and Crockett and never do their own testing but believe their nonsense that need to be dismissed and/or ignored.
-
Well at least conclusions are based on testing and viewing of images. And I've provided a means for anyone else who cares to do so. After that, whatever they decide to do workflow wise is AOK with me. It's the people who have predetermined ideas about color and workflows, or those that have read stuff by people like Rockwell, Fong and Crockett and never do their own testing but believe their nonsense that need to be dismissed and/or ignored.
Well, as you know from other threads on this forum, I've done a hell of a lot of testing and also a hell of a lot of under-the-hood and theoretical digging. I think you sort of fall under the category of someone who needs to be listened to with caution: when you demonstrate the clipping of an image when going from ProPhoto to sRGB and conclude that sRGB is inferior to ProPhoto and should be avoided as it results in bad prints ... you are really not advising people correctly.
I do post my thoughts on this forum, but I don't pretend to be a color management guru. If I did then I would be a lot more careful in my recommendations and conclusions.
Having said that ... I do think most of your advice is very sound and well thought through. But you do have some hobby-horses in the color management and sharpening areas that may not be entirely open-minded.
Robert
-
Well, as you know from other threads on this forum, I've done a hell of a lot of testing and also a hell of a lot of under-the-hood and theoretical digging. I think you sort of fall under the category of someone who needs to be listened to with caution: when you demonstrate the clipping of an image when going from ProPhoto to sRGB and conclude that sRGB is inferior to ProPhoto and should be avoided as it results in bad prints ... you are really not advising people correctly.
Proof is in the print bud. No theoretical digging necessary!
-
Proof is in the print bud. No theoretical digging necessary!
I know bud ... and I've done a hell of a lot of printing! Not just recently, but since I bought my first Epson 4000 in 2004.
For someone who knows (talks and teaches) so much about the theory of color management and printing, saying that 'No theoretical digging is necessary' is a bit rich :).
Robert
-
I know bud ... and I've done a hell of a lot of printing! Not just recently, but since I bought my first Epson 4000 in 2004.
That long, wow?
My first digital printer was a Kodak XL-7700, cost me $10K used back in 1993!
And yes, viewing two prints side by side to evaluate print quality doesn't require a lick of theoretical digging. You do need to have a good pair of eyes however...
-
when you demonstrate the clipping of an image when going from ProPhoto to sRGB and conclude that sRGB is inferior to ProPhoto and should be avoided as it results in bad prints ... you are really not advising people correctly.
I know I said I was out of this thread, but sorry, this comment I’m really having a hard time with.
First, your statement that ppRGB can “get you into trouble” is what started this whole thing, and while you point out some theoretical issues with perceptual rendering intents, you haven’t provided a single real world example which actually demonstrates this problem. You claim it’s not up to you to prove it, perhaps this is because you haven’t been able to?
I went back through a couple hundred of my images last night, and found around 20 that I decided a perceptual intent offered me a better print, since your main premise is this is mostly problematic when using that intent. No surprise to me, all of these are ones that exceeded sRGB and AdobeRGB quite a bit ... so in these cases in a workflow where I try to predetermine the appropriate size of the working space, which seems to be what are advocating, i would have chosen ppRGB. I couldn’t find a single example of an image with a fairly limited color palette that may have fit inside a smaller space where I decided a perceptual intent was necessary. So while perhaps there are issues with perceptual renderings, the only way around this would be clip the colors into a smaller working space to start with, something which even you claim isn’t the best policy.
I tried this with a few images last night, trying to see if I could get a better image. Choosing images that appeared to easily fit in the gamut of AdobeRGB, I opened two copies from ACR, one in aRGB, the other in ppRGB (both in 16bit). I left them a little “off” I made a couple of saturation, density, and color changes inside of photoshop, and then I printed each of those twice, once using a relative intent, once using a perceptual. Sorry, no real difference at all, the fact that the ppRGB space was so large didn’t really change anything in either case, most likely because the colors weren’t that far out of gamut from the printer space.
So I took you challenge ... and after a few hours with my 9900 I can’t see where ppRGB got me into trouble because my image palette was small enough to be contained in sRGB or aRGB, and choosing ppRGB messed things up.
Whereas Andrews advice (as well as many others) seems pretty sound (just stay in ppRGB until you are ready for output), at this point the main conclusion from this entire thread is what you advocate isn’t necessary because it’s a waste of time and won’t yield any visible difference (and runs the risk of costing some quality) ...
So not intending to sound blunt or direct and with no desire to offend, it appears you are that one that may not be offering the best advice. Now admittedly it probably won’t hurt anything, but it doesn’t gain anything.
My first digital printer was a Kodak XL-7700, cost me $10K used back in 1993!
I ended up buying three of those before they finally introduced the 8300 which we ended up deploying in about 100 locations (3 in each)
Built like tank! (because that’s where they went first )
I remember how amazing it seemed at the time ...
-
Built like tank! (because that’s where they went first )
I remember how amazing it seemed at the time ...
Yup, rack mountable and weighted a lot too. I still have prints made way back then, stored in the original 10x10 Kodak boxes. They still look damn good considering how old that technology was.
-
That long, wow?
My first digital printer was a Kodak XL-7700, cost me $10K used back in 1993!
And yes, viewing two prints side by side to evaluate print quality doesn't require a lick of theoretical digging. You do need to have a good pair of eyes however...
Yes, well I have to bow to your superior experience :)
Quite right, you don't need a lick of theoretical digging to compare two prints side by side. What about getting the best out of your equipment and workflow though? Just happens by luck I suppose. Buy the camera, click the button, send the file to the printer ... and hey-presto you have a wonderful print, every time. Would be nice, wouldn't it?
What about all that color management stuff, profiles, raw images, bla bla bla? No need to know about any of that?
Come on Andrew ... you're arguing for the sake of arguing, and losing the battle I'm sorry to say because, as you know, you're on shaky grounds when it comes to that video of yours. Best to accept that you've overstated the case and correct the information.
Robert
-
Come on Andrew ... you're arguing for the sake of arguing, and losing the battle I'm sorry to say because, as you know, you're on shaky grounds when it comes to that video of yours. Best to accept that you've overstated the case and correct the information.
You are entitled to that opinion, and that's all it is. Given what you've written here about a number of areas of color management, I'm taking that opinion with a grain of salt (or less than a grain ;D). In terms of winning or losing an argument, which I didn't think was par for this post, it appears you sir are the one who's peers here are disagreeing with your opinions as you've got little to back them up. It's why long ago, I suggested it was time to move on. Certainly the OP did after you kind of hijacked the thread.
-
You are entitled to that opinion, and that's all it is. Given what you've written here about a number of areas of color management, I'm taking that opinion with a grain of salt (or less than a grain ;D). In terms of winning or losing an argument, which I didn't think was par for this post, it appears you sir are the one who's peers here are disagreeing with your opinions as you've got little to back them up. It's why long ago, I suggested it was time to move on. Certainly the OP did after you kind of hijacked the thread.
Yes, well I'm not sure that I can be accused of being the only one who has hijacked this thread ... but you're right, it's poor form on all our parts, so on my part I apologize to the OP.
Robert
-
I know I said I was out of this thread, but sorry, this comment I’m really having a hard time with.
Well I’m glad that you are back because I was really concerned that I had offended you seriously with my flippant remark. I hope we can put that unfortunate episode behind us.
First, your statement that ppRGB can “get you into trouble” is what started this whole thing, and while you point out some theoretical issues with perceptual rendering intents, you haven’t provided a single real world example which actually demonstrates this problem. You claim it’s not up to you to prove it, perhaps this is because you haven’t been able to?
ppRGB can get you into trouble primarily because it’s easy to push colors out of gamut in any workspace that is larger than your monitor’s workspace, as you can’t always see the OOG colors (you may see banding but the problem may only manifest itself at output).
Here’s an example. The image on the left looks fine, doesn’t it? (if you viewed the original image on a wide-gamut display in ProPhoto you might think it a bit over-saturated and I would agree, but a lot of photographers are still on sRGB displays and the image will look fine on these). The image on the right is the same one with gamut warning turned on. The image is in ProPhoto and the output profile is for a Canson Baryta paper, which has a gamut slightly bigger than aRGB.
(http://www.irelandupclose.com/customer/LL/OOG.jpg)
What’s going to happen to the OOG colors? Well we can get an idea from soft-proofing, but if we don’t know about soft-proofing and gamut warnings etc., we may get an unpleasant surprise when we print. We may not, but we may.
The point is that if you know what you’re doing, then you can work in ProPhoto with little risk – because you will check the image gamut, you won’t push it beyond your printer gamut … and so on. But a lot of people (look at the start of this thread) really don’t know very much, if anything, about profiles, OOG etc. So let them loose with ProPhoto and it’s like giving a Lamborghini to a 10-year-old: he’ll probably crash it.
So yes, of course ProPhoto can get you ('one', I should say) into trouble. You, no doubt, are fine: you’ve been at this game for decades and you really do know what you’re doing. That isn’t true of all photographers, not even professional ones.
I went back through a couple hundred of my images last night, and found around 20 that I decided a perceptual intent offered me a better print, since your main premise is this is mostly problematic when using that intent.
No, I didn’t say that Perceptual is the one that is most likely to cause problems. Actually it’s probably the one that is LEAST likely to cause problems because a good perceptual profile will normally do a reasonable job of squeezing the OOG colors into the smaller space, with little or no banding. Although it will shift the colors, more than likely (see below).
Actually a Relative Colorimetric mapping is much more likely to cause flattened areas and banding … as Andrew demonstrated in his video. What happens when you go from ProPhoto to sRGB can just as well happen when you go from a larger working space to a smaller destination space using RC.
No surprise to me, all of these are ones that exceeded sRGB and AdobeRGB quite a bit ... so in these cases in a workflow where I try to predetermine the appropriate size of the working space, which seems to be what are advocating, i would have chosen ppRGB.
You’ve made my point. The images that caused problems were images that had a wider gamut than your output device. If your image had been in a smaller working space you would not have had the problem, mainly because the image colors would have been less saturated.
I couldn’t find a single example of an image with a fairly limited color palette that may have fit inside a smaller space where I decided a perceptual intent was necessary. So while perhaps there are issues with perceptual renderings, the only way around this would be clip the colors into a smaller working space to start with, something which even you claim isn’t the best policy.
If the image has a small gamut (smaller than the destination) then you can quite happily use a relative or perceptual mapping: it will make very little difference especially if the profiles are good.
When I talk about the possible greater shifting of colors when printing (using perceptual) from a very wide gamut working space compared to the same image printed from a smaller working space (that can still contain the image’s gamut) I’m talking about very subtle differences. You would only be concerned with these if you were a perfectionist like me. I wouldn’t worry about it.
Of course clipping the colors into a smaller working space is not at all a good idea! Especially as WS->WS mappings are always RC, and so you will literally get clipping and possible flattening and banding (as Andrew demonstrated in his video … b-x, I’m getting a sense of déjà vu all over again, as Yogi Berra said). However, if you want to minimise the color shifts then converting to a smaller working space that DOES contain the image’s color WITHOUT clipping may give you less of a color shift when mapping with a perceptual intent. It depends on how ‘good’ or ‘bad’ the profile is (and ‘good’ profiles that give a true perceptual mapping are likely to cause a greater color shift … so you might consider them to be ‘bad’ profiles :)).
I tried this with a few images last night, trying to see if I could get a better image. Choosing images that appeared to easily fit in the gamut of AdobeRGB, I opened two copies from ACR, one in aRGB, the other in ppRGB (both in 16bit). I left them a little “off” I made a couple of saturation, density, and color changes inside of photoshop, and then I printed each of those twice, once using a relative intent, once using a perceptual. Sorry, no real difference at all, the fact that the ppRGB space was so large didn’t really change anything in either case, most likely because the colors weren’t that far out of gamut from the printer space.
So I took you challenge ... and after a few hours with my 9900 I can’t see where ppRGB got me into trouble because my image palette was small enough to be contained in sRGB or aRGB, and choosing ppRGB messed things up.
Here’s an example:
(http://www.irelandupclose.com/customer/LL/OOG-RP.jpg)
Same image, both in ProPhoto, the left image is mapped with a relative colorimetric intent and the right hand image with perceptual.
Even someone with pretty dodgy eyesight can see that there are significant color differences: look at the sky blues and the petal magentas.
Maybe they look fine to you and you would be happy with either (or neither!) … but don’t tell me there’s no difference!
Whereas Andrews advice (as well as many others) seems pretty sound (just stay in ppRGB until you are ready for output), at this point the main conclusion from this entire thread is what you advocate isn’t necessary because it’s a waste of time and won’t yield any visible difference (and runs the risk of costing some quality) ...
That’s up to each of us to decide for ourselves.
I believe that there is a risk of loss of quality (in terms of color shifts, banding, flattening of areas of color) which may cause you to have to re-edit and reprint if you work in too large a working space without taking real care in your work (which in itself is an overhead, and possibly a waste of time).
You sort of don’t have much choice initially if you work from Lightroom: you will effectively be in a large working space. You don’t need to commit to a smaller working space until you are ready to print. As I’ve suggested in an earlier post (today, I think), you can keep your developed raw image as a smart object in Photoshop, which allows you to change from one working space to another.
So here’s an example of a valid workflow from raw:
- Process the image in Lightroom (and be careful not to go crazy OOG over an intermediate workspace like Adobe RGB, but don’t worry too much about it)
- Open the image into Photoshop as a Smart Object – choose whichever working space you like: ProPhoto is fine
- Do the next stage of editing in Photoshop
- Now you decide to print and you know because you’ve examined your image gamut that Adobe RGB will contain the image’s colors without clipping (quick soft-proof will tell you that)
- Convert the image to Adobe RGB
- Make any further tweaks to get the image ready for print (good idea to turn soft-proofing on)
- Print your image
You might say: why bother? Well supposing that your output is the web and not print. You now have no choice but to go to sRGB … so you convert your image to sRGB instead of aRGB in step 5 above. Whoa! Banding, flattening … ugly! No problem, go back into the raw smart object and adjust the saturation so that it fits into sRGB without the ugglies.
So choosing smaller workspaces does not mean that you are forever limited to them.
In case you think I’ve just made up this workflow to get out of a sticky spot, have a look at this thread: http://www.luminous-landscape.com/forum/index.php?topic=91514.0
So not intending to sound blunt or direct and with no desire to offend, it appears you are that one that may not be offering the best advice. Now admittedly it probably won’t hurt anything, but it doesn’t gain anything.
Could be, but as you’ve guessed, I don’t think so :).
Robert
-
ppRGB can get you into trouble primarily because it’s easy to push colors out of gamut in any workspace that is larger than your monitor’s workspace, as you can’t always see the OOG colors (you may see banding but the problem may only manifest itself at output).
So you propose we clip all the colors into the gamut of our displays? We'd then be able to see them all.
You understand that the OOG overlay you use is buggy, shows OOG colors that are not really OOG and treat a tiny degree of OOG the same is a boat load of OOG? It's pretty useless IMHO (and it's a legacy feature that predates soft proofing in Photoshop which is far more effective.
-
So here's my PA272W (red) with Adobe RGB (green wireframe) with a big honking piece of the 3880 out of gamut for both. What this illustrates is the silly idea that ProPhoto RGB is too big because it falls outside display gamut and is true for many (most) of our output devices! We soft proof yes? Lots of colors we can't see. So let's just throw the baby out with the bath water, clip colors we can capture and can print to (in this case) Adobe RGB just so we can see them on the display? I don't think so! Not when I can see them when they are printed.
Show me an output device that fully contains the gamut of a working space like sRGB. Good luck. There are some that fall fully within Adobe RGB (1998) SWOP V2 fully falls within Adobe RGB (1998) gamut. Not a Lightjet (most but not all colors). A modern ink jet? Forget about it!
The idea we have to somehow match the gamut of our output devices OR working space's to fully fit our display profile so we can see them is just silly! Unless your only output is to a display. Or you're happy to clip colors you can capture and can reproduce but decide it's more important to see them on an intermediate device (the display) than the final device (the printer). This idea we can't use a color space because it contains color we can't see is largely FUD.
(http://www.digitaldog.net/files/AdobeRGB_PA272vs3880Luster.jpg)
This illustrates too how Adobe RGB is too small a working space in terms of gamut to use for output to the 3880. It's why in the test I did today, the ProPhoto RGB image has much better blues/cyans on the fish image, the fishermans shorts, and why the colorful cloth image has more 'shadow detail/sharpness' because I didn't clip allow those useful colors seen above.
-
Here’s an example:
(http://www.irelandupclose.com/customer/LL/OOG-RP.jpg)
Same image, both in ProPhoto, the left image is mapped with a relative colorimetric intent and the right hand image with perceptual.
Even someone with pretty dodgy eyesight can see that there are significant color differences: look at the sky blues and the petal magentas.
Maybe they look fine to you and you would be happy with either (or neither!) … but don’t tell me there’s no difference!
That’s up to each of us to decide for ourselves.
Ok, you've proven that there is a difference between RelCol & Percept rending when printing from PP RGB. Cool...did you expect anything less? Of Course there will be a difference. DOOOOH. So which is better? RelCol or Percept? Are you saying the you cant make a move to make one look like the other? (clue, pretty easy to do with HSL).
So, the question begs to be asked, which looked "better" RelCol or Percept? Do you need help making one look like the other?
Look, ignore OOG warning info will you? Realize that the OOG warning is at best telling you that some colors may be out of gamut...it doesn't tell you much else.
You really, REALLY need to move beyond Out Of Gamut colors...The odds are, if you've opened a raw capture into PP RGB there will be OOG colors in most printers. The important thing to consider is what do those OOG colors look like? That's what soft proofing provides.
Once you know what the final print will look like, what moves do you want to make (which is a strength of LR's soft proofing).
Nope, sorry, still not convinced...
Storing my master RGB in PP RGB still seems lie the best option as long as you use soft proofing.
If you don't know how to soft proof, that's not my problem...
BTW, let me know if you want to know how to make the required adjustments to make one look like the other in the above posted images...really easy to do (hint: HSL adjustments)
-
So you propose we clip all the colors into the gamut of our displays? We'd then be able to see them all.
You understand that the OOG overlay you use is buggy, shows OOG colors that are not really OOG and treat a tiny degree of OOG the same is a boat load of OOG? It's pretty useless IMHO (and it's a legacy feature that predates soft proofing in Photoshop which is far more effective.
Don't put words in my mouth Andrew. I've never suggested we clip all the colors into the gamut of our displays. There's a big difference between selecting an appropriately-sized workspace for your image and clipping all the OOG colors to a workspace that is far too small to contain the image's gamut (as you so ably ... or perhaps not so ably ... demonstrated in your video by clipping the hell out of your test image when you converted it to sRGB).
If you don't trust the Photoshop or Lightroom OOG warnings (is the Lightroom OOG warning also a legacy feature that is buggy, in your opinion?) then there are other tools that are not buggy and give a much better view of the potential problems, as you very well know. Here is a GamutVision colormap that shows OOG colors: as you can see it shows more OOG colors than does Photoshop, and does so with more discrimination:
(http://www.irelandupclose.com/customer/LL/Orchid-oog.jpg)
But anyway, I get it: ProPhoto and the print is the holy grail and anything else is a load of gunk. Hope you don't waste too much paper and ink.
Robert
-
But anyway, I get it: ProPhoto and the print is the holy grail and anything else is a load of gunk. Hope you don't waste too much paper and ink.
Pretty much yes...and yes I don't waster a lot of paper/ink...I usually nail it 1st print out (after soft proofing). Sometimes I print a 2nd print (in case I screwup signing the darn print-but that's atypical).
Yes, you can go down various rabbit holes if you want...I choose not to do so.
And yes, ACR Smart Objects are "interesting"...heck you can even spec out Lab as an output space if you want to go down that route.
Personally, my personal choice is ProPhoto RGB and a Linear gamma as an output space in Photoshop (from Lightroom). But that's another debate all by itself (as to why linear is a better gamma to work in than 1.8).
-
Ok, you've proven that there is a difference between RelCol & Percept rending when printing from PP RGB. Cool...did you expect anything less? Of Course there will be a difference. DOOOOH. So which is better? RelCol or Percept? Are you saying the you cant make a move to make one look like the other? (clue, pretty easy to do with HSL).
So, the question begs to be asked, which looked "better" RelCol or Percept? Do you need help making one look like the other?
Look, ignore OOG warning info will you? Realize that the OOG warning is at best telling you that some colors may be out of gamut...it doesn't tell you much else.
You really, REALLY need to move beyond Out Of Gamut colors...The odds are, if you've opened a raw capture into PP RGB there will be OOG colors in most printers. The important thing to consider is what do those OOG colors look like? That's what soft proofing provides.
Once you know what the final print will look like, what moves do you want to make (which is a strength of LR's soft proofing).
Nope, sorry, still not convinced...
Storing my master RGB in PP RGB still seems lie the best option as long as you use soft proofing.
If you don't know how to soft proof, that's not my problem...
BTW, let me know if you want to know how to make the required adjustments to make one look like the other in the above posted images...really easy to do (hint: HSL adjustments)
You remind me of my brother, Andrew: he's a master argumenter, and what he does is to shift the subject when he's on the losing end of the argument.
You asked me to give you examples to demonstrate color shifts, but when I do you say "doh! what did you expect?" and then you lecture me on how to correct these colors and to ignore the fact that they were OOG. The reason they are wrong is that they are OOG and so the perceptual rendering shifts them to bring them into gamut whereas the relative rendering clips them. Of course we can do something to correct this: we can not let them go into gamut in the first place; we can bring them back into gamut, or we can tweak them to bring them back to something like what they should be (which can be very difficult if we can't see the colors on our monitor and we don't trust the OOG warnings!). Also, if you do need to make corrections like this, I would recommend Selective Color rather than HSL as it gives much better control.
What you appear to be suggesting is this:
- Keep your image in ProPhoto and forget about Gamut Warnings, they're unreliable and a waste of time
- Soft proof the image and tweak it to make it look 'good'.
- Print the image in both RelCol and Perc because you won't be able to see which looks better on your monitor (since the monitor gamut is smaller than your printer gamut)
- Pick the print you like best and throw away the other (or give it to charity) .... or ....
- Go back to step 2 and see if you can make further tweaks that will result in an acceptable print
So, if you like pain then that's fine, it will keep the ink and paper suppliers in business, so some good will come of it.
But don't tell me to ignore OOG warnings and at the same time tell me to trust the soft-proofing, when you know only too well, since you mentioned this yourself in another thread, that the problem is that the monitor gamut is smaller than the print gamut in areas, AND the monitor gamut is significantly smaller than ProPhoto so you may not be able to SEE colors that are out of gamut in these areas, even with soft-proofing on, if the colors are greater than your sRGB or aRGB monitor.
Whether you like it or not, this is currently a problem, and there is no magic solution to it. You can take a chance as you propose, and go ProPhoto all the way; or you can try to reduce the unknowns by restricting your image to a space that is close to your monitor's gamut. Yes, this will mean that you may not be able to print some of the more saturated colors that you would have been able to do from ProPhoto ... but it also means that these more saturated colors won't be there, and you can use your HSL or Selective Color or Contrast or dodge/burn, or whatever adjustments to give the saturated look you want (as you know the impression of saturation is a relative one: if you have a desaturated color near a more saturated one, you bump up the impression of saturation by a huge amount, in the same way that local contrast gives a greater impression of detail, tonal depth and sharpness).
Look at this painting I did recently:
(http://www.irelandupclose.com/customer/LL/riverscene.jpg)
You may be interested to know that this was painted in PHOTOSHOP, with brushes that I have personally developed. The image was painted in sRGB. I think you may agree that there is plenty enough saturation, although I used watercolor colors that are not at all saturated. The effect of saturation is because of the adjacent and contrasting unsaturated colors.
So, as they say, there's more ways than one to skin a cat.
Robert
-
Pretty much yes...and yes I don't waster a lot of paper/ink...I usually nail it 1st print out (after soft proofing). Sometimes I print a 2nd print (in case I screwup signing the darn print-but that's atypical).
Yes, you can go down various rabbit holes if you want...I choose not to do so.
And yes, ACR Smart Objects are "interesting"...heck you can even spec out Lab as an output space if you want to go down that route.
Personally, my personal choice is ProPhoto RGB and a Linear gamma as an output space in Photoshop (from Lightroom). But that's another debate all by itself (as to why linear is a better gamma to work in than 1.8).
Great ... I'm glad to hear your printing is usually successful. But then, Jeff, you are a person who has years of experience printing and who has done a huge amount of investigating and experimenting in this area. So you know, without needing much 'instrumentation' what is going to be OK and what is not, and you are not going to do stupid things like going bonkers with saturation in areas that you know your printer will struggle with (like saturated reds, perhaps).
It's like exposure: do you need to look at the histogram every time you take a shot? I don't because I know from experience how to get a good exposure, just from the shutter speed and aperture. Having said that, neither do I discount the camera's exposure meter or the captured image histogram: these are useful tools ... and they are especially useful when you are learning. As you get more experienced you don't need to rely on them as much, and you don't need to take 3 shots in order to get one right any more. Just as you no longer need to do 3 prints in order to get one right.
Same isn't true for all of us.
Robert
-
What you appear to be suggesting is this:
- Keep your image in ProPhoto and forget about Gamut Warnings, they're unreliable and a waste of time
- Soft proof the image and tweak it to make it look 'good'.
- Print the image in both RelCol and Perc because you won't be able to see which looks better on your monitor (since the monitor gamut is smaller than your printer gamut)
- Pick the print you like best and throw away the other (or give it to charity) .... or ....
- Go back to step 2 and see if you can make further tweaks that will result in an acceptable print
Well, you keep thinking one can't tell what rendering intent would be the most useful to use nor determine what moves one might make to get the final print you want. I don't bother to use both rendering intents (the vast majority of the time it's RelCol) and with with soft proofing I can reliably predict what the final print looks like-before putting ink on paper.
Not sure why you have a hard time understanding this...it's almost like you plot all this on paper and then because of the plotted result, determine in advance, that what you are thinking is gonna prevent you from getting the results you want, prevent you from getting the result you want and you simply quit.
Sure, I'm willing to make test print to prove that what I think a print is gonna look like actually looks like soft proofing predicts it will look like...the more I do that, the more I'm convinced that the soft proofed prediction is correct.
Sorry, you keep digging your hole and only get deeper with time...and what I keep doing keeps working. So, who's right? Well, what I'm doing seems to keep working really well. So, there ya go...do what I do or do what you do. I'll keep doing what I do...
-
Well, you keep thinking one can't tell what rendering intent would be the most useful to use nor determine what moves one might make to get the final print you want. I don't bother to use both rendering intents (the vast majority of the time it's RelCol) and with with soft proofing I can reliably predict what the final print looks like-before putting ink on paper.
Not sure why you have a hard time understanding this...it's almost like you plot all this on paper and then because of the plotted result, determine in advance, that what you are thinking is gonna prevent you from getting the results you want, prevent you from getting the result you want and you simply quit.
Sure, I'm willing to make test print to prove that what I think a print is gonna look like actually looks like soft proofing predicts it will look like...the more I do that, the more I'm convinced that the soft proofed prediction is correct.
Sorry, you keep digging your hole and only get deeper with time...and what I keep doing keeps working. So, who's right? Well, what I'm doing seems to keep working really well. So, there ya go...do what I do or do what you do. I'll keep doing what I do...
I don't know why you think that I don't get the results that I want? ... and that after much plotting and measuring and calculating I just quit 'cause I've proved to myself I can't get the result that I want? Honestly, you're as bad as Andrew!
What makes you think I don't have a very good idea of what is the best rendering intent to use for a particular print? What have I said that gives you this notion? ... or are you just about making unfounded statements like this?
I get wonderful prints that I and my customers are delighted with. Just because I don't follow your workflow doesn't mean that mine is any more complicated, takes any more time, or produces inferior results. It's like the sharpening discussion we had: because we find out that deconvolution can give better results than USM doesn't mean that our workflow has suddenly become incredibly complex ... all it means is that we may be getting better results than before.
Instead of all of these put-downs it would be more useful if you went back to some of my examples and commented on these critically and intelligently.
Robert
-
Don't put words in my mouth Andrew. I've never suggested we clip all the colors into the gamut of our displays.
You're now being rather ridiculous as we pin you down Robert. I didn't put words in your mouth, I asked you a question! See the little character at the end of the sentence that looks like this ? (another question mark). Quote from: Robert Ardill on September 25, 2014, 04:56:40 PM
ppRGB can get you into trouble primarily because it’s easy to push colors out of gamut in any workspace that is larger than your monitor’s workspace, as you can’t always see the OOG colors (you may see banding but the problem may only manifest itself at output).
Andrew Rodney: So you propose we clip all the colors into the gamut of our displays?
You started this sillyness early on, suggesting there are issues, problems with ProPhoto RGB. By and large, your peers here have dismissed this and disagree. You've got an issue with it defining colors that fall outside display gamut, you wrote that just yesterday. I am unsure of your understanding of color management after all these pages so I asked. Are you aware that lots of color spaces, working space and output spaces fall outside display gamut? IF SO, how can you single out ProPhoto RGB?
Moving on. You suggest there's some issue with rendering intents and wide gamut and illustrate they appear differently. As Jeff so elegantly wrote: Duh! So what? But to backup your prejudices you write:
You asked me to give you examples to demonstrate color shifts, but when I do you say "doh! what did you expect?"
Color shifts? Color difference yes but shifts? Seems a stretch to me. Seems you sir are the politician!
You have this prejudices against ProPhoto RGB. You attempt to explain to lurkers that it is problematic but can't illustrate the issue, and admit you use it, then ignore that at least the one issue you have with it is shared by boat-loads of other color spaces. You're welcome to your flat earth ideas about color, but those of us with the satellite imagery see otherwise. As yet, I haven't seen anyone agree with you (quite the opposite). You're welcome to use whatever workflow you wish, I think I can speak for everyone by saying do use it and we wish you well. For lurkers and for the OP, much of what you've written doesn't wash. Doesn't make sense, can't be proven using a scientific method. And yet you love those gamut maps which are questionable and simply do not dismiss the facts our print output shows us time and time again.
Whether you like it or not, this is currently a problem, and there is no magic solution to it.
No, it's not a problem. At least for many, many LR/ACR and Photoshop users. It's your problem, your prejudice and if and when you properly learn to use the tools as others here have, you'll see it's not a problem. You call this an argument. I don't think so. I think you're kind of confused and have a workflow to defend and a prejudice towards a working space that IS used to process many or our images by choice of the raw converter we select. You're making up FUD with all these 'potental problems' and we're not buying it. I wrote we should move on pages ago. If the post has served any benefit , it's to point out that there are no prefect RGB working space. ProPhoto makes the best sense for many of us and that you're making mountains out of molehill's in terms of the issues you think there are with it's use. You can be very creative and screw up any image due to ignorance or on purpose to make a point. Don't screw up images.
Instead of all of these put-downs it would be more useful if you went back to some of my examples and commented on these critically and intelligently.
You may wish to review your own writings in this thread towards myself and Wayne before you go down that path Robert. Your quote above sounds like that of a politician who see's he's slipped up and has to cower to his base (whoever else that may be here if anyone).
-
Look at this painting I did recently:You may be interested to know that this was painted in PHOTOSHOP, with brushes that I have personally developed. The image was painted in sRGB. I think you may agree that there is plenty enough saturation, although I used watercolor colors that are not at all saturated.
Immaterial to the discussion, a digression, misdirection.
-
You're now being rather ridiculous as we pin you down Robert. I didn't put words in your mouth, I asked you a question! See the little character at the end of the sentence that looks like this ? (another question mark).
You started this sillyness early on, suggesting there are issues, problems with ProPhoto RGB. By and large, your peers here have dismissed this and disagree. You've got an issue with it defining colors that fall outside display gamut, you wrote that just yesterday. I am unsure of your understanding of color management after all these pages so I asked. Are you aware that lots of color spaces, working space and output spaces fall outside display gamut? IF SO, how can you single out ProPhoto RGB?
You know Andrew, there is also a thing called sarcasm and irony. When you say "So you propose we clip all the colors into the gamut of our displays?" that is what I take it to be. You surely wouldn't seriously ask me this question, wondering whether this is what I am actually proposing, wanting a serious reply from me.
If you did ask the question seriously, which I entirely doubt, then it's an absurd question, especially considering the fact that I have been lambasting you for doing just that with your test image on your video.
I don't feel that you are pinning me down at all. On the contrary, I am completely confident in what I have said and so far you have failed to respond to the points I have made or to answer my questions to you. For example, in the next post from you (the one before this reply), your comment is: "Immaterial to the discussion, a digression, misdirection.". That has tended to be the gist of your responses.
So I will again ask you the questions that have been for me at the root of our discussion: and that is regarding your assertion that sRGB is a bad working space to use. Here are my questions again:
Do you, or do you not accept that there is nothing wrong with sRGB, providing that the image gamut is contained within it?
Do you, or do you not accept that in your video you clip the wide gamut colors from the image, into a smaller color space whose gamut is much smaller than the image gamut, using a relative colorimetric mapping, and that you use this to 'demonstrate' that the smaller color space is deficient?
Moving on. You suggest there's some issue with rendering intents and wide gamut and illustrate they appear differently. As Jeff so elegantly wrote: Duh! So what? But to backup your prejudices you write:Color shifts? Color difference yes but shifts? Seems a stretch to me. Seems you sir are the politician!
Again, it seems to me that a response of "Duh! So what?" ... is not elegant at all but rather dismissive and discourteous.
Perhaps you would then answer me this question:
- How do you get color differences without color shifts? And do you not think you are splitting hairs?
You have this prejudices against ProPhoto RGB. You attempt to explain to lurkers that it is problematic but can't illustrate the issue, and admit you use it, then ignore that at least the one issue you have with it is shared by boat-loads of other color spaces. You're welcome to your flat earth ideas about color, but those of us with the satellite imagery see otherwise. As yet, I haven't seen anyone agree with you (quite the opposite).
I do not have prejudices against ProPhoto. I just do not think that it is the best working space to use unless your image has a very wide gamut that cannot be contained in a smaller color space but which nevertheless can be printed (as can be the case). I have simply suggested that it is better (and you are free to disagree, of course) that using an unnecessarily large color space is unnecessary and can cause problems.
Of course I agree that all working spaces, as they are currently defined, have problems: as I've said, we are trying to fit a round peg into a square hole, and this applies to all current working spaces. sRGB has major issues too, at the opposite end to ProPhoto in that it is too small for many images. Adobe RGB also has issues: again, it falls short of the gamut of modern printers, so that it is unsuitable for images that have a gamut that lies within the printer gamut but outside of its own gamut. So I do agree that if you wish to use only one working space, then that working space should be large enough to hold the gamut of your images, and so a working space like ProPhoto is a valid choice. You could also pick an intermediate one like Beta RGB which will pretty much cover all real-life colors (but which is in spots smaller than the best printer gamuts).
I have illustrated the potential problems with very large working spaces both in this topic and in links that I have posted. I have also suggested that you should talk to Graham Gill who is a CMM engineer and the author of ArgyllCMS as I personally think that he has in-depth knowledge of color management and can give you an independent view on this subject. So I am not asking you to take my word for it: I have tried to show you the problems and I have given you a link to an expert in the field.
You're welcome to use whatever workflow you wish, I think I can speak for everyone by saying do use it and we wish you well. For lurkers and for the OP, much of what you've written doesn't wash. Doesn't make sense, can't be proven using a scientific method. And yet you love those gamut maps which are questionable and simply do not dismiss the facts our print output shows us time and time again. No, it's not a problem. At least for many, many LR/ACR and Photoshop users. It's your problem, your prejudice and if and when you properly learn to use the tools as others here have, you'll see it's not a problem. You call this an argument. I don't think so. I think you're kind of confused and have a workflow to defend and a prejudice towards a working space that IS used to process many or our images by choice of the raw converter we select. You're making up FUD with all these 'potental problems' and we're not buying it. I wrote we should move on pages ago. If the post has served any benefit , it's to point out that there are no prefect RGB working space. ProPhoto makes the best sense for many of us and that you're making mountains out of molehill's in terms of the issues you think there are with it's use. You can be very creative and screw up any image due to ignorance or on purpose to make a point. Don't screw up images. You may wish to review your own writings in this thread towards myself and Wayne before you go down that path Robert. Your quote above sounds like that of a politician who see's he's slipped up and has to cower to his base (whoever else that may be here if anyone).
You do sound quite angry. I have already apologized to Wayne over the 'Flat Earth Society' quip and I hope he's accepted my apology. I think it would be a good idea for me to go back on this thread to see if what you say is true and that I have been unpleasant, confrontational and illogical. If so then I offer an unreserved apology to everyone I may have upset.
But I do think that it is perfectly possible to show the pros and cons, strengths and weaknesses and problem areas of mappings from one color space to another by examining the profile that is used for the mapping and the way in which the CMM interprets this profile. I admit that some of it is hidden to us because the manufacturers do not reveal their algorithms much of the time: however, we can, if we wish, use profiles from ArgyllCMS and LCMS for the mappings, in which case all of the information is freely available to us as these are both open-sourced programs. As we can look at the source code and as we can examine the profiles we can know exactly what is happening. In other words, given an image, we can know exactly what the output to the output device will be and this will tell us precisely what is happening to the colors.
We do not need to print in order to see this. What we are looking at is the data that is being sent to the printer. This doesn't reduce the need to look at the prints themselves, of course: but if we are getting issues with our prints then it may well show us that the problem is not with the profile or CMM (for instance) but at the printer itself (or vice-versa). So it can provide useful information and help in diagnosing print problems.
Gamut maps are not the holy grail, but they can be very useful, as you know. They can show you immediately and visually if there is a fundamental problem with your profile (both Chromix and Imatest give examples of this) ... caused perhaps by misreads when scanning the profiling chart. They can show you what areas of your working space fall inside and outside of your print gamut, so you can focus your attention on these areas as they are the ones where the worst problems are likely to occur. Additional features in programs like GamutVision allow you to see the color differences that will occur when you map your image from your working space to the destination space (in other words give you a gamut warning type image that is FAR more useful and sophisticated than either LR's or PS's: the map shows quite accurately the color differences that will occur and where these are).
So I'm really surprised to hear you say that the gamut maps are questionable, especially as you are something of a color management expert yourself. In what way are they questionable? It would certainly be very useful to know in what way they are misinforming us, so I would be very grateful to you if you would be kind enough to explain the issues to us.
Anyway, it isn't clear to me that all of the 'lurkers' who have viewed this post have their minds made up that I'm talking nonsense. Perhaps some think that there may be something to it, and that it is worth trying to get an idea of what sort of things can help us get a better print without having to do it by trial and error (very expensive, very time consuming!!). It would be good to hear from some of these photographers ... who may also have other ideas and suggestions that could be of benefit to all of us.
Robert
-
Anyway, it isn't clear to me that all of the 'lurkers' who have viewed this post have their minds made up that I'm talking nonsense.
I have made up my mind, that's enough for me to follow my own advise and move on. Anything else (in terms of your comments about this) is just a waste of my time to pay attention to. Got to put you on the Ingore/Do not call list on this one.
-
Anyway, it isn't clear to me that all of the 'lurkers' who have viewed this post have their minds made up that I'm talking nonsense.
When you find yourself in a hole, the first thing to do is to stop digging.
-
OK, no problem ... I'm thoroughly tired of this discussion too, and like you I feel that I'm wasting my time and that all we're doing is going round and round. It reminds me of the tower houses in the Peloponnese in Greece which were built so that neighbors could lob stones at each other from the relative safety of their own massive walls. At harvest time they called a truce so they could get their crops in and after the harvest they would start again.
But I have to say, Andrew, that I am disappointed that you didn't answer the two simple questions I've been asking you regarding your video: since this is out there for the public to view, it would be good to get a statement from you regarding exactly what is happening when you convert the image to sRGB, why the clipping/flattening occurs, and whether or not this is a fundamental problem with sRGB, or whether it is a fundamental problem with converting an image with a wide gamut which is in a wide-gamut working space to a working space with a small gamut.
Robert
-
Hi Andrew,
I had a look at your video ... very well done as usual! In general I think your recommendations are fair, however comparing ProPhoto to sRGB is not really. It gives the impression that the wider the better, which is not necessarily true.
Here is a gamut map of Adobe RGB and the Epson 9900 with Canson Photo Hi Gloss paper (about as good a combination as one can get at this stage, gamut-wise):
(http://www.irelandupclose.com/customer/LL/aRGB-ep9000.jpg)
It is clear that even with Adobe RGB there is some possibility of clipping/shifting in the darker regions (as well as the lighter ones). However the clipping is minimal in the darker regions and certainly will not clip to black. There is of course considerably more clipping using sRGB and it makes no sense to have a printer like the 9900 and then printing saturated images from sRGB. With aRGB it's a judgement call, as you say in your video: have colors that you can't see but can print, or see what you are going to print and take the hit on some of the saturated colors.
What you don't really say in your video is what things look like with ProPhoto. Here it is:
(http://www.irelandupclose.com/customer/LL/pRGB-ep9000.jpg)
No clipping admittedly :). But look at all of the colors that are entirely unprintable and unviewable! So ProPhoto needs to come with a very big warning. If you print using a perceptual mapping you will, in all probability, get a serious color shift when printing from ProPhoto. Depending on the profile this could even happen if NONE of your colors are outside of the printer gamut (because some profiles compress the whole of ProPhoto into the destination gamut ... and they do this because they have no way of knowing at the time the profile is made what colors will be outside the destination gamut).
So it's one of these things: if you want to squeeze the utmost from your images then sure, go for a wider gamut than Adobe RGB (Beta RGB would be a better choice than ProPhoto) ... but if you don't fully understand what is happening and don't know how your printer profiles have been built you could end up with unintended colors on your print; if you are willing to sacrifice a bit of the most saturated colors and be safe then you would be better off staying in Adobe RGB; if you want a compromise between these two then an intermediate working space like Beta RGB would be a good choice.
IMO, at any rate :)
Robert
I've had a look back over this thread, as I said I would, as I was concerned that I had been possibly rude or aggressive, or that I might have unintentionally said things that are incorrect.
There's no doubt that things did take a turn for the worse, but it is easy to trace it back to this post of mine (quote above). I think it is also easy to see that the issues have to do with my criticism of Andrew's video, and what seems to have been taken as a criticism (or dislike) of ProPhoto. I certainly have no strong views about ProPhoto since it's just another working space ... except to reiterate that it does need to be used with some caution because it is much wider than all of our current output devices or monitors.
So it would seem that the point at which the discussion became a bit edgy was over Andrew's video. My view of that hasn't changed, as I do not think that it is valid to criticize sRGB (or any smaller working space) by clipping colors from ProPhoto (or any larger working space) into the smaller working space. Chopping colors from a large to a smaller working space is not a demonstration that the smaller working space is inferior or that the large working space is superior: it is simply showing that the smaller working space cannot contain the full range of colors that the larger working space can.
I would still like Andrew to address this point, although I don't suppose he will.
Robert
-
Chopping colors from a large to a smaller working space is not a demonstration that the smaller working space is inferior or that the large working space is superior: it is simply showing that the smaller working space cannot contain the full range of colors that the larger working space can.
If you like your colors dumbed down, I guess that is fine. I can't imagine many people would aspire to that if they plan to print their work on an inkjet printer.
-
I would still like Andrew to address this point, although I don't suppose he will.
I thought this beaten horse was dead…didn't we say it was dead? It sure smells dead. Please, let it be dead...
-
If you like your colors dumbed down, I guess that is fine. I can't imagine many people would aspire to that if they plan to print their work on an inkjet printer.
No, I don't like my colors dumbed down John. The point is that if you already have colors that are within a particular working space (say Adobe RGB for sake of argument), then printing them from Adobe RGB or converting them to ProPhoto RGB before printing will give the same results: the ProPhoto colors won't be more saturated (or less dumbed down).
If you convert the colors from Adobe RGB to sRGB you may or may not be dumbing down the colors: you will be if the image colors are not within the sRGB gamut, otherwise you won't.
So the critical thing is not the working space gamut, or the destination gamut, but the image gamut. As long as the colors that are in the particular image are fully contained in both the working space gamut and the destination gamut, all will be fine. It's when the working space and/or the destination space are smaller than the image gamut that the image colors will have to be shifted or clipped (either by the photographer, or by the CMM).
We can either work in a larger working space for all of our images, one that can contain all of the colors of all of our images, or we can pick the working space to be big enough to contain a particular image's gamut, and do this for each image. There are pros and cons to both of these options, but it is not true to say that one is inherently better than the other, providing that each is used with understanding and care.
What is certainly true is that if your image colors can not be contained in a smaller working space, and you convert them colorimetrically to a smaller working space , you WILL cause the out of gamut colors to be clipped. If you convert them using a perceptual mapping (which you can't do, directly, from working space to working space) then the colors will be shifted. That does not make the smaller working space inherently bad ... it just means that it is too small for this particular image.
Robert