Thread: Final Cut Pro X Released
|
|
07-11-2011, 03:08 PM
I know Andrae, but it seems no one here or at apple knows exactly what they are talking about, because, you know, there isn't any explanation anywhere of how colorsync works. I really would like the simplicity of a quadro card, 10bit displayport to my dreamcolor, easy and unexpensive, but i don't know if that works, probably not, and i can't find my magical connector, don't know where i put it.
:p
07-11-2011, 05:17 PM
Honestly, this argument is just silly. By this logic, you could argue for grading on a 6-bit monitor. Plenty of people are watching YouTube on laptop.Originally Posted by Chris Kenny
Is that where you think we're going? Or is that just where you think Apple thinks we're going?
For what it's worth, I've always agreed with you that Apple is not seriously concerned with the "pro" market, and that this has always been the case. They are a consumer products company that has dallied in various pro spaces. And you are right that the elegance they bring to consumer products has often benefitted more serious users.
But to argue that a cinematographer should not care about the very real differences between 8 and 10-bit color because some peop,e can't see them is akin to arguing that a painter shouldn't paint in oils because the full effect won't be seen in a print. That dog just won't hunt.
07-11-2011, 07:46 PM
After agreeing that we were beating a dead horse on FCP, I promised myself I wouldn't post in this thread unless I could mention a horse in almost every sentence. <sigh> Refresh rates between CRTs and LCDs are a horse of a different color.
CRT
On an analog CRT, the refresh rate reflects the time that it takes for the system to display an entire screen. Since it's analog, everything is direct coupled. It starts with the RAMDAC (which is integrated into a GPU nowadays) which reads the data from the framebuffer and sends it directly to the display. The display then scans the electron beam across the glass at that same speed. When the e-beam hit the phosphot, it lit up "instantly' but the decay is slower. The decay is what allows monitors to refresh at a specific rate and also account for the flicker. The intensity/decay depends on the type of phosphor used (P22, SMPTE-C, Trinitron, etc.). I know that the P22 consumer phosphor had a decay rate of something like 0.8ms for a 10% shift but that the colors decayed slightly differently and that the P22 was engineered to give a punchier, more saturated color for consumers (this in the pre-color calibration era).
72 Hz was reported as "flicker free" by manufacturers because the decay was small enough that by the time it was perceived by the average user, the electron beam was already redrawing/re-energizing the phosphor. This was a marketing number since it was possible to notice an improvement in flicker with increasing refresh rates.
LCD
The signal path for an LCD is different than that of a CRT. I will focus on the pure-digital transmission since analog transmission is the same thing with a DAC and ADC on each end. With LCDs, the source sends data via a protocol such as DisplayPort, SDI, DVI/HDMI. Although displayport can theoretically "directly drive" an LCD panel, the majority of panels are still driven by LVDS controllers.
Most LVDS controllers output at 60Hz.
This is the bottleneck in which the LVDS chip may be receiving data from the PC at >60Hz but the LVDS only changes the pixels of the LCD at 60Hz.
However, unlike the CRT, this isn't a problem. In a CRT (or plasma) situation, the electron beam directly energizes phosphors. Without a refresh, the image begins to decay. With LCD, there is a continuous light source whether it be CCFL or LED. CCFLs aren't like old-school fluorescent bulbs powered by magnetic ballasts that refreshed at 60Hz. Electronic ballasts refresh at 20kHz to 60kHz depending on the model. So even though the phosphors in the CCFL decay, they're being re-energized at a faster rate (and therefore do not flicker).
Recently, improvements have allowed for 120Hz and now 240Hz LCD displays. At least for conventional PC monitors, this is the exception rather than the norm.
LCDs work by changing the alignment of crystals in the matrix to control the amount of light that is filtered. The response-time of the LCD reflects the speed with which the alignment can change. So one speed is the one that the computer is barking instructions to the display and the other speed is the ability for it to "keep up" with the orders.
Originally, LCD pixel refresh was reported in black-to-white-to-black, the slowest/worse case scenario. Technologies such as overdrive (changing the voltage and pattern of voltage) allowed faster gray-to-gray transitions, and since gray-to-gray is statistically more common, is how manufacturers report their numbers. Still, this is the best case rather than the worst case scenario.
Further complicating the LCD situation is the balance between color accuracy and performance. TN-film based displays offer the fastest pixel refresh times and are cheaper and easier to manufacture. These have poorer color accuracy (as many are based on dithering) and poor viewing angles with greater color shifts. IPS displays offer the widest viewing angles and the most accurate color, but are classically slower and more prone to smearing and also suffer from worse black levels. MVA/PVA are supposed to the middle ground compromise.
OLED
OLED is the future. The best viewing angles, and a response time in the 0.01 ms range. All OLED is not created equal and historically the challenge with OLED has been color accuracy, durability and cost. I haven't seen the Sony OLED displays, but presumably it's pretty accurate. ;)
07-11-2011, 09:14 PM
If I understand you correctly FCPX manages render files worse than FCP 7. If you add an effect it trashes all previously rendered frames? Not just the changes? That could be disheartening.
07-11-2011, 10:03 PM
Yes... that's exactly what it's doing. In FCP7 you render in the foreground and it's a complete render out to a clip file. You then decide to change your mind and it keeps your old rendered files and then renders out new files. In FCPX it stops in the middle of the process and then restarts. It looks like it's rendering out file frames to a few cryptic folders... I guess it deletes those file frames and starts over again. It's doing all this automatically and stopping and starting all on its own... it has no way to read your mind to see what your intent is... so it just starts rendering any changes.
07-12-2011, 06:38 AM
LCD panels are not inherently locked to 60 Hz. That it, it's not a fundamental limitation of LCD technology. But it is the only refresh rate mainstream desktop displays support. Hilariously, this is somewhat hard to demonstrate, because there's so little variation that this is rarely broken out on spec sheets, but I recommend you open the display settings on the next dozen computers you run across, and see what refresh rates are selectable. Unless those machines are hooked up to specialty monitors like the Dreamcolor, or to TVs or video projectors, 60 Hz is generally going to be the only option you'll see.
Just to clarify here, it's not my position that there's literally no difference between a broadcast monitor and modern computer display. That would be silly. Rather, my point is that a lot of people seem to believe there's something fundamentally different about broadcast monitors that enables them to display accurate Rec. 709 color, whereas computer monitors can never do this. This is not actually the case. Broadcast monitors (at least until you get into really expensive things like Sony's new OLED broadcast displays) aren't using fundamentally different and superior display technologies. Rec. 709 is not even a very big color space by modern standards. Displaying accurate Rec. 709 color is just a matter of doing the right sort of image processing, and any image processing a broadcast monitor does with onboard electronics can theoretically be replicated by hardware/software on a computer, these days generally in real-time.
If you're primarily working on web content it's probably not an especially crazy idea to check it on a 6-bit monitor at some point.
Err... I'm talking about post, not acquisition. Acquiring a high bit-depth image is useful regardless of deliverable format, because it lets you push things around more. And processing at a high bit depth is useful, for similar reasons. I just think some folks are more concerned with the monitoring issue than the technical realities suggest is sensible. Is it better to monitor at 10 bits? Sure, in general. Will anyone be able to tell from the finished product if you monitored at 8 bits? Realistically, no.
07-12-2011, 09:09 AM
One aspect I've found frustrating with FCPX is that without the ability to set scratch disks, it's near impossible to spread out the hard drive thrashing. As a test project I tried to recreate a project I had already finished, one utilizing 4 separate cameras. Leaving aside the lack of multicam support, I figured it would be a good project to test the basics of the program.
The 13 different clips from the 4 different cameras (which had already been transcoded to prores) all happened to reside on one hard drive (which despite not being the ideal proved to work just fine in earlier versions of FCP as well as Premiere). I had set FCPX to not move the files, nor to transcode them, which I assume meant it wouldn't have to do any rendering. Instead, upon ingest the system becomes bogged down as it tries to render 13 files at once. I have no idea what it's actually doing with these files, it doesn't tell me. There's so much overhead going on during "background rendering" that the system ends up being slow enough that it's not really worth editing on. The hard drive ends up thrashing so much trying to work on so many files concurrently that I have to manually go in and pause the renders. Mind you, I've actually TURNED OFF background rendering, but it seems to make no difference.
The synchronize clips feature seems like a great feature, except it randomly doesn't work on certain clips, and seems to take forever compared to Pluraleyes.
The stinger came when a few days after working with all this I got yellow exclamation marks and red screens on all my footage, as if the files had moved, which they hadn't. But I have no way to reconnect those files, because according to everything I read, clips don't get disconnected in FCPX.
07-12-2011, 09:25 AM
The discussion with opposing views often tends to get more and more detailed, leading to discussing things looked under the microscope.
While that does carry the potential to add beneficial information to a discussion, often the focus gets lost in the abundance of details.
Sometimes things like dissecting and analyzing "biochemical compounds and nutritive elements for soil contained within a fertilizer" need zooming out.
Using a wide shot of the scene discussed, many highly detailed analysis become redundant,
failing to justify a steaming pile of sh*t on a breakfast table.
| « Previous Thread | Next Thread » |
