Anyone who’s read it and has anything they’d like to see in the next edition (or feels they could live without), let me know in the comments or by email.
I’m also going to see if I can get a few copies to give away when it gets published.
]]>Website Vimeo… seems to offer all the features of YouTube but with improved resolution and picture quality, ideal for anyone with HD footage to show off.
There are a couple of catches: “HD” is limited to 720p (1280×720 pixels) and you can only upload 500MB of video per week.
Gone in a Flash - HD from Chris Crutchfield on Vimeo.
So here goes:
- The first line of the batch file must contain the headings of the relevant fields, separated by tabs. These must be named precisely (see below for possible field headings).
- The fields “Name”, “Media Start”, “Media End” and “Reel” are required.
- The information for clips must be provided on one line per clip.
- Folders in a project are defined on a line by starting with an asterisk (*), a space, and the folder name (e.g. “* AAA_cut_aways”). All clips listed after that label will be placed are in that folder. Strangely though, FCP seems to ignore these labels when importing a batch list.
- The file must be plain text.
As of Final Cut Pro 6.0.3, any of the following field headings can be used:
- Name
- Duration
- In
- Out
- Media Start
- Media End
- Tracks - must be in the form “1V,2A” (for 1 video track and 2 audio tracks in this case)
- Good - “Yes”/”No”
- Log Note
- Label
- Label 2
- Audio
- Frame Size - must be in the form “pixel_width x pixel_height” (e.g. “1920 x 1080″)
- Vid Rate - must be in the form “25 fps”
- Compressor
- Data Rate - must be in the form “2048/sec”
- Aud Rate - must be in the form “96.0 KHz”
- Aud Format
- Alpha
- Reverse Alpha - “Yes”/”No”
- Composite
- Pixel Aspect
- Anamorphic - “Yes”/”No”
- Field Dominance - “Upper (Odd)” or “Lower (Even)”
- Description
- Scene
- Shot/Take
- Angle
- Reel
- Master Comment 1
- Master Comment 2
- Comment 1
- Comment 2
- Master Clip - “Yes”/”No”
- Offline - “Yes”/”No”
- Last Modified - Must be in the form “Tue, Mar 4, 2008, 17:19″
- Film Safe - “Yes”/”No”
Other things to note:
- Although many people are under the impression that right-clicking on a sequence and choosing Export->Batch List will produce a list that only contains clips used in the selected sequence, this is actually not the case. Exported batch lists will always contain all clips in the project.
- Exporting a batch list from FCP will only export field data for columns that are visible in the project. So if you have the “Master Comment 1″ column hidden, that data won’t get exported.
- The frame rate gets determined by the project that the list is imported into, and is not specified in the list directly.
Katzenberg says it’s not happening fast enough, whilst Spielberg is arguing that digital projection is inferior to 35mm film (for anything originating on film), and doesn’t want the latest Indiana Jones movie projected on digital screens.
But they’re both wrong:
On one hand, digital cinema just doesn’t offer any clear advantage to the consumer over film, which makes it difficult to build a case for adoption. But then on the other hand, film doesn’t really offer any clear advantage to the consumer in terms of quality over digital, even when you factor colour space conversion and digitisation. Sure there’s a loss from going from 35mm to digital in terms of colour, dynamic range, and resolution. But that also happens to some extent going from 1st generation film prints to 3rd, 4th and so on generations. There’s also the “second-hand” generation loss that we experience in the UK, where film that has been run through US projectors thousands of times then get debut screenings over here, covered in all manner of dust and scratches.
And as for the resolution and clarity issues, much like David Pogue once pointed out… no-one can really tell the difference anyway.
]]>But very occassionally, I stumble upon a solution to a problem within the post industry that is actually viable. Although we’re not yet ready to reveal the details of what exactly this solution will be, I can certainly talk about the problem we’re hoping to solve, and something that will strike a chord with a lot of people, I’m sure.
For the past 10 years, and with increasing frequency as film gets phased out, there has been the problem of how to archive digital footage in a way that provides no limit on the quantity of data and that doesn’t degrade. Over the last few months, there’s been talk of holographic storage… as well as many other proprietary methods, but they all share similar weaknesses: they are bound to specific hardware, they are largely untested in real-world scenarios, and they are inacessible.
With more people turning to Red and similar digital capture methods, the problem is only getting worse. People are finding that they have lots of data files and nowhere to put them. And I suspect that in a few months from now, a lot of people who are new to this will discover that their backup strategy has failed. This happened with the boom in digital photography, but was less of a problem because the volume of data in question was typically limited to gigabytes, not terabytes. For most digital photographers, having a USB backup disk is enough protection for their images. But for people with digital masters or RedCode rushes, that simply isn’t viable. In addition, while digital photographs are normally the responsibility of a single person, film shoots belong to organisations, so several people may need access to it at any time.
As well as the data integrity implications of long-term archiving, there are also security implications- making sure that only authorized people have access to it, and that if the data falls into the wrong hands, that it is unusable. Being able to store and retrieve the data in a very simple way is a bonus.
We’ve still got some way to go on this before we can say we have a system that fulfills all these criteria, but at the present time it seems like the technology part of it is in the can. Hopefully I will have more details on this soon.
]]>
If you change the brightness for any part of the image, all the selected pixels are affected in the same way.
In one of my previous rants, I proposed that resolution was more important than bit-depth… Since then, I’ve been wondering why, in practice, this is never the case. After some thought, I realised that the way digital colour correction works is different from changing the exposure of film.
Changing the exposure of film, on microscopic level, affects the image like this:
The individual grains are not affected uniformly. It’s that a percentage of the grains become exposed (or not), not that every grain becomes more exposed. To the viewer, the result from a distance is that the affected region is brighter. It’s also the reason that grain structures are visible.
Until now, it didn’t make sense for colour correction software to work like this: the resolution of images was too small to make sense. However, for 4k and beyond, non-uniform (or dithered) colour-correction may very well yield superior control over the colour-correction process.
So the question I find myself asking is, why don’t any high-end colour grading systems offer this kind of functionality?
Sildeshow of images...]]>First off, the Red Ray, a hardware-based RedCode player.
Secondly, the much-anticipated Scarlet, a camera targeted at the lower end of the market. The Scarlet boasts a 3k resolution, with frame rates of 1-120 fps. So much for low-end.
Finally, something which has been kept very quiet, the new Epic camera. This is an improvement over the Red One, with 5k resolution and a full super-35 size sensor.
Although Red are not taking pre-orders this time, they are offering a deal that sounds too good to be true: buy a Red One today and then part-exchange it against the cost of the Epic (the pricing of which has yet to be set) at it’s purchasing price. As one member of the CML… put it,
]]>…the RED ONE to EPIC trade-in program certainly puts other manufacturers to shame.
Noteworthy changes are the separation of metadata and user colour settings, and the addition of multiple batch-processing templates.
Changes:
]]>1. Import update method now matches by Reel, Camera, Clip, Start TOD Timecode and Date rather than filename.
2. There are two sets of colour parameters, one for the clip’s metadata and another, user-defined one. Importing CSV files will only write to the metadata parameters.
3. Added button to paste colour parameters from metadata.
4. Added button to reset colour parameters to defaults.
5. Added an ID field to clips table for indexing purposes.
6. Added infrastructure for multiple project tracking (note multiple projects are not implemented yet…)
7. Added template tags for metadata values. For example {ISO Meta} will be replaced with the value stored in the ISO metadata field. {ISO} will be replaced by the custom ISO value.
8. Added ability to copy and paste values via a “colour clipboard”.
9. Redline-specific options have been placed into their own tab under the revamped “Batch script generation” area.
10. You can now create and work with multiple templates.
11. Added some text to the UI to make the purpose of different sections a little clearer.
12. Added {RedDate} template tag, which uses the older (6-digit) method of calculating the numeric date value. New templates now use this method for the output path by default.
13. Added a button to generate some example templates.
After all, the vast majority of discussions of Red camera workflow are necessarily theoretical, after all very few people are using it for anything other than test footage. The editing stage is often the first stumbling block, as actually getting any of the footage into an editing suite to play around with can be challenging. There’s also a much more problematic issue that deserves attention: ensuring that the finished edit can actually be used for an online somewhere.
There is a popular workflow with Red footage which is to edit the R3D files directly in FCP. The benefit of this is that it is very simple: you just load the QuickTime proxies into a project and snip away as normal. You can even do your online in FCP if you wish, putting Final Cut’s colour correction and effects tools to good use. You can then export to a wide variety of formats, including some uncompressed* variants.
*Note: I’ve not done any tests on this workflow to see if working in this manner produces a “true” uncompressed result (compared to converting the RedCode data directly to an uncompressed format first, and editing with that). It is possible that somewhere along the path, probably at the Red proxy file, some amount of compression is introduced.
However, I’m not a big fan of workflows like this, because they make the process proprietary and reliant on specific software configurations. It’s entirely feasible that at some point RedCode will be treated in the same manner as formats such as DV, universally recognised, and with predictable results regardless of your editing system. Furthermore, we didn’t want to limit ourselves to having to use FCP for cutting (although ultimately that was exactly what we used). And finally, I was concerned that the cases of clips with duplicate names would give us grief when un-picking the edit in preparation of the online.
The method we used in the end was to convert everything using the Redline command-line processor (from Red), by creating a batch script using our Redemption… database. We set everything to output 1920×1080 DVCPROHD movie files (which would retain the original timecodes) but prefixing our own reel numbers to each file. There were a couple of bugs in the Redline code (which are being addressed) that prevented the iso value of each file being read automatically so we had to plug those numbers in ourselves. It was also apparent that it was necessary to apply a gamma-curve during the conversion process to prevent everything looking flat: helpful for the online process perhaps, but not so much for the edit.
We then had a folder of movie files that could (in theory at least) be loaded into any editing system. We went with Final Cut, and an additional step was that we had to change the reel number FCP had assigned (based on the filename I assume) to our reel number.
That done, the editor took over and started to cut, as if working with any other footage. Meanwhile, we could start looking into getting the material prepped for the 4k online.
As a side note, one of the other things we were able to do easily due to the digital nature of all this was have our proprietary database automatically match the shoot notes to the Red data logs, so we were also able to produce a reference log for each clip.
The third and final part will look at using Autodesk’s Lustre to online the 4k files.
Sildeshow of images...]]>