Dennis Couzin
Forum Replies Created
-
Gary, I just checked and verified that I already made a video in FCP with 2048×1536 pixels. I described that clip in a long ago discussion strand. Apparently your figure of 2048×1152 is the limit for 16:9 format video only. FCP can handle more total pixels than that in 4:3 format. At least my FCP 5.1.4 can.
-
Gary, thanks for the info that maximum FCP size is 2048 x 1152. Luckily I constructed the experiment in such a way that I can still crop all the 2000 x 1500 bitmaps down to 2000 x 1152.
My arithmetic checks. I’m using codec None as 8-bit grayscale, which is what the bitmaps are. A 2000×1500 8-bit grayscale image requires just 3 million bytes. That’s 75 million bytes per second, 71.5 MB/sec if you will. Did you calculate for bits instead of bytes? Hard drive read speed is generally specified in MB/sec.
Now cut down to 2000×1152 the demand will be just 55 MB/sec. Maybe my Samsung HD103UJ can do it!
-
Michael, thanks for that lead to Make RAM Disc.
The suggestion about 10-bit uncompressed doesn’t work however. For a color video, 8-bit uncompressed would indeed be half the size of (8-bit) None. But for a monochrome video like mine, there is no advantage to doing 4:2:2 subsampling. Rather there is a disadvantage to using a 4:2:2 codec since it will stick in unnecessary zeros for the chroma. The None codec as implemented by Compressor allows me to code as greyscale. Then None uses just 8 bits per pixel, versus 16 bits per average pixel used by 8-bit uncompressed 4:2:2. I just made QuickTimes both ways and sure enough the None file is half the size of the 8-bit uncompressed 4:2:2 file. -
Anette, a really scary aspect of video is the dependence on the player and the display. In my little experiment I found the QuickTime player was playing a silly game with DV-PAL video, raising its gamma by 10%. In fact, the colors in the DV were not significantly different from those in the uncompressed exports, as shown when they were all converted to a common codec.
Use of a calibrated reference monitor gives a false confidence of “correctness”, since it ignores what the real audience of viewers will see. I’d rather have an array (actual or simulated) of realistic monitors, so I can judge whether the colors I make will look OK most of the time. (It is a new and interesting artistic problem to have to make “robust” pictures which look good regardless of player and display.)
Untold engineers have stuck their fingers into each step of the video chain. This makes an impossible task for anyone wishing to get to the bottom of things. The color aspects of video taking, capture, editing, and display are an engineering patchwork, a valiant try at making everything work with everything. Video, including broadcasting, carries too much practical baggage to be fully scientific.
Concerning RGB and Y’CrCb. We mustn’t forget that all cameras physically operate in the first system, that video is generally coded in the second system, and that all monitors and projectors physically operate in the second system. So early there has to be a RGB->Y’CrCb conversion and late there has to be a Y’CrCb->RGB conversion. The formulae for the first conversion should be based on the physical color characteristics of the camera. The formulae for the last conversion should be based on the physical color characteristics of the display device. Are they? How is FCP making such conversions, since it doesn’t “know” either physical device? Also each conversion should go to extra data bits to avoid rounding errors. Do they?
-
Anette,
As I read your original post, the first image is how FCP displayed the original material and the second image is how some player — you don’t say which — displayed one of your two sample uncompressed exports — you don’t say which. The implication is that there wasn’t noticeable difference between the two exports (otherwise you should you have shown three images). So RGB versus YUV rendering is not the issue here.It only safe to compare the colors of videos which are in the same codec and displayed in the same player. An example of how misleading comparisons occur when codecs are different is discussed in: https://forums.creativecow.net/readpost/8/1025922
-
A color is “out of gamut” when the saturation is too high for the particular hue. In terms of YUV, for each value of U there are maximum and minimum allowed values of V. You must enable the “Excess Chroma” option in the Range Check to see this.
-
In Sequence Settings, under the Video Processing tab, you’re offered three choices — Fastest (linear), Normal, Best — for Motion Filtering Quality. It says right on the tab that this is “the filter quality used when rendering motion tab motion effects.”
John, I reported what I found in FCP 5.1.4. I don’t have FCP 6.
-
Thanks Rafael, you’ve really installed FCP in your brain.
The warning is missing from my FCP5 Manual.
It seems like a program glitch which, once discovered, Apple just documented instead of fixing. -
Rafael, thanks again. I must wait for the editor to return to try nesting. (I don’t know FCP basics.)
I searched the User Manual before asking whether the warning is in it, and I’ve searched again. Is it missing from the FCP 5 Manual?In Sequence Settings, under the Video Processing tab, you’re offered three choices — Fastest (linear), Normal, Best — for Motion Filtering Quality. It says right on the tab that this is “the filter quality used when rendering motion tab motion effects.” Does the User Manual contradict this?
-
[Rafael Amador] “i don’t think your eyes will be able to tell when a clip have overcome one more generation.
i’ve made tests with DV, and you can make few re-compression without much visual degradation”Hi Rafael, it’s good you found that because it tends to confirm that “recompression of a compressed video doesn’t necessarily change it at all.” Many in this forum have the heebie-jeebies about all recompression. This isn’t helped by the FCP User Manual’s blanket statement “not recompressing frames reduc[es] unnecessary artifacts when exporting to the same video codec.”