Forum Replies Created

Page 2 of 41
  • Mike Most

    December 31, 2018 at 5:05 pm in reply to: Noob question Re: GH5s and V-Log

    [Bouke Vahl] “The whole shebang with log / luts was made up to overcome shortcomings in the codecs, not be able to record raw.”

    Uhhhh.. No. Log coding has nothing whatsoever to do with “codecs.” It is a way to bring a larger dynamic range into a limited 10 or 12 bit space so that it can be contained within a reasonable size file. It is an adaptation of what was done for film scans in the past, and is intended to retain all values of an image and leave it up to the user as to what values should be retained in the final image and which should not. If you “shoot normally” (I interpret that to mean record in Rec709) you are taking images with more values than can fit into a Rec709 signal and deciding during production which values at the extreme ends are going to be retained and which are going to be clipped. The problem with that is that you have very limited control of contrast when shooting. You can use filtration, or you can flatten the signal, but it’s not optimal to do either of those things. Encoding to a log curve allows you to retain more than the Rec709 signal can hold, so you can adjust contrast/clipping in a more controlled environment. Recording RAW also largely accomplishes this, but at the expense of having to do much “heavier” processing at the back end. It might also be pointed out that most “RAW” formats are not purely the information from the sensor in its original form. Most of them do some type of transform to allow that information to fit into a reasonable sized file, in a number of cases using log encoding of the RAW values to accomplish that. Log encoding is just math, not some elaborate scheme or hoax. It’t not a gimmick, it’s a way of retaining extended values at the high and low end to allow for more flexibility in finishing. The reason I suggested the ACES approach is because properly used, that approach “tames” the entire process and gives you essentially a “better” version of Rec709 recording due to its use of “proper” color science and sensible rolloffs at the high and low ends (particularly the high end). And you still have the original log image if you wind up using a colorist for final finishing.

  • Mike Most

    December 28, 2018 at 6:22 pm in reply to: Noob question Re: GH5s and V-Log

    There is no need for any special “skills” if you take a proper approach. Starting from scratch and trying to use “standard” color controls to turn the Vlog image into a sensible Rec709 image is not a “proper” approach. Try this instead: Forget about trying to normalize the shots in Premiere Pro. Open the shots in Resolve. Go into Color Management and enable ACEScct, selecting Panasonic Vlog as the input color space and Rec709 as the output. When you bring the shots into the media pool make sure they are all set to use Panasonic Vlog as the input color space. Open the shots in a new timeline and go to the Color page. Set the Contrast to somewhere between .85 and .9. That’s it. You should now see an excellent representation of what you shot. The advantage of being in Vlog is that you can now vary the exposure and balance settings to whatever you need. The advantage of using ACEScct is that you don’t have to figure out a “proper” starting point.

    I know that many people online (including countless YouTube videos) will tell you to do everything by hand from the original log image. Those people, for the most part, are self taught experimenters and not professional colorists. Professional colorists understand color spaces and color pipelines, and how to interpret them for proper results. It’s not about blindly tweaking curves until you like what you see. It’s about knowing how the original file was created and putting it into a proper path for the monitoring you’re using and/or the format you’re delivering to. To do that sensibly requires a proper scientific approach that implements proper transforms to get you from one to the other. That’s how high end digital intermediate work is done and it’s what you should at least try if you want an optimal result with the least guesswork.

    BTW, a suggestion regarding exposure. When shooting in Vlog, the histogram is your friend. It will turn from yellow to white when you’re in a “proper” exposure range, but more importantly, it lets you see when you’re approaching clipping points in either the highlights or the shadows. Keeping the histogram towards the highlight clip without actually hitting it is a good way to get a solid exposure, although anything in between the two should be fine.

  • Mike Most

    December 21, 2018 at 7:11 pm in reply to: Premiere Pro CC 2019 Rendering

    Resolve can do multicam in an almost identical manner to Premiere Pro. If that’s your only objection, it’s not really a valid one. And the comment regarding color correction somehow being inferior on Resolve is rather laughable. Resolve was built as a color correction program and is used by a number of the highest end post facilities for just that purpose.

  • Mike Most

    December 19, 2018 at 12:05 am in reply to: AVCHD footage from C100 workflow

    If you download the latest version of Adobe Media Encoder, you can make Prores on a Windows machine as well.

  • Mike Most

    November 23, 2018 at 2:50 am in reply to: RELINK Issues

    Clip names are unimportant to Avid. The only criteria Avid needs to properly relink is tape name and timecode. That’s it. Everything else is irrelevant, assuming you have the tape name and can duplicate it from the original media.

    What you are trying to do is not complicated, but you must keep in mind that you cannot relink master clips. Only subclips and sequences. That makes sense if you understand that a master clip is a direct connection to a specific source file with specific metadata and cannot be retargeted. So assuming you’ve already got a cut sequence, THAT is what you need to use for the relink. So what you want to do is AMA import the Red clips into a new bin, select all of them, then select the sequence. Now right click on the sequence and select relink. In the relink dialog, you want to choose “Selected Items in All Open Bins.” Deselect “relink only to media in this project.” Now, the rest depends on what is already in your Avid project. If the raw file name is in the Tape column, that’s good. Under Relink By, on the Original side, you want Start as the timecode, and Tape Name or Source File ID as the source name. On the Target side, you want to check the Target If Different Than Original button, and select Start for the timecode, and Tape Name or Source File Name (NOT ID) for the source name. Also click Ignore Extension. Leave everything else on the defaults. If that doesn’t work, try changing the Relink to Video Format selection under Video Parameters.

    If that doesn’t work, I’d need more information to figure out why.

    Relinking is not mysterious, it is not magical, and it is not problematic if you understand what it’s trying to do.

  • Mike Most

    October 30, 2018 at 7:04 pm in reply to: Is it okay to AMA link to already transcoded files?

    You should not be using AMA to link to proper Avid media. You should take the MXF files and put them in the proper path (../Avid MediaFiles/MXF/1 (or any numbered folder) ). After going back to Avid, it should scan that directory and create an .mdb file in the same directory. Drag and drop that file in a new bin and it should populate with all of the clips. AMA is used for non-native files. It doesn’t sound like that’s what you have.

  • Mike Most

    August 16, 2018 at 11:30 pm in reply to: Batch .MXF import (easier way)

    Not meaning to nitpick, but there is no such thing as a “Digital Intermediate Technician.” The proper name for the camera department position is “Digital Imaging Technician.”

    Carry on now.

  • I suspect your main problem is that you have never worked with anything but file names. In Avid, file names mean nothing unless you force them to, but that’s not how the Avid workflow normally works if you’re making “native” Avid media.

    If you are exporting MXF OP-Atom, that is Avid’s “native” file format. You should not be “linking” those clips in Avid, you should be putting them in a folder under the Avid MediaFiles tree (Avid MediaFiles/MXF/NumberedFolder), which Avid will then scan when you open the program (or when you change anything in there). You can then either use an ALE generated by Resolve to populate an Avid bin and relink the clips, or just drag the .mdb file Avid creates in the numbered folder directly to a bin. File names mean absolutely nothing to Avid, the important items are in metadata: tape name (called Reel in Resolve) and time code. You can change the actual media file names at any time and it won’t affect anything in Avid. To check that you did things properly, look first at your dailies project and look at the Reel Name column in the Media Pool (either on the Media page or the Edit page). If it’s not populated that’s your problem. If it is populated with anything that doesn’t look like “C040C001_160929_R2IX” then you haven’t set the Assist Using options correctly. You should see those same names under the “Tape” column in the Avid bin. When you make the AAF to go back to Resolve, you need to check the correct options there as well. The main one is “use AAF edit protocol”. You should also make sure you check “link to video files”.

    When you’re trying to relink in Resolve, you should put the media in one place and bring it into the Media Pool manually. Then, when you import the AAF from Avid, uncheck “automatically import source clips into media pool”. That will force Resolve to look only at the files you have brought in manually. As long as you’ve enabled the reel names correctly, this should work.

  • Mike Most

    April 29, 2018 at 4:37 pm in reply to: Best editing codec for DaVinci Resolve

    >>Most of our projects are big – let’s say between 5TB – 10TB 4k data.

    Everything is relative. On a number of features that we work on, that is one DAY’s worth of data….

  • With recent versions of Avid, the exchange of speed information (including keyframed changes) with recent Resolve versions (i.e., anything from 12.5 on) is reasonably seamless.

Page 2 of 41

We use anonymous cookies to give you the best experience we can.
Our Privacy policy | GDPR Policy