Pages: 1 2 3 [4] 5 6 7   Go Down

Author Topic: ipf8400 gamut  (Read 25195 times)

Robert Ardill

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 658
    • Images of Ireland
Re: ipf8400 gamut
« Reply #60 on: September 24, 2014, 06:32:21 am »

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
Logged
Those who cannot remember the past are condemned to repeat it. - George Santayana

digitaldog

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 20652
  • Andrew Rodney
    • http://www.digitaldog.net/
Re: ipf8400 gamut
« Reply #61 on: September 24, 2014, 10:19:01 am »

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.
Quote
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.
Logged
http://www.digitaldog.net/
Author "Color Management for Photographers".

samueljohnchia

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 498
Re: ipf8400 gamut
« Reply #62 on: September 24, 2014, 10:59:12 am »

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).
Logged

Robert Ardill

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 658
    • Images of Ireland
Re: ipf8400 gamut
« Reply #63 on: September 24, 2014, 11:25:05 am »

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


« Last Edit: September 24, 2014, 11:40:00 am by Robert Ardill »
Logged
Those who cannot remember the past are condemned to repeat it. - George Santayana

Robert Ardill

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 658
    • Images of Ireland
Re: ipf8400 gamut
« Reply #64 on: September 24, 2014, 11:39:09 am »

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
Logged
Those who cannot remember the past are condemned to repeat it. - George Santayana

samueljohnchia

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 498
Re: ipf8400 gamut
« Reply #65 on: September 24, 2014, 12:03:15 pm »

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 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. :-)
Logged

digitaldog

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 20652
  • Andrew Rodney
    • http://www.digitaldog.net/
Re: ipf8400 gamut
« Reply #66 on: September 24, 2014, 12:08:35 pm »

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:
Quote
The ONLY way to show the actual gamut of the device is to use the Absolute Colorimetric intent when calculating.
Moving on...
Quote
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.
Quote
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.
Logged
http://www.digitaldog.net/
Author "Color Management for Photographers".

Geraldo Garcia

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 470
    • Personal blog
Re: ipf8400 gamut
« Reply #67 on: September 24, 2014, 12:20:48 pm »

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?
Logged

digitaldog

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 20652
  • Andrew Rodney
    • http://www.digitaldog.net/
Re: ipf8400 gamut
« Reply #68 on: September 24, 2014, 12:41:53 pm »

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
Quote
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.
Logged
http://www.digitaldog.net/
Author "Color Management for Photographers".

samueljohnchia

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 498
Re: ipf8400 gamut
« Reply #69 on: September 24, 2014, 12:43:51 pm »

Quote
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.
Logged

Robert Ardill

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 658
    • Images of Ireland
Re: ipf8400 gamut
« Reply #70 on: September 24, 2014, 01:11:09 pm »

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
Logged
Those who cannot remember the past are condemned to repeat it. - George Santayana

Robert Ardill

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 658
    • Images of Ireland
Re: ipf8400 gamut
« Reply #71 on: September 24, 2014, 01:13:29 pm »

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 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. :-)

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
« Last Edit: September 24, 2014, 01:17:33 pm by Robert Ardill »
Logged
Those who cannot remember the past are condemned to repeat it. - George Santayana

Robert Ardill

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 658
    • Images of Ireland
Re: ipf8400 gamut
« Reply #72 on: September 24, 2014, 01:30:47 pm »


There is an interesting article 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
Logged
Those who cannot remember the past are condemned to repeat it. - George Santayana

Wayne Fox

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 4237
    • waynefox.com
Re: ipf8400 gamut
« Reply #73 on: September 24, 2014, 02:26:12 pm »

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.

Quote
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.
Logged

digitaldog

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 20652
  • Andrew Rodney
    • http://www.digitaldog.net/
Re: ipf8400 gamut
« Reply #74 on: September 24, 2014, 03:21:09 pm »

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.
Logged
http://www.digitaldog.net/
Author "Color Management for Photographers".

Robert Ardill

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 658
    • Images of Ireland
Re: ipf8400 gamut
« Reply #75 on: September 24, 2014, 04:21:22 pm »

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
Logged
Those who cannot remember the past are condemned to repeat it. - George Santayana

Robert Ardill

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 658
    • Images of Ireland
Re: ipf8400 gamut
« Reply #76 on: September 24, 2014, 04:30:49 pm »

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
Logged
Those who cannot remember the past are condemned to repeat it. - George Santayana

digitaldog

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 20652
  • Andrew Rodney
    • http://www.digitaldog.net/
Re: ipf8400 gamut
« Reply #77 on: September 24, 2014, 04:36:59 pm »

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.
Logged
http://www.digitaldog.net/
Author "Color Management for Photographers".

Robert Ardill

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 658
    • Images of Ireland
Re: ipf8400 gamut
« Reply #78 on: September 24, 2014, 04:46:03 pm »

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
Logged
Those who cannot remember the past are condemned to repeat it. - George Santayana

digitaldog

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 20652
  • Andrew Rodney
    • http://www.digitaldog.net/
Re: ipf8400 gamut
« Reply #79 on: September 24, 2014, 04:53:12 pm »

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.
Logged
http://www.digitaldog.net/
Author "Color Management for Photographers".
Pages: 1 2 3 [4] 5 6 7   Go Up