I guess you're right, DaLiv. I don't know anything about the DV codecs, nor uncompressed codecs, nor YUV codecs. I've tried to help you with my limited knowledge and ability to look at this from all sides. I was hoping to learn something new myself because I'm new to the game. Thank you for your patience, I'll leave this to others to debate with you since I'm not capable of understanding the merit to this discussion.
Good luck

O.k. - once anew.

You have an uncompressed AVI file called "16_235_Sun.avi" accessable from

http://www.videoediting.ru/tmp/16_235_Sun.avi

Now you say, no matter which dv codec is used for processing - after processing with a dv codec there will be changes which are be seen on TV monitor as a loss of orange slightly turning to yellow then and which will not be seen on the original uncompressed AVI.

Processing means - not only copying the file (what would happen if we render without having a filter applied) but real render the file, having an encoding process for compression and having a decoding process afterwards which is needed to view the file after rendering.

Right till here?

O.k. - I took this uncompressed AVI put it in the Vegas timeline. Applied the timecode filter. Ensured Sony Pictures DV will be used for encoding and decoding. I rendered the file. So now I have a DV AVI.
I viewed the file inside Vegas, preview set to "Best (Full)". Compared original uncompressed AVI and rendered DV AVI. No difference in colors (only difference is the timecode burnt into the rendered file).
I analyzed the file inside Vegas using waveform and vectorscope. Compared original uncompressed and rendered DV AVI. No differences.
Staying in Vegas I switched to external preview. Connection to the external monitor is done by the Sony GVD-300 DV recorder which works as DA converter now. Used a tv monitor. Compared original and rendered file. No difference.
Same procedure but used a video monitor instead a tv monitor. Compared both files. No difference.
Connected an analog waveform monitor to the dv device. Compared both files. No difference.
Connected an analog vectorscope to the dv device. Compared both files. No difference.
Printed the rendered dv file to dv tape. Compared it all the way described before on monitors and analog analyzers to the direct Vegas output. No difference.

So whatever your theory is for a difference between colors of original uncompressed AVI "16_235_Sun.avi" and a rendered DV AVI version - I cannot state this difference.

Here is my rendered DV AVI file called "chroma_test_DV.zip".

chroma_test_DV

Download it. Unzip it. Watch it. Analyze it. Compare it to "16_235_Sun.avi". If you'll see differences in color or luminance - it is likely these are not done by Sony Pictures DV. Probably there is something else what influences your system. Maybe your DV device. Maybe your monitor. Some of the things Spot mentioned. I don't know. But I cannot state the differences you described. Here's everything fine after rendering/recompression and decoding if only I use an adequate dv codec.

I have done many tests like this one so I know Sony Pictures DV, Canopus DV, Matrox DV configured to 0-255, MainConcept DV configured to 0-255 - all those dv codecs (latest versions) behave the same way. There is no problem in converting YUV to RGB or RGB to YUV. (BTW: Canopus DV does not work in RGB at all but in YUV all the way)
Quite different Microsoft DV, Panasonic DV, earlier version of MainConcept DV, MainConcept DV configured to 16-235, Matrox DV configured to 16-235 - all those codecs cannot handle YUV-RGB/RGB-YUV conversions without losses in chrominance and luminance (dependend on what exactly is done there).

Marco

{You have an uncompressed AVI file called "16_235_Sun.avi" accessable from }
it's not uncompressed - it's DV compressed frame (if you are not knew - see info about file in vegas explorer status line)
{Processing means - not only copying the file (what would happen if we render without having a filter applied) but real render the file, having an encoding process for compression and having a decoding process afterwards which is needed to view the file after rendering.}
processing -1. decoding of existing DV matherial to "X" and 2. then encoding "X" to the new DV
/we are at now have trouble at point 1 - can not get correct "X".
it's decoding stage that you have missed in your tests - you try to encode and then decode .... but decoding (IN WHICH IS PROBLEM) before your encoding you are ommited/
so next your tests is falsed as point (1.) of processing have been executed.



I have done many tests like this one so I know Sony Pictures DV, Canopus DV, Matrox DV configured to 0-255, MainConcept DV configured to 0-255 - all those dv codecs (latest versions) behave the same way. There is no problem in converting YUV to RGB or RGB to YUV. (BTW: Canopus DV does not work in RGB at all but in YUV all the way)
Quite different Microsoft DV, Panasonic DV, earlier version of MainConcept DV, MainConcept DV configured to 16-235, Matrox DV configured to 16-235 - all those codecs cannot handle YUV-RGB/RGB-YUV conversions without losses in chrominance and luminance (dependend on what exactly is done there).

and in addition i'm to say the ALL dv codecs (Sony Pictures DV, Canopus DV, Matrox DV, MainConcept DV configured to 0-255 also) have losses in YUV-RGB conversion in matherial with high crominance and luminance values. (listed versions have much smallest losses than other - but they still present)

P.S. vectrocscope in vegas works with decoded data - RGB while DV matherial is YUV and so you can not see changes that applied in decoding stage on it.

I download both the original file i.e "16_325_sun.avi" and the "chroma_test_dv.avi" put them on the time line in vegas and viewed them via firewire on my tv. They look very different indeed, I am using the sony dv codec although because the files don't need to be recompressed for viewing it shouldn't make a difference anyway. I have noticed a similar problem with some footage that I have, but I cannot explain what is happening.

Berti

i can explain this at now as :
most NLE programs works in RGB24 colorspace - that is 8-bit on each of primitive color (R,G,B) and when using DV format (which is YUV based) will implemented conversion YUV->RGB, which can not directly map all values of YUV to RGB.
it's problem will exist till moment when manufacturers of NLE programms and plugins will work with extended rgb ranges or with native yuv.

From my research and limited knowledge the explaination is fairly simple. You cannot convert the entire PAL RGB color gamut into YUV or the other way around. It's that simple. That's why even though your luminance may be within legal limits you can still have illegal values because those RGB values cannot be translated into YUV in the PAL or NTSC color space. There's heaps of high level stuff about this out there, most of which goes clean over my head. The same thing happens going from YUV to RGB.
Nothing is broken and nothing can be fixed, it's the way the system was designed. If you don't like it, sell the house and shoot 35mm.
Even assuming DaLiV is right and something is happening by his own admission it happens in every NLE he's tried it on. What does he expect to happen here, that's what I don't get.

My Question going back to the original example files (16_235_sun and chroma_test_dv) is why the difference between these files as viewed on an external monitor (TV) is not visible on all systems. The discusion for most of this thread was about some people aparently not seeing a difference in these images. If this is so what's up with my setup? My second question would be if it's not my setup, how can I do an accurate color correction if any kind of rendering (even if it's only for inserting time code) changes the very colors I'm trying to correct in my film ?

Any help very much appreciated

Berti

DaLiV,
You're missing the point here. Your camera took ILLEGAL footage. Sony cameras are notorious for this, it makes them look good in the shop and easier to sell. You can check what I'm saying with some difficulty. Get a vectosrscope and connect it the output of your camera and playback the footage you're complaining about. Get someone who works in broadcast to look at what's on the vectorscope and tell you if that's acceptable for broadcast.
I have several friends who have rejected more programs than I'll make in lifetime because of this problem. During my investigation of what you're talking about I found at least one post in a forum from someone who'd had this happen to him. SPent ages making a program, all the levels looked legal yet still the station rejected the footage.

As for your wish for NLEs to work in YUV, lots of luck. The trend at the high end of the business is more and more to work in pure RGB colorspace. One far from small time player is deserting Apple because, amongst other things, QT only supports YUV.

Berti,
see some of my posts above. I suspect the issue is that some are looking at this in NTSC and others in PAL. I believe NTSC has a larger color gamut than PAL so you're less likely to see the problem in NTSC than PAL. This quite a different issue to the sampling difference in DV, the issue occurs even at 4:4:4 sampling.

while exist DV specification - not needed to say about high end that works in RGB - they are not DV consumers.

farss -check RTFM, specifications, and so on ...
NTSC and PAL the same - they use YUV 411 and 420.
difference in structure is minimal (and especialy for them who don't want search technical info):
YUV420 macroblock
(Y1,U) (Y2)
(Y3,V) (Y4)
YUV411 macroblock
(Y1,U,V) (Y2) (Y3) (Y4)

and conclusion - NTSC - one UV pair for 4 horisontal pixels
PAL - one UV pair for 2 pixels multiple 2 lines

also if you can not search thru internet -there info exist ...:
http://www.abo.fi/~Jerker.Bjorkqvist/digitv/lect2.pdf

with your setup is all ok.
problem persist in all DV codecs - they can not convert all data to computer RGB format.

they don't want to see differencies - or they don't understand when this must see ....

we must wait next:
NLE manufacturers go to extended RGB (RGB32,RGB48, or RGB Real [this is each color defined by real numbers,not as now integer]) as this already done in sound industry - many can have in mind 8-bit soundcards, after them was 16, now 24 .....

Do we ask Sony for a 10bit RGB pipeline or an adoption of YUV, or a complete switch to YUV?

Their silence suggests we are worrying about our ideals. Which like worrying about the inch and centimetre (or whitworth thread), is probably just an excuse to blame the tools.

I like Vegas being quick, and will probably never quite understand why a final render would consider draft/good/best.

I do suspect that most things to do with SD video will become uncompressed, maybe even 4:4:4 within the next decade. Moore's law should permit even target/delivery formats to go this way. Albeit improving the quality of film theft without also improving the countermeasures.

My videography isn't going to be calibrated per shot for a good long while. So I don't mind a few irregularities myself. I also agree with the notion that Vegas does things about aswell or better the rest. No objection.

I do disagree that computers are RGB only. They are in fact whatever we want them to be. Keep the limitations to camera and distribution formats = please!

>> it's not uncompressed - it's DV compressed frame

Oh, yes, sorry - my fault.

>> processing -1. decoding of existing DV matherial to "X" and 2. then encoding "X" to the new DV

...

>> it's decoding stage that you have missed in your tests

Sure - DV files must always be decoded first to do anything with'm. So - no, I did not miss that process. Decoding happend.


>> and in addition i'm to say the ALL dv codecs (Sony Pictures DV, Canopus DV,
>> Matrox DV, MainConcept DV configured to 0-255 also) have losses in YUV-RGB
>>conversion in matherial with high crominance and luminance values.

Again: Canopus DV does not work in RGB at all but in YUV. So there cannot be losses in YUV-RGB conversion. There is no YUV-RGB conversion.

>> P.S. vectrocscope in vegas works with decoded data - RGB while DV
>> matherial is YUV and so you can not see changes that applied in
>> decoding stage on it.

Yes, sure - you are right. But I only mentioned this because I did use INTERNAL digital vectorscope as well as EXTERNAL analoge vectorscope. And both gives same result.

Now - how it comes I do NOT have the differences you describe - the color shift from orange to yellow?

Marco

I admit that I am new to video editing and was not aware of things like YUV to RGB conversion etc. but I have to say that I am very dissapointed if not shocked that my film changes color even if all I want to do is add some time code to it. Even if my camera made some "out of standard" or "illegal" footage, it seems suprising to me that todays video editing programmes and dv codecs cannot deal with this in a way that atleast looks like the original ! In my case I have peoples skin color changing from a natural pink into a stange yellow ! perhaps this problem only occurs under very extreme conditions but my original film "looks" by no means extreme. I can understand that there cannot be a 100% conversion between YUV and RGB but why is the difference in my case so obvious ?

Sorry to keep moaning

Berti

I've read the article you mentioned. It has aboslutely nothing to do with the problem. I know how NTSC and PAL sampling works for DV25. PAL and NTSC can also sample at 4:4:4 and does so on hi-end equipment. DigiBetacam samples at 4:4:4. HiDef NLEs already work at 10 bit RGB resolution.

None of this is relevant though. Out of gamut is still out of gamut no matter what the bit depth is. Both PAL and NTSC impose limitations on the acceptable values of YUV. These are not simple numerical value limitations. This article doesn't address this issue specifically:

http://www.beezlebugbit.com/school/color/colorspace.htm

But you will see on the phasor diagram that different systems impose limitations. Now the NTSC and PAL systems in the YUV space define their own set of limitations. these were defined before the advent of digital image processing.

Page 7 of this rather hard to read document:

http://www.cinemasource.com/articles/human_vision.pdf

clearly shows what I'm talking about. YUV permits the full gamut of colors to be defined however far from all of these fall within the legal range for NTSC or PAL. You will notice that although the PAL and NTSC gamuts are close they are not the same.

>> they don't want to see differencies - or they don't understand when this must see ....

DaLiV, this is a rather unkind reaction to those people here who are interested in the topic you arose and who want to bring some of their own experience and knowledge into the thread.

You might say we don't or don't want to see if we only compare visual results because this might be rather subjective. But analyzing color signals using a vectorscope is the most objective way to proof a color signal. Even if I'd be color blind I would see the difference - the color SHIFT in the vectorscope. Besides - it is my daily job to realize things like that.
The only error which might be there is if we'd used only internal digital vectorscopes which are fed by a RGB signal. But for we also used an external analog vectorscope connected to the dv device this is not given. If there'd be the difference you described - a color shift from orange to yellow - I would have seen this. I am not blind, not even color blind.

Fact is - and you see me, I believe what you are reporting about - some people like you got differences in the signals compared and some people like Spot and me got no differences in the color angle.
Now - we all used same codec for processing: Sony Pictures DV, didn't we!? But we all used different devices around - at least different dv-devices and different TVs/monitors.
So I think it is not legal to say it's the codec which makes the difference. If it is the codec Spot and me would have seen the differences too. But here on my systems there is no way to state the differences. So it is impossible it's the codec (used in the NLE) which causes the difference. Maybe it's the hardware-codec of your dv-device you use to connect the external monitor.

And not to arise any missunderstanding: When I speak of "no changes" or "no differences" I mean this related to the color switch you mentioned. There are a few changes indeed, but nothing which relates to a visible color shift, but changes which also appear if I render to M-JPEG or DVCPro50, both working in YUV 4:2:2.


Marco

Thanks for the info, Still feel pretty damm miffed that even supposedly very good programs and their codecs cannot give me a decent digital copy of my original analog film. I mean that's got to be a sad day when my hi8 video performs better than the digital copy, I'm not asking for the dv copy to look better, after all it's just a copy of the poor original. But I did think it would be possible to make a copy that looked the same.

Thanks for the input, shame we can't find a solution

Berti

... don't see orange turn to yellow when comparing these two files outputting on an external monitor. We do discuss this now in our german Vegas forum (again ...) and till now 2 more people proofed the two files and stated there are no changes the way you described. And I'm sure even more will come to tell: "No color shift visible." We all test PAL here.

Marco

noone word of PAL in this document.
i'm left this discussion
you are knew about this problem - but can't see - so it's your problem.
not only i'm have this problem - it's already known and described in any sources - if you want - can search thru internet - but ...