|
|||||||||
|
Thread Tools | Search this Thread |
June 20th, 2004, 06:54 AM | #1 |
New Boot
Join Date: Jun 2004
Location: West Des Moines, Iowa
Posts: 8
|
DVI and HD10u color space editing questions?
I wish to edit HD10u footage using DVI/HDMI only. With my current setup, the ATI Radeon 9600 Pro Mac G5 edition transmits to a HiDef front projection in the RGB color space. I am concerned about color space truncation vs. preservation of high def color and not just preservation of HiDef resolution. I am concerned about color distortion caused by color space transformation.
The HiDef HDMI color spaces are: A. RGB 4:4:4 B. YCBCR 4:4:4 C: YCBCR 4:2:2. What I need to know are as follows: 1. In LumiereHD decoding, which HiDef color space is the data decoded into? 2. If the answer to #1 depends on the codec, which color space is "uncompressed". 3. What are the uncompressed data rates for 1280x720P @ 30 fps for: A. RGB 4:4:4 B. YCBCR 4:4:4 C: YCBCR 4:2:2. 4. Which color space does FCP use "internally"? 5. When exporting the final edit to a QuickTime Pro movie, which color space is used? 6. Which Mac graphics cards support YCBCR 4:4:4 or YCBCR 4:2:2 at 1280x720P @ 30 fps with output via DVI? 7. What color space does WMV9 encode into? 8. I understand there is a Mac HiDef format demonstration DVD like WMV9. Which color space did that use use? Most important: 1. Which color space should I use to edit in? 2. Are there any Mac Graphics cards which support YCBCR 4:4:4 or YCBCR 4:2:2 at 1280x720P @ 30 fps with output via DVI? Rationale: Just as HiDef is the future, HDMI is the future for cable, satellite, and the next generation high capacity blue laser "DVD players". The Epson is a fine "end-user" HiDef playback device. I want to make final editing decisions re: color correction and filtering using a DVI/HDMI interface to the Epson and not analog component video; the latter causes an unnecessary extra D/A-A/D conversion and is not how most content will be played back in the future. Most content will be played back via DVI/HDMI. My setup: 1. PowerMac G5 Dual 2 GHz, 2.5 GB RAM, Final Cut Pro HD/LumiereHD, ATI Radeon 9600 Pro Mac G5 edition graphics card (one ADC out for a 19" Mac flat panel {1280x1024} and one DVI out for the Epson). 23 foot DVI cable. DVI/HDMI adaptor. 6 foot HDMI cable. Optional Geffen 4 channel DVI switcher. Epson Powerlite Cinema 500 front projection DLP. Excerpts from the HDMI spec: See http://www.hdmi.com Video data is carried as a series of 24-bit pixels on the three TMDS data channels. TMDS encoding converts the 8 bits per channel into the 10 bit DC-balanced, transition minimized sequence which is then transmitted serially across the pair at a rate of 10 bits per pixel clock period. Video pixel rates can range from 25MHz to 165MHz. Video formats with rates below 25MHz (e.g. 13.5MHz for 480i/NTSC) can be transmitted using a pixel-repetition scheme. The video pixels can be encoded in either RGB, YCBCR 4:4:4 or YCBCR 4:2:2 formats. In all three cases, up to 24 bits per pixel can be transferred. HDMI allows a wide variety of explicitly defined video format timings to be transmitted and displayed. These video format timings define the pixel and line counts and timing, synchronization pulse position and duration, and whether the format is interlaced or progressive. The video pixels carried across the link shall be in one of three different pixel encodings: RGB 4:4:4, YCBCR 4:4:4 or YCBCR 4:2:2. The HDMI Source determines the pixel encoding and video format of the transmitted signal based on the characteristics of the source video, the format and pixel encoding conversions possible at the Source, and the format and pixel encoding capabilities and preferences of the Sink. An HDMI Source that is capable of transmitting any of the following video format timings using any other component analog or uncompressed digital video output, shall be capable of transmitting that video format timing across the HDMI interface. 1280x720p @ 59.94/60Hz 1920x1080i @ 59.94/60Hz 720x480p @ 59.94/60Hz 1280x720p @ 50Hz 1920x1080i @ 50Hz 720x576p @ 50Hz An HDMI Sink that is capable of receiving any of the following video format timings using any other component analog or uncompressed digital video input, shall be capable of receiving that format across the HDMI interface. 1280x720p @ 59.94/60Hz 1920x1080i @ 59.94/60Hz 1280x720p @ 50Hz 1920x1080i @ 50Hz 6.2.3 Pixel Encoding Requirements Only pixel encodings of RGB 4:4:4, YCBCR 4:2:2, and YCBCR 4:4:4 (as specified in Section 6.5) may be used on HDMI. All HDMI Sources and Sinks shall be capable of supporting RGB 4:4:4 pixel encoding. All HDMI Sources shall support either YCBCR 4:2:2 or YCBCR 4:4:4 pixel encoding whenever that device is capable of transmitting a color-difference color space across any other component analog or digital video interface. All HDMI Sinks shall be capable of supporting both YCBCR 4:4:4 and YCBCR 4:2:2 pixel encoding when that device is capable of supporting a color-difference color space from any other component analog or digital video input. If an HDMI Sink supports either YCBCR 4:2:2 or YCBCR 4:4:4 then both shall be supported. An HDMI Source may determine the pixel-encodings that are supported by the Sink through the use of the E-EDID. If the Sink indicates that it supports YCBCR-formatted video data and if the Source can deliver YCBCR data, then it can enable the transfer of this data across the link. Thanks in advance, Frank |
June 23rd, 2004, 11:31 AM | #2 |
Major Player
Join Date: Jul 2003
Location: North Ridgeville, Ohio
Posts: 407
|
Frank,
Sure looks like you've done a lot of research on formats. If FCP is like other editors I've seen, there is no conversion from original format as you scrub and mark clips. If you preview an effect of any sort, then of course that must be rendered. The final render (or real time output) is then converted to whatever output format you have asked for. The HD10 is already 4:2:0 (I think!), and 720P MPG compressed. Any upscaling you do will simply take more disk space, although sometimes this is advantageous to facilitate editing. Obviously, you don't want to downscale and loose what you already have. Generally speaking, your best bet is to edit in native format (whatever it is) and save a master in that format. You can't improve quality by upscaling - you just take more space for your master. Later, you can convert to any needed format. I guess I wouldn't worry about what future formats I need until I need them. I hope this helps some.
__________________
Dave |
June 23rd, 2004, 01:29 PM | #3 |
Trustee
Join Date: May 2004
Location: Knoxville, Tennessee
Posts: 1,669
|
Yes, the HD10 is 4:2:0.
|
June 23rd, 2004, 06:20 PM | #4 |
New Boot
Join Date: Jun 2004
Location: West Des Moines, Iowa
Posts: 8
|
Thanks David and Graham for responding,
I assume the HD10u is YCBCR 4:2:0. In other threads, users have recommended upconverting for editing, color correcting, layering, and filtering. While the original data lost due the HD10u compression can't be recovered, filters and color correction can be added in a higher resolution, or even uncompressed, format for pleasing results. To clarify my color space question, recall Adobe photoshop. The RGB color space includes a smaller gamut of colors than the CMYK color space of a graphics printer. I am concerned that editing and outputting in RGB 4:4:4 won't include all the darker shadow colors which a HiDef playback device could display if YCBCR 4:4:4 or YCBCR 4:2:2 were used. Any thoughts or info on this? Thanks Frank |
June 23rd, 2004, 08:39 PM | #5 |
Major Player
Join Date: Jan 2004
Location: Katoomba NSW Australia
Posts: 635
|
This brings to mind something that's never been truly clarified to me regarding the HD10's output....i.e. Via component connection the cam uses an on-board processor to deliver 1080i 60fps to a Y/Pb/Pr capable device, so technically the I-link 720p 30fps should be scaleable to 1080i 60fps. Of course the 4:2:0 colour space remains the same, but would there be any benefit to using a HD component capable capture card to receive the 1080i signal directly from the cam rather than using a NLE to do the job?
It does seem Frank, that you're a little concerned with the HD10's colour handling capabilities. While it's true that without ND/Polarizing filters the colour can be a bit 'washed out', the colour the cam records is excellent if you add said filters, and set exposure/aperture carefully. It's a lot easier to retain colour information if it's there in the first place..... As we are all basically trying to come to grips with all this new (to us at any rate) HD technology/terminology, I have no idea what would happen with HD10 4:2:0 footage if you saved out to 4:2:2 or 4:4:4.....the only way to know would be to try and see what happens!! I believe you'll find that CMYK is a more restricted gamut than RGB as the CMYK gamut is a pigment or reflective/additive based colour space, rather than a transmissive/subtractive colour space such as RGB, YUV, HSB etc..... |
June 24th, 2004, 07:19 AM | #6 |
MPS Digital Studios
Join Date: Apr 2003
Location: Palm Beach County, Florida
Posts: 8,531
|
This should help you out with the camera specifications.
There's another link, too. Here's the HD10 page on the JVC. heath
__________________
My Final Cut Pro X blog |
June 24th, 2004, 01:56 PM | #7 |
Major Player
Join Date: Jul 2003
Location: North Ridgeville, Ohio
Posts: 407
|
Here's my understanding of some of these issues.
Cameras pretty much don't create colors that press the gamut limits. On the other hand, it's pretty easy with a graphics program to create an "unrealistic" color - say high chroma saturation close to black or white - neither of which can have any color by definition. Tools are continually appearing to broaden our capabilities in the m2t format. I have Ulead MSP6. I would need to upgrade to 7.0 AND pay the $300 for the HDV plug-in to edit HDV. I was told at NAB that ALL the MSP features would then be available to me. I'm waiting just a bit longer to see what other options appear. I guess native format editing just seems the way to go - to me at least. While I'm as quality conscious as the next guy, I think we can go to extremes that will contribute very little (if any) to the final product. With the exception of possibly a few very high end display devices used on location (studio or field), no-one will have the opportunity to se 4:4:4 - or 1080p. All distrubution formats limit color space and resolution - and use compression as well. I don't see this changing. Having said that, I am sometimes amazed at the quality seen on my 1280x720 DLP set. Other times I am greatly disappointed! A good picture isn't all numbers and specs. Constant vigilence is the best way to create good pictures and sound! Sorry - got a little carried away perched on my soap box.
__________________
Dave |
June 25th, 2004, 04:52 AM | #8 |
RED Problem Solver
Join Date: Sep 2003
Location: Ottawa, Canada
Posts: 1,365
|
Does not the HD10 use the standard def 601 colour space though??
Graeme
__________________
www.nattress.com - filters for FCP |
June 25th, 2004, 09:07 AM | #9 |
CTO, CineForm Inc.
Join Date: Jul 2003
Location: Cardiff-by-the-Sea, California
Posts: 8,095
|
Yes the HD10U does use BT.601 color space -- odd for a high def product. However 601 is a blessing for this first generation product as all the video cards out don't yet support BT.709 (the HD color space for YUV.) This mean it is easier to edit and color correct HD10U on standard PCs/Macs.
Frank original worries are correct. RGB output will clip the highlights of YUV data. White in YUV is defined as 235,128,128 when converted to RGB to is output as 255,255,255. The problem is most cameras will shoot white levels above the spec'd 235. These "out-of-range" highlights are clipped by the RGB system. They are also commonly clipped by your video card when you play out to an RGB display. This is been an issue for a very long time, the same problem occurs with DV cameras. Only the higher-end software makes any attempt to deal with this by redefining RGB (video systems RGB) or staying in the YUV domain. Staying is YUV would be best yet so many tools are RGB only (i.e. compositors like After Effects and 3-D renders are all RGB.) It is a interesting problem.
__________________
David Newman -- web: www.gopro.com blog: cineform.blogspot.com -- twitter: twitter.com/David_Newman |
June 25th, 2004, 02:23 PM | #10 |
Major Player
Join Date: Jul 2003
Location: North Ridgeville, Ohio
Posts: 407
|
David,
I don't quite understand your comments. We change digital resolution all the time - 16 bit audio to 8 bit - 32 bit color to 24 bit - etc. This doesn't mean things are clipped - just fewer bits to represent the same material. Most cameras are RGB (HD10 is an example of one that is not). To my knowledge ALL display devices must have video converted to RGB (internally). By the same token CMYK must be used for printing. In fact, CMYK has no other purpose. ANYTIME you convert, things can only get worse. In my view it's counterproductive to convert to something intermediate, then later convert again to your desired output. I have been very impressed with the quality, and low data rate of Windows Media 9 - in spite of how much I dislike Microsoft. This may well be become THE HD standard for distribution. As time goes on, there seem to be fewer and fewer reasons to use film at all. Think about it! I have long thought that what film makers bring to the table is not film but their TALENT! In fact, lets use the term MOTION PICTURE makers, and forget about film and video altogether!
__________________
Dave |
June 25th, 2004, 04:52 PM | #11 |
CineForm (Aspect HD)
Join Date: Aug 2003
Location: Oceanside, CA
Posts: 57
|
David K. - Since David N. is up at a film festival I'll jump in with a quick response and let DN follow up later.
You're confusing the two issues of bit-depth and color-space conversion. The clipping happens when you take full range YUV and convert to RGB. It isn't a 10-bit vs. 8-bit issue it is a color-space issue. You're correct that the camera sensors are mostly RGB but the data is normally stored as YUV in a variety of encoding schemes. So using RGB as an editing format would result in the very thing you are trying to avoid - multiple conversions between color spaces. Phil |
| ||||||
|
|