Weird color changes when exporting (Adobe PP)

[Turboguard]

So I'm working on this portrait piece and have heavily graded it to my liking. 

After encoding it and converted my final grade, Premiere changes the colors for me.

Look at attached image, left side is converted Prores HQ 422 and right is my Program window in PP.

Why does this happen?

Thanks

[Mikey R]

Hi Turboguard, could be a few things - quicktime gamma shift - http://www.thedvshow.com/vault/detail.php?id=QT Gamma Stripper, could be PP's h264 encoding http://nofilmschool.com/2014/09/massive-difference-export-quality-fcpx-and-premiere-pro 

Try playing the file in VLC and see if that helps..

The other thing is PP has no built in colour management, so afaik you have to use a (lut?) calibrated external display with a seperate ouput as you can't really trust the colours in PP's gui window https://forums.adobe.com/thread/1733974

Hopefully someone else with a bit more knowledge can chip in here..

Good luck!

[Turboguard]

My workflow is usually match up most of my footage (RAW) in Davinci, then encode as ProRes, then color with Filmconvert, Threeway etc in PP. I've never seen this happen before, that's why I got so confused by it happening.

 

And thanks, I'll give your links a read!  

[andrgl]

Sort of off-topic but not, vimeo and youtube reencoding can mess with your colours too. I've had 255,255,255 white get shifted to magenta.

[AKH]

This might be a helpful link:

http://www.drastic.tv/index.php?option=com_content&view=article&id=202:prores-colour-shifts-in-post-production&catid=59&Itemid=94

Also have a look at the stopp.se article linked in the page.

[cantsin]

The problem lies deeper than just with QuickTime - it has to do with the fact that consumer HD video (including HDTV, web video and DSLR video) is recorded in the Rec709 color space, and Rec709 has no defined standard gamma. In other words, color science in today's consumer video technology is a completely screwed up and an unrepairable mess. It's years behind digital photography where sRGB and AdobeRGB are solid color spaces that make sure that colors of digital stills remain consistent across platforms and software applications.

The only fix will be, on the consumer end, Rec2020, the color space defined for 4K/UltraHD, and ACES, the new color space defined for postproduction (that has the potential of replacing today's vendor-proprietary log color spaces and raw video). Unfortunately, today's consumer 4K/UltraHD cameras, flatscreen TVs and streaming web sites do not implement Rec2020 yet, but still use Rec709. ACES 1.0 has been standardized just a month ago and will take years if not a decade to find its way into cameras and post production.

[Luke Mason]

The problem lies deeper than just with QuickTime - it has to do with the fact that consumer HD video (including HDTV, web video and DSLR video) is recorded in the Rec709 color space, and Rec709 has no defined standard gamma. In other words, color science in today's consumer video technology is a completely screwed up and an unrepairable mess. It's years behind digital photography where sRGB and AdobeRGB are solid color spaces that make sure that colors of digital stills remain consistent across platforms and software applications.

The only fix will be, on the consumer end, Rec2020, the color space defined for 4K/UltraHD, and ACES, the new color space defined for postproduction (that has the potential of replacing today's vendor-proprietary log color spaces and raw video). Unfortunately, today's consumer 4K/UltraHD cameras, flatscreen TVs and streaming web sites do not implement Rec2020 yet, but still use Rec709. ACES 1.0 has been standardized just a month ago and will take years if not a decade to find its way into cameras and post production.

​I'm afraid that's not accurate.

Yes for a long time BT.709 did not have a specific decoding gamma, but in 2011, ITU published BT.1886 standard which gave BT.709 and BT.2020 a well-defined decoding gamma (a "smart" gamma curve that adapts to displays' actual black level - after calibration of course). 

[cantsin]

I stand corrected - but the problem still seems to be that BT.1886 gamma came late and isn't universally used in Rec709 implementations. Particularly not in computer video (where compatibilty issues between Rec709 and sRGB, plus non-standard Rec709 implementations do abound). 

[hmcindie]

Premiere doesn't change anything for me, but different players display differently. Try importing that prores back into Premiere to see if there is actually any difference.

[cantsin]

This page provides valuable information:

http://www.drastic.tv/index.php?option=com_content&view=article&id=202:prores-colour-shifts-in-post-production&catid=59&Itemid=94

Scroll down to section "ProRes Problems/Issues". This one here is particularly telling: 

QuickTime Player is not to be trusted.  Period.  On Windows, with ProRes, it is actually always wrong, using a 1.8 gamma when a 2.2 display gamma is necessary.  This is true no matter what the ProRes header says or any colr atoms.  Interestingly, you can get the correct gamma briefly with QuickTime Player on Windows:  Load 2 ProRes MOVs and switch between them:  The one that does not have focus will have the correct gamma!  Useless, but interesting.

With QuickTime X on OS-X, there are less playback issues than Windows, but when you export ProRes it adds a strange red hue to the video.  The workaround is to post install QuickTime 7 and use that instead.