On 4/8/2014 4:21 PM, usher99@xxxxxxx wrote:
> N. Standard Moose writes
>
>
>>>> ACR and Bridge both show the color space as aRGB, so they are
> correctly relying
>>>> on the Interoperability tags.
> Yikes,
> More info than I bargained for. I think I've lost track of your
> preferred color space work flow. Last time this was discussed the
> consensus apeared to be keep all things in sRGB unless a fair
> possiblity of wanting a print and then then may not be essential.
Not a consensus with me in it. I shoot and process in aRGB. I have never worked
in sRGB except for images that started
that way. I was for a while using the larger Prophoto color space in PS, as
BobW proposed. I somehow fell out of the habit.
> Last time I imported to PS in aRGB and converted to sRGB in PS,
> developed inscrutable undesirable tonal shifts after careful
> processing
There are several settings in the conversion dialog. If you get them wrong,
troublesome/unexpected things can happen.
> and ocassional clipping--latter not unexpected.
Which is exactly why I don't see why anyone would process in sRGB when the
source image is aRGB. If something goes out
of gamut that might well have come back in in a later step, the image color is
compromised - "... inscrutable
undesirable tonal shifts." Keep everything in a broad color space, and only
narrow it if necessary.
Particularly if, as I do, one saves the processed image as a full size PSD file.
> Was given an algorithm to convert with no clipping by a Adobe guru
> tolling the PS forum but never did manage to develope a procedure that
> was satisfactory--ran out of time and reverted to the usual for now.
Again, think about the conversion settings, and about what the conversion
engine has to do. It needs to either clip out
of gamut colors or move them into the smaller color space. If it moves them in,
what is it to do with other, in gamut
colors that were different, but would now be the same? The answer depends on
settings.
But in the end, out of gamut colors must result in clipping and/or color shifts
of some sort. There's no alternative.
That's why you have the choice of two conversion engines, four colorimetric
intents and black point compensation.
> Some browsers also displayed the non sRGB images oddly--that was a
> couple years back though. Little sense restricting color space on the
> front end if possible unless too much trouble is created on the back
> end which seems to be the case for now.
I had some trouble with a few shots some time ago, especially with orange
traffic cones. They would look fine on screen
in PS, and go nuke-lear once converted to sRGB ad viewed on the web. I tried
saving the JPEGs in aRGB, and the problem
was resolved. I checked in IE, FireFox, Safari and Chrome. Where previously
only Safari used the embedded profile
correctly, by then they all looked fine, and almost identical to in PS and to
each other.
I have since then, a few years, saved all web images in aRGB. It's possible
Brian sees them wrong in ancient Opera or
whatever. But the vast majority of people are using contemporary browser
versions.
> Need to inquire into better color space management as time permits, Mike
You might try simply leaving them aRGB from start to finish.
--
What if the Hokey Pokey *IS* what it's all about?
--
_________________________________________________________________
Options: http://lists.thomasclausen.net/mailman/listinfo/olympus
Archives: http://lists.thomasclausen.net/mailman/private/olympus/
Themed Olympus Photo Exhibition: http://www.tope.nl/
|