I’ve received a colour correct from a un-named but well known companythat I have loaded just the same as any other job, and exported as well. The client says my final is brighter, and sends a screen grab of side by sides, one the stringout provided by the colour company, and the other my final spot. Indeed, mine is brighter. It’s become a Major issue. Anyone have any ideas? For the record, I can round trip endlessly without any change, so it’s not a problem with my exports
1 Like
Gamma 2.2 vs 2.4?
Or headroom?
1 Like
What can I do to correct that?
I’m not in front of my computer right now but you’re looking for some thing in the color management node where you first remove gamma 2.4 and then apply gamma 2.2.
Also, you really deserve a ProRes render of the grade of at least one shot from the color house.
Someone sending you a screen grab still from a Mac using QuickTime or anything else is not a good time.
what about “headroom.” I haven’t had to worry about that since video tape input days
2 Likes
Did they send you 4444 ProRes?
yes
Then go back and reimport one of them with headroom enabled and/or disabled. See if that lands in the same place.
Headroom just makes it brighter. I’m trying the gamma thing now.
1 Like
I hate to refer back to the fb logik forum. But there’s a big thread on there about this. Are they judging off a QT? Apparently if they view it in anything besides QT player it’s ok. Apparently, there’s a shift between what QT player tags the file as.
That’s what I’ve been saying, but people’s eyes just glaze over. I need to reverse engineer the actual correct CC so they see what they saw from the co. that made it. I think Randy has set me on the right path.
1 Like
If it’s not gamma 2.2 or 2.4 or headroom something is seriously screwed. Which is unlikely.
Thanks for the speedy and helpful responses today. Sadly this is a cluster fuck and my producer refuses to believe that it’s not broken. He seems convinced that we are doing something wrong and have to fix it.
Hi Tim. Sorry you’re running into this, especially on a Sunday. Not sure if you’ve solved this yet, but reading this thread brought back some memories of one very specific issue I ran into a few years back. It took a while for the cogs to turn in my mind and for me to really remember the verdict, but it’s awfully similar to what you’re describing. I’ll write some stuff down just in case it helps you or someone else one day.
What I ran into has to do with some advanced .mov colorspace metadata. If I’m remembering correctly, Baselight exported a .mov with metadata that flagged the file as having primaries that were “unspecified” or “reserved”. The way you check this is by looking at a .mov in the media hub -> metadata tab and twirl open the YCbCr Colo(u)r Encoding line and you’ll see this:
The number 1 for Primaries, TransferFunction, and Matrix signifies in metadata-speak that this file was tagged as ITU-R BT.709. Jumping back to the issue I had years ago, Baselight exported it with some or all of them as either 0 (which means reserved) or 2 (which means unspecified) and I can’t recall if this was intended and that’s “just how Baselight flags it” or if it was an error. The bottom line was that when we imported it into Flame as “Unknown”, since Flame doesn’t do any automatic color management, it didn’t matter what the metadata was, because we were reading it the same way we always read it. But that is NOT the case for our friend Quicktime Player, which sees those flags and does all sorts of exciting color stuff under the hood behind the scenes with no ability to control anything. This was the issue. The creative who couldn’t be in the color session looked at the Baselight export and approved it. Once we exported ours, it was “different” and “wrong” even though the culprit at the end of the day was Quicktime Player. In the room, the clients saw the correct colors. In the Flame session they also would have seen the correct colors. Technically, our Flame export was “more correct” in Quicktime than the Baselight export, but of course that doesn’t hold much water.
If I’m remembering correctly, I think the solve was for color to apply an adjustment across the whole spot, just bumping everything overall roughly accounting for the Quicktime shift.
7 Likes
So the clip I have has TransferFunction 2. Whereas, what I export is 1. So I assume my client saw her colour correct as unspecified, and Quicktime Player did it’s thing.
3 Likes
Wow! Yes! Looks like it’s the same scenario! If the screenshot they supplied is indeed Quicktime, then yeah, wow, what I described is exactly what happened to you.
You now have some more evidence supporting your claim that you’ve done nothing wrong.
4 Likes
Thanks. This has been a HUGE help.
5 Likes
This is a relatively new feature of Baselight where they’re adjusting the tagging in QTs to be “proper”. Gotten stung by this as well. You can also re-run your output through resolve to change the tagging or use BBC’s utility to change the flags.
5 Likes
So pardon the nob question, do we just need to make sure that the metadata in the qt file is correct? This surely can’t be too hard to fix? And BTW the BBC utility was not as simple as downloading an app and running it. It’s the world of source code and terminal commands.