How to successfully use the "Sizing" information contained on the XML...?

[Luis Otero]

Hello everyone,

We have unsuccessfully tried to use the sizing information contained on the XML to make it working correctly within Resolve. I will present a real case scenario, and if someone has had any success using it before, or has any suggestion, it will be welcomed if it is shared with us.

I will try to elaborate just enough so you can understand the magnitude of having this function to work correctly. And yes, we have tried to work with BMD support, but apparently this is either to easy, or too hard, that they have not been in a situation before to try to troubleshoot this function with any previous user. So, here we go with the facts:

1. We completed the editing and grading of a 115 min feature shot on Red One - MX at 4.5K resolution.
2. We followed the same workflow we have successfully established for all previous projects, and edited the film using the _M proxy (in FCP).
3. As we all know, Resolve uses the original 4.5K R3Ds for the grading purposes, and scale it down to our projector and monitors resolution (1920X1080 in our case).
4. Since it is about 115 mins in length, it has six reels.
5. It will be theatrically released during last week of February/2012
6. Due to the film's market, it will be printed in both, film and electronically (DCPs).
7. We will be performing the transcoding as 2K DPX sequences per reel.
8. Due to the fact stated in item #6, we will be obviously be generating the two "versions" needed: the one with the film stock emulation LUT burned in for the DCP, and another one without the fully calibrated stock emulation LUT for film printing.
9. There is about 10% of the shots that have some type of re-framing, rotation, added movement, etc.
10. Such information is contained on the XML, technically now we can use it during exporting by taking advantage of the software new feature that can use it to apply it to the shots it was used on, so the exported files will already have such corrections.
11. Previously it was needed to export all the clips as shot, and during conforming, the changes made during editing needed to be "translated" into the new files. I call it "translate" since by virtue of using a different resolution during editing than the one of the final product, it cannot just be copied as an "Attribute". It does not have a 1:1 relationship, so some calculation or "eye-balling" was used.

Now, the big question: is there any right or magical combination of settings that should be played within Resolve so we can take advantage of this feature during final transcoding of the footage? I mean, it it was added as a function to the software, there must be a way to make it to work.

Please, feel free to make any suggestion so we can confirm if we have tried it before without success. It will be greatly appreciated...!!! Remember, six reels, with dual conformance since it will be used for print in film and to generate DCPs. So, if it is usable, the conforming should be a breeze...

Respectfully,

[Luis Otero]

OK, I want to post this just as an update to my question based on responses directly from BMD. As of today, it seems it will work perfectly fine if the size of the material you are grading is the same as the material you edited. If you use Proxies, or even are transcoding before grading, and the dimensions are not the same, the system does not have a calculation function to equalize the two sizing differences.

The advise that I received was to "do a manual by eye comparison in the conform page with an offline video of the finished edit since the development team is committed to other areas for improvement", and cannot add this feature in a fast-track fashion. Also, it was pointed to me that potentially the "Scale to Sequence" function in Final Cut may add another layer of complication to this calculation.

So, we are doing it fully manually, just as before the new function was added as part of the upgrade.

[Marc Wielage]

This was also a problem with previous DaVincis and also the Pogle Pandora. Sizing and Power Windows would not always be correct between standards, or if you color-corrected in 1080 and output in 2K (2048x1556). Usually it was a global problem, but it required extremely careful checking to make sure nothing accidentally slipped through at the last minute.

In the "old days," the editor would send along a low-res QuickTime movie or something for us to use as a match-to source, and we'd double- (or even triple-) check all repos, comps, titles, and so on, usually as a split-screen with the high-res original. (This is easily done with Baselight and Pablo, but a simul reference comparison can only be done with stills in Resolve. At worst, you could take the offline edit, export that as a medium-res file, then take the 2K deliverables, and export those as the same-size file. Do a split on those on an editing system. You'll know immediately when a title is wrong, a repo is the wrong size, an effect is missing, an image is flopped (or needs to be flopped), etc. Dynamic repos are particularly critical, making sure the stop and start are on the precise frame.

I've had clients get tripped up at the last minute, particularly with textless versions, foreign versions, TV versions, and other deliverables that somehow did not get checked as much as the original theatrical version. This is all part of the granular nature of post: you have to keep track of all the little pieces.

[Luis Otero]

That is what we have always done, Marc. However, the thread and question came after the introduction of the "Use sizing information contained in XML" as part of the upgrade. We wanted to take advantage of this new feature to expedite our conformance, but even the BMD were not aware that it works as intended only if both sides of the operation (editing and grading), are done at the exactly same size.

Being this site dedicated to 4-5K footage, this becomes more relevant since it will never work as implemented since the graded data always uses the original size R3Ds, which almost nobody uses for offline editing.

[Marc Wielage]

Yeah, I've seen some hitches with XML data, even during simple conforms. I think it's still a dodgy area.

What happens when you A/B the files? Are you seeing consistent sizing changes? It seems to me if that were so, even the "normal" size material might not be in the right place.

Or is it a percentage slippage, like when you do a 10% blow-up, what you get is 12% (or worse)? I seem to recall when we had this HD/2K problem with the old DaVinci 2K, it was X number of pixels off. We also had issues with blanking on occasion, even going from HD to 525.

I think the only answer for now would be to eye-match everything, and keep a list of all repos just to verify that they wind up in the right relative position.

[Luis Otero]

Yeah, I've seen some hitches with XML data, even during simple conforms. I think it's still a dodgy area.

What happens when you A/B the files? Are you seeing consistent sizing changes? It seems to me if that were so, even the "normal" size material might not be in the right place.

Or is it a percentage slippage, like when you do a 10% blow-up, what you get is 12% (or worse)? I seem to recall when we had this HD/2K problem with the old DaVinci 2K, it was X number of pixels off. We also had issues with blanking on occasion, even going from HD to 525.

I think the only answer for now would be to eye-match everything, and keep a list of all repos just to verify that they wind up in the right relative position.

Marc,

You just nailed it ALL the way through...!!! Right now, if you activate the XML sizing feature, the immediate reaction is to zoom it in, even if the clip size, pan, tilt, or rotate have not been manipulated at all. So, you got it, sir.


Edit: So, that is why this feature will not be an easy cookie to bake to make it work 100% perfect. There will be, at lease, two calculations needed to happen under the hood, so it can work just right: the first is the ratio of size of editing material size vs graded material size, and second, the effect of "Scale to Sequence" when applied to the off-line size material.

[Marc Wielage]

Lucky guess!

[Luca Immesi]

From Davinci Resolve 8 manual:
"Effects Processing in Round-Trip Workflows
In workflows where you want to send a project back to an NLE after grading for final finishing, adding titles and other effects before to final delivery, Resolve handles different effects in different ways.
Unsupported effects do not appear in Resolve. However, the effects data is preserved, invisibly, and when you export an XML file to send back to Final Cut Pro, the effects all reappear, this time applied to the color corrected media that you rendered out of DaVinci Resolve.

Speed effects, composite modes, opacity settings, and transitions are handled differently. Even though these effects are visible in Resolve while you work, they’re not “baked” into the final media that you render in preparation for sending back to Final Cut Pro. Instead, the portion of each media clip that’s used in your project is rendered as an individual file, and the XML file that you export from Resolve contains all the effects information necessary to reassemble the rendered media into a timeline that uses Final Cut Pro effects applied to Resolve-graded media."

According to this my plan is to roundtrip to FCP quicktime uncompressed files rendered from Resolve and from FCP export an xml and with automatic duck (that now it's free) import to After Effects and export the final sequence from there (dpx for dcp, prores 4444, etc.) from there. In this way I think we should keep all the effects applied during the editing.

[Björn Benckert]

It's Basically so that the step from EDL:s to something more solid ended up in something quite messy called XML... That's what I tell my clients.

I think the best would be to separate the two until XML is a fixed format and the editing tools and the grading tools are all in synk. Im sitting in my flame and most of my work is actually correcting errors in the XML files and doing stupid eye match sessions against an offline quicktime to see that it's all correct.

It would be great if XML2.0 or such was introduced ant that it was an edit decision list that had correct:

Transformations.
LUT grading.
Time warps.

Right now the above is not kicking... Can not see why there is no such standard.

[Luis Otero]

Luca,

The main advise here: do not count on the "sizing" information contained in the XML. If the size of the edit proxy/transcode, and the grading file are different, it will be all wrong (sizing wise).