Re: rendering intents (was: In search of a D50...)
This is exactly the point I tried to make in the bug report. The user *is* being lied to. The UI creates confusion, because in these circumstances users are expecting the app to be doing exactly what it says, and the app is intentionally doing something else without informing them. There are plenty of instances where the UI prevents someone from doing something that is not appropriate or possible. Assign a CMYK profile to an RGB image? Convert a 16-bit image in sRGB to indexed color? Or an 8-bit Lab image to indexed color? Take a 32-bit image and Save for Web as a JPG? The list goes on and on, and I fail to see the difference in this case. I still feel that if a rendering intent is not appropriate, it should be greyed out. The astute user will ask why and will learn something. The less astute user will just do what is allowed, and will realize that certain transformations are not allowed in certain circumstances. I fail to see the “confusion” that is created. To the contrary, it prevents users from thinking that certain transformations are allowed when they are not, “because Photoshop can do it.” —Rich Wagner On Sep 5, 2014, at 12:00 PM, colorsync-users-request@lists.apple.com wrote:
On Sep 5, 2014, at 11:45 AM, Steve Upton <upton@chromix.com> wrote:
Further, some users will complain that they're being denied access to rendering intents.:-)
But you see, that’s the exact problem I find with users, only in reverse. They complain that they’re granted access to intents that don’t exist.
I think this is a classic UI issue. We should not be shown a Rendering Intent we can't use. I don't see why in this context, the RI's that don't apply are not grayed out. User's can't complain. They should not be granted access to selecting something that isn't going to do what they select, they are kind of being lied to.
Andrew Rodney http://www.digitaldog.net/
the ColorSync api (to the best of my recollection) never published a function to return a list of available intents for a given profile—which would be requisite to determine grayed items. i expect this data is adduceable from the profile header: can anyone (who knows all intent relative tags) write down instructions to list the intents present? if so, it might be interesting to fork this thread on ColorSync-dev & add expert knowledge in the developer space. cheers, edward taffel On Sep 5, 2014, at 3:36 PM, Rich Wagner <Rich@wildnaturephotos.com> wrote:
This is exactly the point I tried to make in the bug report. The user *is* being lied to. The UI creates confusion, because in these circumstances users are expecting the app to be doing exactly what it says, and the app is intentionally doing something else without informing them. There are plenty of instances where the UI prevents someone from doing something that is not appropriate or possible. Assign a CMYK profile to an RGB image? Convert a 16-bit image in sRGB to indexed color? Or an 8-bit Lab image to indexed color? Take a 32-bit image and Save for Web as a JPG? The list goes on and on, and I fail to see the difference in this case. I still feel that if a rendering intent is not appropriate, it should be greyed out. The astute user will ask why and will learn something. The less astute user will just do what is allowed, and will realize that certain transformations are not allowed in certain circumstances. I fail to see the “confusion” that is created. To the contrary, it prevents users from thinking that certain transformations are allowed when they are not, “because Photoshop can do it.”
—Rich Wagner
On Sep 5, 2014, at 12:00 PM, colorsync-users-request@lists.apple.com wrote:
On Sep 5, 2014, at 11:45 AM, Steve Upton <upton@chromix.com> wrote:
Further, some users will complain that they're being denied access to rendering intents.:-)
But you see, that’s the exact problem I find with users, only in reverse. They complain that they’re granted access to intents that don’t exist.
I think this is a classic UI issue. We should not be shown a Rendering Intent we can't use. I don't see why in this context, the RI's that don't apply are not grayed out. User's can't complain. They should not be granted access to selecting something that isn't going to do what they select, they are kind of being lied to.
Andrew Rodney http://www.digitaldog.net/
_______________________________________________ Do not post admin requests to the list. They will be ignored. Colorsync-users mailing list (Colorsync-users@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/colorsync-users/etaffel%40me.com
This email sent to etaffel@me.com
On Sep 5, 2014, at 1:05 PM, edward taffel <etaffel@me.com> wrote:
the ColorSync api (to the best of my recollection) never published a function to return a list of available intents for a given profile—which would be requisite to determine grayed items. i expect this data is adduceable from the profile header:
I think Lars has addressed this point in mentioning that technically, each profile can be used for each intent. Not the same thing, I know but….
can anyone (who knows all intent relative tags) write down instructions to list the intents present? if so, it might be interesting to fork this thread on ColorSync-dev & add expert knowledge in the developer space.
I think we’re ok on this list. There’s more than a few of use who live in that space. regards, Steve
I think Lars has addressed this point in mentioning that technically, each profile can be used for each intent. Not the same thing, I know but….
i must have missed something: i understood, there are cases in which some intents should be grayed.
can anyone (who knows all intent relative tags) write down instructions to list the intents present? if so, it might be interesting to fork this thread on ColorSync-dev & add expert knowledge in the developer space.
I think we’re ok on this list. There’s more than a few of use who live in that space.
i’m good w/ that, & expect a programmer doing a search will find the information—just, i have no wish to breach list scope/etiquette.
i must have missed something: i understood, there are cases in which some intents should be grayed. I'd like to know at least one case that you want to disallow. For a LUT profile, perceptual is required. It's also the default intent. For a TRC profile, the TRC is relative colorimetric. This can easily lead to cases where a pair of profiles have no intents in common: Profile 1 TRC relative only -> profile 2 perceptual only. This is a common conversion from display to print. There is no common intent, so conversion should then not be allowed. To prevent this, ICC has a fallback logic to these intents. See below. Also to consider: BPC is not colorimetric, so relative + BPC should be classified as perceptual. And is saturation + BPC == perceptual? If so, all intents become perceptual if BPC is on, so all combos are valid! can anyone (who knows all intent relative tags) write down instructions to list the intents present? if so, it might be interesting to fork this thread on ColorSync-dev & add expert knowledge in the developer space. Here is the precedence order. You can ignore a). AToB0Tag is for perceptual, so perceptual is a LUT profile's default intent. From ICC 8.10.2: For input, display, output, or colour space profile types, the precedence order of the tag usage for a designated rendering intent shall be the following. a) Use the BToD0Tag, BToD1Tag, BToD2Tag, BToD3Tag, DToB0Tag, DToB1Tag, DToB2Tag, or DToB3Tag designated for the rendering intent if the tag is present, except where this tag is not needed or supported by the CMM (if a particular processing element within the tag is not supported the tag is not supported). b) Use the BToA0Tag, BToA1Tag, BToA2Tag, AToB0Tag, AToB1Tag, or AToB2Tag designated for the rendering intent if present, when the tag in a) is not used. c) Use the BToA0Tag or AToB0Tag if present, when the tags in a) and b) are not used. d) Use TRCs (redTRCTag, greenTRCTag, blueTRCTag, or grayTRCTag) and colorants (redMatrixColumnTag, greenMatrixColumnTag, blueMatrixColumnTag) when tags in a), b), and c) are not used. Lars
On Sep 5, 2014, at 9:03 PM, Lars Borg <borg@adobe.com> wrote:
i must have missed something: i understood, there are cases in which some intents should be grayed.
I'd like to know at least one case that you want to disallow.
that i disallow?
Lars Borg wrote:
This can easily lead to cases where a pair of profiles have no intents in common: Profile 1 TRC relative only -> profile 2 perceptual only. This is a common conversion from display to print. There is no common intent, so conversion should then not be allowed.
That makes the assumption that the user only indicated one intent to cover the two profiles involved. Yes, many CMM's dumb it down to one intent, creating this issue, while making it simpler for the user and keeping them in dark as to what's going on. (This is all part of the deeper problem of casting the illusion that there's real gamut mapping going on here, something that's difficult to impossible to achieve using pre-calculated source and destination profiles where the profiles are meant to implement the gamut mapping.) The lack of separate intents created the user "surprise" problem in the first place with the use of absolute intent in Photoshop. What users most often wanted was absolute intent for the input printer profile, and relative colorimetric for the display profile. Yes, having fall-backs makes it all easier to use in practice.
Also to consider: BPC is not colorimetric, so relative + BPC should be classified as perceptual.
In my view BPC is a lightness axis only, source & destination tailored gamut mapping. So BPC + relative = perceptual mapped light axis + relative colorimetric in every other way.
And is saturation + BPC == perceptual? If so, all intents become perceptual if BPC is on, so all combos are valid!
Since BPC only scales the lightness axis, BPC + saturation = saturation more accurately tailored to the particular source space. Graeme Gill.
On Sep 5, 2014, at 1:36 PM, Rich Wagner <Rich@WildNaturePhotos.com> wrote:
This is exactly the point I tried to make in the bug report.
I've reported this since at least Photoshop 5 or perhaps 6 (I've been a pre-release tester since Photoshop 2.5). It's not going to happen. On Sep 5, 2014, at 2:05 PM, Lars Borg <borg@adobe.com> wrote:
Matrix profiles such as Prophoto and sRGB support all rendering intents. So no rendering intent is missing in this case.
But you you don't get what you ask for. If you want to convert from ProPhoto RGB to sRGB (using the profiles installed by Adobe) and select Perceptual, you get RelCol. Andrew Rodney http://www.digitaldog.net/
Please correct me if I am wrong but, by virtue of the tags available in a matrix profile, only Relative Colorimetric is supported. / Roger -----Original Message----- From: colorsync-users-bounces+graxx=videotron.ca@lists.apple.com [mailto:colorsync-users-bounces+graxx=videotron.ca@lists.apple.com] On Behalf Of Andrew Rodney Sent: 5 septembre 2014 16:22 To: ColorSync Subject: Re: rendering intents (was: In search of a D50...) On Sep 5, 2014, at 1:36 PM, Rich Wagner <Rich@WildNaturePhotos.com> wrote:
This is exactly the point I tried to make in the bug report.
I've reported this since at least Photoshop 5 or perhaps 6 (I've been a pre-release tester since Photoshop 2.5). It's not going to happen. On Sep 5, 2014, at 2:05 PM, Lars Borg <borg@adobe.com> wrote:
Matrix profiles such as Prophoto and sRGB support all rendering intents. So no rendering intent is missing in this case.
But you you don't get what you ask for. If you want to convert from ProPhoto RGB to sRGB (using the profiles installed by Adobe) and select Perceptual, you get RelCol. Andrew Rodney http://www.digitaldog.net/
participants (7)
-
Andrew Rodney
-
edward taffel
-
Graeme Gill
-
Lars Borg
-
Rich Wagner
-
Roger Breton
-
Steve Upton