Glenn November 3, 2021 Share November 3, 2021 Hi. Relatively new resolve user here. Had a .cine job the other day and it looked to me like resolve was not reading the code off the .cine files correctly. I did a couple searches and I saw some threads from years back about there being some issues with this but nothing really recent. Still an issue? I tried switching the raw file settings for cine in resolve prefs but nothing changed as far as the way the code was being read. Baselight and Phantom Cine Player read the code the same and that matches what was on the client edl. Ended up just changing the code for each shot in the resolve media pool to match the way the code is read by baselight and that worked. running 17.2.1 Any other work arounds? Thanks Link to comment Share on other sites More sharing options...
David Coiffier November 5, 2021 Share November 5, 2021 On 11/3/2021 at 2:38 PM, Glenn said: Had a .cine job the other day and it looked to me like resolve was not reading the code off the .cine files correctly. I did a couple searches and I saw some threads from years back about there being some issues with this but nothing really recent. Still an issue ? I tried switching the raw file settings for cine in resolve prefs but nothing changed as far as the way the code was being read. Baselight and Phantom Cine Player read the code the same and that matches what was on the client edl. Ended up just changing the code for each shot in the resolve media pool to match the way the code is read by baselight and that worked. Hi Glenn, I'm not a killer colorist but I have a bit of experience with .cine files as I 'm a lucky Phantom owner. What exactly do you mean by reading the code ? Getting correct metadata ? From what I understand, I assume you've tried to change global cine settings in the raw tab settings, but it didn't change a thing, while switching individual clip to custom settings does work. The only case I know these settings will be ignored is when using the DVR color managed mode. Is this your case here ? From what I think I've understood by myself, when Resolve is set to color managed mode, linear raw data is automatically mapped into your actual colourspace, bypassing the classic raw tab with specific phantom options, notably the transfer curve selection (rec709, log1 & log2 curves). While I was trying to set a pipe to color grade .cine files in an HLG colourspace, I've noticed that when color management is ON, the result is quite different to any available curve you can get when in unmanaged mode. And I definitely prefer the rendition I get from the unmanaged mode, with the classic raw tab tools. This color science was probably provided by Vision Research at first, when I suspect the curve being applied by Resolve in managed mode being developed by Blackmagic... In the case you're in unmanaged mode, then this is an issue, as it has always worked well in any actual or previous Resolve versions... Link to comment Share on other sites More sharing options...
Glenn November 5, 2021 Author Share November 5, 2021 Thank you for the response David. I didnt do such a hot job explaining. Sorry. This is all about timecode and conforming. I'm supplied an XML and ref pic from the editorial company. When I try to conform my spot with that xml and ref pic- no files link on resolve. . It seems to me that the resolve does not "read" (for lack of a better word) the timecode correctly off my cine files. As an example file 4662_P5_8 when that file is dropped in resolve the start timecode on it is 19:45:22:02 Same file on baselight and phantom cine player the timecode on that file is 23:45:22:02 And that 23:45:22:02 is the code that is in the clients XML. So its a bit of a hassle to conform these spots on resolve. So I was just trying to figure out why resolve reads the timecode on that file differently than its read on cine player and baselight. Thanks. Link to comment Share on other sites More sharing options...
David Coiffier November 6, 2021 Share November 6, 2021 (edited) I'm also sorry for the confusion... TC is a complex matter with hispeed files. SMPTE TC is derivated from a realtime timestamp, but does not really exists as such inside the metadata. Still, the SMPTE being generated on the fly is supposed to be same no matter what software is used. I had a quick check, here is what I've found so far : • Resolve shows TC related to the inner timestamp (expected behavior) • Silverstack shows also same TC as Resolve. • PCC (Vision Research windows app) DOES NOT show the same TC as Resolve, and this TC is unrelated to actual realtime timestamp. So, as weird as it seems, I'd say correct TC in the Resolve one, while PCC (and so phantom player) won't... That being said, it's of no help for your actual issue... Btw, did you notice a constant offset between those TCs ? Edited November 6, 2021 by David Coiffier Link to comment Share on other sites More sharing options...
Glenn November 8, 2021 Author Share November 8, 2021 (edited) David thank you very much for that info. Very interesting, particularly that nots on the PCC software. In the past I have seen definite constant offsets. 3hrs comes to mind. But not with this lates job we had. This one was all kind of random. And so it appears that resolve was not the system used to generate the transcodes that the editor used. Our solution going forward is going to be to not only get the raw cine files but the transcodes used. This way in resolve we can assing the code from those transcodes to the cine so we can use the client xml to conform the spots. Not the greatest solution but it works. Thanks again! Edited November 8, 2021 by Glenn Link to comment Share on other sites More sharing options...
andrea turri August 7, 2022 Share August 7, 2022 Hi all, and sorry for a probably too late reply, I own a Phantom Flex4K and I'm very conscious about the TC issue, especially when you have to use the XML file to export a project from a software to another. As Glenn mentioned is a bit tricky but possible. Phantom cameras are using the GPS as a standard clock, that's why during the camera setup you can choose from LOCAL or UTC. UTC of course is the Greenwich time, your local time it depends about where you are. I live in Italy and I'm always one hour ahead UTC time. The camera (as far as I know) must seton SMPTE time code, not IRIG, especially for media and production shooting. So, let's say you are shooting a clips at some certain time of the day, one after another, finally your cinemag is full, time to change media. You give the Cinemag at the media manager for the transfer and he's saving the files. At this moment, using the PCC (the software release by Vision Research) selecting the clip you want to transfer, there are different menu you can choose, one of them is "FRAME INFO". Just below the frame info menu there's a voice named TIME. Pressing the curtain menu you can see LOCAL, UTC or TIME CODE. The camera provide a LTC Time Code embedded in the file, when you select the TC of course you suppose to choose the frame rate. That it. Where's the trick? When you open DaVinci Resolve on the menu Camera RAW you need to select Phantom Cine, and at the voice Time code setting select SMPTE, in that case DaVinci will choose the LTC and not the UTC or LOCAL. I just have in front of me DaVinci Resolve and PCC, both open and I see the TC on PCC and DaVinciResolve are exactly the same, everything based on the frame rate you choose. I know PremierePro has a lot of issues with metadata, so probably you need to make some test. Another thing you can do with the PCC is to change the TC on the clip you are saving, once again with Resolve I don't see any issue and the XML file have the SMPTE TC based on 25fps (or whatever you are using). I hope this might help Andrea Link to comment Share on other sites More sharing options...
Glenn August 12, 2022 Author Share August 12, 2022 Hey Andrea, Thank you very much for the response. Very helpful! Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.