PDA

View Full Version : Color Management: LightWave compatible LUT files for Adobe RGB and/or ProPhoto RGB?



rsfd
04-12-2018, 02:10 AM
LightWave holds LUT files for television and movie workflows alongside with the standard (and small) sRGB color space.
It would be highly beneficial for those who are working in a more photographic/print environment to have LightWave compatible LUT files for AdobeRGB and/or ProPhoto RGB color spaces to import into LightWave's color management system.
Modo i.e. does have these color spaces embedded, but unfortunately the files cannot be imported into LightWave.
I failed to find anything on the web so far, so:
does anyone ever has found a source for LW compatible (*.csp, *.3dl, *.cube) LUTs of AdobeRGB and/or ProPhoto RGB color spaces?

(If others do have the same problem, I'll make it a Feature Request)

COBRASoft
04-12-2018, 12:59 PM
Nice question!

gerardstrada
04-17-2018, 07:44 AM
Notice that "colorspaces" shipped with LW define transfer functions only. It doesn't define other color properties, so in LW, sRGB space is not really "small", nor big, since gamut is not defined. Even when LW support LUTs, these native reproduction curves are formulas, not LUTs. You won't find LUTs OF aRGB, Prophoto or any other colorspace because LUTs -alone- can not define a colorspace. But you can generate LUTs FOR those RGB colorspaces to your display standard for previewing and guide in that way your color choices. Notice however that values above 1.0 will be clipped. In such case you need to pre-manage your input colors externally in a CM-aware software or within LW with something like SG_CCTools. Btw, for print work, here's a way to preview CMYK colors in LW (http://forums.newtek.com/showthread.php?127209-CYMK-Ouch&p=1243952&viewfull=1#post1243952).



Gerardo

rsfd
04-19-2018, 10:41 AM
Hello Gerardo, thank you for your answer!

(I hope that my understanding of color management within 3D applications (mostly OCIO) is correct to some extent).

Mainly I’m encountering these 2 problems:

(SG_CCTools cannot help me, as they unfortunately are Windows-only).

In LW (and Blender) it isn’t possible to import images that originate in a „larger then sRGB” colorspace/Gamut (mostly AdobeRGB, sometimes ProPhoto RGB) and transfer them correctly to the color management system, as there are no LUT files for these colorspaces (Gamuts) to assign to them.
(As far as I understand, the colors are treatened as originating in sRGB (8- and 16-bit imagery), thus incorrectly transferred).
In Modo however, this is possible through the „Foundry-v1” OCIO configuration (which offers LUT files for aRGB and ProPhoto RGB).

So my idea was, if LUT files for AdobeRGB/ProPhoto RGB would be available (similar to the known ICC profiles), I could import them into LW to be able to assign them to according images and to get correct color transfers.
Also, the Preview Renderer could then be set to i.e. AdobeRGB (as possible in Modo).


The second and main problem seems to originate in the way, OCIO is implemented in Mac versions of 3D applications (or how the Previewers forward the color values to the OS) when one is using a Wide Gamut monitor, calibrated to AdobeRGB:
Colors seem to be mapped into the monitor’s Gamut, the monitor’s profile seems to be ignored.
This is very obvious with extreme (somewhat artificial) colors (i.e. 255-0-0), when the Previewers of Modo, LW and also Blender clearly don’t show a sRGB or aRGB red, but an oversaturated red, which most likely simply is the monitor’s maximum red.
So, even if I can set the Preview Renderers in all applications to sRGB (and even to aRGB/ProPhoto RGB in Modo), colors seem mapped into the monitor’s Gamut instead.

There is of course the workaround to limit the monitor to sRGB at the hardware level, but this is somewhat unsatisfying (esp. when this must be done every time one switches from i.e. a 3D application to a color aware application).

(This issue btw. seems not to show up on Windows computers (even with Wide Gamut monitors), so to my understanding it must have something to do with the way, „raw” color data is treated/forwarded on the OS level or at a very deep application level.
It seems to me that for some reasons the color values „bypass” the OS color management, thus don’t get correctly transferred into the monitor’s Gamut).

To my understanding, one solution could probably be to generate a LUT file for (or from?) the monitor’s calibration ICC-profile, so that it would be possible to set the Preview Renderers to this LUT.
But according to my past searches, this does not be possible (or only in very rare and special cases), as both concepts (ICC and LUT) are too different?

I don’t expect color awareness as found in color aware image editing applications, but I’d simply like to find a way to be able to handle colors more consistent within 3D applications, at least for onscreen display.

gerardstrada
04-21-2018, 12:53 PM
LW CS system does not make any assumptions about color gamuts, then images are not really incorrectly converted, it's just that this color property is ignored by the CS system.

I understand it is not apparent at first sight, but it's indeed possible to import images originated in a wider gamut than sRGB. There's not native tools for complete colorspace conversions but it's even possible to perform matrix conversions within DP Image Filter Node Editor in pre-processing (possible in v2015 and below). In v2018 this is also somehow possible with some trickery (Node editor in TexturedFilter applied to a clone of the image), but it would be too memory consuming and unstable with many images, so not production-viable in v2018.

As commented previously, LUTs alone can not define a colorspace (actual colorspaces in OCIO are not LUTs neither), however as commented before, you can built a table that stores a specific colorspace2colorspace conversion (from an CM-aware software) and use that instead, just consider values above 1.0 will be clipped. Such method assumes your display is calibrated or/and you have a reliable way to proof colors to monitor.

As for the second issue, OCIO converts to a display standard, it does not convert by default to your specific monitor in any platform because OCIO doesn't recognize the ICC profile your OS is using. For that, in OCIO context, you need first to calibrate and characterize your monitor, translate profile to ACES framework, reconfig CM settings and set up a color proof conversion. Guess you will find a lot easier just setting the standard your monitor is calibrated to as display space. Setting up any other standard will display wrong colors. Notice OCIO configs by default are not shipped with aRGB display. OCIO is based on ACES framework which assumes a motion picture production pipe, and aRGB space is considered by them as a "graphics design" or "print" output space.

Agree about the workaround you mention, it's not convenient at all. As commented before, for LW (from v10 to v2018) you can generate a table (LUT) that stores a specific colorspace2colorspace conversion, from any RGB profile to your display profile to guide your color choices. Differently to a profile able to provide meaning to a color, a LUT is just a table that maps one value to another. So your LUT will be only useful under the same CM conditions and framework it was generated for. In CS panel is possible also to pick your ICC display profile directly, but LW still has a bug there with what it seems is a wrong illuminant.



Gerardo

rsfd
04-24-2018, 10:00 AM
Hello again Gerardo and thank you again for your reply (much appreciated)


…I understand it is not apparent at first sight, but it's indeed possible to import images originated in a wider gamut than sRGB. There's not native tools for complete colorspace conversions but it's even possible to perform matrix conversions within DP Image Filter Node Editor in pre-processing (possible in v2015 and below). In v2018 this is also somehow possible with some trickery (Node editor in TexturedFilter applied to a clone of the image), but it would be too memory consuming and unstable with many images, so not production-viable in v2018.
As I paused with LW for some years, I only have v.9.6, 10.x and 2018. 2018 is of course the version that I would like to use now (because of the PBR/Principled Shader workflow).


As commented previously, LUTs alone can not define a colorspace (actual colorspaces in OCIO are not LUTs neither), however as commented before, you can built a table that stores a specific colorspace2colorspace conversion (from an CM-aware software) and use that instead, just consider values above 1.0 will be clipped. Such method assumes your display is calibrated or/and you have a reliable way to proof colors to monitor.
Even this sounds a bit complicated, I will do some research on this.



As for the second issue, OCIO converts to a display standard, it does not convert by default to your specific monitor in any platform because OCIO doesn't recognize the ICC profile your OS is using.
Yes, I’m aware of this. Nonetheless there seems to be a platform dependant issue with the way, colors are forwarded to the display, as I could not replicate the same behaviour (the issue with the obvious color mapping into the monitor’s Gamut) on a Windows-PC, also with a calibrated WideGamut monitor.


…Notice OCIO configs by default are not shipped with aRGB display. OCIO is based on ACES framework which assumes a motion picture production pipe, and aRGB space is considered by them as a "graphics design" or "print" output space.
Modo (since around v.90x) comes with an OCIO config file „Foundry_v1”, which holds LUTs (?) for both AdobeRGB and ProPhoto RGB.
This config file is most likely only available within Foundry applications (although I only use Modo, I imagine it’s also available within Mari, Nuke aso).
This OCIO configuration allows me in Modo to import textures that originate either in sRGB or AdobeRGB and have them match perfectly, as I just need to set the appropriate Colorspace property to the texture files (overwriting i.e. the application’s color default preferences).
Unfortunately I fail to build up a similar setup within LW2018 so far.


…In CS panel is possible also to pick your ICC display profile directly, but LW still has a bug there with what it seems is a wrong illuminant.
Thank you for that info, I had tried to import my Monitor’s ICC profile earlier, but LW refused to load it. Now I had tried to import the standardized AdobeRGB profile and it worked out.
I guess, LW only loads v.2 ICC profiles, so I will generate a v.2 Monitor profile next time. (And hopefully that bug you mention is fixed then).

gerardstrada
04-25-2018, 06:40 PM
Hello again Gerardo and thank you again for your reply (much appreciated)
As I paused with LW for some years, I only have v.9.6, 10.x and 2018. 2018 is of course the version that I would like to use now (because of the PBR/Principled Shader workflow).
LW2018 has not pixel and image filter node editors to work with, nor similar native functionality pitifully. Hope they support Denis for implementing his main tools in last LW version since there's a lot of things like color management, pre- and post- compositing, filtering, optical effects at subpixel and image levels, post-effects, color grading, multipass management, rendering enhancements, physical camera simulator, etc, etc, etc, that we can not do in v2018 and are still necessary.


Even this sounds a bit complicated, I will do some research on this.
The table I'm referring is just a 3D LUT. LW tends to work well with .cube LUTs.


Yes, I’m aware of this. Nonetheless there seems to be a platform dependant issue with the way, colors are forwarded to the display, as I could not replicate the same behaviour (the issue with the obvious color mapping into the monitor’s Gamut) on a Windows-PC, also with a calibrated WideGamut monitor.
A problem would be the lack of color mapping to monitor (or display standard) or maybe you are referring that colors are sent to monitor without conversion to aRGB standard. This could mean aRGB display in your Modo for MAC is somehow failing.


Modo (since around v.90x) comes with an OCIO config file „Foundry_v1”, which holds LUTs (?) for both AdobeRGB and ProPhoto RGB.
This config file is most likely only available within Foundry applications (although I only use Modo, I imagine it’s also available within Mari, Nuke aso).
This OCIO configuration allows me in Modo to import textures that originate either in sRGB or AdobeRGB and have them match perfectly, as I just need to set the appropriate Colorspace property to the texture files (overwriting i.e. the application’s color default preferences).
I'm referring that OCIO is not shipped with proper display according to ACES framework for aRGB space (display colors are converted and sent directly to monitor with no color rendering, no OCES transformation, etc) and it's the same for the Foundry config you refer. Last time I checked, Prophoto conversion in Foundry config was wrongly made. Notice that even when the folder we see is called "luts", what really provides the gamut conversion are the matrices files, not the LUT files - which define only the gamma curve (thing that would be better solved with an actual gamma function instead of a clipped 1D LUT), in any way, it would be an idea check if the matrix files are there because the problem you describe seems to be the lack of gamut conversion to display standard.


Unfortunately I fail to build up a similar setup within LW2018 so far.
Notice the setup you are trying to replicate from Modo is not really useful for working in wider gamuts, but rather the contrary. It's for converting from wider gamuts to a narrow one (sRGB). Not really recommendable, but if you want to try it anyway (to work in sRGB range with an aRGB monitor), I'm attaching an aRGB LUT, just use it instead of display sRGB space in v2018.


Thank you for that info, I had tried to import my Monitor’s ICC profile earlier, but LW refused to load it. Now I had tried to import the standardized AdobeRGB profile and it worked out.
I guess, LW only loads v.2 ICC profiles, so I will generate a v.2 Monitor profile next time. (And hopefully that bug you mention is fixed then).
Yes, you could try also the AdobeRGB standard profile. Might convert a display ICC profile from V4 to V2, but as commented there's a bug since LW10 (a pink color cast) when using ICC profiles in CS panel.



Gerardo

rsfd
05-01-2018, 07:23 AM
Hello Gerardo,

first of all: thank you very much for the AdobeRGB LUT file.
It really helps to set this up for the Monitor output.
I’ve also created a v.2 Monitor Profile which LW now loads.


LW2018 has not pixel and image filter node editors to work with, …
This is pretty disadvantageous and after having downloaded the Modo v12 trial now, my first impression tends towards the realization that I most likely will have to bite the bullet and go Modo maintenance, as Blender obviously has the same Color Management restrictions as LightWave.


A problem would be the lack of color mapping to monitor (or display standard) or maybe you are referring that colors are sent to monitor without conversion to aRGB standard. This could mean aRGB display in your Modo for MAC is somehow failing.
Seems to be the first case. I’m just wondering why I can’t observe this issue on a collegue’s Windows-PC.
Might be an issue how untagged color values are handled by OS. (Might be: Windows: treads these as sRGB, OSX as MonitorRGB).
The conversion matrices in Modo seem to work ok. New version even has more options: setting up default colorspaces for Numeric Color Values and LUT files for Wide Gamut Displays aso.
My first impressions here are pretty good and if this continues, it seems that this will be my final goodbye to LW, as I cannot afford to run 2 paid 3D-applications with similar scope (Photographer here in the first place).


Notice the setup you are trying to replicate from Modo is not really useful for working in wider gamuts, but rather the contrary. It's for converting from wider gamuts to a narrow one (sRGB). Not really recommendable, but if you want to try it anyway (to work in sRGB range with an aRGB monitor), I'm attaching an aRGB LUT, just use it instead of display sRGB space in v2018.
What I would like to achieve is actually to be able to work in aRGB while still additionally importing sRGB imagery (> 3rd party Textures usually originate in sRGB).
This does work in Modo, as there it is possible to set a colorspace property to an image which overwrites the application’s default settings.
In LW, this seems not to work: even when I set the Color Space RGB property in the Image Editor, LW does not handle images/textures with different colorspaces correctly.
(2 texture files with the same effective color in color aware applications, but out of different colorspaces (aRGB and sRGB) don’t show identical colors in LW. However, they do so in Modo and any color aware application).

Roger

gerardstrada
05-02-2018, 11:45 PM
Hello Gerardo,

first of all: thank you very much for the AdobeRGB LUT file.
It really helps to set this up for the Monitor output.
I’ve also created a v.2 Monitor Profile which LW now loads.
Hello Roger,

Hope the LUT helps until the pink colorcast with ICC profiles gets fixed.


This is pretty disadvantageous and after having downloaded the Modo v12 trial now, my first impression tends towards the realization that I most likely will have to bite the bullet and go Modo maintenance, as Blender obviously has the same Color Management restrictions as LightWave.
Not sure what same CM restrictions are you referring to, but differently to Modo (or Blender), LW makes no assumptions about gamut aspect, which for the purposes you are referring to -working in sRGB range with wide-gamut monitor- a display LUT may work as well.


Seems to be the first case. I’m just wondering why I can’t observe this issue on a collegue’s Windows-PC.
Might be an issue how untagged color values are handled by OS. (Might be: Windows: treads these as sRGB, OSX as MonitorRGB).
The conversion matrices in Modo seem to work ok. New version even has more options: setting up default colorspaces for Numeric Color Values and LUT files for Wide Gamut Displays aso.
My first impressions here are pretty good and if this continues, it seems that this will be my final goodbye to LW, as I cannot afford to run 2 paid 3D-applications with similar scope (Photographer here in the first place).
Windows manages monitor colors by depending on the color profile assigned for display, so what you say about your collegue's PC is very plausible.
Checked in Modo 11.x and conversion from Prophoto is wrong, but from AdobeRGB conversion is correct.


What I would like to achieve is actually to be able to work in aRGB while still additionally importing sRGB imagery (> 3rd party Textures usually originate in sRGB).
This does work in Modo, as there it is possible to set a colorspace property to an image which overwrites the application’s default settings.
In LW, this seems not to work: even when I set the Color Space RGB property in the Image Editor, LW does not handle images/textures with different colorspaces correctly.
(2 texture files with the same effective color in color aware applications, but out of different colorspaces (aRGB and sRGB) don’t show identical colors in LW. However, they do so in Modo and any color aware application).

Roger
As commented, working in wide gamut range is not possible with the Foundry config you refer in Modo, since what it does is to convert from wider gamut (let's say aRGB) to sRGB, which works for working in sRGB range with a wide gamut monitor. This same thing can be done within LW 2018 by loading sRGB-only images and using the LUT shared previously.

If you want to mix sRGB with aRGB images in LW 2018, Node editor in Textured Filter should work in theory. Pitifully in practice, LUTs used there are not saved/loaded so the colorspace nodes within this editor is lost. Referencing the same image through TexturedFilter is also unstable, in the sense that you need to set things up in a specific order so that the color correction applied can be updated by Image Editor and it doesn't crash LW. I've tried also by using matrices instead of LUTs, and in spite of loading the node setup correctly, the ColorLayer node loses its image reference every time the scene is loaded. Using a clone instead and saving objects and scene again doesn't work either because it seems there's a bug in v2018 where cloned images are not loaded. Maybe you could confirm if this bug has been already solved in last v2018.3 (I haven't checked yet). These limitations are not present in v2015 with DP Image Filter Node Editor, nor with SG_CCTools. This is why I commented in my first post that in v2018 you need to pre-manage your input colors externally in a CM-aware software.



Gerardo

rsfd
05-13-2018, 10:03 AM
Hello Gerardo,

Apologies for this very late reply!


…Not sure what same CM restrictions are you referring to, but differently to Modo (or Blender), LW makes no assumptions about gamut aspect, which for the purposes you are referring to -working in sRGB range with wide-gamut monitor- a display LUT may work as well.
By „restrictions”, I only meant that (until now) I haven’t found a way to assign appropriate colorspaces to aRGB-Textures in Blender.
(Need to add that I just started exploring Blender and the application is in deed quite differently organized. The functionality might be there, but me at last haven’t found it so far.

Mixing aRGB and sRGB imagery and have these correctly previewed and rendered would be my main target.
This seem to work pretty well in Modo with only minor variances. Same setup in LW does not work as the errors are too obvious. (At least by the way I’m trying to accomplish this in LW ’18 obviously)
Only solution here seems -as you already mentioned- reducing aRGB imagery to sRGB prior to loading into LW.


Hope the LUT helps until the pink colorcast with ICC profiles gets fixed.
Actually, I’m not sure about this, as I’ve made a test which resulted in strange color rendition in the shadows area, which seems to be clipped and which introduces a magenta color cast.
Using the standardized „AdobeRGB 1998” ICC profile seems to work better, but the profile is often lost when reopening a scene which is using it.
(I’ve attached 3 results with combined aRGB and sRGB texture files).


…As commented, working in wide gamut range is not possible with the Foundry config you refer in Modo, since what it does is to convert from wider gamut (let's say aRGB) to sRGB, which works for working in sRGB range with a wide gamut monitor. This same thing can be done within LW 2018 by loading sRGB-only images and using the LUT shared previously.
The main point here is to achieve a consistent color rendition in the Preview renderers while mixing aRGB and sRGB imagery.
As mentioned before, this does work pretty well in Modo while LW (and most likely Blender too) needs a strict sRGB pipeline.


…If you want to mix sRGB with aRGB images in LW 2018, Node editor in Textured Filter should work in theory. …
Bear with me, are you referring to the LW Textured Filter, or DP Filter Node Editors?


… Maybe you could confirm if this bug has been already solved in last v2018.3 (I haven't checked yet). …
:D
First need to wrap my head around this all!


…These limitations are not present in v2015 with DP Image Filter Node Editor, nor with SG_CCTools. …
Am I correct in that these solutions would apply to the rendering process and would not influence the Previewer’s color rendition?
(Are DP plugins still compatible with LW2018, esp. the Mac versions? I haven't tried so far, as I was LW-absent for several years and my impression lately was, that NewTek does no longer collaborate with Denis Pontonnier, or he might has withdrawn from working on LW-plugins?)


¬ Roger

p.s.
attached files: 2 textures combined with a mask: inner color patches originate in AdobeRGB, outer color patches are sRGB

gerardstrada
05-14-2018, 03:49 PM
Hello Gerardo,

Apologies for this very late reply!
By „restrictions”, I only meant that (until now) I haven’t found a way to assign appropriate colorspaces to aRGB-Textures in Blender.
(Need to add that I just started exploring Blender and the application is in deed quite differently organized. The functionality might be there, but me at last haven’t found it so far.
Not such restriction in Blender. Every image texture has an (input) colorspace parameter (below source parameter) and available colorspaces can be managed from the CM config file.



Mixing aRGB and sRGB imagery and have these correctly previewed and rendered would be my main target.
This seem to work pretty well in Modo with only minor variances. Same setup in LW does not work as the errors are too obvious. (At least by the way I’m trying to accomplish this in LW ’18 obviously)
Only solution here seems -as you already mentioned- reducing aRGB imagery to sRGB prior to loading into LW.
Well, depending on the CM-aware software you use, you could apply proper gamut mapping from/to arbitrary colorspaces instead of just clipping gamut like happens in Modo, the issue in v2018 is that without image and pixel filter node editors, several other necessary color transformations before and after rendering are lost.


Actually, I’m not sure about this, as I’ve made a test which resulted in strange color rendition in the shadows area, which seems to be clipped and which introduces a magenta color cast.
Using the standardized „AdobeRGB 1998” ICC profile seems to work better, but the profile is often lost when reopening a scene which is using it.
(I’ve attached 3 results with combined aRGB and sRGB texture files).

hmmm... aRGB LUT works fine here, look:


https://s7.postimg.cc/aby2qswmz/LW2018a_RGBresult.jpg

Sorry for not being clear enough when I said "just use it instead of display sRGB space in v2018", with just I meant only as display space. Do not use it for linearization in Image Editor. There are 2 reasons why you should not do this:

- First, you are cancelling the conversion in order you can display proper sRGB colors in your aRGB monitor.
- Second, better use the native sRGB profile. Not only because the images are encoded with sRGB curve but also because the shared cube is just a 36x36x36 3D LUT and you'll get such ugly posterizations with such low resolution if you use it for linearizations.

To give you an idea, the LUT performing linearization in OCIO is a 4096 res 1D LUT. We need a lot of table entries to avoid quantization for linearizations, and even for gamma correcting, a 36 res LUT is not enough in this case (there's indeed a darken results in shadows due to LUT precision). This is why is better to use the sRGB profile instead, which is a parametric solution. This is the reason why I said previously that gamma curves are better solved with an actual gamma function instead of a LUT. There's 2 or 3 ways to avoid quantizations in LUTs, but none of them are supported by LW yet. However there is another option to solve the issue I'm gonna show you later.

Btw, I can notice that, same than with PC, MAC version of LW displays ICC profiles with pinkish colorcast. Hope they solve it eventually.

Anyway, since you are using the LUT for linearizing the image, you are cancelling the proper conversion. Original image chromaticities should be kept intact in this case, otherwise you'll get back sRGB colors instead of aRGB colors (besides posterizations) and colors obviously won't match with aRGB reference.

Do not expect also colors matching up perfectly with aRGB reference, since aRGB gamma curve and sRGB curve are different. So you would need to compare against same curve. Also if color data is originated in wider gamut (and depending on the saturation of sampled colors), you won't be able to recover original gamut if it was previously converted to a smaller one unless some kind of gamut expansion is performed. Thing you can not do in Modo, but it can be done in a CM-aware software.

So in order to address same curve than sRGB but with aRGB chromaticities, you could go in another way. Think this is my first little tut for LW2018 :D

- Go to CS panel and set sRGB preset (the correct v2015, not the incorrect v2018).

- Then switch display from sRGB to Linear.


https://s7.postimg.cc/rcgyzn9q3/CSsetup.png

Now, instead of using the display parameter from the CS panel, we are gonna use the gamma correction trick I shared for FPrime in a magazine long time ago, which also works with VPR as described here, btw:

http://forums.newtek.com/showthread.php?136662-LightWave-and-Wide-Gamut-monitors&p=1337325&viewfull=1#post1337325

In order to update the trick for v2018 we need to go in this way:

- add a plane/card and parent it in front of the camera:


https://s7.postimg.cc/lbja2o2kb/cameracard.png

- Switch to Standard Material and set 0% diffuse / 100% luminosity


https://s7.postimg.cc/t49xuoqjv/cameracardsurf.png

- In Surface Node Editor connect RayPosition and RayDirection from Input node to respective Postion and Direction inputs in RayTrace node.

- Add 2 ConvertColorSpace nodes. Connect raytrace color output to the first ConvertColorSpace node and set at sRGB colorspace (this is our parametric curve) and the next one at aRGB-sRGB LUT (this could be also a matrix) and connect this concatenation to Color Input of Standard material. I'm attaching the aRGB-sRGB LUT.


https://s7.postimg.cc/b1gv3hxa3/cameracardnode.png

- Finally, enable RayTrace Refraction.

That's all. You can see here how colors macth up:


https://s7.postimg.cc/ssshhgcjf/LW2018setupresult.jpg

Nice thing about this solution is that we are leaving display for what it really is, just display. So for example, we can simulate a log output and and a filmic display. in this case I'm emulating a filmic TMO:


https://s7.postimg.cc/7vw9cxrez/lin2cin.jpg

https://s7.postimg.cc/qbgqackyz/cin2film.jpg

We can emulate different print density films in the card and theatrical films in display. Ideally, this should be done in an Image Node Editor, like we can in v2015 with DP Node Image Filter, where we can do even a lot more things.


The main point here is to achieve a consistent color rendition in the Preview renderers while mixing aRGB and sRGB imagery.
As mentioned before, this does work pretty well in Modo while LW (and most likely Blender too) needs a strict sRGB pipeline.
I know is more handy perform the conversion within the 3D package, but if you are not worried about gamut loss, then pre-conversion to sRGB will give you same results than what you get in Modo, which if we think twice, at the end is also a strict sRGB workflow, in the sense that that's what all input images are gonna be converted and what's outputted. In any case I have the idea you could use the LUT I'm sharing in this post to convert your images per surface-basis in v2018. Not ideal, I know, but it should work - in both directions.


Bear with me, are you referring to the LW Textured Filter, or DP Filter Node Editors?
Of course, referring to LW Textured Filter=>Procedurals=>NodeEditor.


:DFirst need to wrap my head around this all!
Idea is referencing the same image in the TexturedFilter to perform the conversion, either directly or through a clone. But it's buggy in v2018. Perhaps it could be done in last v2018.04, but haven't tried yet.



Am I correct in that these solutions would apply to the rendering process and would not influence the Previewer’s color rendition?
(Are DP plugins still compatible with LW2018, esp. the Mac versions? I haven't tried so far, as I was LW-absent for several years and my impression lately was, that NewTek does no longer collaborate with Denis Pontonnier, or he might has withdrawn from working on LW-plugins?)
In v2015 corrections affects rendering process and reflects correctly in previews (VIPER and also possible in VPR with the camera card filter rig shown previously). Moreover, there's an unreleased version of SG_CCTools that when used in Node Image Filter allows us perform several other color transformations in the processing pipe not available in any other 3D package up to date.

Pitifully LW2018 has not pixel and image filter node editors functionality to work with. Really hope they can support Denis to update so useful tools because half of shading and rendering functionality has been lost in v2018, which is a great renderer.



Gerardo

rsfd
05-18-2018, 12:22 PM
Hello Gerardo,

wow, this is jaw-dropping!
Thank you very much again for your time, efforts and patience!


…Not such restriction in Blender. Every image texture has an (input) colorspace parameter (below source parameter) and available colorspaces can be managed from the CM config file.
You are correct. And I’ve sometimes found this parameter in Blender’s UI, but by default AdobeRGB is missing. I once had tried to copy the files from Modo into Blender’s application package, but they seem incompatible. Your info about the config file is very welcomed and I’ll try that later. Blender seems very powerful but the UI is „very special” and I still need to build up an idea of the concept behind it…


Well, depending on the CM-aware software you use, you could apply proper gamut mapping from/to arbitrary colorspaces instead of just clipping gamut like happens in Modo, the issue in v2018 is that without image and pixel filter node editors, several other necessary color transformations before and after rendering are lost.
Still on PS-CS6 here, Affinity Photo and some others.
I’ve tested some more and it seems to me that the idea of mixing AdobeRGB images with sRGB images is not ideal for LW 2018.
As you certainly noticed, I’m not very familiar with the concept of LUT files and I still need to find some more information about how one would create files for colorspace conversions.


hmmm... aRGB LUT works fine here, look:
It’s working here too for VPR. The difference to the sRGB LUT isn’t huge though. Unfortunately, it does not fix the problem with the oversaturated colors in VPR that I’m encountering here under OSX with a Wide Gamut Display.


Sorry for not being clear enough when I said "just use it instead of display sRGB space in v2018", with just I meant only as display space. Do not use it for linearization in Image Editor.
I’ve noticed that this will not work. I still hung on that idea of mixing aRGB and sRGB, so in order to get correct colors out of these, I thought that there are primarily 2 points where to intervene: right at the linearization or at the output.
This was one of the reasons for this post: I thought that I could use a LUT file that would provide the conversion matrix from aRGB to linear and which I could assign to a aRGB image in LW Image Editor. And as this would be a pretty complex file that would do a conversion from one standardized colorspace to another, I was convinced that I wouldn’t be able to create this on my own. On the other hand I thought that such a file would (or at least should) exist and I „just” need to find it somewhere.


Btw, I can notice that, same than with PC, MAC version of LW displays ICC profiles with pinkish colorcast. Hope they solve it eventually.
Can verify this now, seems a magenta shift towards the highlight area. Shadows (to me) don’t seem that much affected.
As this is obviously a long standing bug, I don’t have too much hope for a fix though.


…Original image chromaticities should be kept intact in this case, otherwise you'll get back sRGB colors instead of aRGB colors (besides posterizations) and colors obviously won't match with aRGB reference.
So my idea of using a dedicated LUT for linearization of aRGB images is basically correct?
I imagine that then visually identical colors out of aRGB and sRGB would be linearized to the same color values within a 3D application’s internal „processing engine”.


Do not expect also colors matching up perfectly with aRGB reference, since aRGB gamma curve and sRGB curve are different. So you would need to compare against same curve. Also if color data is originated in wider gamut (and depending on the saturation of sampled colors), you won't be able to recover original gamut if it was previously converted to a smaller one unless some kind of gamut expansion is performed. Thing you can not do in Modo, but it can be done in a CM-aware software.
I wouldn’t expect perfect color match for the reasons you mention, I just always think that it is somewhat strange to work in a 32-bit application and then limit oneself to such a small colorspace as sRGB. Bringing in imagery originating in wider gamuts introduces the known issues though.


So in order to address same curve than sRGB but with aRGB chromaticities, you could go in another way. Think this is my first little tut for LW2018 …
This leads to the 2nd problem that I try to solve:
The „Camera Filter” setup unfortunately shows me in VPR even more oversaturated colors then the standard sRGB setup (even with aRGB-LUT for display).
This is the issue where I think that it probably has to do with color handling on the OS level or with the way OCIO is working or is being implemented for the different platforms.
This issue affects LW-Mac in conjunction with WideGamut AdobeRGB calibrated monitors.
Colors in Preview Renderers like VPR turn out oversaturated and are hardly usable for previewing purposes.
That’s why I render to 32-bit and try to get everything in order in postproduction.

While the standard sRGB workflow shows oversaturated colors here, the „Camera Filter” setup shows even more oversaturated colors that I even cannot do a screen capture of these, as OSX converts the colors either to sRGB or the used Monitor Profile (depending on how the screenshot is made) and the „true” oversaturation is reduced to „normal” oversaturation.



I know is more handy perform the conversion within the 3D package, but if you are not worried about gamut loss, then pre-conversion to sRGB will give you same results than what you get in Modo, which if we think twice, at the end is also a strict sRGB workflow, in the sense that that's what all input images are gonna be converted and what's outputted. In any case I have the idea you could use the LUT I'm sharing in this post to convert your images per surface-basis in v2018. Not ideal, I know, but it should work - in both directions.
So am I mistaken in the idea that it would be possible to bring aRGB imagery into a 3D application and have these correctly linearized (with a dedicated LUT), as all input runs through the sRGB linearization process?
In this case, reducing to sRGB externally prior to loading into a 3D application would be the easiest workflow of course.
(But I would still have the oversaturation problem in VPR).



…Moreover, there's an unreleased version of SG_CCTools that when used in Node Image Filter allows us perform several other color transformations in the processing pipe not available in any other 3D package up to date.
This must be the long awaited Mac-version of the SG_CCTools :)
(No, realistically I don’t expect a Mac version to come up anytime).


Pitifully LW2018 has not pixel and image filter node editors functionality to work with. Really hope they can support Denis to update so useful tools because half of shading and rendering functionality has been lost in v2018, which is a great renderer.
Couldn’t agree more…


>>Attachements (for the oversaturation issue):
-downsized sRGB texture
-screenshot in VPR (LW2018) Mac on AdobeRGB calibrated Wide Gamut Display (as mentioned above there is no way to screen-capture the oversaturation seen when using the „Camera Filter” setup)

141748141747

gerardstrada
05-18-2018, 05:32 PM
Hello Gerardo,

wow, this is jaw-dropping!
Thank you very much again for your time, efforts and patience!
Hope some of this may be helpful for you or someone else.


It’s working here too for VPR. The difference to the sRGB LUT isn’t huge though. Unfortunately, it does not fix the problem with the oversaturated colors in VPR that I’m encountering here under OSX with a Wide Gamut Display.
Saving of course the differences in tone scale due to LUT precision, the difference here is consistent between aRGB and sRGB gamuts, look:


https://s7.postimg.cc/4130sdabf/a_RGB-s_RGB-_LUTdiff.jpg


I’ve noticed that this will not work. I still hung on that idea of mixing aRGB and sRGB, so in order to get correct colors out of these, I thought that there are primarily 2 points where to intervene: right at the linearization or at the output.
It depends on what the input is and what you want to do with it. Idea of the aRGB LUT (or the shared method previously for that matter) is to input sRGB images ONLY and preview in aRGB monitor. In such case, as commented, do not use the aRGB LUT for linearization. Just for display, and linearize with native sRGB profile (which only takes into account sRGB transfer function).


This was one of the reasons for this post: I thought that I could use a LUT file that would provide the conversion matrix from aRGB to linear and which I could assign to a aRGB image in LW Image Editor. And as this would be a pretty complex file that would do a conversion from one standardized colorspace to another, I was convinced that I wouldn’t be able to create this on my own. On the other hand I thought that such a file would (or at least should) exist and I „just” need to find it somewhere.
In LW, linear is not a colorspace properly, it's just a transfer function or a TRC if you wish. If by linear you mean what you get in Modo when converting from aRGB space with The Foundry config, then that linear is sRGB linear. There are several ways to perform such linearization in an image node editor context, but a simple cube it's not really a practical way.


So my idea of using a dedicated LUT for linearization of aRGB images is basically correct?
Not a LUT for linearization. As shown in this thread, a single LUT (as tables supported by LW) is not a convenient way to perform linearizations. But as commented in the method shared before, and though the setup is for preview purposes only, you could try by linearizing the transfer function in Image Editor, and then apply the aRGB-sRGB LUT (or matrix) within Surface Editor for your aRGB 8-bpc images (notice the LUT may work in both directions). Not ideal because it should be done per surface-basis, unless the issue with cloned images has been solved in v2018.04.


I wouldn’t expect perfect color match for the reasons you mention, I just always think that it is somewhat strange to work in a 32-bit application and then limit oneself to such a small colorspace as sRGB. Bringing in imagery originating in wider gamuts introduces the known issues though.
Yes, agree, as I commented before, limiting to sRGB is not recommendable at all. Even less for a PBR engine.


This leads to the 2nd problem that I try to solve:
The „Camera Filter” setup unfortunately shows me in VPR even more oversaturated colors then the standard sRGB setup (even with aRGB-LUT for display).
This is the issue where I think that it probably has to do with color handling on the OS level or with the way OCIO is working or is being implemented for the different platforms.
This issue affects LW-Mac in conjunction with WideGamut AdobeRGB calibrated monitors.
Colors in Preview Renderers like VPR turn out oversaturated and are hardly usable for previewing purposes.
That’s why I render to 32-bit and try to get everything in order in postproduction.
While the standard sRGB workflow shows oversaturated colors here, the „Camera Filter” setup shows even more oversaturated colors that I even cannot do a screen capture of these, as OSX converts the colors either to sRGB or the used Monitor Profile (depending on how the screenshot is made) and the „true” oversaturation is reduced to „normal” oversaturation.
So am I mistaken in the idea that it would be possible to bring aRGB imagery into a 3D application and have these correctly linearized (with a dedicated LUT), as all input runs through the sRGB linearization process?
In this case, reducing to sRGB externally prior to loading into a 3D application would be the easiest workflow of course.
(But I would still have the oversaturation problem in VPR).
hmmmm... The setup looks well here, look:


https://s7.postimg.cc/ia2na3oqj/setupresultscomparison.jpg

The setup with the aRGB display really match the aRGB original, which is of course less saturated than the sRGB input. Just in case, be sure you are not using the Removed output instead of the Applied one (which would invert the table and saturate the results instead). If you want, you can attach your scene file and I can check here if I get same results than yours. If I get the same results I'm getting here, it means it's something in the way your OS is configured. If not, then it might be something in your scene setup.


This must be the long awaited Mac-version of the SG_CCTools :)
(No, realistically I don’t expect a Mac version to come up anytime).
Well, a MAC version would depend on the Picker mostly, I guess.



Gerardo

p.s. Just in case, it seems that for the shared setup is not necessary to enable RayTrace Refraction anymore :)

rsfd
05-20-2018, 10:03 AM
Hello Gerardo,


Hope some of this may be helpful for you or someone else.
It surely is!


It depends on what the input is and what you want to do with it. Idea of the aRGB LUT (or the shared method previously for that matter) is to input sRGB images ONLY and preview in aRGB monitor. In such case, as commented, do not use the aRGB LUT for linearization. Just for display, and linearize with native sRGB profile (which only takes into account sRGB transfer function).
hmm, I start to think that I may be subject to a false way of thinking: I did understand that the LUT is used to map the outgoing color values better into a aRGB Display’s Gamut.
But am I wrong in thinking that it must be possible to import images originating both in aRGB and sRGB into one single scene?
According to my understandig, both image types would need to undergo different linearization processes. A sRGB image would be linearized „by default”, while a aRGB image would need to undergo a different linearization process, so that i.e. visually identical colors (in aRGB and sRGB) would end up as (nearly - depending on the „quality” of the linerization process) identical color values within the application’s internal processing unit.


In LW, linear is not a colorspace properly, it's just a transfer function or a TRC if you wish. If by linear you mean what you get in Modo when converting from aRGB space with The Foundry config, then that linear is sRGB linear. There are several ways to perform such linearization in an image node editor context, but a simple cube it's not really a practical way.
By linear I think about some sort of de-gamma-rization for images that originate in 8 or 16 bpc and usually have a Gamma curve applied through the used colorspace.
But I don’t have insight in what linear is used in LW. I’m assuming that it is sRGB linear. (But it seems that Blender i.e. is using Rec.709/D65 by default, so it’s maybe this one in LW too?).

By your description, a linearization of images that originate in other color spaces (as i.e. aRGB) would be possible in general, but it isn’t possible in LW2018 (at least natively).


hmmmm... The setup looks well here, look:
But just as a side note: you are on Windows-OS exclusively?


The setup with the aRGB display really match the aRGB original, which is of course less saturated than the sRGB input. Just in case, be sure you are not using the Removed output instead of the Applied one (which would invert the table and saturate the results instead). If you want, you can attach your scene file and I can check here if I get same results than yours. If I get the same results I'm getting here, it means it's something in the way your OS is configured. If not, then it might be something in your scene setup.
That’s very kind of you. I attached the scene file but I do think that everythink is in order. Nevertheless, 4 eyes see more than 2.

I still think that the oversaturated colors that VPR shows is an OS „effect”. Unfortunately, I don’t have enough insight about how the colors are send to screen display.
I imagine that these are some sort of „raw” values, thus untagged with a colorspace. And my idea is that those color values are interpreted by Windows by default as sRGB while OSX just maps these color values into the Display’s (Wide) Gamut. I don’t know if OSX still handles untagged color values this way (it was like that at least many years ago, the reason being that untagged color values don’t tell anything without an assigned colorspace). But Apple did do some changes (i.e.switch from default 1,8 Gamma to 2,2 Gamma with OSX-Lion (I think it was this version)).
Unfortunately, it’s not easy to get more information about the internals of OSX without being a software developer or similar.
If I get a better idea about in what way VPR i.e. sends colors to the Display, I think I may be able to get some more information about what causes the oversaturation issue probably at an Apple Forum or maybe directly at X-Rite or EIZO…
The only way for me at the moment to get colors that are close to the input colors is to set the Display to the build-in AdobeRGB or sRGB Preset Modes. The Monitor’s profile seems to be completely ignored by LW. (The AdobeRGB-LUT in Modo on the other hand seems to act more aggressively, as color saturation is strongly reduced and the overall contrast seems lower then expected…)

¬ Roger

gerardstrada
05-23-2018, 03:17 PM
Hello Gerardo,
It surely is!

Glad it helps!


hmm, I start to think that I may be subject to a false way of thinking: I did understand that the LUT is used to map the outgoing color values better into a aRGB Display’s Gamut.
Yes, that's right.


But am I wrong in thinking that it must be possible to import images originating both in aRGB and sRGB into one single scene?
No, no. I think you are right. That's indeed possible and production viable within v2015 with third-party tools/CM systems (and even in previous versions before LW 10) and it's also possible in v2018, I think. The issue is, how to do it with only native tools and in an efficient way within v2018.


According to my understandig, both image types would need to undergo different linearization processes. A sRGB image would be linearized „by default”, while a aRGB image would need to undergo a different linearization process, so that i.e. visually identical colors (in aRGB and sRGB) would end up as (nearly - depending on the „quality” of the linerization process) identical color values within the application’s internal processing unit.
Your understanding is fine, but here's the knot of the rope. A transfer function, or more generally speaking, a tone reproduction curve, is only one single aspect (from the several ones) necessary to define color and it's the only property that LW CM system deals with. So LW "profiles" by default are very limited to be able to differentiate among linear versions of different colorspaces because it has no native tools to describe color properly.


By linear I think about some sort of de-gamma-rization for images that originate in 8 or 16 bpc and usually have a Gamma curve applied through the used colorspace.
But I don’t have insight in what linear is used in LW. I’m assuming that it is sRGB linear. (But it seems that Blender i.e. is using Rec.709/D65 by default, so it’s maybe this one in LW too?).
That's probably the most important aspect of linear. As commented, the linear used in LW only takes into account transfer functions. So theoretically speaking it can be "linear" for any colorspace. In practice however we need proper ways to define which linear colorspace we are working with. Some ways are far more flexible and efficient (third-party CM systems), some are more restricted but viable (adopting a single standard - commonly sRGB), and some are more limited and sometimes not so efficient (only native tools). Btw, default Blender is not quite using Rec.709/D65, it's more sRGB/ACES, but that's another topic.


By your description, a linearization of images that originate in other color spaces (as i.e. aRGB) would be possible in general, but it isn’t possible in LW2018 (at least natively).
Not really. It is indeed possible in v2018, but once again, all depends on what you want to do. If you'd adopt the aRGB standard instead of sRGB standard, then things would be even easier for you, because your monitor is already aRGB, you would not have any issues previewing aRGB images directly and gamma linearization is 1/2.2. But if you want to mix different colorspaces like one is able in a CM-aware software, then things get complicated in LW2018. It's possible (as commented, it can be done in Surface Node Editor), but it's not efficient for production changing the color of 300 images one by one multiple times every time you need to use them in a shader or material. this is something that it's better solved at (Node) Image Editor level or even previously in v2018.


But just as a side note: you are on Windows-OS exclusively?
Yes, only Win here and most of CM cases that I've seen are in PC platform and some few in MAC. But never heard before about the issue you are experienced, so I'm curious.


That’s very kind of you. I attached the scene file but I do think that everythink is in order. Nevertheless, 4 eyes see more than 2.
I still think that the oversaturated colors that VPR shows is an OS „effect”. Unfortunately, I don’t have enough insight about how the colors are send to screen display.
I imagine that these are some sort of „raw” values, thus untagged with a colorspace. And my idea is that those color values are interpreted by Windows by default as sRGB while OSX just maps these color values into the Display’s (Wide) Gamut. I don’t know if OSX still handles untagged color values this way (it was like that at least many years ago, the reason being that untagged color values don’t tell anything without an assigned colorspace). But Apple did do some changes (i.e.switch from default 1,8 Gamma to 2,2 Gamma with OSX-Lion (I think it was this version)).
Unfortunately, it’s not easy to get more information about the internals of OSX without being a software developer or similar.
If I get a better idea about in what way VPR i.e. sends colors to the Display, I think I may be able to get some more information about what causes the oversaturation issue probably at an Apple Forum or maybe directly at X-Rite or EIZO…
The only way for me at the moment to get colors that are close to the input colors is to set the Display to the build-in AdobeRGB or sRGB Preset Modes. The Monitor’s profile seems to be completely ignored by LW. (The AdobeRGB-LUT in Modo on the other hand seems to act more aggressively, as color saturation is strongly reduced and the overall contrast seems lower then expected…)
I've checked the scene and there are some few (but important) issues:

- For some reason your camera filter object is not doing anything in the scene. So I just made a new one from scratch and it's working fine here after reloading the scene.
- The scene is not using the aRGB-sRGB LUT I provided for the ColorSpaceConversion node needed in the camera filter card. It's set up as Linear. However you have included the LUT in the LUTs folder (it might be also v2018 in MAC has issues saving LUTs properly).
- The scene is using the aRGB LUT as display. This is wrong for the camera filter card setup as described in the little tut. Unless you are picking colors, let the display as linear there because you are compensating for previewing precisely with the camera filter card.

As commented, both setups (the display aRGB LUT and the camera filter card) is for inputting sRGB images ONLY and previewing in aRGB monitor. It is not for mixing aRGB and sRGB images. Then the proper way to test the results is by getting rid of the mask setup you have there in the card surface and loading the aRGB color card first, render - that's your reference. Then, load the sRGB color card - set up the LUT or the filter card and render. Then compare both results. This is what I get here:


https://s7.postimg.cc/46s04fgy3/LW2018comparisoncards.jpg

In order to use the mask as it's setup (but not used) in the color card surface, you would need to try another setup for mixing colorspaces. As commented, a way is by trying the shared aRGB-sRGB LUT within Surface Node Editor, ONLY for sRGB images. But the thing with that LUT is that it also compensates for sRGB and 2.2 gamma curve differences. So let's try another way.

This is my second little tut for LW 2018 :D

In order to work in sRGB space with an aRGB monitor by mixing images originated in both (aRGB and sRGB) colorspaces, just use the Camera Filter Card setup I shared previously. It's the same process so I won't repeat it here. Then:

- For every aRGB image in Image Editor, switch colorspace from sRGB to Linear. (aRGB curve for images is not sRGB curve but 2.2 gamma curve)


https://s7.postimg.cc/dfu6ed2mz/Image_Editsetup2.png

- Then in Editing tab, set the proper gamma linearization value in gamma parameter: 1/2.2


https://s7.postimg.cc/mav0oxovf/Image_Editsetup.png

- Finally in Surface Node Editor, use the attached matrix every time you use an aRGB image for building a shader or material.


https://s7.postimg.cc/ir92z5oqj/matrix.png

That's all. And as we can see, it's working:


https://s7.postimg.cc/6cmayvmyj/a_RGB2s_RGB.jpg
(it's not apparent but I'm using the mask here to separate original sRGB from transformed aRGB color patches)

Surprisingly, results match up better than what you got in Modo!

But, once again, same as with the LUT, the matrix is able to work in both directions. What this means? That we can go also from sRGB to aRGB. Of course since this is a simple matrix conversion you are gonna have the same issues than with OCIO, so out-of-gamut areas will be just clipped.

So for working in aRGB space with an aRGB monitor by mixing images originated in both (aRGB and sRGB) colorspaces, get rid of the camera filter card rig altogether and just use the sRGB preset (the v2015, not the incorrect v2018). Then:

- For every aRGB image in Image Editor, switch colorspace from sRGB to Linear. (notice sRGB images should keep sRGB curve correction).

- Then in Editing tab set the proper gamma linearization value in gamma parameter: 0.4545 for aRGB images ONLY.

- Finally in Surface Node Editor, use the attached matrix every time you use a sRGB image for building a shader or material, double click in the node and enable Inverse transform.


https://s7.postimg.cc/619fzl8ob/Inv_Matrix.png

That's all. this is the matching we got:


https://s7.postimg.cc/49gh4wf3f/s_RGB2a_RGB.jpg

We can notice results are a bit more contrasted because we are previewing with the sRGB curve instead of 2.2 gamma. If you want a 2.2 gamma preview just set up a gamma correction with the Camera Filter Card rig instead.

There are several issues with this approach though. You would need to do this for every single sRGB (or aRGB) texture, any time is used in any shader or material. As commented, it's possible, but not really efficient for production. There are other issues as well. In this case you are lucky sRGB and aRGB share same illuminant, but if your images would use other illuminants, then things would start to get a bit more complicated. Also if you use LUTs instead, you are at expense of the standard framework you are working with. So different types of colorspaces and image conditions, more complicated the setup. Now multiply this by the number of images and things start to get very tedious. I tried these solutions previously to SG_CCTools and it's not really production-viable with more complex projects of serious wingspan, but could be viable for simple projects - or for bit more complex projects and a lot of patience :)



Gerardo

p.s. attaching the 3 scenes externally because file surpasses the 5Mb forum limit. Curious how they look like in your MAC.
https://www.sendspace.com/file/monqky
p.p.s. forgot also to mention it's a good idea disabling all shadows options in the card object properties. Notice also the Camera Filter Card rig works faster with Non-Interpolated Radiosity in v2018.

rsfd
05-26-2018, 09:03 AM
Hello Gerardo,
thank you again for your time and efforts!


No, no. I think you are right. That's indeed possible and production viable within v2015 with third-party tools/CM systems (and even in previous versions before LW 10) and it's also possible in v2018, I think. The issue is, how to do it with only native tools and in an efficient way within v2018.
Thank you for clearifiying this.
And just to clear out any uncertainties: is it also possible to preserve the full range of AdobeRGB or are we speaking about a way to import aRGB images into a 3D application and then have these images match sRGB (a Gamut reduction in the end, what would somewhat useless in my opinion. So the whole idea of importing aRGB would be pointless at the end).


Your understanding is fine, but here's the knot of the rope. A transfer function, or more generally speaking, a tone reproduction curve, is only one single aspect (from the several ones) necessary to define color and it's the only property that LW CM system deals with. So LW "profiles" by default are very limited to be able to differentiate among linear versions of different colorspaces because it has no native tools to describe color properly.
Oh, I see. Seems I had „higher expectations” in that regard. I thought that the build-in transformations would be more precise, that i.e. a reference colorspace would be used (similar to L*a*b* in PS).


Not really. It is indeed possible in v2018, but once again, all depends on what you want to do. If you'd adopt the aRGB standard instead of sRGB standard, then things would be even easier for you, because your monitor is already aRGB, you would not have any issues previewing aRGB images directly and gamma linearization is 1/2.2. But if you want to mix different colorspaces like one is able in a CM-aware software, then things get complicated in LW2018. It's possible (as commented, it can be done in Surface Node Editor), but it's not efficient for production changing the color of 300 images one by one multiple times every time you need to use them in a shader or material. this is something that it's better solved at (Node) Image Editor level or even previously in v2018.
Problem with purely aRGB would be that ~100% of texture files (free and commercial) are in sRGB. So one would need to convert all of these to aRGB without getting any more (color) data in the end. It would be ok for any self-created imagery though.


Yes, only Win here and most of CM cases that I've seen are in PC platform and some few in MAC. But never heard before about the issue you are experienced, so I'm curious.
…seems I’m part of a really tiny user group: 3D on Mac, plus hardware calibrated WideGamut Display with AdobeRGB as target colorspace…


I've checked the scene and there are some few (but important) issues:
upps, think I should have added my „Scene Info Read Me File”…



- For some reason your camera filter object is not doing anything in the scene. So I just made a new one from scratch and it's working fine here after reloading the scene.
Scene starts with the „default” setup.
It is set up just for sRGB texture on aRGB Display.
The camera filter object is disabled in Scene Editor at this state, but visibility is set to Wireframe just as a reminder, that the object is in place.
(Would have probably been a better idea to just provide 2 scenes instead, sorry. A „Comment”-Node in Surface-Node-Editor would also probably be a useful addition, I guess).


- The scene is not using the aRGB-sRGB LUT I provided for the ColorSpaceConversion node needed in the camera filter card. It's set up as Linear. However you have included the LUT in the LUTs folder (it might be also v2018 in MAC has issues saving LUTs properly).
That’s the case indeed: The aRGB-sRGB LUT is mostly lost here, imported .icc files are always lost.
It worked somewhat better for the LUT after I copied it into the scene directory, but it seems that there are still issues with holding the connection to these files…


- The scene is using the aRGB LUT as display. This is wrong for the camera filter card setup as described in the little tut. Unless you are picking colors, let the display as linear there because you are compensating for previewing precisely with the camera filter card.
(As above: scene is not set up for the camera filter at the beginning.
Btw: is it ok to change CS-Settings in LW „on the fly”, or would it be better to change settings, save and close scene and application and then restart Layout and re-load the scene? I’m asking, as I sometimes had the impression that LW gets somewhat „confused” when the CS-settings within an opened scene are repeatedly changed).


As commented, both setups (the display aRGB LUT and the camera filter card) is for inputting sRGB images ONLY and previewing in aRGB monitor. It is not for mixing aRGB and sRGB images.
I think that this is most likely the point that I’ve misunderstood, as I interpreted your explanations according to my assumptions (which I unfortunately hadn’t made clear enough earlier - my fault, sorry).


Then the proper way to test the results is by getting rid of the mask setup you have there in the card surface and loading the aRGB color card first, render - that's your reference. Then, load the sRGB color card - set up the LUT or the filter card and render. Then compare both results.
All of your setups do work here as expected for the rendered images. The Matrix also seems to work better here as the other solutions btw.
But they do not influence VPR in the same way. VPR renders oversaturated colors with all setups.

I’ve posted at the Apple Support Forum to hopefully get a correct answer about the internals in regard of how untagged color values are send to Display (and if my assumptions are correct in that regard).
I doubt however that this issue will be fixed for LW-Mac in any way, as the affected user group is just too small.

As of now, I think my best option is to set the Display to the generic sRGB preset when working in LW (or Modo), as this gives me the best matching colors between VPR and Render Display.
If I choose the AdobeRGB generic preset for the Display and set LW CS Display to aRGB, then I need to set Render Display Window to sRGB for Display to get matching colors.

jwiede
05-26-2018, 06:05 PM
Gerard, I just had a quick sidebar question to a small pt in the current discussion: Have you heard anything back from Newtek about fixing the 2018 CS settings for picked & lights? At this point, I get the impression you're the only one they'll listen to regarding this problem.

gerardstrada
05-27-2018, 10:33 PM
Thank you for clearifiying this.
And just to clear out any uncertainties: is it also possible to preserve the full range of AdobeRGB...
Yes, it's possible.


or are we speaking about a way to import aRGB images into a 3D application and then have these images match sRGB (a Gamut reduction in the end, what would somewhat useless in my opinion. So the whole idea of importing aRGB would be pointless at the end).
As commented, it has no sense to clip gamut by working in sRGB range.


Oh, I see. Seems I had „higher expectations” in that regard. I thought that the build-in transformations would be more precise, that i.e. a reference colorspace would be used (similar to L*a*b* in PS).
Well, at least in the transfer function aspect, transformation is precise with sRGB curve (some 3D packages don't even have this correctly set up). Guess you might refer to some connection color model. Just in case, the XYZ "space" is a matrix transformation that assumes sRGB standard as well.


Problem with purely aRGB would be that ~100% of texture files (free and commercial) are in sRGB. So one would need to convert all of these to aRGB without getting any more (color) data in the end. It would be ok for any self-created imagery though.
Well, that's the case if software does not perform actual gamut mapping but just "gamut projections", like happens with utility colorspaces in OCIO.


Btw: is it ok to change CS-Settings in LW „on the fly”, or would it be better to change settings, save and close scene and application and then restart Layout and re-load the scene? I’m asking, as I sometimes had the impression that LW gets somewhat „confused” when the CS-settings within an opened scene are repeatedly changed).
I had no issues here loading scenes with custom CS settings. I mean, no need to closing the scene and reloading.


All of your setups do work here as expected for the rendered images. The Matrix also seems to work better here as the other solutions btw.
But they do not influence VPR in the same way. VPR renders oversaturated colors with all setups.
As far as I understand you are saying that final renders (F9) look correct but VPR looks incorrect, right? That sounds like a mismatch between final render and VPR in MAC, which according to documentation they are the same in v2018. That sounds like a bug to me. Could you specify which of the 3 scenes saturates and which saturates more? or all saturates the same now? Because the aRGB-LW2018-colorpatch-matrix.lws does not use ANY camera filter or LUT, just the common sRGB curve applied in CS settings and the matrix correction is made at Surface level, so at least this scene should look correct in VPR (if it indeed works the same as the final render in MAC). Just out of curiosity, could you please make some print-screens of VPR window of the 3 scenes, go to PS, paste, assign your monitor profile, save as JPEG by checking the profile, just to check something here :)


I’ve posted at the Apple Support Forum to hopefully get a correct answer about the internals in regard of how untagged color values are send to Display (and if my assumptions are correct in that regard).
I've seen many display issues originated in the way the display calibration is managed in the system. Just in case, check if there's no double managed profile, at OS level, at videocard level or at display/calibration software level. As rule of thumb, we have to pick only a single level to perform the display management. When this is made at multiple levels, calibrations may concatenate and do wacky things with colors sent to display.


--- o ---



Gerard, I just had a quick sidebar question to a small pt in the current discussion: Have you heard anything back from Newtek about fixing the 2018 CS settings for picked & lights? At this point, I get the impression you're the only one they'll listen to regarding this problem.
Frankly not, John. Do you know if someone using v2018 has reported the bug formally?



Gerardo

jwiede
05-27-2018, 10:47 PM
Frankly not, John. Do you know if someone using v2018 has reported the bug formally?

No idea, but suggest you do so, as you likely carry more weight than others on that topic/issue. I'll be happy to help if needed.

gerardstrada
05-28-2018, 03:16 PM
Probably, but really not using v2018 here yet. The bug it's very simple to fix by just re-saving the correct preset, but what really worries it's not the bug by itself but the statement that it was a bug "by design" and the subsequent implications.



Gerardo

rsfd
05-29-2018, 04:26 AM
Hello Gerardo,

thank you again for time and patience, really don’t want to overtax you.


…As far as I understand you are saying that final renders (F9) look correct but VPR looks incorrect, right?
It seems I need to take that back: in your scenes, VPR and F9 do match. It might have been a wrong setting in Image Viewer’s Display Color Space (but I haven’t saved various scenes, I just have used one single scene and constantly altered the settings).
Colors show up oversaturated though both in VPR and Render Image Viewer (compared to the original texture files and of course to the original (physical) colorchecker card).
A side-note: Render Status Window is showing colors as I would expect them (closest match to the used sRGB colorcard texture).
That’s why I assumed that it has to do with the internals of either LW and/or OSX: to me, Render Status Window seems to be the only window that undergoes some sort of colormanagement, it seems the only window to „respect” the Display profile.


That sounds like a mismatch between final render and VPR in MAC, which according to documentation they are the same in v2018. That sounds like a bug to me.
(This is why I assumed that there is something going on at the OS level or similar).

As I’m loosing a bit of self-confidence actuallly, I think I need to reassure some basics:
The CS preference for the applied color space to Display should be the same as the one set in Image Viewer, right?

If that’s the case indeed, then using the (v2015) sRGB setup with the sRGB colorcard-texture, but the aRGB-LUT for „Display”, colors turn out differently in all 3 states: VPR, Render Status and Render Image View.

* For VPR, the aRGB-LUT has nearly no effect compared to the default sRGB Display Preference (colors are just a very little touch less blueish). The oversaturation remains.

* Render Status shows the best match to the original sRGB texture file’s colors.

* With the aRGB-LUT for Render Image Viewer, colors are more saturated as in Render Status, but far better then in VPR. If I use sRGB for „Display” colorspace in the Render Image Viewer, colors match with VPR (but fall back to the oversaturated state).


Could you specify which of the 3 scenes saturates and which saturates more? or all saturates the same now?
Of course:
„LW2018-colorpatch” and „LW2018-colorpatch-matrix” both show massively oversaturated colors.
„aRGB-LW2018-colorpatch-matrix” offers the best color rendition onscreen.
Colors are still somewhat oversaturated, but it’s by far the best match to the original texture.

Everything always compared of course to the „expected color rendition”, that is to say: always compared to the original texture file’s (as seen i.e. in Photoshop) and the (physical) colorchecker card’s colors.


Because the aRGB-LW2018-colorpatch-matrix.lws does not use ANY camera filter or LUT, just the common sRGB curve applied in CS settings and the matrix correction is made at Surface level, so at least this scene should look correct in VPR (if it indeed works the same as the final render in MAC).
This is indeed the scene that comes up with the best color rendition in VPR.


Just out of curiosity, could you please make some print-screens of VPR window of the 3 scenes, go to PS, paste, assign your monitor profile, save as JPEG by checking the profile, just to check something here :)
I attached 3 screensgrabs, but I need to explain a bit (as screengrabs are probably handled differently in OSX).
In OSX, there are 2 ways to do screengrabs with the tools supplied by the OS:
One can use the „Grap.app” which results in sRGB screenshots (thus they don’t show the oversaturation even on the WideGamut Display here).
Or one uses the OS-keyboard-shortcuts for screengrabs, then the Display’s profile is embedded.
I used this latter method for the attached screengrabs (and just needed to shrink them down from default .png to usable .jpg.
Actual Display profile is v4, but I had checked every setup with a v2 Display profile and haven’t found any differences (so I reverted to the v4 one).


I've seen many display issues originated in the way the display calibration is managed in the system. Just in case, check if there's no double managed profile, at OS level, at videocard level or at display/calibration software level. As rule of thumb, we have to pick only a single level to perform the display management. When this is made at multiple levels, calibrations may concatenate and do wacky things with colors sent to display.
Calibrating a Display usually is a pretty straight routine in OSX.
(Although I now wouldn’t even exclude me from doing something wrong).
I’m using a hardware calibrated EIZO Display with EIZO’s ColorNavigator 6 software.
It’s basically starting the software, plugging in the colorimeter, choosing the profiling target, run the calibration and accept the created profile. The profile is saved at the system level, so that it is accessible for all user accounts and it’s automatically set as default Display profile. (There are no videocard settings to manage - althought I have to admit that I’m using a PC-GPU in my MacPro. This is no issue in all other applications, so I wouldn’t necessarily expect LW to behave completely different. I can test against the old original (Mac-)GPU, but this would need to wait until weekend).

¬Roger

141880141881141882

gerardstrada
05-31-2018, 08:06 PM
Hello Gerardo,
thank you again for time and patience, really don’t want to overtax you.
No problem Roger, I enjoy this type of cases and really curious what's happening in your case. I'm aware the solutions I've provided actually work for PC platform. What I'm trying to do first is discard if the issue originates in the 3d package, because that's commonly the case.



It seems I need to take that back: in your scenes, VPR and F9 do match. It might have been a wrong setting in Image Viewer’s Display Color Space (but I haven’t saved various scenes, I just have used one single scene and constantly altered the settings).
Colors show up oversaturated though both in VPR and Render Image Viewer (compared to the original texture files and of course to the original (physical) colorchecker card).
A side-note: Render Status Window is showing colors as I would expect them (closest match to the used sRGB colorcard texture).
That’s why I assumed that it has to do with the internals of either LW and/or OSX: to me, Render Status Window seems to be the only window that undergoes some sort of colormanagement, it seems the only window to „respect” the Display profile.
(This is why I assumed that there is something going on at the OS level or similar).
Examining your images, think I've found the reason why you are seeing wrong colors.


As I’m loosing a bit of self-confidence actuallly, I think I need to reassure some basics
Don't worry, you are doing things right. Forget about the aRGB.cube LUT, it won't work as you are expecting because your monitor is not quite aRGB, which is good news!


Of course:
„LW2018-colorpatch” and „LW2018-colorpatch-matrix” both show massively oversaturated colors.
„aRGB-LW2018-colorpatch-matrix” offers the best color rendition onscreen.
Colors are still somewhat oversaturated, but it’s by far the best match to the original texture.
Everything always compared of course to the „expected color rendition”, that is to say: always compared to the original texture file’s (as seen i.e. in Photoshop) and the (physical) colorchecker card’s colors.
Ok. First, these two scenes use a LUT called aRGB-sRGB.cube. All times I loaded the scenes, it was from the same USB folder. But today I loaded from another USB port and surprise, got this result:


https://s22.postimg.cc/m0ywgy6xd/missed_LUT.jpg

Instead of this one that I always get:


https://s22.postimg.cc/gqtxpbuap/with_LUT.jpg

The reason? The aRGB-sRGB.cube LUT was missed and LW was using a linear conversion instead. Just like you have described that happens in your in MAC. When assigning your monitor profile to the result without the proper LUT, I get exactly same results than yours:


https://s22.postimg.cc/rqf513shd/missed_LUTmonitapplied.jpg

Then, can you check please when loading LW2018-colorpatch.lws and the LW2018-colorpatch-matrix.lws that this ColorSpaceConversion node has the aRGB-sRGB.cube assigned?


https://s22.postimg.cc/ge2jjdwo1/LUTassigned.png

I think the LUT should be missed and you'll have to assign it by hand and re-save the scenes again in order they work as expected. Now, if everything goes well, you'll see these results with your monitor profile:


https://s22.postimg.cc/x1u1lxovl/with_LUTmonitprof.jpg

Which are practically the same results you get with aRGB-LW2018-colorpatch-matrix.lws when you say:


This is indeed the scene that comes up with the best color rendition in VPR.

It's near, but still a bit saturated. Why? (and this is where your monitor profile characteristics becomes relevant), your monitor profile is not actually aRGB range, its gamut is overall wider. See:


https://s22.postimg.cc/y5e5xqowh/2_Dgamut.png

The bigger gamut plot is from your monitor. There are some few dark colors not covered:


https://s22.postimg.cc/5sio7bdgx/gamutbottom.png

but most of its gamut volume is bigger than aRGB:


https://s22.postimg.cc/nikcsew7l/gamuttop.png

This is good news for you because you are able to see more color range, but it also means that even if you work in aRGB range, when working with LW, Modo, Blender, etc. you'll see more saturated colors because aRGB colors are sent directly to your monitor. In order to see the right colors, you'll need a color proof setup. This is where SG_CCTools makes things a lot easier. Ideally you could just use your ICC profile directly with the LW2018-colorpatch-Proof.lws scene I'm attaching, but you'll get a pink colorcast if doing so in LW CS panel.

So another way to go is like in the attached LW2018-colorpatch-Proof.lws scene, where I collapsed the color proof concatenation in a LUT. Then, be sure the LUT toMonitor.cube is setup in the camera filter card surface.


https://s22.postimg.cc/hue21mmr5/tomonitor.png

The result is like this:


https://s22.postimg.cc/eotgb0yvl/tomonitor.jpg

The other way to go is just delete the camera filter card object and use the attached Monitor.cube LUT as display LUT instead in CS panel. For some reason the LUT shows very inaccurate in VPR in v2018 but shows fine in final render. Remember these 2 LUTs are lo-res LUTs but results should be good enough as to give you a good match to the ICC profile. The toMonitor.cube is about 700 kb, but the Monitor.cube is about 5 Mb because it goes from linear to sRGB curve and needs double resolution. Once again, using the actual profile would be ideal.

Please do let me know if it's working as expected there.



Gerardo

p.s. attached scene and LUTs:
https://www.sendspace.com/file/htgpzy

rsfd
06-04-2018, 01:40 AM
Hello Gerardo,


No problem Roger, I enjoy this type of cases and really curious what's happening in your case.
:)
Guess these are my lucky days! Again: Thank you very much for your support!


I'm aware the solutions I've provided actually work for PC platform. What I'm trying to do first is discard if the issue originates in the 3d package, because that's commonly the case.
As I stated earlier, there is a similar issue in Modo 90x, which I found not to be present on Windows. Hence my idea that the internal color management on OS level and the way OCIO works might also have an influence.


Don't worry, you are doing things right. Forget about the aRGB.cube LUT, it won't work as you are expecting because your monitor is not quite aRGB, which is good news!
It’s „officially” a 99,8% AdobeRGB Display (because the Gamut does not fully encompass aRGB in the „blueish area”). But I thought that aRGB should give me at least a better color representation as the default sRGB setup. (And as you already stated, the other colorspaces are targeted at the movie industry).


The reason? The aRGB-sRGB.cube LUT was missed and LW was using a linear conversion instead. …
I can confirm this issue. This happens here all the time: the conversion LUT was never loaded when I re-opened a scene later on. Same goes for any .icc file for CS-Display: these were also always lost.
Every time I needed to check and re-load these files into the scene(s) and then re-assign them appropriately. Not quite a useful behaviour.
(Should be fixed by NT as it is a constant source of errors).


Then, can you check please when loading LW2018-colorpatch.lws and the LW2018-colorpatch-matrix.lws that this ColorSpaceConversion node has the aRGB-sRGB.cube assigned?
(Had done so every time).


Which are practically the same results you get with aRGB-LW2018-colorpatch-matrix.lws when you say:
Yes they are. (see attachements)


It's near, but still a bit saturated. Why? (and this is where your monitor profile characteristics becomes relevant), your monitor profile is not actually aRGB range, its gamut is overall wider.
This makes sense.
(I hadn’t expected that the Gamut difference to aRGB would be so noticable though).


This is good news for you because you are able to see more color range, but it also means that even if you work in aRGB range, when working with LW, Modo, Blender, etc. you'll see more saturated colors because aRGB colors are sent directly to your monitor.
Does this mean that I was right in thinking that there is no color management happening in regard of respecting a certain colorspace?
So 255-0-0 (1-0-0) just turns out as maximum red of the Display’s Gamut, instead of maximum sRGB or aRGB red?
I still wonder why this issue can’t be replicated on a Windows machine, even with a Wide Gamut Display. (I’m referring to the test that I made in Modo on a colleagues Windows computer. And I think that this should be a OS issue. Unfortunately, there still are no responses to my question on the Apple forum. Found some tech notes at the apple.developers site, but they all „just” describe techniques how colormanagement can be introduced into applications, which frameworks are available and how they can be implemented. But no info about how OSX handles color values that come completely „raw/untagged” {which is still my best explanation for this issue especially for VPR}).


In order to see the right colors, you'll need a color proof setup. This is where SG_CCTools makes things a lot easier.
This could have been a nice addition to LW in the case that NewTek would have adopted these tools platform independantly. (But as I stated earlier, I don’t expect a Mac-version anymore, still don’t want to switch platform or take up again working with the „Bootcamp”-option).


Ideally you could just use your ICC profile directly with the LW2018-colorpatch-Proof.lws scene I'm attaching, but you'll get a pink colorcast if doing so in LW CS panel.
That’s what I have thought also. I was happy when LW loaded the .icc (v2) profile, but besides the colorcast issue there is also the „.icc profile always lost”-issue.
And colors come out oversaturated both in VPR and F9, so this seems not even be the help I thougth it would be (at least on LW-Mac - see attachements).


So another way to go is like in the attached LW2018-colorpatch-Proof.lws scene, where I collapsed the color proof concatenation in a LUT. Then, be sure the LUT toMonitor.cube is setup in the camera filter card surface.
This works pretty good.
(Just to reassure, as first ColorConversion-Node was set to „Linear”:
It must be set to sRGB, right? So:
CamCard: RayTrace > colconv1:Apply „sRGB” > colconv2:Apply „toMonitor”).



The other way to go is just delete the camera filter card object and use the attached Monitor.cube LUT as display LUT instead in CS panel. For some reason the LUT shows very inaccurate in VPR in v2018 but shows fine in final render. Remember these 2 LUTs are lo-res LUTs but results should be good enough as to give you a good match to the ICC profile. The toMonitor.cube is about 700 kb, but the Monitor.cube is about 5 Mb because it goes from linear to sRGB curve and needs double resolution.
This one shows a pretty interesting result:
All viewports now come up with a greenish colorcast (minor issue of course), but VPR is still strongly oversaturated.
Render Status Window comes out with lesser saturation, but F9 shows quite a good color rendition.

Now this leads to the question, why all 3 windows come up with different color rendition.
If I understand you correctly, VPR and F9 also come up with different color rendition on Windows-platform?
Still I wonder, what causes these differences.
The result here seems to me as if VPR does not respect the Monitor.LUT file, while Render Image Viewer does. And Render Status Window obviously uses a 3rd way to send color values to screen.
Might be a bug? (Or it is done intentionally to keep VPR as fast as possible -while the small group of users of „WiderThenSRGB”-Displays are in trouble).


Once again, using the actual profile would be ideal.
Well, seeing how complicated things can turn out, I can only fully agree here ;)
Just as a side-question: how are you creating these LUT files? Are you using some compositing application or true (prepress) colormanagement/profiling software?


Please do let me know if it's working as expected there.
With pleasure!
Attached are the results of all four setups, including VPR, Render Status and F9. (All screengrabs have my Display’s profile embedded).

LW2018-colorpatch:
slight oversaturation, VPR=F9

LW2018-colorpatch-Matrix:
as LW2018-colorpatch

LW2018-colorpatch-Proof (Monitor.cube LUT):
VPR oversaturated, F9 good color rendition, VPR≠F9

LW2018-colorpatch-Proof (toMonitor LUT):
imo best result, VPR=F9

LW2018-colorpatch (with a v2 .icc Profile in CS):
Oversaturation and colorcast, VPR=F9


¬Roger

141921141922141923141924141925

gerardstrada
06-07-2018, 01:34 AM
As I stated earlier, there is a similar issue in Modo 90x, which I found not to be present on Windows. Hence my idea that the internal color management on OS level and the way OCIO works might also have an influence.
Hello Roger,

That's a possibility, but I still think the issue originates in the 3D package, since it seems you get correct results from PS CS6, right? If monitor profile is well set up in the OS, PS performs color proofing to monitor by default, thing that nor LW, Modo or Blender (and no other 3D package for that matter) set up by default.


It’s „officially” a 99,8% AdobeRGB Display (because the Gamut does not fully encompass aRGB in the „blueish area”). But I thought that aRGB should give me at least a better color representation as the default sRGB setup. (And as you already stated, the other colorspaces are targeted at the movie industry).
Yes, what happens is that the nature of a color gamut is three-dimensional (chromaticities and lightness/luminance) and they may have very different shapes. So even when your monitor's gamut almost encompass whole aRGB gamut, it surpasses this gamut by quite a bit as well. I mean, there are areas of your monitor's gamut (mostly all very bright colors) not covered by aRGB gamut. Your monitor gamut covers 122.853% more colors than aRGB gamut. And these are real (non-imaginary) colors.


I can confirm this issue. This happens here all the time: the conversion LUT was never loaded when I re-opened a scene later on. Same goes for any .icc file for CS-Display: these were also always lost.
Every time I needed to check and re-load these files into the scene(s) and then re-assign them appropriately. Not quite a useful behaviour.
(Should be fixed by NT as it is a constant source of errors).
Totally agree. Even using "Color Tables" folder in scene content directory is not solving the issue. Looks like a v2018 bug as you say.


(Had done so every time).
Good!


Yes they are. (see attachements)
Great!


This makes sense.
(I hadn’t expected that the Gamut difference to aRGB would be so noticable though).
Yes, almost 123% of more colors is something significant.


Does this mean that I was right in thinking that there is no color management happening in regard of respecting a certain colorspace?
Yes.


So 255-0-0 (1-0-0) just turns out as maximum red of the Display’s Gamut, instead of maximum sRGB or aRGB red?
Indeed!


I still wonder why this issue can’t be replicated on a Windows machine, even with a Wide Gamut Display. (I’m referring to the test that I made in Modo on a colleagues Windows computer. And I think that this should be a OS issue. Unfortunately, there still are no responses to my question on the Apple forum. Found some tech notes at the apple.developers site, but they all „just” describe techniques how colormanagement can be introduced into applications, which frameworks are available and how they can be implemented. But no info about how OSX handles color values that come completely „raw/untagged” {which is still my best explanation for this issue especially for VPR}).
I have the idea the Windows machine you refer is using an aRGB-range monitor that hasn't got a gamut as wide as your monitor's one. It might be also that the monitor on PC is fitting more closely to aRGB-range. Consider also some D65 wide-gamut range monitors are able to limit their own gamut to sRGB, NTSC or aRGB standard ranges at hardware level.


This could have been a nice addition to LW in the case that NewTek would have adopted these tools platform independantly. (But as I stated earlier, I don’t expect a Mac-version anymore, still don’t want to switch platform or take up again working with the „Bootcamp”-option).
I understand your point.


That’s what I have thought also. I was happy when LW loaded the .icc (v2) profile, but besides the colorcast issue there is also the „.icc profile always lost”-issue.
And colors come out oversaturated both in VPR and F9, so this seems not even be the help I thougth it would be (at least on LW-Mac - see attachements).
I see. Render Status seems to provide same saturation than Monitor.cube LUT.


This works pretty good.
(Just to reassure, as first ColorConversion-Node was set to „Linear”:
It must be set to sRGB, right? So:
CamCard: RayTrace > colconv1:Apply „sRGB” > colconv2:Apply „toMonitor”).
Yep. Good to hear it's working fine!



This one shows a pretty interesting result:
All viewports now come up with a greenish colorcast (minor issue of course), but VPR is still strongly oversaturated.
Render Status Window comes out with lesser saturation, but F9 shows quite a good color rendition.
Can't see the greenish colorcast here (probably it get lost when converting to sRGB). Also, Render Status and Image Viewer look equal. VPR is oversaturated as expected.


Now this leads to the question, why all 3 windows come up with different color rendition.
They look like bugs. hope they are not "by design".


If I understand you correctly, VPR and F9 also come up with different color rendition on Windows-platform?
Still I wonder, what causes these differences.
The result here seems to me as if VPR does not respect the Monitor.LUT file, while Render Image Viewer does. And Render Status Window obviously uses a 3rd way to send color values to screen.
Might be a bug? (Or it is done intentionally to keep VPR as fast as possible -while the small group of users of „WiderThenSRGB”-Displays are in trouble).
Yes, VPR and Image Viewer also render differently on Windows. I have the idea it's the same as the Viper issue I commented here:

http://forums.newtek.com/showthread.php?155269-Photorealism-and-expanding-the-dynamic-range-in-LW&p=1528251&viewfull=1#post1528251

specifically the part: "which makes me think VIPER displays 1Dx3 LUTs instead of 3D LUTs." (sorry none of my images can be seen now because image server changed its domain from .org to .cc and most of my old posts are screwed up) but the point there was that Viper preview seems to interpret 3D LUTs as 3x1D LUTs instead, as you can see here when using a False Color profile to check exposed areas:


https://s7.postimg.cc/421vv004r/FCin_VIPER.jpg https://s7.postimg.cc/vcn72vdbf/FCin_V.jpg

I thought this could be due to a RT-preview speed reason but thinking twice it should not be in that way (just see any compositing package out there). Anyway, it seems VPR is suffering from the same "feature". But what I find not so funny is that Render Status window also renders differently in MAC (!) In PC Render Status looks the same as Image Viewer. Yes, this sounds like another bug in V2018, it would be an idea to report it if you have upgraded.


Well, seeing how complicated things can turn out, I can only fully agree here ;)
I have the idea is a mismatch with the illuminant of the XYZ model they are using that needs to be compensated for interpreting ICC profiles correctly.


Just as a side-question: how are you creating these LUT files? Are you using some compositing application or true (prepress) colormanagement/profiling software?
Yes, since these are just display LUTs any compositing package will do the work as well. PS CC version is able also to built this kind of LUTs.


With pleasure!
Attached are the results of all four setups, including VPR, Render Status and F9. (All screengrabs have my Display’s profile embedded).
Thanks! very interesting tests! btw, what viewer (from LW2018-colorpatch-Proof [toMonitor LUT]) scene would you say is more similar to what you see in let's say, PS?



Gerardo

rsfd
06-10-2018, 03:33 PM
Hello Gerardo,


That's a possibility, but I still think the issue originates in the 3D package, since it seems you get correct results from PS CS6, right? If monitor profile is well set up in the OS, PS performs color proofing to monitor by default, thing that nor LW, Modo or Blender (and no other 3D package for that matter) set up by default.
Yes, totally agree.
It’s just the fact, that VPR, Render Status and F9 are displaying different colours with certain setups, which makes me think that this might have something to do with the way colour values are send to the Display and how these values are handled internally.
VPR (and Modo Previewer and most likely other RT-Previewers too) seems -at least to me- to be a different type of window, it seems like some sort of „raw” output (most likely for speed reasons) while Render Status and F9 is more a „Standard-OS-Window”.
And if OSX still behaves as it did in Classic OS times, untagged colour values would be send into the Display’s profile colours.
(Mac OS only managed colours when they were tagged with the according colorspace they originated in). To my knowledge, Windows assumes untagged colour values as originating in sRGB which would explain why I cannot replicate this issue in Modo on the collegue’s computer.
There is still no response to my question at the Apple Forum, so still no info about what has possibly been changed in OSX ColorSync (except the switch from default Gamma 1.8 to 2.2) during the last couple of OS upgrades.


Yes, what happens is that the nature of a color gamut is three-dimensional (chromaticities and lightness/luminance) and they may have very different shapes. So even when your monitor's gamut almost encompass whole aRGB gamut, it surpasses this gamut by quite a bit as well. I mean, there are areas of your monitor's gamut (mostly all very bright colors) not covered by aRGB gamut. Your monitor gamut covers 122.853% more colors than aRGB gamut. And these are real (non-imaginary) colors.
Didn’t expect that it is that wide. (Thank you for that info, it wasn’t made that clear in the test that I had read before I bought this Display at that time).


Totally agree. Even using "Color Tables" folder in scene content directory is not solving the issue. Looks like a v2018 bug as you say.
Will prepare some reports, I guess…


I have the idea the Windows machine you refer is using an aRGB-range monitor that hasn't got a gamut as wide as your monitor's one. It might be also that the monitor on PC is fitting more closely to aRGB-range. Consider also some D65 wide-gamut range monitors are able to limit their own gamut to sRGB, NTSC or aRGB standard ranges at hardware level.
You are correct on that one: I’ve done some research on his Display and -even it is a „higher end” Display as mine- it’s Gamut is smaller indeed. But he exclusivly works with the default sRGB setups that are available in his 3D packages and the oversaturation issue cannot be replicated. Thus my idea it has something to do with Windows assuming sRGB for untagged colour values.
(I’m aware of the possibility to limit a Monitor’s Gamut to the factory presets for sRGB or aRGB and this does render „better” colours here of course, but it’s also a bit of a cumbersome workflow, as one would constantly need to switch the presets as one switches from a 3D package to a truly color managed application).


Can't see the greenish colorcast here (probably it get lost when converting to sRGB). Also, Render Status and Image Viewer look equal. VPR is oversaturated as expected.
Oh, sorry, my description obviously wasn’t clear enough: the greenish colorcast does not affect the rendered colours, it only affects the Background colour of the 3D-viewports (so it might affect OpenGL probably).


They look like bugs. hope they are not "by design".
This is a point where I assume it has to do with the OS (and that no extra work is done to tackle OSX specific features).


Yes, VPR and Image Viewer also render differently on Windows. I have the idea it's the same as the Viper issue I commented here:
http://forums.newtek.com/showthread.php?155269-Photorealism-and-expanding-the-dynamic-range-in-LW&p=1528251&viewfull=1#post1528251
specifically the part: "which makes me think VIPER displays 1Dx3 LUTs instead of 3D LUTs." (sorry none of my images can be seen now because image server changed its domain from .org to .cc and most of my old posts are screwed up) but the point there was that Viper preview seems to interpret 3D LUTs as 3x1D LUTs instead, as you can see here when using a False Color profile to check exposed areas:
Well, this is beyond my capabilities, but I see the issue. ;)


I thought this could be due to a RT-preview speed reason but thinking twice it should not be in that way (just see any compositing package out there). Anyway, it seems VPR is suffering from the same "feature". But what I find not so funny is that Render Status window also renders differently in MAC (!) In PC Render Status looks the same as Image Viewer. Yes, this sounds like another bug in V2018, it would be an idea to report it if you have upgraded.
Yes, depending on the setup used it’s either VPR and F9 or Render Status and F9 which are displaying the same colours.
Ideally, all 3 should output the same colours to Display, but at least VPR and F9 should be displaying equal (and usable) colours (even on aRGB/Wide Gamut Displays).
I will surely prepare some report on this.


I have the idea is a mismatch with the illuminant of the XYZ model they are using that needs to be compensated for interpreting ICC profiles correctly.
Correct support for icc profiles would be very nice. I’ll do a report on that one too.


Yes, since these are just display LUTs any compositing package will do the work as well. PS CC version is able also to built this kind of LUTs.
I’m not a software subscription fan, so I hadn’t upgraded PS for a while. Instead I started with Affinity Photo, but though there are some nice points in there, there are several points that I’ve found not so great, so I probably will enter the "subscription zone" while grinding my teeths.


Thanks! very interesting tests! btw, what viewer (from LW2018-colorpatch-Proof [toMonitor LUT]) scene would you say is more similar to what you see in let's say, PS?
For the „toMonitor LUT” setup, I find VPR and F9 the best match to the original sRGB texture in PS. RenderStatus here comes out with more desaturated colours. This setup offers the best solution to me.

Funnily, if VPR and F9 would only behave the same as Render Status Window in the default sRGB setup, this issue would be non-existant, as Render Status renders pretty good colours then. (> attachement)

This was really interesting, thank you so much again for offering your knowledge, time and patience!

¬Roger

141956

jwiede
06-10-2018, 07:36 PM
I'd just be happy if we could get the CS presets to properly handle picked and light colors again. Obviously, those issues you two have discussed also need priority fixes, don't get me wrong. I just worry that if the case can't be adequately made for fixing the CS presets, the chances of the others getting fixed seems even lower.

gerardstrada
06-14-2018, 02:56 PM
Hello Gerardo,
Yes, totally agree.
It’s just the fact, that VPR, Render Status and F9 are displaying different colours with certain setups, which makes me think that this might have something to do with the way colour values are send to the Display and how these values are handled internally.
VPR (and Modo Previewer and most likely other RT-Previewers too) seems -at least to me- to be a different type of window, it seems like some sort of „raw” output (most likely for speed reasons) while Render Status and F9 is more a „Standard-OS-Window”.
And if OSX still behaves as it did in Classic OS times, untagged colour values would be send into the Display’s profile colours.
(Mac OS only managed colours when they were tagged with the according colorspace they originated in). To my knowledge, Windows assumes untagged colour values as originating in sRGB which would explain why I cannot replicate this issue in Modo on the collegue’s computer.
There is still no response to my question at the Apple Forum, so still no info about what has possibly been changed in OSX ColorSync (except the switch from default Gamma 1.8 to 2.2) during the last couple of OS upgrades.
Hello Roger,

Indeed! VPR, Render Status and Image Viewer should display same results. At least in Windows, this is what happens with Render status and Image Viewer, but not in VPR (v2018/2015) and Viper (v2015-LW10). One would argue it's due to speed reasons but see how this works in compositing packages even when using 3D renderers in them. Ideally all viewers should display same results.

In the case of Windows, it sends non-managed color values directly to monitor by using whatever profile is set up as display profile in the OS. By default, it installs a sRGB profile until the user installs monitor drivers with its respective generic profile or set up a calibrated one.


You are correct on that one: I’ve done some research on his Display and -even it is a „higher end” Display as mine- it’s Gamut is smaller indeed. But he exclusivly works with the default sRGB setups that are available in his 3D packages and the oversaturation issue cannot be replicated. Thus my idea it has something to do with Windows assuming sRGB for untagged colour values.
Well, here in PC, any wide gamut monitor displays also oversaturated results with any software not able to proofing colors to monitor. Just like happens in MAC. Though in LW, without the RenderStatus/ImageViewer bug. So if your friend works with the default sRGB setups having a wide gamut monitor and he's displaying correct colors, then either his monitor is conforming (at hardware or at OS level) to sRGB standard by limiting its original gamut, or is using some kind of window color-proofing app (which would imply an external CM system). I have the idea it's the former.


(I’m aware of the possibility to limit a Monitor’s Gamut to the factory presets for sRGB or aRGB and this does render „better” colours here of course, but it’s also a bit of a cumbersome workflow, as one would constantly need to switch the presets as one switches from a 3D package to a truly color managed application).
If I remember well, there was an app for a free CM Linux system (think it was called CompICC) able to color manage portions of the screen or apps' windows. It was designed precisely for wide gamut monitors. So you could select any unaware-CM app window and color manage it externally. Maybe it might be something similar for MAC.


Oh, sorry, my description obviously wasn’t clear enough: the greenish colorcast does not affect the rendered colours, it only affects the Background colour of the 3D-viewports (so it might affect OpenGL probably).
Yes. That's because the BG color is not completely grey.


This is a point where I assume it has to do with the OS (and that no extra work is done to tackle OSX specific features).
It seems those are LW2018 bugs in MAC, at least in the VPR and Image Viewer cases ...considering RenderStatus seems to display correct colors there.


Yes, depending on the setup used it’s either VPR and F9 or Render Status and F9 which are displaying the same colours.
Ideally, all 3 should output the same colours to Display, but at least VPR and F9 should be displaying equal (and usable) colours (even on aRGB/Wide Gamut Displays).
I will surely prepare some report on this.
In PC, RenderStatus and ImageViewer display same correct results. The issue is with VPR and VIPER which might be due to speed reasons as you said. Curiously, this doesn't happen in v2015 when using VIPER and ICC corrections in DP NIF. It only happens with LUTs used as display.


Correct support for icc profiles would be very nice. I’ll do a report on that one too.
Good luck on that one.


I’m not a software subscription fan, so I hadn’t upgraded PS for a while. Instead I started with Affinity Photo, but though there are some nice points in there, there are several points that I’ve found not so great, so I probably will enter the "subscription zone" while grinding my teeths.
Well, you can use also free options like Fusion, DisplayCAL's LUTMaker, LUTGenerator, etc.


For the „toMonitor LUT” setup, I find VPR and F9 the best match to the original sRGB texture in PS. RenderStatus here comes out with more desaturated colours. This setup offers the best solution to me.
Funnily, if VPR and F9 would only behave the same as Render Status Window in the default sRGB setup, this issue would be non-existant, as Render Status renders pretty good colours then. (> attachement)
hmmm... that's interesting. Just in case, you can match VPR and ImageViewer results in RenderStatus by placing the to_Monitor LUT first in the chain instead - before the sRGB conversion. So if you ask me, I'd say RenderStatus is the window in MAC providing the correct display.



This was really interesting, thank you so much again for offering your knowledge, time and patience!
Glad to help a bit!


--- o ---



I'd just be happy if we could get the CS presets to properly handle picked and light colors again. Obviously, those issues you two have discussed also need priority fixes, don't get me wrong. I just worry that if the case can't be adequately made for fixing the CS presets, the chances of the others getting fixed seems even lower.
I agree, having multiple inconsistent displays in MAC is clearly a bug. Well, v2018 sRGB preset is clearly a bug too. In case they are planning to implement OCIO, just hope they don't copy what other 3D packages are doing, which is commonly incomplete or limited, or in other cases even incorrect.



Gerardo

rsfd
07-03-2018, 09:43 AM
Hello Gerardo,

apologies for this very late reply, I’ve had (and still have) some troubles here which clamped (and clamp) me completely…


…Well, here in PC, any wide gamut monitor displays also oversaturated results with any software not able to proofing colors to monitor. …
Oh, I see, this is new to me.


…So if your friend works with the default sRGB setups having a wide gamut monitor and he's displaying correct colors, then either his monitor is conforming (at hardware or at OS level) to sRGB standard by limiting its original gamut, or is using some kind of window color-proofing app (which would imply an external CM system). I have the idea it's the former.
I believe you’re right on this one.


…If I remember well, there was an app for a free CM Linux system (think it was called CompICC) able to color manage portions of the screen or apps' windows. It was designed precisely for wide gamut monitors. So you could select any unaware-CM app window and color manage it externally. Maybe it might be something similar for MAC.
Interesting, thank you very much. Found CompICC on github, no similar Mac-tool so far, but will look further.


…It seems those are LW2018 bugs in MAC, at least in the VPR and Image Viewer cases ...considering RenderStatus seems to display correct colors there.
RenderStatus indeed shows good colour rendition directly with the default sRGB setup. Unfortunately, this doesn’t help much, as VPR shows these oversaturated colours which cannot be used to previsualize a final result then.
So your trickery really is the best solution!


…In PC, RenderStatus and ImageViewer display same correct results. The issue is with VPR and VIPER which might be due to speed reasons as you said. Curiously, this doesn't happen in v2015 when using VIPER and ICC corrections in DP NIF. It only happens with LUTs used as display.
Comparing all the results, there are definitively some errors going on.


…Good luck on that one.
:D
I think I know exactly what you allude to…


…Well, you can use also free options like Fusion, DisplayCAL's LUTMaker, LUTGenerator, etc.
Had searched for these tools earlier, but I was probably thinking too complicated, as I had the idea that for correct color space conversions at least hundreds of colours (or better thousands) would need to be translated correctly to achieve a good/useful conversion. You see, LUT's are still strange to me, I'm just more familiar with ICC-profiles. There is something new to learn again…


…So if you ask me, I'd say RenderStatus is the window in MAC providing the correct display.
That’s my idea too: it seems the only window which is colour managed by OS to the Display ICC profile.
(But I simply don’t know enough about programming to support this idea).


…Glad to help a bit!
It helped much more than just a „bit”!
Thank you again for all your help and support!

¬ cheers, Roger