Display Cal for LUT calibration for DaVinci Resolve

Until I can upgrade my system I have to work with my NEC computer monitor.

It's .icc profiles cannot be read by DVR 14.

So I found this tutorial that uses Display Cal for a LUT calibration - including the i1Pro probe.

It's in German, but if you jump to the middle where he does the calibration you can see what he's doing on the screen.

QUESTION:

Does this work to get a decent calibration?

Would the monitor still be able to access .icc profiles when I work with Photoshop and Final Cut Pro X or would those two calibration "fight" each other?

thanks for your insight!

As long as you don't include the vcgt correction in your 3DLUTs you will be fine.

As long as you don't include the vcgt correction in your 3DLUTs you will be fine.

Thanks Micha - but what is a vcgt correction?

I also saw he's using a decklink card.

I'm on a single monitor setup (NEC PA271W 27" wide gamut monitor) connected via thunderbolt port).

Can you still do an acceptable LUT calibration?

As long as you don't include the vcgt correction in your 3DLUTs you will be fine.

Thanks Micha - but what is a vcgt correction?

I also saw he's using a decklink card.

I'm on a single monitor setup (NEC PA271W 27" wide gamut monitor) connected via thunderbolt port).

Can you still do an acceptable LUT calibration?

Resolve outputs corrected video via Decklink to a secondary monitor. This method of calibration will not work with single monitor.


Sent from my iPhone using Tapatalk Pro

Thanks Micha - but what is a vcgt correction?
I also saw he's using a decklink card.
I'm on a single monitor setup (NEC PA271W 27" wide gamut monitor) connected via thunderbolt port).
Can you still do an acceptable LUT calibration?

Vcgt means video card gamma table - it's what provides the "calibration" for your monitor in the ICC profile (loaded by DisplayCAL's profile loader). If you include it in your 3DLUT (it's a checkbox in DisplayCAL's 3DLUT maker), the calibration correction will be applied twice, which is incorrect. You could choose to blacklist Resolve in DisplayCAL's profile loader, so that it will unload the gamma LUT whenever you start Resolve, and apply it again once you quit Resolve, but if you alt+tab out of Resolve while it is running, colours in other applications will be incorrect.

Long story short it is the most intuitive to not include the vcgt in any 3DLUTs you make for Resolve.

Because you are not using a Decklink output, you have to set the 3DLUT under the heading "Color Viewer 3DLUT", instead of "Monitoring 3DLUT". Monitoring is for external output through a playout card, color viewer is for the GUI viewers inside Resolve. Make sure to set the LUTs for scopes to "No LUT" or else your scopes will be incorrect.

Using GUI viewers only can still be acceptable depending on your needs - there will be some colour banding because of 8-bit output combined with the gamma 1DLUT. Some members on this forum will stress that you absolutely need to have a playout card and 10-bit output, but I maintain that it is up to your own needs.

Until I can upgrade my system I have to work with my NEC computer monitor.

in this case, this video tutorial will not be very helpful for you, because it does only explain, how to calibrate external screens, which are connected by a dedicated decklink i/o-card or adapter to your machine. if you want do calibrate the preview on the computer screen, the necessary process looks a little bit different...

(i'm always puzzled by this kind of tutorials, which do not calibrate both kinds of visual representation as good as possible)

It's .icc profiles cannot be read by DVR 14.

you shouldn't trust into this kind of factory provided monitor profiles. every individual screen will look slightly difernet and will even change its color rendition over time. it's therefor really advisable to calibrate it with adequate measurement devices periodically.

So I found this tutorial that uses Display Cal for a LUT calibration - including the i1Pro probe.

yes -- DisplayCal and an i1Pro are very affordable tools to handle this kind of tasks in suitable accuracy for more common usage scenarios. for real high end use, you would definitely need much more expensive probes and most likely also utilize other software.

Does this work to get a decent calibration?

it mainly depends on your monitor whether the results will be acceptable for serious work.
but DisplayCal will present you also very useful validation reports about the actual strengths and weaknesses of your screen resp. it's actual capabilities. that's IMHO just as valuable as the actual calibration benefit.

Would the monitor still be able to access .icc profiles when I work with Photoshop and Final Cut Pro X or would those two calibration "fight" each other?

this question can be only be answered in two distinctive ways, because output via decklink cards works a little bit different the usual video output via graphic cards on computer screens:

in case of decklink-i/o the answer is quite simple, because this kind of devices are really dumb and are not able handle all of this complex tasks, which nowadays computer graphic cards are able to support. they are only designed, to output simple fullscreen video previews resp. video streams to typical broadcast equipment. they are usually unable to process more complex kinds of color space transformations or compensation profiles. that's a job, which has to be done in the used video application software. but this isn't a significant limitation in practice, because beside this very few specialized video processing solutions, decklink cards are anyway useless. you simply can not use them for work in photshop or any other common software on your computer.

for the other case -- i.e. the preview on computer screens -- the answer is a little bit more complex and can not be explained in a way, which would fit for all different platforms. nevertheless it's a least possible for application developers, that the colors on screen will be always the same! given this very simple premise, it's always possible to compensate the actual visual representation on screen by this LUT preferences provided in resolve in principle -- because it's just a simple transformation between measured data (A) and the expected correct result (B) -- nothing else! but that's unfortunately just a part of the answer, because it doesn't guarantee, that the video preview will indeed look the same in all different parts of the application. that's a very annoying issue, because it makes a lot of sense in practice, to use different drawing and acceleration mechanisms within the same software for different tasks. the cinema viewer and the preview in the edit section and on the color page may handle it in a slightly different way, to archive more suitable results in all of this different work modes. so you would need in fact a whole bunch of different compensation LUTs to compensate all their [possibly] slightly different behavior perfectly. but that's more a kind of nitpicking...

in practice it's really useful to utilize calibration profiles even for the GUI preview. i have to say, it's looks even more important and nearly unavoidable in this particular case, if you want to archive any useful results!

unfortunately BMD doesn't show much interest to improve the computer screen preview capabilities of resolve, because they obviously want to sell decklink hardware devices, which is very understandable interest, but i really have my doubts, if it still fits in our present world resp. the way how most of us like to use computers for creative work.

if they would produce a simple color calibration probe for the same price as a decklink device and force all resove users to make use of this product to get an acceptable full screen preview on one of the attached computer screens, they would perhaps do a better job in advancing the general availability of really useful high quality video tools for everyone.

Thanks Micha - but what is a vcgt correction?
I also saw he's using a decklink card.
I'm on a single monitor setup (NEC PA271W 27" wide gamut monitor) connected via thunderbolt port).
Can you still do an acceptable LUT calibration?

Vcgt means video card gamma table - it's what provides the "calibration" for your monitor in the ICC profile (loaded by DisplayCAL's profile loader). If you include it in your 3DLUT (it's a checkbox in DisplayCAL's 3DLUT maker), the calibration correction will be applied twice, which is incorrect. You could choose to blacklist Resolve in DisplayCAL's profile loader, so that it will unload the gamma LUT whenever you start Resolve, and apply it again once you quit Resolve, but if you alt+tab out of Resolve while it is running, colours in other applications will be incorrect.

Long story short it is the most intuitive to not include the vcgt in any 3DLUTs you make for Resolve.

Because you are not using a Decklink output, you have to set the 3DLUT under the heading "Color Viewer 3DLUT", instead of "Monitoring 3DLUT". Monitoring is for external output through a playout card, color viewer is for the GUI viewers inside Resolve. Make sure to set the LUTs for scopes to "No LUT" or else your scopes will be incorrect.

Using GUI viewers only can still be acceptable depending on your needs - there will be some colour banding because of 8-bit output combined with the gamma 1DLUT. Some members on this forum will stress that you absolutely need to have a playout card and 10-bit output, but I maintain that it is up to your own needs.

Thank you, Micha! I have spent several hours after this post and researched calibration methods. And, in combination with what Martin said, I'm likely to forego decklink at this time. I am only using the color page in DaVinci (I edit in Final Cut Pro X, which is wonderfully intuitive for editing) - and I absolutely love the color page and its controls.

I have a NEC MultiSync PA271W which is capable of hardware LUT calibration.
The German monitor profiling software Basiccolor 5 can do hardware LUT calibration of my monitor.
This 3D LUT could be used by all applications: Photoshop, Capture One Pro, Final Cut Pro, DaVinci Resolve 14.2 GUI viewer on the color page).

For now, I only edit for the web.

So, my next line of research will be (after rereading your and Martin's post) to see if this is in fact correct: that all these applications could use the 3D LUT created by BasicColor 5 - which would free me of the kind of questionable .icc profiles.

PS: I am still a bit confused about the "double calibration" via video card gamma table. Is this something different from a LUT or a .icc profile, or part of them? Is a .icc a 1D LUT versus the three-dimensional 3D LUT? And would it mean to disable the .icc - is that what you mean? If yes, then this would go well with my plan to not use .icc at all any more and create 3dLUT hardware calibration of my monitor via i1pro and BasicColor 5). I hope I'll achieve it, as a deadline is approaching...

Until I can upgrade my system I have to work with my NEC computer monitor.

in this case, this video tutorial will not be very helpful for you, because it does only explain, how to calibrate external screens, which are connected by a dedicated decklink i/o-card or adapter to your machine. if you want do calibrate the preview on the computer screen, the necessary process looks a little bit different...

(i'm always puzzled by this kind of tutorials, which do not calibrate both kinds of visual representation as good as possible)

It's .icc profiles cannot be read by DVR 14.

you shouldn't trust into this kind of factory provided monitor profiles. every individual screen will look slightly difernet and will even change its color rendition over time. it's therefor really advisable to calibrate it with adequate measurement devices periodically.

So I found this tutorial that uses Display Cal for a LUT calibration - including the i1Pro probe.

yes -- DisplayCal and an i1Pro are very affordable tools to handle this kind of tasks in suitable accuracy for more common usage scenarios. for real high end use, you would definitely need much more expensive probes and most likely also utilize other software.

Does this work to get a decent calibration?

it mainly depends on your monitor whether the results will be acceptable for serious work.
but DisplayCal will present you also very useful validation reports about the actual strengths and weaknesses of your screen resp. it's actual capabilities. that's IMHO just as valuable as the actual calibration benefit.

Would the monitor still be able to access .icc profiles when I work with Photoshop and Final Cut Pro X or would those two calibration "fight" each other?

this question can be only be answered in two distinctive ways, because output via decklink cards works a little bit different the usual video output via graphic cards on computer screens:

in case of decklink-i/o the answer is quite simple, because this kind of devices are really dumb and are not able handle all of this complex tasks, which nowadays computer graphic cards are able to support. they are only designed, to output simple fullscreen video previews resp. video streams to typical broadcast equipment. they are usually unable to process more complex kinds of color space transformations or compensation profiles. that's a job, which has to be done in the used video application software. but this isn't a significant limitation in practice, because beside this very few specialized video processing solutions, decklink cards are anyway useless. you simply can not use them for work in photshop or any other common software on your computer.

for the other case -- i.e. the preview on computer screens -- the answer is a little bit more complex and can not be explained in a way, which would fit for all different platforms. nevertheless it's a least possible for application developers, that the colors on screen will be always the same! given this very simple premise, it's always possible to compensate the actual visual representation on screen by this LUT preferences provided in resolve in principle -- because it's just a simple transformation between measured data (A) and the expected correct result (B) -- nothing else! but that's unfortunately just a part of the answer, because it doesn't guarantee, that the video preview will indeed look the same in all different parts of the application. that's a very annoying issue, because it makes a lot of sense in practice, to use different drawing and acceleration mechanisms within the same software for different tasks. the cinema viewer and the preview in the edit section and on the color page may handle it in a slightly different way, to archive more suitable results in all of this different work modes. so you would need in fact a whole bunch of different compensation LUTs to compensate all their [possibly] slightly different behavior perfectly. but that's more a kind of nitpicking...

in practice it's really useful to utilize calibration profiles even for the GUI preview. i have to say, it's looks even more important and nearly unavoidable in this particular case, if you want to archive any useful results!

unfortunately BMD doesn't show much interest to improve the computer screen preview capabilities of resolve, because they obviously want to sell decklink hardware devices, which is very understandable interest, but i really have my doubts, if it still fits in our present world resp. the way how most of us like to use computers for creative work.

if they would produce a simple color calibration probe for the same price as a decklink device and force all resove users to make use of this product to get an acceptable full screen preview on one of the attached computer screens, they would perhaps do a better job in advancing the general availability of really useful high quality video tools for everyone.

Thank you for clearing this up, Martin!

As I'm only using the color page I only have to really look at one particular viewer. So the viewer in the color page would give different colors than e.g. the full screen cinema viewer?

My current plan is to ditch .icc profiles and go for hardware LUT calibration of my NEC Multisync PA271 via BasicColor 5. Shouldn't this give me one LUT that would work for all applications from Photoshop to the viewer on the color page in DaVinci Resolve?

When I read your text I had the impression that getting a 3D LUT is not enough for DVR - it wants another translation of the general monitor LUT to the viewer on the color page. Just how would you achieve such a correction? And why?

I found this document that has again different steps to create a calibration for the viewer in DVR: https://hub.displaycal.net/wiki/3d-lut- ... r-resolve/

As I'm only using the color page I only have to really look at one particular viewer. So the viewer in the color page would give different colors than e.g. the full screen cinema viewer?

i simply can't answer this question with certainty, because we all do not know, how this different kind of previews are actually implemented in resolve and what consequences it entails in practice. measuring the actual visual results on screen (e.g. by the calibration validation feature of DisplayCal) in all relevant working modes on your particular system, is perhaps the most adequate way to check and avoid this kind of misleading errors.

i just mentioned this kind of issues, because you'll find many bug reports in this forum (e.g. [1],[2],[3]) concerning this kind of errors -- in particular: differences of the color rendition in the edit and color grading tab.

although BMD usually seems to ignore this kind of bug reports and flaws, because they are obviously more interested in increasing the decklink sales, i still would see it just as an avoidable misbehavior of the software, because provided features and preference options simply should work as expected or otherwise be removed.

but beside this annoying little bugs there is another very important principal limitation of resolves preview LUT feature:
there is only one slot resp. 1D/3D LUT entry available in the preferences which affects all output on the computer screens just the same, but if you use more then one attached physical screen, you would need individual LUTs for all of them to realize sufficient software calibration!

My current plan is to ditch .icc profiles and go for hardware LUT calibration of my NEC Multisync PA271 via BasicColor 5. Shouldn't this give me one LUT that would work for all applications from Photoshop to the viewer on the color page in DaVinci Resolve?

if you only want to use your screen for video production and need external scopes or similar broadcast stuff, hardware calibration or external LUT boxes may indeed entail undeniable benefits, but in your described usage scenario, it seems to be much more desirable to switch between different kinds of applications resp. expected color spaces without any uncomfortable need to reconfigure the output devices -- i.e. not always have to press some buttons on the screen for the different purposes.

that's quite simple in case of common sRGB screens, because the differences between rec709 and sRGB are rather small and can be handled in a suitable manner by very simple adaptations resp. transformation LUTs. but in case of wide gamut screens it maybe indeed useful to calibrate two distinctive settings for AdobeRGB and sRGB/rec709 utilization on the monitor and manually toggle between both modes in case of different applications. otherwise you will not be able to use all possible values for sRGB/rec709 applications on the anyway quite limited 8bit communication line.

By using hardware calibration to a Rec709 target you will forego the wide gamut capabilities of your monitor. You can use a hybrid approach where you use the 3DLUT hardware calibration feature of your monitor to calibrate to a theoretical model of your monitor (the listed/measured RGB x/y coordinates and a given gamma curve), and then use DisplayCAL in profiling mode only (so no calibration) to generate an ICC profile with XYZ LUT, and any 3DLUTs you need for Resolve.

To clarify:
Calibration is intended to correct a display's colours to a certain standard (In the case of ICC profiles and 1D LUTs: a certain gamma curve and white point, and in the case of 3DLUTs: a certain gamma curve, white point and gamut). The process for this is to measure a certain colour, measure the deviation from the desired standard, then apply an offset, measure again, etc. until the measurement is within the desired margin of error.

Profiling is intended not to correct a display's colours, but rather to measure what the display performs like after calibration. Any errors that could not be caught by the profiling process are contained within the XYZ LUT that maps the display's RGB colour space as calibrated into device-independent perceptual XYZ space.

So what this hybrid approach does is, instead of either conforming the display to a colour space with a smaller gamut than its native RGB space (like Rec709), which makes it impossible to view for instance Adobe RGB files accurately in Photoshop, or trying to conform the display to a colour space with a larger gamut than its native RGB space (like DCI-P3) which will inherently be imperfect due to the limitations of the display (97% or so coverage of the target gamut), you will be conforming the display to a mathematically ideal model of your display (to the best of its ability). Then you will profile the result of that calibration, and generate 3DLUTs which map standard colour spaces like Rec709 and DCI-P3 to the device native colour space, which you can select in Resolve based on the needs of your project (P3 for theatrical presentations and Rec709 for BluRay/web).

For best results, I would recommend using absolute colorimetric rendering intent when making 3DLUTs for colour spaces with a target gamut that is smaller than your monitor's native space (100% or more gamut coverage), and perceptual appearance for colour spaces with a target gamut that is larger than your monitor's native space (99% or less gamut coverage). Note that any perceptual or relative intent will also shift the white point of the colour space to the native (calibrated) white point of your display. DCI-P3 has a greenish white point (0.314x 0.351y) compared to D65, but this is only an issue if you are trying to match to a projector in the same room. Chromatic adaptation of your eyes will ensure that within 10 to 15 minutes or so, P3-D65 will look more or less identical to DCI-P3. Also keep in mind that P3's gamma of 2.6 is intended for viewing in a pitch black environment. If you grade for P3 in daylight or indoor lighting you will inadvertently raise blacks and deep shadows.

Do note that because your monitor does not cover the entire P3 gamut, the 3DLUT for that colour space will be inherently imperfect. It is always recommended to view your finished product on a real cinema projector as a final quality check to ensure that no obvious mistakes slipped in as a result of imperfect colour reproduction of your grading monitor.

You can safely install the profiling-only ICC profile in your system for use by ICC-aware apps like Photoshop. Because the ICC profile does not contain any calibration data (vcgt), it will not interfere with Resolve.

I'm sorry if I went a bit deep down the rabbit hole, but when it comes to colour management, there are only two modes of operation: either you just blindly follow standard workflows with no understanding of the subject matter, or you have to dive deep and understand exactly what and why you are doing things a certain way. Feel free to ask any additional questions you might have.

One of the best explanations I've seen in a long time!

Just one thing to add: if you only calibrate a computer screen with a probe, the correction is written into the graphics card. If the connection between computer and monitor is only 8 bit (most of them still are) you may see banding on the monitor and thinks it's a problem with your source, while it not really is.

Serious grading monitors have a USB input and internal circuits with more bit depth to load calibration data, so they'll avoid that problem.

By using hardware calibration to a Rec709 target you will forego the wide gamut capabilities of your monitor. You can use a hybrid approach where you use the 3DLUT hardware calibration feature of your monitor to calibrate to a theoretical model of your monitor (the listed/measured RGB x/y coordinates and a given gamma curve), and then use DisplayCAL in profiling mode only (so no calibration) to generate an ICC profile with XYZ LUT, and any 3DLUTs you need for Resolve.

To clarify:
Calibration is intended to correct a display's colours to a certain standard (In the case of ICC profiles and 1D LUTs: a certain gamma curve and white point, and in the case of 3DLUTs: a certain gamma curve, white point and gamut). The process for this is to measure a certain colour, measure the deviation from the desired standard, then apply an offset, measure again, etc. until the measurement is within the desired margin of error.

Profiling is intended not to correct a display's colours, but rather to measure what the display performs like after calibration. Any errors that could not be caught by the profiling process are contained within the XYZ LUT that maps the display's RGB colour space as calibrated into device-independent perceptual XYZ space.

So what this hybrid approach does is, instead of either conforming the display to a colour space with a smaller gamut than its native RGB space (like Rec709), which makes it impossible to view for instance Adobe RGB files accurately in Photoshop, or trying to conform the display to a colour space with a larger gamut than its native RGB space (like DCI-P3) which will inherently be imperfect due to the limitations of the display (97% or so coverage of the target gamut), you will be conforming the display to a mathematically ideal model of your display (to the best of its ability). Then you will profile the result of that calibration, and generate 3DLUTs which map standard colour spaces like Rec709 and DCI-P3 to the device native colour space, which you can select in Resolve based on the needs of your project (P3 for theatrical presentations and Rec709 for BluRay/web).

For best results, I would recommend using absolute colorimetric rendering intent when making 3DLUTs for colour spaces with a target gamut that is smaller than your monitor's native space (100% or more gamut coverage), and perceptual appearance for colour spaces with a target gamut that is larger than your monitor's native space (99% or less gamut coverage). Note that any perceptual or relative intent will also shift the white point of the colour space to the native (calibrated) white point of your display. DCI-P3 has a greenish white point (0.314x 0.351y) compared to D65, but this is only an issue if you are trying to match to a projector in the same room. Chromatic adaptation of your eyes will ensure that within 10 to 15 minutes or so, P3-D65 will look more or less identical to DCI-P3. Also keep in mind that P3's gamma of 2.6 is intended for viewing in a pitch black environment. If you grade for P3 in daylight or indoor lighting you will inadvertently raise blacks and deep shadows.

Do note that because your monitor does not cover the entire P3 gamut, the 3DLUT for that colour space will be inherently imperfect. It is always recommended to view your finished product on a real cinema projector as a final quality check to ensure that no obvious mistakes slipped in as a result of imperfect colour reproduction of your grading monitor.

You can safely install the profiling-only ICC profile in your system for use by ICC-aware apps like Photoshop. Because the ICC profile does not contain any calibration data (vcgt), it will not interfere with Resolve.

I'm sorry if I went a bit deep down the rabbit hole, but when it comes to colour management, there are only two modes of operation: either you just blindly follow standard workflows with no understanding of the subject matter, or you have to dive deep and understand exactly what and why you are doing things a certain way. Feel free to ask any additional questions you might have.

Thank you, Micha.

So the hardware calibration is off the table, I will continue to use .icc profiles for Photoshop & Co to take advantage of the 97% 14bit coverage of Adobe RGB of my display.

As you stated, the tutorial I linked to is for an external monitor, not for my one-monitor system, and therefore not usable.

I understand I can create a 3D LUT for my monitor that does not affect when an .icc application needs to use the .icc profile.

What I would need now is a process on how to create such a 3DLUT inside DVR. One thing that really raises concern that in the Youtube tutorial you need to adjust the monitor RGB values via the monitor on-screen menu (it seems to me that would change the functioning of the monitor and would render .icc files obsolete because the monitor's RGB output is changed - and probably not to the better for the bigger Adobe RGB color space)

So my quest is now to find a 3D LUT creation process that works with DVR and does not affect my professional use of my monitor with PHotoshop & Co.

One of the best explanations I've seen in a long time!

Just one thing to add: if you only calibrate a computer screen with a probe, the correction is written into the graphics card. If the connection between computer and monitor is only 8 bit (most of them still are) you may see banding on the monitor and thinks it's a problem with your source, while it not really is.

Serious grading monitors have a USB input and internal circuits with more bit depth to load calibration data, so they'll avoid that problem.

What I'm looking for is to create the internal LUT for DVR without affecting the .icc workings of my display. I can't seem to find a step-by-step solution that doesn't include fiddling with the RGB onscreen menu of my monitor which would imbalance the monitor for .icc Photoshop work.

If I could create such a LUT cube and get DVR to load it on start.

I also saw that the color management set by Davinci is Davinci YRGB - which is unmanaged.

The setting "use Mac display profile for calibration" would then not be considered.

I changed the setting to "DaVinci YRGB Color Managed" and the input color space from Rec 709 gamma 2.4 to Rec 709 gamma 2.2 and it is now much nearer to what FCP X shows. (Gamma 2.4 makes the image much darker)

I'm just wondering why the input color space is Rec 709 - is that what comes from FCP X when you do an xml export?

One of the best explanations I've seen in a long time!

yes, it's indeed a very nice and useful explanation!

but i also have to add, that this kind of traditional ICC oriented terminology and structuring doesn't fit very well into the actual handling of this kind of tasks in the video and film industries. that's not only my personal opinion, but something, which looks very significant and constitutive for this other class of tools and color related workflows e.g. in OpenColorIO and ACES (just take a look at the section about ICC profiles in the OpenColorIO documentation, to get a rough idea about some of the fundamental differences). nevertheless it's still very useful to understand the more print industry shaped ICC concepts as well to choose at least adequate settings in DisplayCal and other more traditional CMS oriented calibration software.

the term "software calibration", which we often use to characterize this kind of color transformations, indeed has to be seen as oxymoron from a strict ICC oriented point of view. the only task, which could be accepted as 'calibration' in the strict sense by this particular terminology, concerns the setting of brightness and color channel amplification on the screen. everything else would fall under some kind of profile generation or application, which again causes a lot of misunderstandings, if it isn't actually handled by common ICC structured CMS infrastructure and software.

i therefore think, it's often useful to avoid some of this traditional concepts and technical terms to get closer to a more realistic and practice oriented view of things.

when i speak about "software calibration", i tacitly assume, that we are only interested in color corrections of so called "absolute colorimetric intent" of the ICC schemata. we usually do not want to approximate only some kind of useful similarity between the colors on screen within an unrepresentable wider color space, but rather objective correct rendition of the colors of a given data point related to a common color space on screen. that's a quite different premise to color management in the print industries, where you often have to bridge the gap between fundamental different kinds of color representation and reproduction technologies. it's also somehow a little bit of an excuse, why we usually speak just about "calibration" in this much simpler case, although it's indeed some kind of software driven translation.

in this case it also doesn't matter, if the actual translation gets applied within the video processing software on your computer, in an external LUT box between your computer and the screen, or handled by the video processing software of your monitor. the result will be more or less the same, although any of this alternatives will unavoidable go hand in hand with some slightly different pros end cons.

archiving transformations, like the suggested use of a P3 perceptive/relative intent profiles on an actual 8bit AdobeRGB screen, looks much more questionable to me. i personally wouldn't advice this kind of workarounds for serious video work. it's IMHO much more useful to remain modest and just utilize the actual physical capabilities of a given display in the most accurate way as possible by more or less simple calibration efforts.

What I'm looking for is to create the internal LUT for DVR without affecting the .icc workings of my display. I can't seem to find a step-by-step solution that doesn't include fiddling with the RGB onscreen menu of my monitor which would imbalance the monitor for .icc Photoshop work.

you will indeed have to make two calibration setups in parallel. one more common ICC related one for photshop etc. and a 3DLUT based one for resolve.

this will be always a kind of compromise, because serious photo editing is usually done at different screen brightness and even at another withe point resp. ambient light -- and photographers are usually just as picky about this kind of peculiarities as video and film colorists.

I also saw that the color management set by Davinci is Davinci YRGB - which is unmanaged.

on mac os it's a little bit different, because this edition of resolve is able to use the system wide CMS, but on windows and linux it's indeed just using this isolated 3D LUT approach, which isn't uncommon in the video and film industries.

Okay, first off. DisplayCAL is fundamentally an ICC profiling application. It uses ArgyllCMS, which is a colour management library that creates and manipulates ICC profiles. If you don't want a "traditional ICC oriented" workflow for whatever reason you cook up in your mind, don't use DisplayCAL. Since this thread is about DisplayCAL, I assumed the OP wants to use DisplayCAL. (I don't blame him - it's free!)

Second, displays like the NEC PA271 are ultimately "prosumer" screens. There is a giant price gap between 97% DCI-P3 and 100% DCI-P3. You can either say "no, I can't grade P3, I don't have the equipment", or you can create a perceptual gamut mapping and go about your business. I personally use the gamut mapping method to monitor P3 on my dual 31MU97Z displays (99% AdobeRGB, 97% P3), and the last film festival I graded a short film for, the film that I graded was the only entry that was natively P3, with all other entries being finished in Rec709 and converted to DCP. Everyone I spoke to there, including the director, said it looked stunning. Full disclosure, I don't grade for big film studios; I grade independent short films. I don't live in Burbank CA, and I can't afford a Sony BVM-X300. I would assume OP's situation is similar.

With that out of the way, I want to clear up some confusion about the hybrid approach that I described. What I meant was not to disable hardware calibration entirely, but to perform a 3DLUT hardware calibration in BasICColor or CALman, and target the native display properties:
Red 0.6821x 0.3101y
Green 0.2218x 0.6876y
Blue 0.1529x 0.0543y
CCT 0.3127x 0.3290y
White level max (as measured)
Gamma 2.2

Then, with that calibration loaded into the display, perform a display characterisation (profiling) using DisplayCAL, which generates an ICC profile. The default settings should be fine here, although you might want to use a bigger test chart. I usually go with the chart size that corresponds to a 45 minute profiling session.

Once you have your ICC profile, you can install it as the system profile, and apps like Photoshop can use it right away. To use it with Resolve, you have to open "3DLUT Maker". Select your target profile (for instance Rec709) as the input profile, and select the display profile for your PA271 (that you just made) as the destination profile. "Apply calibration (vcgt)" should be greyed out, because your display profile does not contain any calibration data. For Resolve, set the output format to "IRIDAS (.cube)". After generating the 3DLUT, DisplayCAL will have spat out some extra files in the output folder like a PNG file, an ICC profile and a log file. You can safely delete these, you will only use the .cube file. Copy it to C:\ProgramData\Blackmagic Design\DaVinci Resolve\Support\LUT. I personally make a subfolder inside the LUT folder named "DisplayCAL" to group my display LUTs and keep them separate from all the other LUTs I use like film emulation LUTs.

Okay, first off. DisplayCAL is fundamentally an ICC profiling application. It uses ArgyllCMS, which is a colour management library that creates and manipulates ICC profiles. If you don't want a "traditional ICC oriented" workflow for whatever reason you cook up in your mind, don't use DisplayCAL. Since this thread is about DisplayCAL, I assumed the OP wants to use DisplayCAL. (I don't blame him - it's free!)

the resolve 3d LUT generation feature of DisplayCAL doesn't have much in common with ICC oriented parts of the this tool. and even the underlying ArgillCMS and its modular components (e.g. scanin) are suitable for many non-ICC tasks. e.g. i use it a lot within DCamProf, which is more DNG profile oriented, and for ACES IDT creation. that's the real benefit of "free" tools, that your are able to uses and extend them to your very specific needs.

You can either say "no, I can't grade P3, I don't have the equipment", or you can create a perceptual gamut mapping and go about your business.

there is also a third option -- well, it's partially just a variant of your first one -- available, which is often suggested by experienced experts and looks quite simple/natural/plausible to me:

For grading, stick to a colour space your display can do accurately - rec709 or P3.

...use a space that your display can properly represent, then do a mathematical conversion to xyz for delivery...

but i really appreciate you description of this more uncommon approach. i just want to see it more as a kind of personal preference and not as the one and only way, how we should all have to handle this kind of tasks in practice.

Just to clarify, an "ICC" profile is just a file in a specific (standardized) binary format. For the topic of this discussion, this is an implementation detail that has no actual bearing on the discussion.

3D LUT calibration always involves these steps, in this order:

1. (Optional) the monitor may be adjusted to meet certain target characteristics (e.g. whitepoint), by means of monitor controls and/or (also optionally) 1D curve adjustments to each individual R, G, and B channel. You could call this optional step linearization.
2. The monitor is profiled, i.e. its response is measured and recorded, by sending a number of RGB triplets to the monitor. The RGB triplets by themselves have no meaning. The measured CIE tristimulus values are related to the RGB triplets (which adds meaning). We now know "this RGB triplet produces this CIE tristimulus value" on this particular monitor. So, the profile in itself is already a three dimensional lookup table (monitor RGB -> CIE tristimulus), although there is also the possibility to derive simpler 3x3 matrix based models (not as accurate) which we can safely ignore.
3. Now that we have the monitor response in form of a profile (which, in its simplest form, may just be a text file with a list of RGB and measured CIE tristimulus values), we can simulate any other desired response, e.g. by creating a Rec. 709 + gamma x.x RGB to monitor RGB lookup table, that converts between these two responses directly. We could create these lookup tables on-the-fly (how ICC color managed applications work) or "bake" them up-front (which is usually used in the video world).

that's a really excellent description of the whole process!

Thanks for weighing in on the matter, Florian. (Florian is the author of DisplayCAL, by the way.)

i really appreciate you description of this more uncommon approach. i just want to see it more as a kind of personal preference and not as the one and only way, how we should all have to handle this kind of tasks in practice.

I never presented it as anything more than that. It all depends on your personal needs and as long as you communicate transparently with your clients about what you are doing and any limitations in your workflow, and give them alternatives, I don't see anything wrong with it.

At least in the low-budget world of independent short films, when you give your client the choice between only having a Rec709 master that is guaranteed WYSIWYG, or a Rec709 master for web combined with a theatrical DCP that might not look exactly the same in the grading room as in the theatre, many will choose the latter option, and in fact do not regret their choice after seeing the film projected.

I don't like the black and white view that I keep reading on forums. Human vision is inherently relative, and thinking in absolutes ultimately works against you. For instance, I see many colourists working with absolute colorimetric white points, but then having their GUI monitors in a totally different white balance from their grading monitor, and maybe even using a warm white desk lamp. This changes your vision into a mixed chromatic adaptation state, where all bets are off when it comes to accurate colour reproduction! The CIE colour models that we use for colour matching assume certain viewing conditions, and the whole model breaks down when those conditions are violated. In other words, all significant light sources should be the same white balance, meaning that if your GUI monitors are D65, you will achieve more accurate colour reproduction if you grade in P3-D65 than if you grade in DCI-P3. This has nothing to do with how good or expensive your equipment is, but simply with knowing what you are doing and what effects it has on your vision. Your eyes can play tricks on you, and no amount of display calibration will help you there!

In that respect, I think it is a bit like racing. If your grading setup is your race car, and you, the colourist, are the race driver, you can be the best driver in the world, but you will either need to hire a good mechanic to tune your engine, or you need to become a good mechanic yourself.

Just to clarify, an "ICC" profile is just a file in a specific (standardized) binary format. For the topic of this discussion, this is an implementation detail that has no actual bearing on the discussion.

3D LUT calibration always involves these steps, in this order:

1. (Optional) the monitor may be adjusted to meet certain target characteristics (e.g. whitepoint), by means of monitor controls and/or (also optionally) 1D curve adjustments to each individual R, G, and B channel. You could call this optional step linearization.
2. The monitor is profiled, i.e. its response is measured and recorded, by sending a number of RGB triplets to the monitor. The RGB triplets by themselves have no meaning. The measured CIE tristimulus values are related to the RGB triplets (which adds meaning). We now know "this RGB triplet produces this CIE tristimulus value" on this particular monitor. So, the profile in itself is already a three dimensional lookup table (monitor RGB -> CIE tristimulus), although there is also the possibility to derive simpler 3x3 matrix based models (not as accurate) which we can safely ignore.
3. Now that we have the monitor response in form of a profile (which, in its simplest form, may just be a text file with a list of RGB and measured CIE tristimulus values), we can simulate any other desired response, e.g. by creating a Rec. 709 + gamma x.x RGB to monitor RGB lookup table, that converts between these two responses directly. We could create these lookup tables on-the-fly (how ICC color managed applications work) or "bake" them up-front (which is usually used in the video world).

If I have calibrated Rec.709 screen and play P3 video with color management I assume I will get "correct" result (assuming color management reads all flagging and does conversion properly)? Is this more accurate than using LUTs?

If I have Rec.709 2.4 gamma graded video and play it through color managed system and to Rec.709 2.2 gamma bcalibrated monitor I will get "proper" preview as well? I assume it's not going to be 100% the same as on reference 2.4 gamma based screen, but still should look "correct".

In theory if I had perfect Rec.2020 monitor with color managed player then I could preview quite accurately about any master file on it (if we forget how human eye reacts to different display technology)?

If I have calibrated Rec.709 screen and play P3 video with color management I assume I will get "correct" result (assuming color management reads all flagging and does conversion properly)?

If you play P3 video on a Rec709 screen, you should get gamut clipping, because the source gamut is larger than the target gamut. However, since you said your hypothetical video player reads all flagging, the default rendering intent embedded in the ICC profile is perceptual, which means the larger P3 gamut will be shrunk to the Rec709 gamut, resulting in undersaturated colours. Ideally, your video player would allow you to select a colorimetric rendering intent instead, which would "correctly" clip the gamut.

If I have Rec.709 2.4 gamma graded video and play it through color managed system and to Rec.709 2.2 gamma based monitor I will get "proper" preview as well? I assume it's not going to be 100% the same as on reference 2.4 gamma based screen, but still should look "correct".

Gamma correction is a very simple operation and aside from possible banding, ICC-managed applications should be perfectly capable of displaying 2.4 gamma content on a 2.2 gamma display, provided the source is properly tagged/identified and the display is profiled.

As far as I understand color management will perform proper conversion, so I will get correct (mathematically correct?) representation of my P3 master on my Rec.709 screen. This may not be the best (you could add colorist artistic decisions) representation, but it should be quite decent preview.

Lets say I have P3 gamut with 2.4 gamma (deliberately) calibrated display with player which has working color management system. I should be able quite reliably preview many different masters, yes? It's not going to be perfectly the same as having monitors calibrated to different gamuts+gammas, but it should be quite decent.

More complicated question.
If I have random monitor which can eg. display 90% P3 gamut, but I know its ICC profile perfectly matches its parameters then I should be still able quite reliably grade Rec.709 videos assuming whole thing is color managed. Is this correct? Fact that monitor is not calibrated to Rec.709 should not be a problem at all (as long as monitors really matches its profile and it's above Rec.709 gamut).

More complicated question.
If I have random monitor which can eg. display 90% P3 gamut, but I know its ICC profile perfectly matches its parameters then I should be still able quite reliably grade Rec.709 videos assuming whole thing is color managed. Is this correct? Fact that monitor is not calibrated to Rec.709 should not be a problem at all (as long as monitors really matches its profile and it's above Rec.709 gamut).

sure -- will work! but in case of an 8bit connection the visible banding resp. usable color nuances will unfortunately look noticeable worse than on a very simple 8bit rec709/sRGB screen.

and concerning the 'hypothetical video player': mpv already supports most of this typical CMS handling. e.g.:

Code: Select all

--icc-intent=<value>
              Specifies the ICC intent used for the color transformation (when
              using --icc-profile).
              0      perceptual
              1      relative colorimetric (default)
              2      saturation
              3      absolute colorimetric


I do use mpv player when needed.

How is the ICC managed? On GPU 32bit float math?

How is the ICC managed? On GPU 32bit float math?

the implementation in mpv is based on LittleCMS and uses 3D LUTs of 16bit resolution which are processed on the GPU by utilizing OpenGL 3D texture capabilities.

I just learned that you can convert a .icc profile to a 3D LUT via DisplayCal.

If I have Rec.709 2.4 gamma graded video and play it through color managed system and to Rec.709 2.2 gamma calibrated monitor I will get "proper" preview as well?

If the system allows you to flag or otherwise indicate the source appropriately(!) and the color managed playback system adheres to it strictly(!), then yes.

However, since you said your hypothetical video player reads all flagging, the default rendering intent embedded in the ICC profile is perceptual, which means the larger P3 gamut will be shrunk to the Rec709 gamut, resulting in undersaturated colours.

Not necessarily. Only cLUT profiles support different rendering intents, and what's actually in the tables depends on the profile creation software (e.g. for DisplayCAL with default settings, when creating a XYZ cLUT profile, the perceptual table will match the colorimetric table, except the black point will be mapped).

but in case of an 8bit connection the visible banding resp. usable color nuances will unfortunately look noticeable worse than on a very simple 8bit rec709/sRGB screen.

8 bit connections are not necessarily a limitation. A good solution should use dithering to eliminate banding.

I just learned that you can convert a .icc profile to a 3D LUT via DisplayCal.

Not a conversion - a 3D LUT is a link between two color spaces (profiles), with the display profile as the destination.

but in case of an 8bit connection the visible banding resp. usable color nuances will unfortunately look noticeable worse than on a very simple 8bit rec709/sRGB screen.

8 bit connections are not necessarily a limitation. A good solution should use dithering to eliminate banding.

that's an interesting point of view!

i wouldn't say, i disagree, because i also esteem adequate dithering techniques and also think, that you often may archive rather satisfaying results by 10->8bit dithering and 8bit+FRC panels, which are hardly distinguishable from real 10bit solutions.

but in this specific case - i.e. the side effects of gamut transformation resp. their consequences for quantification aspects -- i usually have to think about all those unsatisfying color artifacts, which most of us know from working with LOG-footage from affordable cameras, which are also mainly caused by a very similar inefficient use of huge reference color spaces (e.g. V-Gamut) for sensors and purposes, which do not make use of all the available gamut extend in practice. and this causes indeed very unpleasant side effects.

that's just a very realistic and well know issue, which should us remind, that this kind of color transformations are not only the result of accurate mathematical transformation but also limited by quantification constraints and their consequences in practice.

but in the case of video output on screen, dithering is indeed much more useful than in video recordings. the reason for this significant difference has to be seen in the simple fact, that RGB output on screen doesn't imply any kind of video compression on the communication line. that's very important in practice, because dithering and satisfaying compression are strict irreconcilable!

even in those cases, where YUV/YCbCr color subsampling is used for the communication between computer on monitor, dithering will not be a very satisfying solution anymore.

i therefore think, that real 10bit communication, as it's it becoming more and more a common capability on nowadays computer graphics hardware -- although only useful utilizable via display port connections --, is a really useful and desirable improvement. it even entails quality gains in those cases, where the result finally gets dithered again by the monitors software or some kind of FRC techniques on actual 8bit panels. but dithering in software or by the computers OpenGL graphics drivers may nevertheless be seen as very useful workaround as well in all those cases, where this more satisfaying solutions are not available.

Still no solution as Displaycal and its 3Dlutmaker didn't work.

My goal was to use the last performed .icc calibration via i1 Display Pro and Spectraview II (my current display, a NEC pa271w experiences backlight issues and can no longer achieve white point calibration. The newest model, the PA271Q is only avaiable in about 6-8 weeks, so I have to work with the existing calibration that is still workable)

Problems:

Cannot create a 3Dlut from the .icc file - displaycal's settings do not show any .icc file and does not let me navigate to it.

The 3DLUT maker that comes with DisplayCAL does not open: when I double-click on it in the displaycal folder I get the error message "this application could not be opened"

I would need step-by-step info on how to turn this software nightmare into a solution and would appreciate such to the point information - thanks!

Cannot create a 3Dlut from the .icc file - displaycal's settings do not show any .icc file and does not let me navigate to it.

Profiles that have not been created by DisplayCAL are not supported by the main application for 3D LUT creation, you'd have to use the stand-alone 3D LUT maker.

The 3DLUT maker that comes with DisplayCAL does not open: when I double-click on it in the displaycal folder I get the error message "this application could not be opened"

Did you follow the instructions in the documentation (directly under the download link), specifically the bit about removing the "quarantine" flag under macOS?

Cannot create a 3Dlut from the .icc file - displaycal's settings do not show any .icc file and does not let me navigate to it.

Profiles that have not been created by DisplayCAL are not supported by the main application for 3D LUT creation, you'd have to use the stand-alone 3D LUT maker.

The 3DLUT maker that comes with DisplayCAL does not open: when I double-click on it in the displaycal folder I get the error message "this application could not be opened"

Did you follow the instructions in the documentation (directly under the download link), specifically the bit about removing the "quarantine" flag under macOS?

Yes, I entered the line into the programming window.

I still cannot open the 3DLut maker. "The Application 3Dlut maker could not be opened".

There seems to be no software for the mac to turn a .icc file into a 3dlut.

PS: Could this be that a .icc file is only 4kb?

I found a way to deal with this problem.

What didn't work:

I cannot use DisplayCal for this as I cannot load the .icc profile into it as it doesn't recognize it.
I cannot use the 3D Lut maker of Display Cal as it doesn't open.
And I cannot calibrate via Display Cal as my monitor does no longer calibrate.

So either grade the whole project in Final Cut Pro X (and I am no fan of FCP X color correction tools) or play it by the eye and create my own adjustment for the difference from what I see in DVR and the output in Quicktime.

What works:

So I created my own "calibration node" in DaVinci Resolve. The output is too bright and too low contrast, so I increased contrast and lowered brightness with a curve.

Then I compared the quicktime loaded file with the file as it looks in DaVinci Resolve 14.2. viewer - first try and I'm already quite close.

Not exactly a high end calibration but better than nothing and it will get my grade into the ballpark.


As I'm now in the market for a new display I'll set up my system that such horrors will no longer occur.

A bit late to this thread, but the NEC PA271W can actually be calibrated (accurately) directly via 3D LUTs.
See: https://www.lightillusion.com/nec_manual.html

And for additional information ICC profiles this page may be of interest: https://www.lightillusion.com/icc_profiles.html

You can also convert ICC into 3D LUTs through the use of an ICC aware graphics program (Photoshop for example) and what is known as a LUT Image: https://www.lightillusion.com/lut_image.html
(Resolve also has such an 'image'.)

Steve