Perceptual Rendering Intent -- ProPhoto to sRGB

[Peter_DL]

Below are what I have observed.

Sorry, can't see any images / attachments below of your post.
Maybe it did not upload.

Color de-saturation due to conversion with PhotoGamut RGB's is more obvious than with jc1's perceptual conversion.

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.

As for RGB clipping due to conversion, it would be nice if that can be shown with histogram.

Believe me, the histogram is unfortunately totally useless as for a (desired) correlation of saturation/gamut-clipping and a best-possible rendition.

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.

Peter

--

[jc1]

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?

Have updated the link or Here

Thank you

jc

[jc1]

Hi,

Sorry, can't see any images / attachments below of your post.
Maybe it did not upload.

No attachment, I was referring to your image Untitled-11b (photogamut) and Untitled-11d (jc1 perceptual).

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.

I have proved that they have similar (so close) color matching 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.

the histogram is unfortunately totally useless as for a (desired) correlation of saturation/gamut-clipping and a best-possible rendition.

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.

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

It will be much appreciated if someone could prove it untrue with just one real image (non descriptive type!).

Thank you.

Sincerely,
jc

[crames]

Have updated the link or Here

Thanks. That one also seems within sRGB gamut, except for the very lightest whites.

While trying to catch up with this thread, I have a few questions:

Where does the Green_1b come from in your post #25 ?

How do your results compare to using the ICC v.4 sRGB profile?

What is your gamut mapping strategy? It seems you are allowing hue to change - usually undesirable.

[Peter_DL]

I have proved that they have similar (so close) color matching 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.

Ok, got it.

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

"Prove to me that I’m wrong" is probably not an ideal way to promote your idea.
Sounds a bit like "the defense" of a thesis as rooted in the European academic tradition.
Anyway.

For me, the question is more why to leave the PhotoGamut RGB pathway (?).
Hey, they have a nice website. A kind of public source.
Also, as we find / as shown above, post-processing is as important as the way of gamut mapping,
i.e. Local contrast enhancement applied through an inverted Saturation Mask in order to defeat the loss of "compressed" image details.

Peter

--

[jc1]

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 ?

Thank for pointing it out. It is a mistake. Green_1b is for sRGB, RGB=(0 255 0).
In CS, Lab vaule is (88 -128 128) for Prophoto RGB=(0 255 0), same as Green_1a except the value b.
I am wondering what should be the correct limits for a and b, 127 or 128? 

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.
Change in hue or color shift is unavoidable in perceptual rendering, may be that is one good reason why perceptual rendering is not always the only choice.

Thanks

jc

[jc1]

"Prove to me that I’m wrong" is probably not an ideal way to promote your idea.
Sounds a bit like "the defense" of a thesis as rooted in the European academic tradition.

Sorry for my words. I did it without that intention at all. Thanks for pointing it out.

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,
i.e. Local contrast enhancement applied through an inverted Saturation Mask in order to defeat the loss of "compressed" image details.

Fully agreed. In most cases, the perceptually compressed details have negligible differences compared with conversion with straight RelCol.

Regards,
jc

[Peter_DL]

... I intend to make it publicly available.
That was my original intention and it still remains the same.

Good idea.
I believe you have a "story" to tell and something to offer to the community.


If of interest, here is the Action I used.

Kind regards, Peter

--

[jc1]

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.

Regards,
jc

[crames]

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.

I took a Color Checker image and boosted the Chroma by 78% in ProphotoRGB, making 10 of the patches out of gamut for sRGB. After converting the super-colorful image to sRGB with your method, the hues for most patches changed very little - a few degrees or less (CIECAM02 hue). The largest hue change of 11 degrees was in the cyan patch (sixth in the third row). Lightness of the patches are also well preserved, again the worst is cyan which has been lightened by 7 J (CIECAM02 lightness).

No severe color shifts - actually I would say that your method does a very good job!

 

[Peter_DL]

No severe color shifts - actually I would say that your method does a very good job!

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.

Peter

--

[jc1]

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.


Update: jc1RGB and sRGB_jc1 0.9 (RC)

Changes:
a) jc1RGB:
    G and B primaries are further optimized.
    Profile size is compacted to below 1K bytes.
    Created with another profiler.
    Color rendering in blue may be improved slightly.
b) sRGB_jc1:
    Optimizing profile size.
    Based on test sample, no difference at all in color reproduction with compared to Beta 2.1     
 
Downloads
jc1RGB and sRGB_jc1 0.9 (RC)
PS actions

jc

[Peter_DL]

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.

The person to ask is Ethan Hansen.
I think, he is sometimes around here as well, although I was referring (from my memory) to a discussion a couple of years ago in the Rob Galbraith forum.

Peter

--

[jc1]

Color Space Comparison: PhotoGamut vs sRGB_jc1

        

Basic Property         PhotoGamut     sRGB_jc1
White                     D50                   D50
Color space             RGB                   RGB
Implementation        Cluts                  Cluts
Profile size(bytes)    148,480              589,928
icc format version    2.0                     2.1
Gamut Volume*       902,827              770,429
Profile Device type   OutputClass         OutputClass
Rendering Intent      All**                  All**
Last Update            2004, avg6c        2011, ver 1.0***
Availability              FOC                   Publicly available        

*     Under D50 condition
**   Colorimetric, Saturation and Perceptual
*** < Link >

Proposed Usage
PhotoGamut: was proposed as a RGB working space.
sRGB_jc1: as a conversion bridge between wide gamut RGB (ProPhoto or scanner space) and sRGB.

[jc1]

Converting aRGB (Adobe RGB) to sRGB

Converting aRGB to sRGB with Relative Colorimetric Intent (RelCol)
Refer to below illustration, data for destination1 was computed with straight Relcol to sRGB, whereas data for destination2 was computed with perceptual conversion to sRGB with icc profile sRGB_jc1.

          

  

Above result shows that for color space conversion from aRGB to sRGB with Relcol, the RED channel (G=B=0) begins to clip at R=219 (source space) onwards. These clipped colors are  indistinguishable in sRGB color space.

jc

[jc1]

jc1RGB Release v1.0
It can be downloaded from this link < click >


My next project: Perfect Color Space

What is Perfect Color Space
                                       

Thanks

jc

[Tim Lookingbill]

Could you show us what the advantage of using jc1RGB as a working/editing space over the established ones already in use today?

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?

Why should we use it?

[jc1]

Hi,

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.

Refer to my previous thread for jcSPACE color space which resemblances jc1RGB. jcSPACE is created with the profile quality on par with ProPhoto,  Adobe RGB and sRGB, just to name a few. It will be made publicly available as well.

Unlike ProPhoto, all colors in jcSPACE are visible.  IMHO, it is the largest possible absolute color space with visible color and that possesses the scalable color characteristic when converting  with colorimetric intent between the same family ( ProPhoto, jcSPACE, Adobe RGB and sRGB and a few others). The main advantage with visible color space is that it connects to the output device more readily with the current CMM environment. The trade off is, similar to ProPhoto, 16-bit workflow is needed.

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.
 

Regards,
jc

[Tim Lookingbill]

The main advantage with visible color space is that it connects to the output device more readily with the current CMM environment.

Can you show visual samples of this happening between the display (soft proofing on or off) and the final print? Is your term "connect to the output device more readily" something physically happening or theoretically happening?

What does this intermediary color space of yours fix or prevent that shows up in a print other than printing from ProPhotoRGB?

How does printing out of jc1RGB improve the appearance of the print over just printing out of ProPhotoRGB?

[jc1]

My analysis was done mostly with test patches, for instance,  ProPhoto GrangerRainbow to sRGB wiith Perceptual intent and Blue Ball test.
 
Perceptual rendering intent is based on Lab and Cluts,  imaginary colors  in source space may not be rendered correctly as illustrated by the above examples. But that may change, as I see improvement in handling such issue for newer released profiler.
 
Download the profile and test chart to experience it yourself. I have read about perceptual intent may not always be the best option for better color reproduction compared with RelCol, but I am unsure if that was due to colors outside the visible spectral locus. Do you print directly for image with ProPhoto?
 
The download links for Digital graner rainbow and jc1RGB profile are reloaded below.
 
Digital graner rainbow
jc1RGB
 
jc