DV codecs errors while YUV->RGB recompression. (to sonyEPM: please stick this post)

Back to post

Comments

DaLiV wrote on 1/28/2004, 5:39 AM
you want to say - you have after recompression the same pure orange color ? - i'm not believe. - here will be shift to yellow (on pc monitor always present).
i'm using all of next codecs - and all of them produce this effect:
internal vegas codec
microsoft dvsd
Adaptec DVSoft 1.1
Canopus DV software v2.7 multithread
Canopus DV software v2.8
DualMoon DV Iris CODEC v1.0
IO-DATA Device v.4.21
MainConcept DV CODEC 2.3.1 2.4.4
Matrox DV 4.0.0.85
Panasonic Software DV v.2.64
Sony Software DV v.2.43
farss wrote on 1/28/2004, 5:47 AM
OK,
I think I'm starting to get it, sorry the language barrier isn't helping!

Can we just look at the first bit:

quote]
You shot a sunset with a camera. Played that back to a TV. All looked fine.
Capture that into Vegas. Looks the same on PC monitor.
[/quote]
here not so good - capture into any of programm and there is difference - worst


So after you capture the footage from the camera it looks bad on the PC monitor, right?
But if you played it back from the camera via the A/V outputs into the TV it looks OK, right?

A few things to know:
Most cameras convert the data from the CCDs into an analogue signal first and then the codec chip converts that to DV for recording on tape. If you monitor the cameras A/V outputs prior to recording what you see is not the same as what goes onto the tape.

When you capture from tape nothing happens to the data that the codec created in the camera assuming your using a DV camera and capturing via firewire. If it looks different on the PC monitor well it can only be the calibration of the PC monitor or the TV. Most likely both are out of calibration. In fact I'd say there isn't a TV that CAN be calibrated correctly!
taliesin wrote on 1/28/2004, 5:48 AM
>> you want to say - you have after recompression the same pure orange color ?

Believe it or not. There is no difference at all after rendering and watching the decoded file. And this is the way it should be. This is one of the reasons I chose Vegas as my favorite NLE.

We have this discussion several times a year in many german video forums and in the end it's not a trick to proof the proper behaviour of codecs like Sony Pictures DV.

Wait a while - I'll send you another test file to proof codecs behaviour.

Marco

DaLiV wrote on 1/28/2004, 6:45 AM
{So after you capture the footage from the camera it looks bad on the PC monitor, right?}
YES
{But if you played it back from the camera via the A/V outputs into the TV it looks OK, right?}
YES

things already known, and time by time explained to other .....

but calibration is not current problem.
before any process on pc stream have no changes and so played back correctly on tv and incorrect on pc. after FX on pc : tv picture seems aproximately the same as on pc (both incorrect)
taliesin wrote on 1/28/2004, 6:49 AM
Here's the file:

Download Testfile

Please unzip and watch it on PC first. What exactly do you see there?

Marco
DaLiV wrote on 1/28/2004, 7:04 AM
i'm see now you are ADVERTISER and only.
i'm also like vegas, but these problem in all codecs not only vegas - noone of NLE (that works in rgb) can correctly works.

have difference betveen played "have no decoded" and "decoded"

can you show to us picture after decoding that be different from this (which is with yellow shift ): http://195.2.110.74/~daliv/video/image0.png

otherwise PLEASE STOP ADVERTISEMENT - only facts, that you can argue.
mine facts - youu already saw, and mathematically verified.
but you while only say "vegas internal codec is best".
Former user wrote on 1/28/2004, 7:07 AM
I may be out of line here, but if you are seeing the error when you capture to the PC (before doing any editing), then the problem is in the Camera Firewire signal. The camera DV encoding is causing the problem.

The capture to PC is just a DATA transfer, no codec is involved.

Dave T2
taliesin wrote on 1/28/2004, 7:11 AM
Please tell me what you see when watching this DV-AVI. This is only fact which helps coming to the thruth.

Marco
DaLiV wrote on 1/28/2004, 7:13 AM
HELLO (on black) WORLD (on white)
DaLiV wrote on 1/28/2004, 7:18 AM
it's known. (noone says that captured data differs from tape - but the data after decoding on pc will cut off color information)
codec used when you watch data on pc monitor(and shift colors) ... and have not used when you the same data transfer from PC via 1934 thru DV-camcorder to TV
Spot|DSE wrote on 1/28/2004, 7:23 AM
DaLiv,
I've now tried this too, given the length of thread and passion you present.
Using your file, using scopes, previewing on external monitor (only as NTSC since I don't have a PAL monitor) I transcoded this from PAL to NTSC. There was no significant color shift based on my eye and based on the Waveform/Vectorscope. There was a 1% shift in green, to be expected given the different color sampling for PAL from NTSC DV.
Did the same thing rendered to another new track, this time in PAL. Same result. Nothing different on the waveform monitor/vectorscope.
Somewhere, your monitor is flawed, or you are seeing something that isn't real nor related to Vegas.
My preview flow:
Vegas timeline>Firewire out to Panasonic AGDV 2000>SVid to Sony broadcast monitor. No video card preview, it's firewire output. My vid card is a Matrox Parhelia, DVI to Mitubishi LCD. No analog out connected on the Parhelia.

I've posted my results at http://www.sundancemediagroup.com/scopes.htm
DaLiV wrote on 1/28/2004, 7:25 AM
need to see around of sun where white transforms to orange
on TV: pure orange color of sun without any wave of yellow
(on pc monitor you always see this yellow waves using anyone codec)
taliesin wrote on 1/28/2004, 7:31 AM
To your other accusements: I did never say Sony Pictures DV codec is best. There are much more properties to proof before saying things like that.
What I say is: There are lots of DV codecs - and Sony Pictures DV is one of them - which does NOT TOUCH the color range in any way. Neither when encoding, nor when decoding. Codecs like these handle full range of 0-255 without any changes! This is profen dozens of times.
Decoding the AVI I have given by this link is one thing to be beware of when analyzing this.

I have given you information from the international standard ITU-601which is another link in this chain to proof codecs like this.

Marco
DaLiV wrote on 1/28/2004, 7:32 AM
about scopes in vegas : this got after processing to rgb - not native dv format, that in YUV.
need to try recode this matherial to ntsc without coming to rgb - may be advanced pal/ntsc converter can be helpful to this - only if this processPAL YUV to NTSC YUV.

pal/ntsc transcoding in vegas pass trhu codec that works in rgb.
taliesin wrote on 1/28/2004, 7:35 AM
O.k. - this states your decoding works same like mine regarding the luminance range.

Now let me think about what other circumstances may cause different results for you. Gimme a while ...

Marco
DaLiV wrote on 1/28/2004, 7:36 AM
{ Why don't you answer my question?}
may be language barrier - i'm try answer as i'm understand your question. ask this in another form.
if question about black and white - i'm answered to that - see the answers tree - on each post i'm answer individually - not in one post to many branches
taliesin wrote on 1/28/2004, 7:41 AM
Yes, I meant the b/w AVI. Saw your reply now. Thanks, knowing about how this AVI behaves on your system is a valuable information.

Marco
DaLiV wrote on 1/28/2004, 7:47 AM
i can try to help you:
in your example we can see white and black color which in rgb is R=G=B with higher range, in mine - you have R<>G<>B and also with high range.
Spot|DSE wrote on 1/28/2004, 7:50 AM
I'm sorry, I'm just not understanding why you are staying blind that it could be anything else you are dealing with. It could be your video card, converter, tv cable, monitor, any number of other things. Why YUV anyway, since it's RGB from capture, to Vegas, to output?
I just played with it again, rendering to Huffman YUV. No significant change/shift. True, scopes are reading RGB, but if the shift you indicate was there, it would STILL show shift.
I'm not really interested in getting advanced conversion tools. These work just fine, and I've got both PAL decks and NTSC decks, PAL converters and NTSC converters, I'm only missing a PAL monitor, and don't really need one. My Sony deck shows PAL, it's just too tiny to see much very accurately. Besides, it's LCD. But I do have the tools to see that your media isn't shifting like you say it is, therefore I submit the problem you are having is absolutely not related to Vegas. Believe me, if it were, the EPM's would be all over this.
I've just uploaded the image of the Huffy-rendered media to the same page.
http://www.sundancemediagroup.com/scopes.htm
taliesin wrote on 1/28/2004, 7:52 AM
Yes, but that's not it. For I have no changes on your AVI after rendering and decoding then. I only wanted to proof you do not use a codec like MS DV for decoding.
Does not touch our discussion, but ... if you like - do watch my "hello world"-AVI using the MS-DV codec and see how this differs then ...

I at work now and have to pause testing. I'll be back later in the evening.

Marco
DaLiV wrote on 1/28/2004, 8:01 AM
#here also may be helpful for you:
#avisinth 2.5 script:
clip = AVISource("16_235_sun.avi")
clip1 = ConvertBackToYUY2(ConvertToRGB24(clip))
res = Subtract(clip,clip1)
return res.colorYUV(Analyze=true)

on your example you will see your differenced "hello world"
on mine - color that loses after decoding
and information about losses ....
see all numbers on both files
DaLiV wrote on 1/28/2004, 8:03 AM
{Why YUV anyway, since it's RGB from the camera, }
no rgb from camera - DV is YUV in base

DV is in fact YUV 4:1:1 color sampling (or YUV 4:2:0 in PAL).
{scopes are reading RGB, but if the shift you indicate was there, it would STILL show shift}
if this compare matherials with the same color base. too late catch the shift when it's done before any of measurement
DaLiV wrote on 1/28/2004, 8:21 AM
you want to see differences - i'm can try to help:
there is script to see differencies
http://mediasoftware.sonypictures.com/forums/ShowMessage.asp?ForumID=4&MessageID=248554
main losses in on first phase - decoding to rgb. - so second pass - encoding will not able to test

also if you rendered after decoding to rgb - you already works with incomplete data
Spot|DSE wrote on 1/28/2004, 8:26 AM
At this point, all I can suggest is that either;
A; You have faulty hardware
B; The YUV codec has a problem
C; you are trying to create an issue that isn't there for whatever reason

The same media, reading on the scopes contained in other NLE tools show the same results. The image appears the same on the external monitor as it does on the LCD monitor. The scopes are consistent regardless of the format of file as an RGB codec or a YUV codec. If the scopes and the eye see the same thing, and the shift that you claim is happening isn't visible to either when multiple people are looking and playing with it, then it's not a shift in the conversion, but rather something else in the process.
If a system only supports a YUV codec, then the output from the RGB rendering pipeline must be re-converted back to YUV every time it is stored to disk or passed back to the video card. This can mean multiple color conversion steps required to process most video effects. Many of these color space conversions can be saved if the video is encoded directly to RGB upon capture, or if intermediate results of rendering can be preserved in RGB color space within the computer, whether it's 4:1:1, 4:2:2, 4:4:4, 4:2:0, or other codec format.
{edit} Looking at your image in acticom as a YUV image, as that's the only tool I've got that I can use to measure your original image, it's identical to the scope output as Vegas sees. What is equally supportive in my mind, is that in testing FCP's handling of YUV vs RGB,Adam Wilt's findings are identical, that using a high quality codec, there is no significant shift in chroma nor luma values. {edit}
The camera signal IS converted to RGB at capture, and this is the most efficient format for editing and processing. But even if you want to convert back to YUV which apparently you do, the loss in the conversion, which is no doubt there at some level, is not significant as you indicate it is. Why is it that you aren't willing to look at other possiblities for the problem? If there is a problem? I'm failing to see the point in this discussion.