Page 2 of 2 FirstFirst 12
Results 16 to 28 of 28

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

  1. #16
    •••••••••••••••••••• rsfd's Avatar
    Join Date
    Sep 2007
    Location
    Europe, de
    Posts
    1,301
    Hello Gerardo,
    thank you again for your time and efforts!

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

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

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

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

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

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

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

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

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

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

  2. #17
    Electron wrangler jwiede's Avatar
    Join Date
    Aug 2007
    Location
    San Jose, CA
    Posts
    5,975
    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.
    John W.
    LW2015.3UB/2018.0.5 on MacPro(12C/24T/10.13.6),32GB RAM, NV 1080ti

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

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

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

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

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

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

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


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

  4. #19
    Electron wrangler jwiede's Avatar
    Join Date
    Aug 2007
    Location
    San Jose, CA
    Posts
    5,975
    Quote Originally Posted by gerardstrada View Post
    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.
    John W.
    LW2015.3UB/2018.0.5 on MacPro(12C/24T/10.13.6),32GB RAM, NV 1080ti

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

  6. #21
    •••••••••••••••••••• rsfd's Avatar
    Join Date
    Sep 2007
    Location
    Europe, de
    Posts
    1,301
    Hello Gerardo,

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

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

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

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

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

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

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

    Click image for larger version. 

Name:	LW2018-colorpatch-matrix_VPR.jpg 
Views:	16 
Size:	89.0 KB 
ID:	141880Click image for larger version. 

Name:	LW2018-colorpatch_VPR.jpg 
Views:	12 
Size:	88.0 KB 
ID:	141881Click image for larger version. 

Name:	aRGB-LW2018-colorpatch-matrix_VPR.jpg 
Views:	16 
Size:	85.4 KB 
ID:	141882

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


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

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

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


    Instead of this one that I always get:


    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:


    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?


    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:


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

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


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


    but most of its gamut volume is bigger than aRGB:


    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.


    The result is like this:


    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

  8. #23
    •••••••••••••••••••• rsfd's Avatar
    Join Date
    Sep 2007
    Location
    Europe, de
    Posts
    1,301
    Hello Gerardo,

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

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

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

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

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

    Quote Originally Posted by gerardstrada View Post
    Which are practically the same results you get with aRGB-LW2018-colorpatch-matrix.lws when you say:
    Yes they are. (see attachements)

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

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

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

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

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


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

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

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

    Click image for larger version. 

Name:	LW2018-colorpatch.jpg 
Views:	16 
Size:	153.5 KB 
ID:	141921Click image for larger version. 

Name:	LW2018-colorpatch-matrix.jpg 
Views:	10 
Size:	134.6 KB 
ID:	141922Click image for larger version. 

Name:	LW2018-colorpatch-Proof_Monitor-cube.jpg 
Views:	12 
Size:	139.0 KB 
ID:	141923Click image for larger version. 

Name:	LW2018-colorpatch-Proof_toMonitor.jpg 
Views:	13 
Size:	134.2 KB 
ID:	141924Click image for larger version. 

Name:	LW2018-colorpatch-Proof_Monitor-icc.jpg 
Views:	14 
Size:	137.4 KB 
ID:	141925

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

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

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

    Quote Originally Posted by rsfd View Post
    (Had done so every time).
    Good!

    Quote Originally Posted by rsfd View Post
    Yes they are. (see attachements)
    Great!

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

    Quote Originally Posted by rsfd View Post
    Does this mean that I was right in thinking that there is no color management happening in regard of respecting a certain colorspace?
    Yes.

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

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

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

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

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


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

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

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


    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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Click image for larger version. 

Name:	Default-sRGB.jpg 
Views:	9 
Size:	137.4 KB 
ID:	141956

  11. #26
    Electron wrangler jwiede's Avatar
    Join Date
    Aug 2007
    Location
    San Jose, CA
    Posts
    5,975
    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.
    John W.
    LW2015.3UB/2018.0.5 on MacPro(12C/24T/10.13.6),32GB RAM, NV 1080ti

  12. #27
    Quote Originally Posted by rsfd View Post
    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 (v2012015) 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.

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

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

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

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

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

    Quote Originally Posted by rsfd View Post
    Correct support for icc profiles would be very nice. I’ll do a report on that one too.
    Good luck on that one.

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

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


    Quote Originally Posted by rsfd View Post
    This was really interesting, thank you so much again for offering your knowledge, time and patience!
    Glad to help a bit!


    --- o ---


    Quote Originally Posted by jwiede
    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

  13. #28
    •••••••••••••••••••• rsfd's Avatar
    Join Date
    Sep 2007
    Location
    Europe, de
    Posts
    1,301
    Hello Gerardo,

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

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

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

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

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

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

    Quote Originally Posted by gerardstrada View Post
    …Good luck on that one.

    I think I know exactly what you allude to…

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

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

    Quote Originally Posted by gerardstrada View Post
    …Glad to help a bit!
    It helped much more than just a „bit”!
    Thank you again for all your help and support!

    ¬ cheers, Roger

Page 2 of 2 FirstFirst 12

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
  •