Page 1 of 2 12 LastLast
Results 1 to 15 of 28

Thread: Color Management: LightWave compatible LUT files for Adobe RGB and/or ProPhoto RGB?

  1. #1
    •••••••••••••••••••• rsfd's Avatar
    Join Date
    Sep 2007
    Location
    Europe, de
    Posts
    1,305

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

    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)

  2. #2
    Super Member COBRASoft's Avatar
    Join Date
    Dec 2005
    Location
    Oudenburg, BEL
    Posts
    3,178
    Nice question!

  3. #3
    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.



    Gerardo

  4. #4
    •••••••••••••••••••• rsfd's Avatar
    Join Date
    Sep 2007
    Location
    Europe, de
    Posts
    1,305
    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.

  5. #5
    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

  6. #6
    •••••••••••••••••••• rsfd's Avatar
    Join Date
    Sep 2007
    Location
    Europe, de
    Posts
    1,305
    Hello again Gerardo and thank you again for your reply (much appreciated)

    Quote Originally Posted by gerardstrada View Post
    …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).

    Quote Originally Posted by gerardstrada View Post
    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.


    Quote Originally Posted by gerardstrada View Post
    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.

    Quote Originally Posted by gerardstrada View Post
    …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.

    Quote Originally Posted by gerardstrada View Post
    …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).
    Last edited by rsfd; 04-24-2018 at 10:03 AM.

  7. #7
    Quote Originally Posted by rsfd View Post
    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.

    Quote Originally Posted by rsfd View Post
    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.

    Quote Originally Posted by rsfd View Post
    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.

    Quote Originally Posted by rsfd View Post
    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.

    Quote Originally Posted by rsfd View Post
    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.

    Quote Originally Posted by rsfd View Post
    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
    Attached Files Attached Files

  8. #8
    •••••••••••••••••••• rsfd's Avatar
    Join Date
    Sep 2007
    Location
    Europe, de
    Posts
    1,305
    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.

    Quote Originally Posted by gerardstrada View Post
    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.

    Quote Originally Posted by gerardstrada View Post
    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).

    Quote Originally Posted by gerardstrada View Post
    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

  9. #9
    Quote Originally Posted by rsfd View Post
    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.

    Quote Originally Posted by rsfd View Post
    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.

    Quote Originally Posted by rsfd View Post
    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.

    Quote Originally Posted by rsfd View Post
    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

  10. #10
    •••••••••••••••••••• rsfd's Avatar
    Join Date
    Sep 2007
    Location
    Europe, de
    Posts
    1,305
    Hello Gerardo,

    Apologies for this very late reply!

    Quote Originally Posted by gerardstrada View Post
    …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.

    Quote Originally Posted by gerardstrada View Post
    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).

    Quote Originally Posted by gerardstrada View Post
    …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.

    Quote Originally Posted by gerardstrada View Post
    …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?

    Quote Originally Posted by gerardstrada View Post
    … Maybe you could confirm if this bug has been already solved in last v2018.3 (I haven't checked yet). …

    First need to wrap my head around this all!

    Quote Originally Posted by gerardstrada View Post
    …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
    Attached Thumbnails Attached Thumbnails Click image for larger version. 

Name:	LW2018_x-rite_LUT.jpg 
Views:	42 
Size:	107.4 KB 
ID:	141673   Click image for larger version. 

Name:	LW2018_x-rite_icc.jpg 
Views:	36 
Size:	102.2 KB 
ID:	141674   Click image for larger version. 

Name:	Modo12_x-rite.jpg 
Views:	37 
Size:	102.1 KB 
ID:	141672  
    Last edited by rsfd; 05-13-2018 at 02:32 PM. Reason: p.s.

  11. #11
    Quote Originally Posted by rsfd View Post
    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.


    Quote Originally Posted by rsfd View Post
    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.

    Quote Originally Posted by rsfd View Post
    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:


    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

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

    - Then switch display from sRGB to Linear.


    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....=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:


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


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


    - Finally, enable RayTrace Refraction.

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


    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:




    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.

    Quote Originally Posted by rsfd View Post
    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.

    Quote Originally Posted by rsfd View Post
    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.

    Quote Originally Posted by rsfd View Post
    First 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.


    Quote Originally Posted by rsfd View Post
    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
    Attached Files Attached Files
    Last edited by gerardstrada; 05-14-2018 at 05:04 PM. Reason: reposting images

  12. #12
    •••••••••••••••••••• rsfd's Avatar
    Join Date
    Sep 2007
    Location
    Europe, de
    Posts
    1,305
    Hello Gerardo,

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

    Quote Originally Posted by gerardstrada View Post
    …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…

    Quote Originally Posted by gerardstrada View Post
    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.

    Quote Originally Posted by gerardstrada View Post
    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.

    Quote Originally Posted by gerardstrada View Post
    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.

    Quote Originally Posted by gerardstrada View Post
    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.

    Quote Originally Posted by gerardstrada View Post
    …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”.

    Quote Originally Posted by gerardstrada View Post
    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.

    Quote Originally Posted by gerardstrada View Post
    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.


    Quote Originally Posted by gerardstrada View Post
    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).


    Quote Originally Posted by gerardstrada View Post
    …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).

    Quote Originally Posted by gerardstrada View Post
    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)

    Click image for larger version. 

Name:	img1.jpg 
Views:	34 
Size:	84.1 KB 
ID:	141748Click image for larger version. 

Name:	img2.jpg 
Views:	36 
Size:	78.4 KB 
ID:	141747

  13. #13
    Quote Originally Posted by rsfd View Post
    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.

    Quote Originally Posted by rsfd View Post
    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:


    Quote Originally Posted by rsfd View Post
    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).

    Quote Originally Posted by rsfd View Post
    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.

    Quote Originally Posted by rsfd View Post
    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.

    Quote Originally Posted by rsfd View Post
    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.

    Quote Originally Posted by rsfd View Post
    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:


    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.

    Quote Originally Posted by rsfd View Post
    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

  14. #14
    •••••••••••••••••••• rsfd's Avatar
    Join Date
    Sep 2007
    Location
    Europe, de
    Posts
    1,305
    Hello Gerardo,

    Quote Originally Posted by gerardstrada View Post
    Hope some of this may be helpful for you or someone else.
    It surely is!

    Quote Originally Posted by gerardstrada View Post
    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.

    Quote Originally Posted by gerardstrada View Post
    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).

    Quote Originally Posted by gerardstrada View Post
    hmmmm... The setup looks well here, look:
    But just as a side note: you are on Windows-OS exclusively?

    Quote Originally Posted by gerardstrada View Post
    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
    Attached Files Attached Files
    Last edited by rsfd; 05-20-2018 at 10:13 AM. Reason: orthography :{

  15. #15
    Quote Originally Posted by rsfd View Post
    Hello Gerardo,
    It surely is!
    Glad it helps!

    Quote Originally Posted by rsfd View Post
    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.

    Quote Originally Posted by rsfd View Post
    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.

    Quote Originally Posted by rsfd View Post
    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.

    Quote Originally Posted by rsfd View Post
    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.

    Quote Originally Posted by rsfd View Post
    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.

    Quote Originally Posted by rsfd View Post
    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.

    Quote Originally Posted by rsfd View Post
    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:


    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

    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)


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


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


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


    (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.


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


    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.

Page 1 of 2 12 LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •