|
|||||||||
|
Thread Tools | Search this Thread |
December 24th, 2008, 09:24 AM | #16 |
I agree, Shaun. My own turn as devil's advocate, though would follow up on your comment re: 8-bit, 10-bit, whatever. Clearly the convention for what is digi-black is shifting around when the encoded bitrate shifts. How to deal with this? It's still up to the DP, human imput needed? yet, it's gotta be detectable in the header, or something. Scopes that I've seen don't know the difference between REC 601 and REC 709.....that bothers me.
In the end of things, WHATEVER digi-black is defined as, it has to be played back at IRE 7.5 on an NTSC analog display screen. That's a gain setting. And digi-white falls out from the gamma curve. So, in the conversion to analog, a gamma curve is needed(slope or non-linear, take your pick). That's just another gain setting. If it's played back on an HDTV display, the gain settings change...I THINK it's that simple, but, I could be wrong...in fact probably am. |
|
December 24th, 2008, 12:47 PM | #17 | |
Inner Circle
Join Date: Sep 2002
Location: Vancouver, British Columbia (formerly Winnipeg, Manitoba) Canada
Posts: 4,088
|
Quote:
And a follow up: correct me if I'm wrong but 7.5 IRE is only a requirement for NTSC TRANSMISSION, correct? You can safely pass 0 IRE over local analog connections, if I'm not mistaken. Does our "gift" from the regulators in February make 7.5 IRE essentially obsolete?
__________________
Shaun C. Roemich Road Dog Media - Vancouver, BC - Videographer - Webcaster www.roaddogmedia.ca Blog: http://roaddogmedia.wordpress.com/ Last edited by Shaun Roemich; December 24th, 2008 at 12:47 PM. Reason: Changed 7.5 IRE to 0 IRE |
|
December 24th, 2008, 01:45 PM | #18 | |
Quote:
|
||
December 24th, 2008, 04:26 PM | #19 | |
Regular Crew
Join Date: Jul 2007
Location: Alberta
Posts: 61
|
Quote:
If you produce for TV then you still need to confirm to broadcast standards. If your target audience is computer display, projectors, etc. you can produce anything you like – anything your target can display. The ‘February 2009’ date you guys speak of, has nothing to do with NTSC or levels within. It only has to do with over the air method of transmitting the TV signal. The old analog (AM) transmitters OFF, new digital (ATSC) transmitters ON, that’s all. The output of the new DTV converter boxes will still be the same old analog NTSC signal and/or some modern variation of it. The same old method of transmitting analog TV (AM) will still be in use for years in cable. So nothing is changing. If I may ask: Just out of curiosity, what is it that troubles you so much about ‘7.5 IRE’? Rob |
|
December 24th, 2008, 05:00 PM | #20 |
For myself, 7.5 IRE is a small annoyance by itself. Yet in my mind, it represents all the "problems" associated with rasterized image display, all the problems with the "funkiness" that is NTSC, including but not restricted to interlaced images, 60 fps, color standard confusion, and all those kinds of legacy issues. NTSC TV has defined the nature of motion images, whether it's over the air or not, since it was invented. It's archaic, archane and totally needless.....except that it sticks like a bad headcold. It means that production has to account for NTSC (USA), NTSC (ROW), PAL, 601/709, and now HDTV. Can't help but think how much easier things would be if there was only one or two standards, instead of half a dozen.
|
|
December 24th, 2008, 05:30 PM | #21 | |
Trustee
Join Date: Nov 2005
Location: Sydney Australia
Posts: 1,570
|
Quote:
The issue here really is that at acquistion anything that will fit into the available number of bits can and is used. Broadcast standards exist for broadcasting, so everything conforms to the one standard and for obvious reasons. If you want to hand a tape to a broadcaster to put to air it needs to conform to their standards, if it doesn't and they're serious about their sound and images they'll likely reject it. Internally broadcasters tend to shoot vision and record sound to their standards, especially for ENG. This caused me some degree of confusion at first as their tapes seemed to have low audio levels etc. However their thinking is valid. They might need to take a tape straight from a camera and play it to air. We're not working under those constraints and the full range of digital values is at the disposal of our cameras. Certainly a cheap portable HD/SD SDI waveform monitor should find a market. If it was reasonably priced I'd buy one for use with my EX1 as the built in histogram is less than useless although I can generally get by with the zebras they tend to get in the way of the other functions the camera's monitor gets used for. So yes, I'm as interested as Bill in such an instrument but I know it will not be a solution to all the issues he raised initially. When I'm handed a DV or HDV tape I always check it with my NLE's scopes so I know what I'm dealing with. I check anything of dubious parentage on a CRT as well. More than once I've had media with the wrong field order or files with mixed field order. Based on what my scopes read I deal with it as need be to preserve all of the dynamic range that was recorded. Depending on what the deliverable format is then I may need to adjust vision levels to suit. I notice there's a lot of interest in using the latest digital still cameras to shoot moving images. I'll bet they're not conforming to any SMPTE standard, at a guess they'll likely record the same way as they record till images, using all the available bits. |
|
December 25th, 2008, 02:07 PM | #23 | |
Regular Crew
Join Date: Jul 2007
Location: Alberta
Posts: 61
|
Quote:
I don’t agree with you there. I think you are a bit overwhelmed with all these different standards for no reason at all. If for luma (value Y) you only stick with these two numbers: 16 and 235 (for 8 bit coding), you will be 99% broadcast compliant in NTSC, PAL, SECAM lands and HDTV. There is no need to differentiate for what standard you are producing. The big confusion and I mean the BIG CONFUSION, is in a way different standards interpret these two values. Let me explain: ITU-R BT.601 - ‘Studio encoding parameters of digital television for standard 4:3 and wide screen 16:9 aspect ratio’. ITU-R BT.709 - ‘Parameter values for HDTV standards for production and international programme exchange’. These two documents as you know, define all parameters for encoding of all SD and HDTV television standards. Aside from the numbers of lines and method for encoding color, these two standards also define minimum and maximum values for parameters like Y, U and V, the bread and butter of video signal. Guess what!? Across all these different standards, the limits are all the same for 8 bit coding. Quote from ‘601 (just the relevant parts): http://www.zabcia.ca/pics/601-1.gif These 625/50 and 525/60 systems, effectively are describing NTSC, PAL and SECAM. Quote from ‘709 (just the relevant parts): http://www.zabcia.ca/pics/709-1.gif Same as above, the table describes parameters for all forms of HDTV. So if according to ‘601 and ‘709 the limits for Y, U, and V are identical across NTSC, PAL, SECAM and HDTV, then why the confusion? For different reasons, each system (NTSC, PAL, SECAM and HDTV) looks at the same numbers and reads them differently. From the tables above we know that black is defined as Y at value 16 and white as Y at value 235 no matter what system. In USA and Canada we have NTSC and we use IRE scale here. Due to the way some test signals were designed (SMPTE bars) the IRE scale start at Y = 0 (0IRE) (this is to accommodate PLUGE). So if Y at 235 is 100IRE then Y at 16 is 7.5IRE. In PAL and SECAM land they don’t use IRE units and they don’t have black setup, they use percent of Full Scale. The scale there starts at Y = 16. Therefore black (Y=16) is 0%FS and white (Y=235) is 100%FS. As you can see there is no way of getting away from these two number no matter what system you work with. But, I can also see how one would confuse the two different methods of reading the same values: Code:
| Y | IRE | %FS | --------------------------------- Black | 16 | 7.5 | 0 | White | 235 | 100 | 100 | IRE = NTSC %FS = PAL, SECAM, NTSC(JP) So no matter what system you produce for, as long as you stick to 16 and 235 limits, you have nothing to worry about. For colors (chroma) there are different considerations, so I won’t even go there. But, there is one more thing worth mentioning about HDTV. If you look at section 5.7 ('709), you will notice that the video data in HDTV can span from 1 to 254 and there are two ‘reserved’ values 0 and 255 – they are reserved for timing reference. I don’t know how or where they are being used, but I would avoid these values at all cost. Merry Christmas Rob |
|
December 25th, 2008, 02:49 PM | #24 |
Thanx, Rob. You and I understand, it would seem. Unfortunately, there's a LOT of people out in the production world who don't. What I get are files that don't comply because of confusion about these issues. To add to the complications, some codec software writers don't get it, either. And therein lies the crux of my dissatisfaction. Some codecs will remap to 16-235, while others map to 0-255. ALL codecs should allow the user to pick, if I were king. Problem is, most codecs have no operating guides to describe how and when they remap or pass thru. Some cameras generate superwhites. I suppose it's because the maker wants to squeeze as much data as he can into 256 bits, I don't know. And then, there's the issue of video for the web, which isn't NTSC, at all, with RGB 0-255. And, as you point out, 10 bit will add a whole new dimension to the confusion for them.
With all these permutations, NLE scopes show the timeline color mapping. NLE's aren't smart enough enough to show waveforms AFTER rendering, altho' they could be made smart, they aren't. What has the editor gotten after a render? It depends on what codec was rendered to, and how the codec is designed to remap values. |
|
December 25th, 2008, 03:37 PM | #25 | |
Inner Circle
Join Date: Sep 2002
Location: Vancouver, British Columbia (formerly Winnipeg, Manitoba) Canada
Posts: 4,088
|
Quote:
BTW, this is a GREAT discussion! PS. I am one of those editors who works with my NLE's WF/VS open during colour correction and fine tunes before final output. Glad to see I'm not the only one...
__________________
Shaun C. Roemich Road Dog Media - Vancouver, BC - Videographer - Webcaster www.roaddogmedia.ca Blog: http://roaddogmedia.wordpress.com/ |
|
December 25th, 2008, 03:39 PM | #26 |
sorry, I use "render" and "export" somewhat interchangeably. I am talking about exporting. as a practical example of what I'm saying, bring a smpte colorbar pattern into your NLE. Be sure to include pluge. Export the colorbars and pluge to both Windows Media and something like an MPEG2 file. Import both the WMV and the MPEG2 back into your NLE. Look at the waveform and vectorscope for all three. Are they identical? Have the luma values been shifted? what about the color values? if you have an eyedropper tool in your NLE, measure the color bars for each. are they all the same?
|
|
December 27th, 2008, 07:37 PM | #27 |
Major Player
Join Date: Sep 2005
Location: Sydney, Australia
Posts: 481
|
Just for my cent's worth. I don't go into the detail most of you guys do but I think you hit it on the head Bob with Standards.
I have an expensive and very useful Sony DVD recorder with firewire input, which is just a few years old now, but if I feed it directly from say, the timeline in premiere 6.5, (I wish I could do this in Vegas), it often produced overloaded sound, even when I did an audio calibration line-up in Prem. In anolgue parlance I would call it input overload. In digital it is disgusting ! Obviously there are some different standards here as I had not encountered it with other devices such as cameras etc. As usual, Sony were quite useless as they never admitted to anything wrong with their product other than to blame Adobe ! As I am now aware of the problem, I make sure my levels are lower than normal to overcome this problem. Standards, what are THEY ! RonC. |
December 29th, 2008, 08:27 AM | #28 | |
Quote:
And, a resounding YES! How can anyone do cc without scopes? Without them, it's russian roulette. I am quite fond of adjusting the gamma curve slope. Doing this, it is very very easy to exceed broadcast standard limitations, even if the gamma curve endpoints are fixed at legal values. Without a scope, you just can't see that. |
||
| ||||||
|
Thread Tools | Search this Thread |
|