Ad
Ad
Ad
Pages: « 1 [2] 3 4 ... 9 »   Bottom of Page
Print
Author Topic: Colour issue driving me crazy. Please help!  (Read 27550 times)
geotzo
Full Member
***
Offline Offline

Posts: 229


WWW
« Reply #20 on: May 20, 2009, 02:17:14 AM »
ReplyReply

Web browsers don't care about monitor profiles, ie they can't use them properly. I ve checked images again and on my Eizo monitor they look very different but quite similar on my Lacie one! Strange? No, I think its just a matter of luck in terms of image+monitor behavior combination and nothing you can actually fully control. Just some thoughts.
Logged
Graham Mitchell
Sr. Member
****
Offline Offline

Posts: 2282



WWW
« Reply #21 on: May 20, 2009, 02:43:35 AM »
ReplyReply

Thanks for the suggestions about sRGB conversion but I was doing all of the same steps already. Still hoping for an answer!
Logged

Graham Mitchell - www.graham-mitchell.com
opgr
Sr. Member
****
Offline Offline

Posts: 1125


WWW
« Reply #22 on: May 20, 2009, 03:10:51 AM »
ReplyReply

Quote from: foto-z
Thanks for the suggestions about sRGB conversion but I was doing all of the same steps already. Still hoping for an answer!

@foto-z:

What monitor calibration sw are you using?

Could you check in the colorsync utility whether all gamma values are equal?

I tried the image here in Safari, Preview, and an older PS, all looked equal, and similar to the saturated warm version.
Logged

Regards,
Oscar Rysdyk
theimagingfactory
opgr
Sr. Member
****
Offline Offline

Posts: 1125


WWW
« Reply #23 on: May 20, 2009, 03:15:52 AM »
ReplyReply

Quote from: MarkDS
The recipe I've been using for creating website images is as follows (and I made an Action of it);

Flatten image
Resize
Convert Mode (from 16 to 8-bit depth)
Convert to Profile sRGB, Rel Col Intent with Black Point Compensation With Dither.
Export using Save for Web in JPEG format at Quality 60, With Optimized, With 1 Pass.

This whole process preserves the original file intacy, happens in a jiffy and produces what seems to me an acceptable approximation of the original - very much less deviation than what is illustrated in the previous posts.


I think it would be better to switch the 16-to-8 bit step and the colorconversion step.
First of all that keeps the colorconversion in 16bit mode, which has obvious benefits, second though, your current setup will introduce dithering twice. First during 16-to-8 bit, then the colorconversion engine will bring the colors back to 16bit (or even more), do the conversion, and introduce dithering again when supplying the 8bit data for final image.

Logged

Regards,
Oscar Rysdyk
theimagingfactory
opgr
Sr. Member
****
Offline Offline

Posts: 1125


WWW
« Reply #24 on: May 20, 2009, 03:26:46 AM »
ReplyReply

Quote from: tho_mas
There is no way to do perceptual conversion to sRGB. If the target profile is a TRC Matrix profile (such as sRGB, AdobeRGB, ProPhotoRGB and others) the sole rendering intend available is relative colormetric as Matrix profiles have no table for perceptual RI.
see myth #21: http://www.colorwiki.com/wiki/Color_Management_Myths_21-25
Only LUT profiles, such as printer profiles (mostly with a big file size while Matrix profiles are small like 4KB) contain tables for perceptual RI (or better: they may contain a percaptual table).
It's somewhat irritating as Photoshop offers the option for all the profiles... but Matrix profile provide only colormetric RI.


This is simply FALSE!

The rendering intent is NOT a property of the profile. It is a PARAMETER supplied to the colormanagement engine which in turn can do with it whatever the heck it wants. If it is supplied 2 matrix profiles, and subsequently told to do a PERCEPTUAL match, it MAY do a totally different conversion than RELCOL.

The Photoshop engine does not currently do a different conversion for matrix profiles, so in practice it makes no difference, but whether or not actual tables are available in the profile is irrelevant.

(It's not unlike BPC. Even if you offer the Photoshop engine a printer profile with a single RELCOL LUT, it can still do BPC.)
Logged

Regards,
Oscar Rysdyk
theimagingfactory
tho_mas
Sr. Member
****
Offline Offline

Posts: 1696


« Reply #25 on: May 20, 2009, 04:15:40 AM »
ReplyReply

Quote from: geotzo
Web browsers don't care about monitor profiles, ie they can't use them properly.
Screenshot of Firefox 3 with colour management enabled. Files in camera profile, converted to AdobeRGB, sRGB, ProPhotoRGB, ECI-RGB V2
[attachment=13802:screen_firefox.jpg]
Seems that at least Firefox cares about the monitor profile...

Quote from: foto-z
Still hoping for an answer!
 Graham... I played around with the "save for web" tool (for the first time...)

what is wrong here:


... is that "preview" is set to Monitor Color". You have to set to "Document Profile".


see here (note: the screenshots are converted to sRGB)...

preview set "monitor color" / convert to sRGB: no
the resulting JPG (below) is too bright and undersaturated here ->
[attachment=13803:display.jpg]

preview set "monitor color" / convert to sRGB: yes
the resulting JPG is too bright and totally oversaturated ->
[attachment=13804:display_srgb.jpg]

preview set to "document color" / (same results with or without "convert to sRGB" activated)
the resulting JPG matches the source ->
[attachment=13805:document.jpg]

But that does not explain why your "safe as JPG"-image is still off ("jack flesher", "opgr" and me are obviously seeing the same).

Maybe you want to post screenshots of...
- your colour settings (advanced)
- your "convert to profile" setting (advanced)
- your proof settings
« Last Edit: May 20, 2009, 04:32:21 AM by tho_mas » Logged
tho_mas
Sr. Member
****
Offline Offline

Posts: 1696


« Reply #26 on: May 20, 2009, 04:18:35 AM »
ReplyReply

Quote from: opgr
The rendering intent is NOT a property of the profile. It is a PARAMETER supplied to the colormanagement engine which in turn can do with it whatever the heck it wants.
But from where does the CMM take the information how to transform perceptual (as there is no general rule how to)? This info is stored in a dedicated table in the profile (IMHO), no?
« Last Edit: May 20, 2009, 04:27:24 AM by tho_mas » Logged
opgr
Sr. Member
****
Offline Offline

Posts: 1125


WWW
« Reply #27 on: May 20, 2009, 06:32:23 AM »
ReplyReply

Quote from: tho_mas
But from where does the CMM take the information how to transform perceptual (as there is no general rule how to)? This info is stored in a dedicated table in the profile (IMHO), no?

There is indeed no general rule. And specifically there is no rule that stops the engine from applying a proprietary perceptual method in case it receives a perceptual conversion request for profiles lacking perceptual data.

If there is perceptual data available, it simply means that some software has prebuild a table by a proprietary perceptual method.

For example:
Most engines will use channelclipping for out-of-gamut colors when computing matrix profile conversions. Instead of channelclipping out-of-gamut colors, an engine could provide a different method of mapping all out-of-gamut colors to maintain their Hue. You still get normal in-gamut color behavior, but you get different out-of-gamut behavior.

Or an engine could compress all corners of a source matrix to fit the destination matrix. This way you would be able to judge the integrity of your source data within your monitorspace during a Convert-To-Profile command. Just like the desaturate option in Photoshop. But you simply switch from RelCol to Perceptual and back.

Logged

Regards,
Oscar Rysdyk
theimagingfactory
tho_mas
Sr. Member
****
Offline Offline

Posts: 1696


« Reply #28 on: May 20, 2009, 06:53:33 AM »
ReplyReply

Quote from: opgr
There is indeed no general rule. And specifically there is no rule that stops the engine from applying a proprietary perceptual method in case it receives a perceptual conversion request for profiles lacking perceptual data.

If there is perceptual data available, it simply means that some software has prebuild a table by a proprietary perceptual method.

For example:
Most engines will use channelclipping for out-of-gamut colors when computing matrix profile conversions. Instead of channelclipping out-of-gamut colors, an engine could provide a different method of mapping all out-of-gamut colors to maintain their Hue. You still get normal in-gamut color behavior, but you get different out-of-gamut behavior.

Or an engine could compress all corners of a source matrix to fit the destination matrix. This way you would be able to judge the integrity of your source data within your monitorspace during a Convert-To-Profile command. Just like the desaturate option in Photoshop. But you simply switch from RelCol to Perceptual and back.
That might be true - thanks for that!
But which CMM actually supports perceptual RI to a matrix profile as target? Windows ICM: no. Apple CMM: no. ACE/AdobeCMM: no. I am not quite sure about Vistas WCS.
I've once tryed to edit profile tags to check the difference between perceptual and relcol when processing from Capture One (C1 always adresses the system CMM and the profile tags). It was always relcol (with matrix profiles as target). Too, when you switch in Photoshop from ACE to the system CMM (either way on Windows (ICM) or Mac) there is no difference from relcol to perceptual.
So what you say is probably correct (I guess)... but with the common tools we are working with it does not work. At least I couldn't do any perceptual conversion to a matrix profile (as target) by now on different systems with different CMMs (that's maybe not a proof but at least an indication to me...).
« Last Edit: May 20, 2009, 06:56:42 AM by tho_mas » Logged
papa v2.0
Full Member
***
Offline Offline

Posts: 197


« Reply #29 on: May 20, 2009, 08:03:41 AM »
ReplyReply

thomas
as far as i know there is not a smart CMM that will produce a perceptual rendering from colrmetric data if no perceptual data is present. The general trend at the moment is  smart profile dumb engine. The main differences between engines are the interpolation methods used when processing data.

opgr

if they are any i could you enlighten me.

thanks
Logged
Mark D Segal
Contributor
Sr. Member
*
Offline Offline

Posts: 6973


WWW
« Reply #30 on: May 20, 2009, 08:04:27 AM »
ReplyReply

Quote from: opgr
I think it would be better to switch the 16-to-8 bit step and the colorconversion step.
First of all that keeps the colorconversion in 16bit mode, which has obvious benefits, second though, your current setup will introduce dithering twice. First during 16-to-8 bit, then the colorconversion engine will bring the colors back to 16bit (or even more), do the conversion, and introduce dithering again when supplying the 8bit data for final image.

In principle yes, in practice, no perceptible differences.

But how do you know the colour conversion engine brings the colours back to 16 bit?
Logged

Mark D Segal (formerly MarkDS)
Author: "Scanning Workflows with SilverFast 8....." http://www.luminous-landscape.com/reviews/film/scanning_workflows_with_silverfast_8.shtml
tho_mas
Sr. Member
****
Offline Offline

Posts: 1696


« Reply #31 on: May 20, 2009, 08:19:53 AM »
ReplyReply

Quote from: papa v2.0
as far as i know there is not a smart CMM that will produce a perceptual rendering from colrmetric data if no perceptual data is present. The general trend at the moment is smart profile dumb engine. The main differences between engines are the interpolation methods used when processing data.
okay, thanks!
So the article of Chromix ("CM Myth #21") is maybe not correct with regard to the cause but correct regarding the result in the real world: there is no perceptual RI when converting to a matrix profile as for today (with Windows, Apple and Adobe CMMs).
Well, at least at color.org one can download a table based sRGB profile (that much as to the smart profiles...)
Logged
opgr
Sr. Member
****
Offline Offline

Posts: 1125


WWW
« Reply #32 on: May 20, 2009, 08:44:12 AM »
ReplyReply

Quote from: MarkDS
In principle yes, in practice, no perceptible differences.

But how do you know the colour conversion engine brings the colours back to 16 bit?

Because if you build a custom CMM, Photoshop ALWAYS requests a CMColor conversion (which is a 16bit definition).

In addition, if you want to implement accurate color-conversions down to the precision offered by Photoshop, you even have to use more than 16bit precision under some circumstances.
Logged

Regards,
Oscar Rysdyk
theimagingfactory
opgr
Sr. Member
****
Offline Offline

Posts: 1125


WWW
« Reply #33 on: May 20, 2009, 08:53:44 AM »
ReplyReply

Quote from: papa v2.0
thomas
as far as i know there is not a smart CMM that will produce a perceptual rendering from colrmetric data if no perceptual data is present. The general trend at the moment is  smart profile dumb engine. The main differences between engines are the interpolation methods used when processing data.

opgr

if they are any i could you enlighten me.

thanks


Don't know, haven't been following the CMM arena lately. But I have build an experimental CMM in the past called Excalibur for the Mac that implemented different renderings for different intents on matrix profiles. It also allowed one to adjust the out-of-gamut rendition through a Preference panel. The discussion back then was triggered in regards to different renderings for RAW processors where this might be a relevant issue for obvious reasons.

Problem then was that Photoshop does NOT allow one to select the CMM for its display rendition, which could give inconsistent results when applying mode changes and which made a custom matrix-to-matrix conversion kind of moot...
Logged

Regards,
Oscar Rysdyk
theimagingfactory
tho_mas
Sr. Member
****
Offline Offline

Posts: 1696


« Reply #34 on: May 20, 2009, 09:02:46 AM »
ReplyReply

Quote from: opgr
In addition, if you want to implement accurate color-conversions down to the precision offered by Photoshop, you even have to use more than 16bit precision under some circumstances.
I thought Photoshop de facto operates in 15bit in colour conversions as bit number 16 is for the +/- algebraic signs in the a/b chanel of Lab...?
But maybe I am wrong and maybe that's too much off the topic here (though interessting).
« Last Edit: May 20, 2009, 09:03:10 AM by tho_mas » Logged
Graham Mitchell
Sr. Member
****
Offline Offline

Posts: 2282



WWW
« Reply #35 on: May 20, 2009, 09:24:39 AM »
ReplyReply

Quote from: tho_mas
preview set to "document color" / (same results with or without "convert to sRGB" activated)
the resulting JPG matches the source ->

That doesn't work for me!

Logged

Graham Mitchell - www.graham-mitchell.com
opgr
Sr. Member
****
Offline Offline

Posts: 1125


WWW
« Reply #36 on: May 20, 2009, 09:31:01 AM »
ReplyReply

Quote from: tho_mas
I thought Photoshop de facto operates in 15bit in colour conversions as bit number 16 is for the +/- algebraic signs in the a/b chanel of Lab...?
But maybe I am wrong and maybe that's too much off the topic here (though interessting).


When I say "16bit" here, I mean to differentiate from 8bit, regardless of whether this includes a signbit or not.

I believe the 15bit story is an entirely different issue all together and probably refers to the fact that Photoshop used to represent 16bit image data INTERNALLY as 15bit(+1) to allow for fast integer operations in 32bit registers. How much of this still holds for the latest Photoshop and current 64bit systems/processors and increasing use of graphic cards for operations, is an interesting question.  


Logged

Regards,
Oscar Rysdyk
theimagingfactory
opgr
Sr. Member
****
Offline Offline

Posts: 1125


WWW
« Reply #37 on: May 20, 2009, 09:35:25 AM »
ReplyReply

Quote from: foto-z
That doesn't work for me!

It seems increasingly plausible that your colorpreferences are inadvertently set to use the displayprofile as workingspace, which is why the preview of the original remains incorrect.
Logged

Regards,
Oscar Rysdyk
theimagingfactory
tho_mas
Sr. Member
****
Offline Offline

Posts: 1696


« Reply #38 on: May 20, 2009, 09:40:17 AM »
ReplyReply

Quote from: foto-z
That doesn't work for me!
Strange!
Does ANYTHING change if you switch the preview from "monitor color" to "Mac (without CM)" to "Win (without CM)" to "document profile" Huh
I still wonder very much about the desaturated "original" file on the left side.
Logged
Graham Mitchell
Sr. Member
****
Offline Offline

Posts: 2282



WWW
« Reply #39 on: May 20, 2009, 09:43:57 AM »
ReplyReply

Quote from: opgr
It seems increasingly plausible that your colorpreferences are inadvertently set to use the displayprofile as workingspace, which is why the preview of the original remains incorrect.

Nope. here they are. (They were set to sRGB when I first posted, but now on AdobeRGB. It makes no difference to the problem I described).

« Last Edit: May 20, 2009, 09:48:02 AM by foto-z » Logged

Graham Mitchell - www.graham-mitchell.com
Pages: « 1 [2] 3 4 ... 9 »   Top of Page
Print
Jump to:  

Ad
Ad
Ad