Maybe I'm a little dense, but could you briefly explain what you are trying to do with these posts. Thank you.
I do know that when I convert from ProPhoto to srgb in "save for web" in CS5, I rarely like the result.
I should have said that while the conversion from ProPhoto to sRGB in "save for web" looked okay in Bridge but awful when viewing in Firefox or in facebook. I've had the same problem with going from ProPhoto to max quality jpgs and then to some of my microstock sites. I believe they convert to sRGB also. Sorry, I don't think I can duplicate them and have them show up the same way here.If they looked OK in Bridge after conversion, the problem wasn't with the conversion to sRGB. More likely, your web browser is not using your monitor profile to display the image, but Bridge is.
I should have said that while the conversion from ProPhoto to sRGB in "save for web" looked okay in Bridge but awful when viewing in Firefox or in facebook.
Load your ProPhoto (wide gamut rgb, best rgb or beta rgb ) image file into Photoshop CS.
1. In CS, convert with 0_jc1RGB (beta1).icc
Rendering intent is always absolute regardless of intent selected.
You may observe insignificant changes on your display screen if color gamut for your image is well within the color gamut for 0_jc1RGB. Make sure you click OK to complete the conversion.
Both the downloaded icc files use standard D50 illuminant and Gamma 2.2 and they are of V2 icc specification.
2. Next, convert with 0_sRGB_D50_jc1 (beta1).icm
This icc profile resemblances closely the standard sRGB, but has added saturation and perceptual rendering intents.
Choose Perceptual rendering for best image reproduction.
Toggle PREVIEW to detect the differences before and after conversion.
Depending on the image color gamut, the other rendering intents may work for you as well.
Now, your image has been converted to sRGB color space from ProPhoto color space, perceptually (provided it works!). You can do a profile assign to sRGB or convert to sRGB. The file size for 0_sRGB_D50_jc1 (beta1).icm is about 1.4 Mbytes and hence may increase the storage file size significantly if you choose not to re-assign or convert to standard sRGB.
Please kindly explain the components of these profiles (matrix primaries, white point, TRC / gamma, ...)
and the idea behind the double conversion starting with AbsCol.
For the following illustration, the colors for the sRGB image were intentionally saturated by assigning it to ProPhoto profile before subjecting it to the conversion.
By means of such pRGB assignment it can easily happen that "imaginary colors" are created which do not exist in reality. Then, it could be a kind of creating a problem first, before solving it. But I don’t want to sound negative at all.
If I get you right, suggested approach is as follows:
regular ProPhoto RGB w/ D50 white, 1.8 gamma, pRGB gamut
-- Abs/RelCol -> jc1RGB (beta2.1) w/ D50 white, 2.2 gamma, gamut: somewhat smaller but still large
-- Perceptual -> sRGB_D50_jc1 (beta 2.1) w/ D50 white, 2.2 gamma, sRGB gamut (?)
-- Abs/RelCol -> sRGB IEC61966-2.1
Please kindly explain the components of these profiles (matrix primaries, white point, TRC / gamma, ...)
and the idea behind the double conversion starting with AbsCol.
Thanks.
& Best regards, Peter
--
Imaginary values may be produced via mathematical transformation.
Adobe color model is based on CIELAB 50 hence imaginary color cannot be created in that way.
Ver 4 ICC profiles are supposed to handle perceptual rendering, but are not widely available.
Ver 4 ICC profiles are supposed to handle perceptual rendering, but are not widely available.
The purpose of this post is to invite further discussion.
AFIK, when you assign a profile in Photoshop (versus Convert to a profile) CIE LAB conversion is not used, rather the RGB values in the file are left unchanged and only the associated profile information (colour primaries and tone curve) is changed. Hence, as Peter stated, it is possible to produce imaginary colours in the image.
Here is a test I have done to confirm this (all files are 8-bit TIFF).This confirms that Assigning can create imaginary colours.
- Firstly I created an sRGB file and filled it with 0-R 255-G 0-B a real colour in sRGB (file: sRGB.tif).
- I then assigned the ProPhoto RGB profile to the file (file: ProPhoto_assigned.tif). When the colour is checked it is still 0-R 255-G 0-B which in ProPhoto RGB is entirely imaginary.
- Finally I took the original sRGB file and converted it to ProPhoto RGB (file: Converted_to_ProPhoto.tif). As expected this did not change the appearance of the colour on-screen but it did change the colour values to 138-R 237-G 78-B which in ProPhoto RGB is the same colour as 0-R 255-G 0-B in sRGB.
Regards
Nigel
In his response JC showed some custom RGB matrix profiles. I can't follow the complexities of his workflow, but it should be noted that matrix profiles lack the lookup tables necessary for perceptual rendering. There are many problems with current perceptual rending algorithms since they apply arbitrary compression of the color gamut without actually looking at what color values are in the image. For a narrow range gamut, no compression at all may be needed. Ver 4 ICC profiles are supposed to handle perceptual rendering, but are not widely available. The purpose of this post is to invite further discussion.
Regards,
Bill
And yet the chromaticity diagrams you yourself have provided here show two colors (primaries) that are imaginary.If that chromaticity diagram was incorrectly presented, I shall try to clarify.
Right, and ideally, both profiles in the chain are V4 and implement the PRMG. I don’t know if this is the case here.PRMG model is a nice concept. But it may or may not work for matrix with imaginary primaries as in the case of ProPhoto.
Brucelindbloom's hard work is much appreciated.
JC , - the Coding Efficiency of ProPhoto RGB is 87.3%, the Coding Efficiency of the Lab gamut is just 35.1%. The Coding Efficiency % indicates the relative portion of the encoding space that represents real colors. Some of the larger volume working spaces contain many RGB (or Lab) triplets for which there is no physical counterpart, and therefore could be considered wasteful.
Source: www.brucelindbloom.com
There is distinctive difference between Lab and XYZ in that Lab is perceptually equal distance, XYZ is not. Lab is derived from XYZ, no?
"How comes? The percentage with Lab is quite poor. The Lab Gamut is essentially the same as CIEXYZ. Going back to the original color matching experiment done with CIE RGB primaries it was found that a negative r matching function is needed to match colors outside the limited CIE RGB triangle. To avoid such negative matching function, a mathematical construct was derived, CIE XYZ which bears all positive matching functions, at the cost of primaries XYZ which are not real colors.
Reference: http://www.fho-emden.de/~hoffmann/ciexyz29082000.pdf".
The ProPhoto RGB gamut which is a subset of CIEXYZ is likewise bearing "imaginary" primary colors. These are needed to hold other saturated colors, particularly yellow hues which actually DO exist in reality."Unless there is direct transformation (XYZ) from RAW, I can't figure out where else can the imaginary color comes from. The practical implementation in the real world has put multiple barriers to restrict it from happening, from tiff (V6 spec) to PhotoShop CS, for instance.
If that chromaticity diagram was incorrectly presented, I shall try to clarify.
PRMG model is a nice concept. But it may or may not work for matrix with imaginary primaries as in the case of ProPhoto.
There is distinctive difference between Lab and XYZ in that Lab is perceptually equal distance, XYZ is not.
But, you may be wrong by simply stating that the Lab values for RGB=(0 255 0) in PS is imaginary.
sRGB --> ProPhoto (smaller gamut --> Bigger gamut)
When converting sRGB to ProPhoto, Lab value remains unchanged. Since this point has the same Lab value, it must be of the same color.
... Therefore if you create a ProPhoto RGB test image from an sRGB file by assigning the ProPhoto profile you may possibly create an image with imaginary colours (you could probably check if the image actually contains imaginary colours by using ColorThink or a similar utility). Hence, when you compare your complex process for converting from a large gamut (ProPhoto RGB) to a smaller gamut (sRGB) against a standard single profile conversion you may be showing differences that are purely a result of the imaginary colours in your test image.
Unfortunately, an incorrect interpretation of the XYZ color space has also resulted in it being labeled as perceptually bad. There is a new realization now regarding what went wrong in the original interpretation.Hi,
Sincerely,
Joofa
I’d be interested what exactly determines the gamut primaries of your initial host space jc1RGB. If you need a somewhat smaller, handier space than ProPhoto RGB to tailor the subsequent perceptual conversion, why not using something known like e.g. Bruce Lindbloom’s Beta RGB. However, you mentioned that you can’t find an easy way out … (?).
By the way, it is summer (at least in the northern hemisphere). Many colorful flowers out there, to shoot and test…
Regards, Peter
I have found utilizing PhotoGamut at some point in a workflow to be helpful in certain circumstances, primarily in working down to a space smaller than itself, sRGB for an on demand book for example. Unfortunately some colors currently available in the gamut of the newest inkjets available are not within PhotoGamut, and therefore some available colors from the printer/paper/inkset my never be utilized. An update of PhotoGamut considering contemporary printer gamut might be welcome.
More pointers please.
BetaRGB was among my choices as an intermediate color space. I have had tested a few profilers too... Though i1Profiler has great performance, due to copyright, I cannot release the profiles to the general public.
If there are profiles to convert perceptually to say sRGB (Beta2.1) or Adobe RGB, do we need another color space?
b) Compare by observing the shadow detail as shown in the histograms.
Take your example of color = [0,255,0], convert it to xyz and compare and see if you spot a discrepancy there. This is a little off topic to your OP so if you want then we can take it offline.
I make use of the latest version of PatchTool to compute those numbers. I have gone through the same exercise repeatedly and no discrepancy was found. My knowledge is that much.
As for Lab=(88 -79 81) for ProPhoto RGB=(0 255 0), the Lab values were read out directly from the CS info screen.
Regards,
jc
It sounds like your LUT for perceptual mapping were fixed, and you are adjusting the gamut primaries of the initial, intermediate host space.This is an old V2 engine with no PRMG intelligence. As for the intermediate host space, I shall compare it with BetaRGB in subsequent stage.
No, that is not the issue. Think about distances here, after all that is what the "perceptual equality" notion is about, which you mentioned.
Sincerely,
Joofa
Subject might be too academic and I shall leave it alone for now.
On a side note, I am more interested in determining optimal primaries as much time was spent with trial and error. For instance, if 2 primaries are fixed, how to determine 3rd primary optimally, or fixed 1 and find the other 2.
I must also say that I like the graphs and the analysis you do. It is so refereshing than endless messages on ETTR, which camera has how much SNR, etc. Your messages are welcoming relief at least for me.
On a side note, I am more interested in determining optimal primaries as much time was spent with trial and error.
…
ProPhoto (Source) --> BestRGB (Destination)
--> jc1RGB (Destination)
--> BetaRGB (Destination)
Rating 1 is better than Rating 2, and that Rating 2 is better than Rating 3.
As said, perceptual rendering is not always the best solution, so does RelCol or other rendering algorithm.
it is not so clear at which stage of progress with "trial and error" suggested procedure already is. Understandable though due to the complex nature of the subject.
3) This implies "larger is better."
http://www.brucelindbloom.com/BetaRGB.html (http://www.brucelindbloom.com/BetaRGB.html)
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."
You are mis-representing what Bruce Lindbloom says:
Bruce describes two conflicting attributes of an ideal working space, you pick one.
By doing so, you allow larger quantization error for the 99% (?) most common colors, in order to accommodate a few outliers.
What is your rationale for that choice?Which is more appropriate as an intermediate color space, BetaRGB or jc1RGB?
Do you encounter many real life (!)colors that are outside the BetaRGB gamut?No. But if you are converting from ProPhoto to BetaRGB, it is possible that highly saturated Red may be clipped. I have demonstrated that with ProPhoto, red channel will be clipped if R>235 (B=G=0) and if BetaRGB is chosen as the intermediate color space, and that is what I am trying to avoid. If this is not the concern, then use direct RelCol sRGB.
Inviting Comments on
If "complexity" is not the deciding factor, can jc1's approach replace straight Relcol, when converting from ProPhoto to sRGB?
Thank you.
Sincerely,
jc
.../rephrase question
Unfortunately, JC1, it seems like that complexity is the issue here. There are some capable people here that contribute to the color forum. Unfortunately, it seems Iliah Borg is no longer contributing, but Peter_DL, DigitalDog, Schewe, and others are still here. Complexity of operations is a thing that people dread. But, it seems like you might have to distill your approach a little to make it more presentable and understandable. I think you want to say something useful here but the message is not coming across the way you want it.
Photoshop action: Pro2sRGB_perceptual.atn
1-click action is available now.
Download the PS action from the below link.
Procedure
1. Load your ProPhoto image into CS.
2. Load PS action: Pro2sRGB_perceptual.atn
3. Shift F9 to execute the perceptual conversion from ProPhoto to sRGB
The last step of the action converts to the current RGB working space which might be set to something other than sRGB. Not sure if this was intentional. Shouldn't the last step be an assign sRGB?
.../Turns out BPC was turn off in my first conversion...Understood. The convert function has options such as BPC.
Yes, that was done intentionally.
Understood. The convert function has options such as BPC.
BPC is activated in Pro2sRGB_perceptual.atn.
Just to be sure, my RGB working space is set to AdobeRGB. When I run your action the final result is an image in AdobeRGB colorspace, not sRGB. Is that the intended result?Ooops! I see your point now.
In the first two steps BPC is OFF. In the third step BPC in ON.Yes, unsure about its final effect.
Also currently, the first two steps are perceptual intent. I thought the first step should have been relative color, no?Actually no difference in final result, as both are Absolute color space with no mapping function.
I applied the 3 steps convertion to Bill Atkinson's twenty-eight balls test image and noticed some strange artifacts in the blue ball. Looks like banding (the Red value goes up and down several times).Sound interesting.
Sound interesting.
I don't seem to be able to download this test image.
Could you advice where this test image can be downloaded, or pm me a link of that.
https://public.me.com/billatkinson (https://public.me.com/billatkinson) Look for Twenty-Eight Balls.tif.zip.Thanks for the link.
Example: ProPhoto to sRGB Conversion without clipping on Highlight
Download link for the example's tiff image < Example1 (https://www.yousendit.com/download/M0RvN3RVdkdFd2Z2Wmc9PQ) >
Below are what I have observed.
Color de-saturation due to conversion with PhotoGamut RGB's is more obvious than with jc1's perceptual conversion.
As for RGB clipping due to conversion, it would be nice if that can be shown with histogram.
Although it has the ProphotoRGB profile embedded, the linked image does not seem to contain anything that exceeds the sRGB gamut. Is that the image you intended to show?
Sorry, can't see any images / attachments below of your post.No attachment, I was referring to your image Untitled-11b (photogamut) and Untitled-11d (jc1 perceptual).
Maybe it did not upload.
My visual impression was that some of the "Perceptual nature" of jc1's conversion got lost with the very final conversion, RelCol to sRGB. Could this be ? I did not futher follow up on this.The main difference between sRGB and sRGB_D50_jc1 is the file size. The file size for sRGB_D50_jc1 is much larger than that for sRGB and therefore no advantage to tag the converted image with a large icc profile.
the histogram is unfortunately totally useless as for a (desired) correlation of saturation/gamut-clipping and a best-possible rendition.I have proved theoretically that there is no color degradation with my approach, compared with conversion with striaght Relcol. Refer to Color Degradation Analysis: RelCol vs Perceptual (http://www.luminous-landscape.com/forum/index.php?PHPSESSID=24205b19480ced199ad3e9e3a10ee9ce&topic=56978.msg463856#msg463856)
When we squeeze something large into something small, sometimes compression is the best option, sometimes it is clipping. And often enough we might wish that it is something in-between. Depends on the content.
Have updated the link or Here (https://www.yousendit.com/download/M0RwZ28yRStkMnQzZUE9PQ)
I have proved that they have similar (so close) color matching (http://www.luminous-landscape.com/forum/index.php?PHPSESSID=24205b19480ced199ad3e9e3a10ee9ce&topic=56978.msg461201#msg461201) characteristic and that difference is negligible if they are interchanged (by assign function in PS). Hence, imho, no loss for this step of the conversion.
I have proved theoretically that there is no color degradation with my approach...
It will be much appreciated if someone could prove it untrue with just one real image (non descriptive type!).
That one also seems within sRGB gamut, except for the very lightest whites.True
Where does the Green_1b come from in your post #25 (http://www.luminous-landscape.com/forum/index.php?topic=56978.msg462413#msg462413) ?Thank for pointing it out. It is a mistake. Green_1b is for sRGB, RGB=(0 255 0).
How do your results compare to using the ICC v.4 sRGB profile?That v4 profile does not seem to work the way it should be.
What is your gamut mapping strategy? It seems you are allowing hue to change - usually undesirable.Minimum channel clipping, preserving color details after conversion, reversible conversion (sRGB to jc1RGB or Adobe RGB, for example) with minimum loss, and most importantly, to produce perceptually pleasing result.
"Prove to me that I’m wrong" is probably not an ideal way to promote your idea.Sorry for my words. I did it without that intention at all. Thanks for pointing it out.
Sounds a bit like "the defense" of a thesis as rooted in the European academic tradition.
the question is more why to leave the PhotoGamut RGB pathway (?).If it works better, I intend to make it publicly available. That was my original intention and it still remains the same.
as we find / as shown above, post-processing is as important as the way of gamut mapping,Fully agreed. In most cases, the perceptually compressed details have negligible differences compared with conversion with straight RelCol.
i.e. Local contrast enhancement applied through an inverted Saturation Mask in order to defeat the loss of "compressed" image details.
... I intend to make it publicly available.
That was my original intention and it still remains the same.
here is the Action I used.Thanks for sharing it with us.
It seems you are allowing hue to change - usually undesirable.If you have specific concern or example showing the severe color shift with jc1's conversion, share with us and I am willing to do a study on that.
If you have specific concern or example showing the severe color shift with jc1's conversion, share with us and I am willing to do a study on that.
No severe color shifts - actually I would say that your method does a very good job!
No severe color shifts - actually I would say that your method does a very good job!That's encouraging.
Once ago in another discussion, a serious (printer) profiling expert claimed that all serious profiling software is based on any somewhat distorted Lab-color models (today we may call it a color appearance model) to write the Lut while suppressing the know hue shifts when walking along iso-Lch lines.Wonder if he has alternative or other suggestion.
Once ago in another discussion, a serious (printer) profiling expert claimed
that all serious profiling software is based on any somewhat distorted Lab-color models (today we may call it a color appearance model)
to write the Lut while suppressing the know hue shifts when walking along iso-Lch lines.
Wonder if he has alternative or other suggestion.
Could you show us what the advantage of using jc1RGB as a working/editing space over the established ones already in use today?My original idea was to use jc1RGB as an intermediate space for converting image with ProPhoto to sRGB, perceptually.
To be more specific how will it improve editing images in that space? Will it make it easier? Faster? With less posterization? Less noise? Less artifacts?No. jcSPACE is similar to other icc profile and it has color gamut in between ProPhoto RGB and Adobe RGB. In order to take full advantage of the output device color reproduction capability, the working space should ideally encompass the printer color space.
Why should we use it?That should be decided by the color reproduction requirement.
The main advantage with visible color space is that it connects to the output device more readily with the current CMM environment.