Page 5 of 17

Re: Final Explanation of Gamma and Color Shift Problems

PostPosted: Sun Dec 22, 2019 10:30 pm
by d.dragun
Andrew Kolakowski wrote:Already explained- mediainfo has no support for MP4 headers.

As I understand not only mediainfo couldn't read, also all inspector app (from first post) couldn't read.
Only macOS Get Info can.

Re: Final Explanation of Gamma and Color Shift Problems

PostPosted: Sun Dec 22, 2019 11:55 pm
by Andrew Kolakowski
About nothing reads it from MP4.

Re: Final Explanation of Gamma and Color Shift Problems

PostPosted: Mon Dec 23, 2019 4:19 am
by Wayne Steven
Your only solution is regime change, as I suggested before, new standard fixing everything up, free standard and GPU code, free explanatory documents and videos to detail what documentation and everything means. Then any vendor can copy or adapt code with an understanding of process and outcome.

Re: Final Explanation of Gamma and Color Shift Problems

PostPosted: Fri Jan 10, 2020 3:11 am
by Marc Wielage
So it's been three months and 203 message posts so far. Is there a Final Explanation yet?

Apparently not... I'm guessing because it's a very complicated problem to solve. I also think the solution lies more to color management than anything else. It's not a Resolve problem per se.

Re: Final Explanation of Gamma and Color Shift Problems

PostPosted: Fri Jan 10, 2020 8:51 am
by Wayne Steven
Marc Wielage wrote:So it's been three months and 203 message posts so far. Is there a Final Explanation yet?

Apparently not...


A new standard :D

Re: Final Explanation of Gamma and Color Shift Problems

PostPosted: Fri Jan 10, 2020 6:20 pm
by Brian Williams II
Marc Wielage wrote:So it's been three months and 203 message posts so far. Is there a Final Explanation yet?

Apparently not... I'm guessing because it's a very complicated problem to solve. I also think the solution lies more to color management than anything else. It's not a Resolve problem per se.

We found ONE solution, maybe not THE solution. Hopefully it will help folks out there because we certainly benefitted from this thread to find our way.

As simply as I can describe it, we took the export from Resolve 16 and re-encoded through Adobe Media Encoder, and every application from then on showed us what we were seeing in Resolve correctly again. I don't know the exact explanation for this, but I can say it fixed our problem.

We do Pro Res exports, so even if you're just working with MP4 clips, try exporting in a Pro Res wrapper, as beefy as you would prefer or need, and then run it through a separate encoder to your desired final destination format. Adobe Media Encoder did the trick for us, but maybe other professional encoders would do just as well. It's not our favorite solution, but it's a solution we found that seems to work. Pictures below.

Image
Resolve 15 export (Pro Res HQ)
Image
Resolve 16 export (Pro Res HQ)
Image
Resolve 16 export run through Adobe Media Encoder (both the Pro Res HQ and MP4 looked identical to the original Resolve 15 export)

I hope it helps!

Re: Final Explanation of Gamma and Color Shift Problems

PostPosted: Fri Jan 10, 2020 7:50 pm
by Jamie LeJeune
Brian Williams II wrote: As simply as I can describe it, we took the export from Resolve 16 and re-encoded through Adobe Media Encoder, and every application from then on showed us what we were seeing in Resolve correctly again. I don't know the exact explanation for this, but I can say it fixed our problem.

The reason that appears to work is because Media Encoder has no color management so two things are happening:
1. AME is ignoring the NCLC tags on the source file
2. When AME writes the new file, it is setting the NCLC tags as 1-1-1

Transcoding the file just to change the NCLC metadata is like using a guillotine to cure a headache.

You can skip AME and get the same result directly out of Resolve v16 in standard Davinci YRGB mode if you set the timeline color space to REC709(scene) because that timeline setting will result in the NCLC tag of the rendered file to be 1-1-1

Re: Final Explanation of Gamma and Color Shift Problems

PostPosted: Fri Jan 10, 2020 9:19 pm
by Andrew Kolakowski
Yes, it has not much to do with 'solution' as there isn't any real solution atm.

Re: Final Explanation of Gamma and Color Shift Problems

PostPosted: Sat Jan 11, 2020 5:13 am
by Dmytro Shijan
Marc Wielage wrote:So it's been three months and 203 message posts so far. Is there a Final Explanation yet?

Apparently not... I'm guessing because it's a very complicated problem to solve. I also think the solution lies more to color management than anything else. It's not a Resolve problem per se.


For me in current reality final explanation is set Resolve timeline to Rec709 (Scene) in YRGB project, as described in updated first port. Timeline color space in YRGB project affect only metadata tags in rendered video so i can keep do all grade in wide gamut color space even if timeline to Rec709 (Scene). This don't help to avoid gamma and colors shift between color managed Quicktime player and non color managed players but at least this will help to avoid additional gamma shifts during Youtube/Vimeo/Handbrake transcoding.
There is nothing else that we can do until large companies agreed to some common way to deal with color managed non HDR video and arrange it to some worldwide ISO standard.

Re: Final Explanation of Gamma and Color Shift Problems

PostPosted: Sat Jan 11, 2020 7:37 pm
by waltervolpatto
Ya know, there is a standard ITU-BT1886.

Ain't rocket science.

Re: Final Explanation of Gamma and Color Shift Problems

PostPosted: Sat Jan 11, 2020 7:51 pm
by Andrew Kolakowski
Where is BT.1886 signalling value in h265 spec then?
There is a lot of crap there, but about 90% of possible signalling values are basically useless. One which is most important and common is simply not there.

Re: Final Explanation of Gamma and Color Shift Problems

PostPosted: Sun Jan 12, 2020 11:09 am
by Andreas Fiebig
Thanks Dmitry and all others for investigation and your work.
I am grading in Gamma 2.4 with a Gamma 2.4 timeline and will use JESExtensifier.app to set correct Gamma after using a CST node on timeline.

What about iOS? Anyone knows how it handles video metadata? Same as Quicktime Player on MacOS?

Re: Final Explanation of Gamma and Color Shift Problems

PostPosted: Sun Jan 12, 2020 7:04 pm
by Robin Erard
Hello,

Sadly, JesExstensifier doesn't work anymore on MacPro 2019 with Catalina...

it was my solution before my computer upgrade.

Robin

Re: Final Explanation of Gamma and Color Shift Problems

PostPosted: Mon Jan 13, 2020 7:08 am
by bigflavorfilms
So what's the verdict here? When I set Resolve's Timeline Color Space to Rec.709(Scene), add a CST node and adjust correctly and upload, to say Frame.IO for client review, the colors still result in a slightly desaturated look. The gamma seems correct but the colors are not.

This thread has been super insightful. Thanks!

Re: Final Explanation of Gamma and Color Shift Problems

PostPosted: Mon Jan 13, 2020 3:12 pm
by whitetree
Brian Williams II wrote:As simply as I can describe it, we took the export from Resolve 16 and re-encoded through Adobe Media Encoder, and every application from then on showed us what we were seeing in Resolve correctly again. I don't know the exact explanation for this, but I can say it fixed our problem.


This actually does work perfectly. It definitely doubles the size of the project, but at least gamma and colors are almost identical to what I see in DVR 15. Thanks!

Re: Final Explanation of Gamma and Color Shift Problems

PostPosted: Mon Jan 13, 2020 5:52 pm
by Andrew Kolakowski
You realise that it does nothing to video itself- just changes MOV headers, which can be done with JESExtensifier app (or OSX Automator) in 3sec without doubling any data etc.

Re: Final Explanation of Gamma and Color Shift Problems

PostPosted: Mon Jan 13, 2020 9:35 pm
by waltervolpatto
Andrew Kolakowski wrote:You realise that it does nothing to video itself- just changes MOV headers, which can be done with JESExtensifier app (or OSX Automator) in 3sec without doubling any data etc.


I still like to do a export at a better quality (like prores 444) from resolve then use adobe media encoder for the h265 and the correct flagging....

Re: Final Explanation of Gamma and Color Shift Problems

PostPosted: Mon Jan 13, 2020 10:58 pm
by Andrew Kolakowski
For that I would not use AME at all. ffmpeg is your better friend. AME is average. It uses mainstream Mainconcept SDK for most codecs. It's only latest AME version which got eg. HDR flagging- not tested it though but there is no way it will be better than x265 quality wise anyway (+x265 allows for any flagging).

Re: Final Explanation of Gamma and Color Shift Problems

PostPosted: Tue Jan 14, 2020 1:42 am
by waltervolpatto
Andrew Kolakowski wrote:For that I would not use AME at all. ffmpeg is your better friend. AME is average. It uses mainstream Mainconcept SDK for most codecs. It's only latest AME version which got eg. HDR flagging- not tested it though but there is no way it will be better than x265 quality wise anyway (+x265 allows for any flagging).


personally (and it is just me), I don't use ffmpeg at home: even if it is a superior encoder, I have the AME handy and it's a lazy, no brain solution...

at work they do what they do, I'm not in the loop.

Re: Final Explanation of Gamma and Color Shift Problems

PostPosted: Tue Jan 14, 2020 1:02 pm
by Frank Engel
Andrew Kolakowski wrote:For that I would not use AME at all. ffmpeg is your better friend. AME is average. It uses mainstream Mainconcept SDK for most codecs. It's only latest AME version which got eg. HDR flagging- not tested it though but there is no way it will be better than x265 quality wise anyway (+x265 allows for any flagging).


Be careful with ffmpeg as in some countries (such as the USA) it may violate patents in the codecs which are not licensed correctly by the project.

Re: Final Explanation of Gamma and Color Shift Problems

PostPosted: Tue Jan 14, 2020 6:14 pm
by Andrew Kolakowski
Until you don't put 1000s of files online and try to make money on it, this is really not a problem.
It's really a problem for big organisations like BBC etc.
I don't live in USA.

If you want to make online service and encode files with AME to h265 you will be responsible for the same licensing fees as in case of ffmpeg. There is nothing illegal in x264/5 in ffmpeg.

Re: Final Explanation of Gamma and Color Shift Problems

PostPosted: Tue Jan 14, 2020 6:58 pm
by Cosmin Hodiș-Mîndraș
After spending way too much time chasing "perfect", I settled for "good enough". Adobe's Caroline Sears wrote an explanation for "Why does my footage look darker in Premiere?" and published a LUT made by "one of their engineers" (https://community.adobe.com/t5/premiere ... -p/4788414).

A quick examination in Lattice reveals a simple 3x1024 1D LUT which does what it says it does (it has quite an extensive description in metadata).

But adding a Gamma -0.06 final node to my grade seems to do the same thing (tested on a grayscale image, using scopes to compare). And the end result is quite there, if not identical to Resolve's colour viewer. So, after playing with crazy LUTs made using HALD images from screenshots, I settled for a slight gamma adjustment.

Re: Final Explanation of Gamma and Color Shift Problems

PostPosted: Wed Jan 15, 2020 3:31 am
by Dmytro Shijan
Andreas Fiebig wrote:Thanks Dmitry and all others for investigation and your work.
I am grading in Gamma 2.4 with a Gamma 2.4 timeline and will use JESExtensifier.app to set correct Gamma after using a CST node on timeline.

What about iOS? Anyone knows how it handles video metadata? Same as Quicktime Player on MacOS?


I really wonder why so many people keep posting complicated and inconvenient things when simple fix based on multiple tests was already described in details: just use YRGB project and set timeline to Rec709(Scene). Rec709(Scene) timeline will affect only metadata tags for output. Inside that Rec709(Scene) tagged timeline you can grade in any desired wide color space, or in any Log or Rec gamma you want.

If you grade in Gamma 2.4 and apply Rec709 gamma (1-1-1) with JES tools later - your footage will have different gamma look from what you see in Resolve viewer during grading. So you need to guess that gamma shift. This is also inconvenient scenario.

For those who not sure how to setup things i created example project archive that may help better understand workflow details described earlier in this post viewtopic.php?f=21&t=65149#p537852
:arrow: You can download project archive here: https://www.dropbox.com/s/kwcgdada65lub ... e.zip?dl=0

Re: Final Explanation of Gamma and Color Shift Problems

PostPosted: Wed Jan 15, 2020 3:43 am
by Dmytro Shijan
Cosmin Hodiș-Mîndraș wrote:After spending way too much time chasing "perfect", I settled for "good enough". Adobe's Caroline Sears wrote an explanation for "Why does my footage look darker in Premiere?" and published a LUT made by "one of their engineers" (https://community.adobe.com/t5/premiere ... -p/4788414).

A quick examination in Lattice reveals a simple 3x1024 1D LUT which does what it says it does (it has quite an extensive description in metadata).

But adding a Gamma -0.06 final node to my grade seems to do the same thing (tested on a grayscale image, using scopes to compare). And the end result is quite there, if not identical to Resolve's colour viewer. So, after playing with crazy LUTs made using HALD images from screenshots, I settled for a slight gamma adjustment.


Probably this -0.06 value bring gamma back to simplified system wide MacOS video gamma 1.961. Effect similar to things described here viewtopic.php?f=21&t=101253&start=100#p565890

Not a perfect solution, because after this adjustment image will start look too dark in Windows and in MacOS non color managed players like VLC

Re: Final Explanation of Gamma and Color Shift Problems

PostPosted: Wed Jan 15, 2020 11:42 am
by Andrew Kolakowski
In a wider view whole process solves nothing (as it can't be properly solved).

Re: Final Explanation of Gamma and Color Shift Problems

PostPosted: Wed Jan 15, 2020 2:59 pm
by Wayne Steven
I think the thread has run it's course.

Re: Final Explanation of Gamma and Color Shift Problems

PostPosted: Thu Jan 16, 2020 12:44 am
by waltervolpatto
I really wonder why so many people keep posting complicated and inconvenient things when simple fix based on multiple tests was already described in details: just use YRGB project and set timeline to Rec709(Scene). Rec709(Scene) timeline will affect only metadata tags for output. Inside that Rec709(Scene)


Because I want and need the timeline color space to be something completely different.

Re: Final Explanation of Gamma and Color Shift Problems

PostPosted: Fri Jan 17, 2020 7:34 pm
by JPOwens
waltervolpatto wrote:Ain't rocket science.


That's what we say here down at the neurosurgery ward.

Andrew Kolakowski wrote:In a wider view whole process solves nothing (as it can't be properly solved).


Because it's "digital" is almost meaningless when most users casually assume the consumer attitude that when they order *a sandwich*, they will somehow get what they had in mind. Why did I get tuna salad when I specifically wanted beef? Sometimes you actually have to know what you want, ask for it by name, and know what the difference is.

Gone Sailing.

Re: Final Explanation of Gamma and Color Shift Problems

PostPosted: Sun Jan 19, 2020 8:20 am
by Wayne Steven
It seems here people actually order beef and the service person returns with Tuna salad.

The situation is weird. People grade on little screens, but on big TV it looks different and at different distances, and in theatre it's going be different. It's going change the flavour of sandwich at each context. That's also why I don't believe perfect everything at the beginning is not absolutely needed, as long as it's very/close, and the drift still looks good. People here are actually saying take a bullet on the colour space to get a calibrated result. The solution, apart from a new wide standard, code base band education, like I said, is obvious, I suppose Black magic will start making displays for grading and editing that resolve can be perfectly mapped too, and toggle GUI switches to show what it will look like on target devices along with controlled lighting rigs and resizable screen output, to emulate different target viewing situations.

Could I suggest that such displays could have room for two or more replaceable GPU cards out back, and multi TB ports, to also do the job of an external GPU. You plug your laptop or tablet into the display and edit or grade. Very compact and portable. This also means BM will have the equipment list to franchise out grading room setups. If they can do the same for equipment for production trucks, like certain big boys do, they can make a high end dent with different grades trucks, and truck kits you can out gut your own, and equipment logger scanner to auto order top up supplies for truck kits, and order list pages. There are small companies out there who might like to get into supplying the equipment BM currently doesn't on co-operation. Like coca cola and their store fridges of the past,, the industry has been giving it away to certain big boys, when they could have fought.

Re: Final Explanation of Gamma and Color Shift Problems

PostPosted: Sun Jan 19, 2020 4:33 pm
by waltervolpatto
Wayne, one of the issue pointed out was that after the export, on the same monitor, with different applications it looks different.

That's one of the main issues, I don't think we're talking about difference in perception of different viewing conditions.

And "color correction mobile trucks" exist.

Re: Final Explanation of Gamma and Color Shift Problems

PostPosted: Sun Jan 19, 2020 4:51 pm
by Wayne Steven
Sorry, I meant production gear trucks. It's not that they don't exists, it's that the high end competition has them in a no worries package, which big budget find important. Even if the micro was as good or better, those sort of things matter to big budgets.

Anyway, I'm saying if it changes so much in perception, absolute accuracy is probably not needed as much. But that is a side comment.

The thread has been going for a while, and I eventually stopped reading it, and marked it to read some other time.

But I missed the same equipment and software produces different results. Are you saying the display, the card, computer and software setup are the same, but the same file displays more than a few percent different? What gives? Manufacturing differences on displays in their thousands should be close in general intent of levels once calibrated (though uniformity might be different).

Re: Final Explanation of Gamma and Color Shift Problems

PostPosted: Mon Jan 20, 2020 1:54 pm
by Robin Erard
Hello,

I use 16.1.2 on MacPro 2019 with Catalina,

My project is color managed :

- Input Rec709 gamma 2.4
- Timeline Rec709 gamma 2.4
- Output Rec709 gamma 2.4

I rendered in Prores4444 and Miracle !!! The render is tagged 2.4 (I can check that into Jes Extensifier).

Best

Robin

Re: Final Explanation of Gamma and Color Shift Problems

PostPosted: Mon Jan 20, 2020 10:39 pm
by Andrew Kolakowski
It has been like this for quite a time.
It again solves not much. Put those files to the wildness (youtube, Vimeo etc.) and all this this tagging will be lost.

Re: Final Explanation of Gamma and Color Shift Problems

PostPosted: Mon Jan 20, 2020 10:41 pm
by Dmytro Shijan
Robin Erard wrote:Hello,

I use 16.1.2 on MacPro 2019 with Catalina,

My project is color managed :

- Input Rec709 gamma 2.4
- Timeline Rec709 gamma 2.4
- Output Rec709 gamma 2.4

I rendered in Prores4444 and Miracle !!! The render is tagged 2.4 (I can check that into Jes Extensifier).

Best

Robin

Yes, Resolve works like this, but problem source is different (read explanation and tests in first post viewtopic.php?f=21&t=101253#p560853 )

Try to transcode it with Handbrake or with YouTube to MP4 and and Miracle !!! The video is tagged as Rec709(Scene) and now looks different in QuicktimeX Player and other color managed macOS apps.

If you on Windows or use VLC player you will not see any difference because those gamma 2.4 or Rec709 tags are just ignored.

Re: Final Explanation of Gamma and Color Shift Problems

PostPosted: Tue Jan 21, 2020 3:59 pm
by Robin Erard
Hello,

Ok, I don't understand something.

My workflow is Rec709 game 2.4 calibrate (Lightspace etc...). For DCP it's not a problem because the DCI rules are very precise and colortransform (Rec709 gamma 2.4 > DCI XYZ Gamma 2.6) are well known.

But how can I be sure that VLC takes in consideration that my Prores is gamma 2.4 if it doesn't read any metadata ?

All my prores output are made to be seen on 2.4 screen. So how this information is passed to VLC ? (for example, if a computer has a monitor gamma 2.2, how my prores gamma 2.4 will appear on it).

Best

Robin

Re: Final Explanation of Gamma and Color Shift Problems

PostPosted: Tue Jan 21, 2020 4:53 pm
by Dmytro Shijan
VLC doesn't read any metadata in the way that QuicktimeX Player reads it. VLC can read only Rec2020 color space tag and HDR tags, and it's color management don't depend of macOS system color management.

Display gamma and color space is not directly related to video file gamma. It is separate device dependent setting (same as scanner input ICC profile don't related to sRGB image profile). You can calibrate monitor to sRGB or to Gamma2.2 or Rec709, or any other setting you prefer depending of light source brightness in your room and personal taste.

The problem is that color management between video source and monitor profile is also implemented differently between different OS and systems.

macOS native color managed apps transforms source gamma and color space of video (and image as well) to monitor gamma and color space.
Different calibration apps create Monitor ICC profile in different way.
There are some specific ICC options inside Monitor ICC profile that may affect how system reads and transforms gamma and color.
I use DisplayCAL app to calibrate monitor. After huge amount of tests it appears for me that ICC profile generated in DisplayCAL with sRGB gamma looks better than gamma 2.2 or 2.4. Probably because all original macOS monitor profiles are use sRGB gamma and so macOS color management adjusted and optimized to transform all source files to into Monitor profile with sRGB gamma curve.
I repeat - i only tested DisplayCAL app. There are other calibration apps that may generate monitor ICC profiles with sRGB gamma that may interact with macOS in very very different way.

Windows system wide do all things in simpler and non-color managed way - it just assigns Monitor ICC profile to Source video (it don't transforms one color space/gamma into another). Graphic and video apps inside Windows usually use their own color management systems to transform image/video color spaces/gammas. Those systems also may produce different results.
Same monitor profile with sRGB gamma that works well for me on macOS probably will look way different in Windows environment. For Windows people usually calibrate monitor to gamma 2.2 or 2.4.

Re: Final Explanation of Gamma and Color Shift Problems

PostPosted: Tue Jan 21, 2020 11:17 pm
by Dmytro Shijan
There are also a lot of different ways to apply monitor calibration:
- Most monitors use software dependent correction with ICC profiles. Simple but it usually produce slight quality loss in gradients smoothness.
- There are also more professional monitors that able to use hardware LUT-based correction. You upload LUT or ICC profile directly to monitor and it's gamma and color space correction became software independent.

Re: Final Explanation of Gamma and Color Shift Problems

PostPosted: Thu Jan 23, 2020 3:56 am
by Marc Wielage
Isn't it amazing that after 4 months and 237 messages, there's still no Final Explanation? It's as if it's a complex problem that has nothing to do with Resolve.

I still find that no matter what you do and how accurate the final file delivery is, you're still at the mercy of the monitor playing back the image. Unless you can control that whole signal chain -- the file, the playback engine, the color management, and the calibration of the display -- it's all chaos theory. Just one of those things being wrong can upset everything.

It would be nice to see a chapter added to the Resolve manual about color management with the deliverable file, just to explain why things can and will go horribly wrong, but it's not an easy subject. Since I haven't done it in a few weeks, I'll post these links again for those who tuned in late:

"Grading for Mixed Delivery" by Cullen Kelly
https://blog.frame.io/2019/10/14/gradin ... -delivery/

"Color Management for Video Editors"
https://jonnyelwyn.co.uk/film-and-video ... o-editors/

For the record, I have had good luck with uploading a simple ProRes 422LT file to Frame.io and watching Frame.io on an "average" computer display. One key is to make sure the PLUGE pulse is set correctly in SMPTE color bars. Without that, it's going to be a total crapshoot.

Image

Re: Final Explanation of Gamma and Color Shift Problems

PostPosted: Fri Jan 24, 2020 12:39 pm
by Wayne Steven
I agree, but I think the finale setting in the monitor and player, should be the user's preference.

Re: Final Explanation of Gamma and Color Shift Problems

PostPosted: Thu Jan 30, 2020 3:50 am
by Alex Potemkin
Hello Dmitry, Andrew!
Thank you, you just helped me to solve another problem linked to the one discussed here.

I struggled with grading Sony HLG footages to rec 709. I used the recommended and expected workflow with DaVinci YRGB Color Managed configuration, separate color space and gamma, with input and timeline set to Rec.2020+Rec2100 HLG and output set to Rec.709 20.4

The result was terrible. Rendered footages appeared with a HUGE color shift, lost contrast and oversaturated colors, harsh gradients, totally unusable. They aren't match not my GUI (not-calibrated) nor calibrated monitor connected via DeckLink.

After reading this thread I tried to play with the output and timeline setting.

Here is the results.

1. With Color Management set to DaVinci YRGB and timeline set to Rec.709, I managed to receive pretty good results, both using CSTnode, 3DLUTCreator for color space conversion, or just grading with regular DaVinci tools. The resulted footages look pretty close to calibrated monitor in QuickTime viewer (yes, with some slight differences but it is close enough for my needs). The results are pretty the same with Timeline set to Rec.709 scene and Rec.709 Gamma 2.4, though the Gamma 2.4 export looks closer to uncalibrated GUI viewer and "Scene" export was closer to the calibrated monitor - but the difference are not critical.

2. But which is more important, the "pure" workflow with Color Management set to DaVinci YRGB Color Managed, with HLG timeline and Rec.709 output, works just perfect when I set Output Color Space to Rec.709/Rec.709!

As I wrote above, I found no critical differences between Timeline set to Rec.709 scene or Rec.709 2.4 - at least for my needs (I works for stock videography, and I have no real clients, so I don't need to be extremely precise in my grading - it should look "nice" and more-less properly but not more). But the level of color and contrast distortion in clips produced from HLG footages with HLG input/timeline and Rec.7-9 2.4 output was totally unacceptable. Setting the Output Colore Space into Rec.709/Rec.709 solved this problem.

Some screenshots attached. The resulting footage in QuickTime in front of DaVinci GUI viewer with the open Color Management settings; filenames in the QuickTime windows' titles describe the process and the corresponded settings are on the screen. Please take a closed look to the 2020 HLG -> Rec709 2.4 results (the last screenshot).

ice_screenshot_20200129-175058.jpg
ice_screenshot_20200129-175058.jpg (281.68 KiB) Viewed 25645 times

ice_screenshot_20200129-172526.jpg
ice_screenshot_20200129-172526.jpg (283.06 KiB) Viewed 25645 times

ice_screenshot_20200129-171905.jpg
ice_screenshot_20200129-171905.jpg (293.6 KiB) Viewed 25645 times

Re: Final Explanation of Gamma and Color Shift Problems

PostPosted: Thu Jan 30, 2020 4:45 pm
by Cary Knoop
I would not recommend limiting the gamut at the timeline color space, the limiting should be set at the output color space. You can gamut limit while grading using the appropriate OFX or automatically at the color settings at the project levels.

Check your rendered result back in Resolve if there is no shift you have a setup problem.

Re: Final Explanation of Gamma and Color Shift Problems

PostPosted: Fri Feb 07, 2020 9:02 pm
by jacobsch
I want to thank Dmitry Shijan and Cosmin Hodiș-Mîndraș for their work!

All I have ever wanted (and I'm sure countless million out there too) is a surefire way to monitor SDR footage on my iMac for web upload only and have it look identical in the Resolve viewer and when uploaded to YouTube and Vimeo. Thanks to their work, I now just set my timeline to Rec709 (Scene), use the Rec709_Scene_to_Mac_21 LUT and voila, I get 99% accuracy for my needs. Literally a game changer. Thank you so much!

I now want to buy a good (enough) viewing monitor to use with Resolve's new "Video Clean Feed" feature to be able to monitor accurately (enough) on a larger screen. My question is, how can I replicate this process to use with a third party monitor? Cosmin, could you let me know if it's possible?

We'd also need a separate LUT for the third party monitor and the ability for Resolve to send a different LUT to the monitor than to the Viewer. Is this possible? Is that what the "3D Video Monitor Lookup Table" would do?

Many thanks in advance :-)

Re: Final Explanation of Gamma and Color Shift Problems

PostPosted: Tue Feb 11, 2020 9:01 pm
by koraybirand
My solution is as follows..
Source file in QTPlayer
Video and Color Monitor in Resolve
Exported rendered file
Exact match..
Image

the lut file needed is found on this post but just in case if you need it:
https://drive.google.com/open?id=1FFUbw ... gMH0LFfgQR

Koray Birand

Re: Final Explanation of Gamma and Color Shift Problems

PostPosted: Thu Feb 13, 2020 5:19 pm
by waltervolpatto
@koraybirand, change the LUT math method from trilinear to thetraedrical, less banding better math for LUTs...

That works only as clumsy workaround: in order to proper manage the output a [explicit color tag] option need to be inserted in the delivery page and that need to be disassociated from the timeline color space.

forcing the main color working space to be something you don't want or need just to fix a tag in export is ridiculous...

Re: Final Explanation of Gamma and Color Shift Problems

PostPosted: Thu Feb 13, 2020 5:23 pm
by Andrew Kolakowski
Exactly.

Re: Final Explanation of Gamma and Color Shift Problems

PostPosted: Thu Feb 13, 2020 5:42 pm
by Dmytro Shijan
waltervolpatto wrote:@koraybirand, change the LUT math method from trilinear to thetraedrical, less banding better math for LUTs...

That works only as clumsy workaround: in order to proper manage the output a [explicit color tag] option need to be inserted in the delivery page and that need to be disassociated from the timeline color space.

forcing the main color working space to be something you don't want or need just to fix a tag in export is ridiculous...


Can't see nothing wrong in those screenshots. Render set to Rec709, metadata(timeline) set to Rec709 as well. He just add LUT for preview only to upscale Rec709 to P3 display color space. Seems like normal way to go.

P.S. thetraedrical LUT math is better for sure.

Re: Final Explanation of Gamma and Color Shift Problems

PostPosted: Thu Feb 13, 2020 5:43 pm
by waltervolpatto
Andrew Kolakowski wrote:Exactly.


LOL I don't remember last time we agreed so precisely!

Andrew, I never take the time to properly thank you for your posts and your technical expertise and help on this forum!.

Re: Final Explanation of Gamma and Color Shift Problems

PostPosted: Thu Feb 13, 2020 5:52 pm
by jacobsch
waltervolpatto wrote:forcing the main color working space to be something you don't want or need just to fix a tag in export is ridiculous...


With all due respect, the state of color management for simple SDR web-only workflows is what's ridiculous. The vast majority of people grading in Resolve do not work in fully-fledged color houses with a team of techs keeping abreast of the latest developments, calibrating monitors, evaluating pipelines and running batteries of tests. All we want is a surefire way to upload to Vimeo or YouTube and see 98% of what we labored over in Resolve. So for that I am extremely grateful for this Rec709 (Scene) / P3 LUT workaround.

Since this workaround is limited to an iMac GUI monitor, I reiterate my question of how to replicate this on a third-party computer monitor (fed out from Resolve via the "Video Clean Feed" function). Can someone help me there?

Many thanks in advance.

Re: Final Explanation of Gamma and Color Shift Problems

PostPosted: Thu Feb 13, 2020 5:55 pm
by Andrew Kolakowski
We agree more than it seems from actual posts :D

Re: Final Explanation of Gamma and Color Shift Problems

PostPosted: Fri Feb 14, 2020 3:29 am
by Wayne Steven
koraybirand wrote:My solution is as follows..
Source file in QTPlayer
Video and Color Monitor in Resolve
Exported rendered file
Exact match..
Image

the lut file needed is found on this post but just in case if you need it:
https://drive.google.com/open?id=1FFUbw ... gMH0LFfgQR

Koray Birand


Koray. Thanks for your contribution.

It is what it is, there is no need to be too disparaging here guys.