Preventing Color/Luma Shifting When Processing DNGs in Adobe Camera RAW

[stevefal]

I posted a feature request/bug at Adobe and started a discussion on their forum. Chime in for visibility:  http://forums.adobe.com/message/6334477#6334477

~~~~~~

Discussed at http://www.magiclantern.fm/forum/index.php?topic=5710.0

People using ACR to import video image sequences into After Effects have discovered that ACR's highlight recovery and other exposure controls produce varied exposures depending on the content of each frame.

The result is "flickering" in the rendered video when the scene changes such as when light or dark objects come into view.

Users have experimented with Process 2010 and Process 2003, but they all exhibit the same problem to some degree.

The problem makes ACR unusable for some video shots where it would otherwise be a great solution due to its superior highlight recovery.

I discovered this issue when reviewing my footage rendered from After Effects. Any with significantly bright or dark objects coming into frame changed the exposure of the rest of the frame, irreparably.

SUGGESTION
The suggestion is to offer an “Exposure Lock” feature in Adobe Camera RAW, which would lock the absolute exposure values determined via the prototype frame (typically the first frame), and use those for every frame of video rendered. This means that exposure computations performed based on the content of each frame would be disabled during rendering. The computations would be performed only when the user interacts with the exposure controls via the ACR UI.

The benefit of this feature is that ACR could be legitimately used to initially process high quality RAW video. A side benefit is any situation, including still photography, where the user needs to match absolute exposure settings between shots.

I hope Adobe will consider adding this feature or something equivalent that provides, for video, ACR’s unsurpassed ability to tame highlights.

[mannfilm]

Fixed with current  ADOBE after effects CC (mac)

If you import DNG's into photoshop CC, the ACR 7.0 opens up as the "photoshop shelled" of ACR,  and you still get the flicker.

BUT if you open After Effects CC, and import the DNG's as a image sequence, a very slightly DIFFERENT version of ACR 7.0 pops up. You can make your changes in this "After Effects shelled" ACR, and it does not flicker.

I assume that the Photoshop version of ACR works as a still editor adapting to each single frame, while the after effects version of ACR works as a video editor and "locks" the effect across all frames.

Confirming this, the exact same ACR control setting produces  different results (in frames other then the "master,") in the photoshop or after effects exported movie.

[stevefal]

I just tested this and AE/ACR CC flickers exactly the same way as CS6. I see no evidence that settings are locked.

I'm beginning to think that the ACR highlight control performs microcontrast adjustments, which, if true, may make flickering inevitable, and the idea of "locking" a fallacy.

[domisol]

Fixed with current  ADOBE after effects CC (mac)

If you import DNG's into photoshop CC, the ACR 7.0 opens up as the "photoshop shelled" of ACR,  and you still get the flicker.

BUT if you open After Effects CC, and import the DNG's as a image sequence, a very slightly DIFFERENT version of ACR 7.0 pops up. You can make your changes in this "After Effects shelled" ACR, and it does not flicker.

I assume that the Photoshop version of ACR works as a still editor adapting to each single frame, while the after effects version of ACR works as a video editor and "locks" the effect across all frames.

Confirming this, the exact same ACR control setting produces  different results (in frames other then the "master,") in the photoshop or after effects exported movie.

Thanks for this information.
Can you source it or does that come from your own experience ? How is it that you use ACR 7 ? Do you mean that this works only with 7 and not 8 ?
This doesn't work for me, using last version AE CC on Os X, with ACR 8.4.1 : 2012 process gives me slightly exposure differences in highlights betweens frames.

Jean-David
 

[Rafael Duarte]

Hello, everyone. I have also tried AE CC on Mavericks and the flickering is also there, albeit less.
I have downloaded Davinci Resolve 11 beta yesterday and they have added some new options on the camera raw tab that are very derivative of camera raw. Besides exposure, temperature and tint, there is now highlights and shadows, color boost (which seems relative to vibrance) and midtone detail (which seems like clarity). I gave just a brief look but it seems nice. Maybe Blackmagic has been hearing us after all.

[seb_]

Saw this in the RAWMagic thread. Looks like it could be a solution, if it could be implemented in one of the raw converter tools

"I have a suggestion, which may or may not be a good idea!

It concerns a possible fix for putting the CDNG's through ACR, which sometimes causes exposure variances, even with using Process 2010 in ACR. It seems that ACR needs the lightest and darkest points in the frame to be constant, otherwise any highlight or shadow recovery causes the exposure shifts.

If RawMagic could add another 2 lines to the image, say a pure white one at the top and a pure black one at the bottom, this would fool ACR into treating the high and low point of all the frames as the same (because they would be the same!)"

Yes, I tried this and it solved the flickering issue for me!

I have to add that I don't use Magic Lantern and RAW video, though. I just grade my regular H.264 videos in ACR and AE. But since it seems to be an issue with ACR, this should work with RAW footage as well.

[stevefal]

I don't think this works reliably. I believe that ACR's algorithms behave based on the number of white/black or highlight/shadow pixels in the image, not just the existence of some. For instance, an image that is mostly black with a little light, will be changed differently than one which is mostly white with a little dark.

The "two lines" approach is the first thing I tested when measuring ACR's behavior, and it did not improve the flickering problem. But trust me, I'd love to be wrong.

Can you demonstrate your technique working with aggressive ACR settings?

Also, what you mean by "grade my H.264 videos in ACR?" How is that possible?

[seb_]

I've only discovered this today, so I haven't had the chance to test it extensively. But I made a short video demonstration. It's not pretty, but it gets the point across.

Recovery and Fill Light sliders were bumped to 100 in both videos. I use 2010 process.

Also, what you mean by "grade my H.264 videos in ACR?" How is that possible?

ACR doesn't only import RAWs, but also other image formats. So I convert my video clip into a TIFF sequence which I then import into AE and grade it with ACR, like I'd do with a RAW sequence (see this video for more

[stevefal]

Well clearly that had a huge impact. I'll have to look at my test data and see if I did the two-line test with Process 2010.

Your unaltered footage seems to clearly show extreme microcontrast, which I assume is from the highlight recovery. I mean, the white clouds are darker than the blue sky, which is weird.

Anyway, cool result.

[stevefal]

I looked at my data and yes, I confirmed that Process 2010 recovery and fill are tricked with black lines. It does not work with Process 2003 or 2012, as those algorithms consider the number of white/black pixels.

I did not try the white line case.

[Danne]

Nice results with 2010 process. Could you try to process with a later process lifting shadows and highlight recovery with the gradient tool and see if that works better as well on the sky clip? My example is from lightroom but works just the same in acr coming from photoshop. Don,t have a good clip to test with.

[stevefal]

Here is my test data and results. Process 2012 is a disaster for this issue:



gradgrey_black


gradgrey_white


gradgrey_white_sliverblack

[Danne]

Hi Stevefal. Are your numbers from the gradient tool experiment?

[stevefal]

My numbers are from testing I did months ago. I wanted to determine how dynamic range of an image impacted the behavior of various exposure controls, and for each of the Processes.

In each test, I tracked the value of an individual pixel before and after making ACR exposure changes, and compared across images that had the same value in that pixel location (150,150), but different overall image dynamic range. A red value means that there was a difference, which essentially amounts to the flicker issue.

The last test image corresponds to seb_'s experiment, in which a small amount of black added to the gradgray_white image negates the differences otherwise introduced. This is only true for Process 2010.

[johannsebastianbach]

It has been two years since the last post in this thread. Things may have changed. I googled this issue with no new solutions so better ask here 

Did anybody solve the problem, or found another way for flicker-free recover highlights in the awesomely way ACR does?

[jmanord]

I am curious as well, and hope to do some simple objective tests in the next couple of days. I have several clips I plan to test, but I don't expect any improvements in results for the controls as outlined by stevefal. However, unless I have incorrect project settings in Resolve, the debayered results from Lightroom's Process2012, before using the highlight or shadow sliders, appears to do a better job preserving dynamic range than the results from using Resolve's highlight recovery slider.

After originally deciding the results from Resolve were good enough, based on how much easier it is to skip Lightroom as part of the workflow, I'm finding that following the ETTR methodology is resulting in too many instances of distracting blown highlights when using Resolve alone. Avoiding the controls that cause issues when using Lightroom's Process2010 profile avoids the flickering problem, but doesn't give results as nice as using Resolves highlight recovery tools. Using Resolve's highlight recovery tools works well, but often introduces bizarre artifacts too the image. I know there are several other raw editors, but Lightroom's stack and auto-stacking features makes it extremely easy to manage clips and apply develop settings to the dngs.

If anything new and helpful is revealed I'll post it here.

[Kharak]

Can not speak for resolve, but to pull back the highlights without introducing flicker, Cinelog-C DCP 2016 will do just that for you and more but you're heading in to log workflow which might seem daunting at first, but there are so many threads and posts on this issue on the forum, that you'll get it no time

[jmanord]

@Kharak - I took your advice and purchased Cinelog-C DCP 2016. After swearing off trying to grade Log footage, I still have a7s slog-2 nightmares, I'm determined to find a quick and effective workflow between Lightroom and Resolve.

My objective test quickly turned into subjective tests. I edited 10 clips shot earlier this month using Lightroom's controls, including those known to introduce flicker, to obtain the aesthetic results I was looking for. After exporting the files to 8-bit tiffs and loading the sequence into Resolve, only 2 clips exhibited visual flickering. Rather than doing individual slider tests to verify which controls introduced the flickering, due to time constraints, I reset all the controls that are known to introduce flicker and verified that the flickering was gone, which it was. I'm optimistic that introducing Cinelog-C DCP 2016 into my workflow will allow me to recover the highlight information I know is in the raw files without introducing additional artifacts.

Before deciding to purchase Cinelog, I wanted to give grading in Lightroom and Resolve one more try and compare my results. After selecting 4 clips and spending a few hours doing my best to achieve a similar look in both programs, I committed the easily avoidable sin of forgetting to save my project in Resolve. It crashed during rendering. Instead of trying to get the clips to match again, I edited them together to demonstrate the differences I experienced in editing the same footage in both. This is the result:

I mostly wanted to show the pink cast and artifacts that often occur in Resolve when trying to recover highlights. The moving center strip is the output from Lightroom. I was fairly happy with the results I obtained within Lightroom while avoiding the Highlights, Shadows, Contrast, Whites, and Clarity sliders. But that was only the case for footage which was exposed to the right by a stop. The footage which was exposed properly or slightly under-exposed, e.g. the third clip in the video above, was easier to grade in Resolve since highlight recovery was not necessary. My fingers are crossed that Cinelog-C tiffs exported from Lightroom will allow me to more easily grade both types of footage in Resolve.

[jmanord]

I wanted to follow up with a video showing an altered Lightroom clip that flickers and a similarly altered Resolve version using Cinelog-C DCP 2016. It may have been better to leave the mask static, but I wanted to be able to scrub between the different areas to compare the outputs. The flickering is more subtle after uploading it to youtube, but if you keep your eyes on the shadow on the left dune you can see it. The Resolve version is the sliding center strip. Sorry for the shaky footage.

[Andy600]

@jmanord - Did you alter any of the raw controls before exporting the tiffs from Lightroom? The profile can't induce flicker if the controls are nulled. It may be that the DNGs themselves have some sort of issue (could be shutter related) or possibly, the output codec. What app did you use to unpack to DNG? Did you use a DNG compressor such as Slimraw or are these straight from the .mlv/.raw file?

If you want to send me that short DNG image sequence I can test it over multiple workflows in AE, Photoshop, Lightroom and Resolve to see where the modulation is occurring.

BTW, I noticed you exported 8bit TIFFs previously!? - 8bits is not enough (10bit min). If you export Cinelog-C to TIFF it should be 16bit.

[jmanord]

@Andy600 - Sorry, my description was not very concise.  I was trying to show that Lightroom's Highlight, Shadow, etc sliders still introduce the flickering. Cinelog DCP solved that problem by exporting the dngs as 16bit tiffs using the Cinelog-C DCP profile in Lightroom and adjusting them in Resolve. I wanted to show how I was able to achieve a very similar look in Resolve from the Cinelog-C tiffs compared to the Lightroom version that had the flickering. Cinelog is awesome, thank you again for your help!

[Andy600]

No problem

I'm still working on the 'Applying Cinelog luts in Lightroom and Photoshop' workflows. It all works but I'll probably need to build a special ICC output profile for Lightroom to get around some of the limitations.

[johannsebastianbach]

Just found this gem. This software is still in the concept phase - they are looking for developers!

http://apertus.org/opencine