"It has helped me to understand that what is *within Vegas* already is much better than....."

Yup.
Not put-down towards Cineform but....
at $130 Cineform neo scene may be worth it simply for the flexibility when jumping from program to program.... but the prospect prices are simply out to lunch for what you get and how the cineform codec stacks up against others. (Just my personal opinion of course)

How is this for a summary of this thread so far?:

Because of the way Vegas works, there is a new Y'CbCr to RGB conversion for each generation. This conversion is where most of the damage was done in the tests Lars conducted.

Working with 4:4:4 footage gives you extra precision and minimizes the errors from these repeated Y'CbCr to RGB conversions.

Thus in Vegas at least, working with a 4:4:4 format (even a long GOP format like mxf) is preferrable to working with a 4:2:2 format, even if it is internally a better multi-generation safe format like Cineform.

Uncompressed footage will handle multiple Y'CbCr to RGB conversions without errors. So will Huffy and Lagarith, but uncompresssed will preview much more smoothly especially in real world situations where filters and transitions are being added.

For now at least, given that Lars is committed to continuing to work in Vegas and that Vegas refuses to move beyond the RGB VFW video pipeline, he has decided to use uncompressed video in his studio and mxf with his laptop because of these issues.

Cineform Neo 4K would probably be just fine, but it is too expensive just to use because of this one issue. The Morgan MJPEG codec might also be fine, but their website is currently taken over by some sort of virus and this has scared him away.

So for now at least, the two formats that Lars will use are uncompressed and mxf.

"So for now at least, the two formats that Lars will use are uncompressed and mfx."

Actually, Lars will be using mxf -- "material eXchange format."

;o)

Thanks Jay. I went back and fixed my post. I still think "mfx" sounds better for though. ;-)

That is an EXCELLENT thread summary, Laurence, and very helpful. Thank you.

Some of us went with the Cineform codec for its ability to remove the 3-2 pulldown from the Sony V1U and Canon HV20 cameras in the 24p setting. Along with the other selling points of the Cineform codec at that time (better preview, better multi-generational renders), that was a great way to go.

The MXF format sounds like an option, albeit without addressing the pulldown issue. I know there's an alternate method to remove the pulldown, but as I recall it's quite involved. I'm very interested to see how the 9a version pans out with Cineform. As Blink stated above, the NeoScene may be a viable option (if 9a fixes the issues), as the cost is reasonable, but I'm not sure that jumping up to Neo 4K is worth the cost.

Missed I lot of posts I see, busy doing work stuff.

Here is the status.
1) Things are looking good for new Vegas components coming from Sony -- thanks guys.
2) Neo Scene has not had the new multi-generation calibration completed for Vegas, that should be done in about a week. Vegas is the only tool that regularly does vsRGB to YUV and back again, so we didn't know it was out, no reports until this thread. Why does calibration go out? We are evolving the underlying technology frequently for more speed, pixel formats, high precision dithering and the new Active Metadata tools. Changes don't always roll out evenly. As the test bed for all the codec inputs and outputs is more complex than codec it self, we also have rely on user feedback if something is not right.
3) Performance totally depends on your PC. I just tested Vegas 9 in my stock desktop i7, 1080p60 plays as at Preview Full only using 50% of the CPU, so 1080p30 or 1080p24 should work on most modern dual core better PCs. These are today numbers using the currently available release. Performance seem pretty very good (better that I expected.) When testing new (beta) Vegas components, the same 1080p60 playback at Preview Half only used 20-25% of CPU, so lots of headroom for filters.

David Newman
CTO, CineForm

Thanks for the update David. That all sounds very positive. Most of us only do a couple of generations by the time a project is completed, but we do want the most quality possible out of those few generations that are necessary.

One more question Lars. Do you check mxf 422 and mxf 444 versions against each other? If so, how did you find they compared after multiple generations?

Of course, the core compression quality has never been better, we just have to make sure all video tools can see that with the pixel formats and colorspaces they prefer. For pixel formats and color space supported, we are now around 20-25 different types, Vegas one uses one of them.

David Newman
CTO, CineForm

>>>I've been accused of being a "measurabator"<<<

Bob, I think that should be taken as a compliment! Discussions based on facts are always more productive. And more easily comprehended.
Obviously Cineform will fix the colour shift problem without us having to move to Neo4K, but can you comment on the numerical bit depth at which Vegas holds image information? Obviously I'm wondering about rounding errors at each vsRGB to YUV and back again cycle.

David,, I do not understand what you mean when you write: "1) Things are looking good for new Vegas components coming from Sony -- thanks guys." Can you give a more detailed explanation?

Jøran Toresen

Jøran,

I've been able to test an upcoming fix to Vegas 9.0. Not a publicly released change yet, testing it now for Sony.

"Discussions based on facts are always more productive. And more easily comprehended."

Agree, obviously. The problem I see here is we don't have access to a lot of facts. We can't put a probe into the middle of the pipeline and measure what's going on. As a result there's always room for working from wrong assumptions.
One of the most befuddling things I had to get my head around when I got back into this game was how two seemingly identical images behaved when you did 'something' to them e.g. color correction. as I now know, eyes can be a poor judge of image fidelty, especially in the video world where the system relies on the limitations of our eyesight. This is made worse by the limitations of cheap display devices. Many LCD displays are only 6 bit, my Dell 24" monitor can show horrid banding where none exists and fails miserably in the blacks. Some monitors apply edge enhancement and/or noise reduction.

"can you comment on the numerical bit depth at which Vegas holds image information"

There's an article here that explains the Y'CbCr to R'G'B' conversion process. Checking the document's history, Glenn has had some input, I assume it's therefore fairly accurate, his only complaint seems to be over the liberal interchanging of the terms Y'UV and Y'CbCr.
Given that these calculations should be performed in floating point for accuracy there has to be rounding errors when converting to 8bit R'G'B' and back again. Vegas does seem to do an excellent job of minimising these but they must still be there. I suspect (no way to test this) that this was what Lars saw happening with the XDCAM 422 codec when it produced minor shifts.
However Vegas also has a 32bit mode. I assume (no way to look inside) this takes the FP values and preserves them, right through the pipeline. Certainly tests I did some time ago with V8 and the 10bit YUV codec confirm this. It'd be interesting but a lot of work to repeat Lars's tests of the XDCAM 422 codec using 32bit.


My primary concern though is the test methodolgy. Res charts, Macbeth charts and color bars are all static images. They were designed before the days of inter frame compression. I know of no standardised test for measuring the impact of inter frame compression. As I've seen many times you can compress still images (basic slideshow) to an incredibly low bitrate with mpeg-2 and they hold up perfectly. Real video especially from cheap cameras in low light is another matter entirely. It's also worth keeping in mind that some of them employ a number of tricks e.g. the V1P's level based dynamic noise reduction. The images look great out of the camera until you try to color correct them and you start to see blocky artifacts come out of the blacks.

There was something said at the NAB party that was quite interesting and perhaps relevant to this discussion. The XDCAM 422 codec has been used as a Digital Intermediate for a motion picture (sorry don't recall the name) and was found to be as good as HDCAM SR. That's a HUGE statement! If you're an indie producer just the cost of SR stock can be significant.
But how relevant is this. Start with scanned 35mm neg that's been through grain reduction and you are starting with a signficantly cleaner image that what most Vegas users will ever get even from the prosummer HD cameras. I'm not saying if XDCAM 422 @ 50mbps will perform well or not for most of us, simply saying "hey hang on, we're not comparing apples to apples here" because the quality of the original image has a very significant impact on what happens to it through the post pipeline. Until this is tested with real world video we are indeed making assumptions. My quick and dirty tests show some loss even after one generation but you've got to look for it.


There's another aspect to this that Dan raised, speed.
Just about everyone here at one time or another complains about preview performance with Vegas. If as stated Vegas's vfw interface forces the codec to decode Y'CbCr to R'G'B' then I *think* I can see some issues. That requires many codecs to not only decode long GOPs but also do that conversion. If the codec is not aware of the preview quality being used it'll be doing a lot of work for nothing. This I assume is addressed in V9. The host application can signal to the decoder that it doesn't need the best possible quality, 'please try to work for speed'. This sounds like a big step up in V9.
However, Vegas is still buffering RGB, an inefficient way to store video. What I'm sayin here is the RAM preview buffer might not be being well used. It might make more sense to buffer the original Y'CbCr data from the source, especially if using external monitors (SDI or firewire) as these also require Y'CbCr. Doing this would make better use of available RAM and reduce CPU load if no FXs are being applied.
And now I've gotten way off the topic and I really have to get back to paying work :)


Bob.

Bob, thanks for that detailed reply. Those are all issues of import. The difficulty for users of NLEs are that they're windowless black boxes and it's easy to run up blind alleys when trying to understand reasons for observed misbehaviour. I was half way up a concern that Vegas is storing at each generation image data at 8 bit depth, possibly generating detectable transformation rounding errors. However seems I got that wrong.

Bob, intra frame compression is a lot easier to "compare" that interframe compression, especially if interframe is using I-frames. intra frame compression is just on single complete frame, so stills on 24p or 30p is a breeze ;-)

@LarsHD,

"Trying to visit that Morgan website and AVG and Google stopped before it allowed the site to load. Warned again viruses and mal.ware etc. Not a good start... Don't want that kind of companies..."

The Morgan website was maliciously attacked and compromised, but it has now been fixed, if you want to download the MJPEG2000 codec demo and try it out. Here's a good guide to using the codec:

http://www.hv20.com/showthread.php?t=3246

J

David,
The changes you're implementing to the Cineform codec to work with Vegas... I'm assuming that these changes will be made to both NeoScene AND Neo HD at the same time? I still have NeoHDV, and if I have to upgrade to either NeoScene OR Neo HD, I'm debating on just jumping right to Neo HD.

CClub,

These are codec core changes so they will apply to all our packages.

Regard Neo Scene vs Neo HD, try Neo HD and do some testing with First Light, as this is the major difference. Neo HD also includes scaling and timing change tools, and support for many more cameras and video sources.

David

apit,
my bad. got "inter" and "intra" mixed up.

Bob.

The keyboard--- my typing is my worst enemy, especially on these mobile devices ;-)

Hi!

------------------------------------------------
Cineforms / David N's post:

David N: "Here is the status."

Lars: If you write "Here is the status" it needs to be something more real I think....

David N: 1) Things are looking good for new Vegas components coming from Sony -- thanks guys.

Lars: "Things are looking good" - hmmm... Sales talk again David ;) BTW, I just did something here, and it's looking great - thanks...


David N: 2) Neo Scene has not had the new multi-generation calibration completed for Vegas, that should be done in about a week.

Lars: Oh that's sad to hear. Why wasn't this done? Ahat are the implications for your clients of you not yet having completed this "multi-generation calibration" on a product you already charged money for? So *NOW* you're saying that the product I've had from you for months isn't "calibrated". Great news! Things are looking great!

(Well, I found out myself after a while...). And when did you get aware of this? When I posted my results?

Does this "calibration" mean getting the luma and chroma levels right etc?

David, you were talking about you yourself having done 200+ generations some time ago... Was this on *another* product than what I had paid for... ? If so, when I complain about one product, why do you write about the advantages of *another* product? Didn't you notice a problem during those 200+ then...? When you wrote that about 200+ there is *no way* at all in this world you could have done 200+ with CIneform in Vegas getting a reasonable result...

(If you are referring to *another* product that you could run 200+ generations, then that is equivalent to selling bad tomatoes and then telling the complaining customer that "our bananas are the best")

David N: Vegas is the only tool that regularly does vsRGB to YUV and back again, so we didn't know it was out, no reports until this thread.

Lars: ??? So my very simple test, rendering, taking it back in Vegas and rerendering again was something you just hadn't done before selling that codec to me? "No reports".... It should be one of the basic tests before even allowing the product to leave your codec factory... So should I now interpret that products from Cinefrom can be severely crippled and it is only until paying users find out.... etc?

David N: Why does calibration go out? We are evolving the underlying technology frequently for more speed, pixel formats, high precision dithering and the new Active Metadata tools. Changes don't always roll out evenly. As the test bed for all the codec inputs and outputs is more complex than codec it self, we also have rely on user feedback if something is not right.

Lars: Not an impressive answer. You need to have internal tests in your company that reveals these problems. If my simple test that I published in this thread could reveal these problems, you could have done that yourself.

I don't want to do beta testing for you and pay for it.

David N: 3) Performance totally depends on your PC. I just tested Vegas 9 in my stock desktop i7, 1080p60 plays as at Preview Full only using 50% of the CPU, so 1080p30 or 1080p24 should work on most modern dual core better PCs. These are today numbers using the currently available release. Performance seem pretty very good (better that I expected.)

Lars: Sales talk.... "better that I excected"..... What is that?? "Performance totally depends on your PC". What sort of performance? FPS? Getting the impression that CIneform is alwyas good and if it isn't, it's the PC's fault. Compare with MXF - how dooes your codec fare then?

Can you play two streams of 1920x1080 29.97 fps during a dissolve and maintain full frame rate in Vegas? Which Vegas? If so, on what system, what disks etc. MXF does that on my Q6600, Asus P5KR, Raid-0 with two 10000 rpm drives.


David N: When testing new (beta) Vegas components, the same 1080p60 playback at Preview Half only used 20-25% of CPU, so lots of headroom for filters.

Lars: What is it that you are trying to say here? That Cineform is playing back at a lower FPS than MXF? Or that uncompressed AVI from good RAID-0 setups will have even lower CPU consumtion than Cineform...? Pls explain.

Summing up my own interpretation of Cineforms response:
I think the response from Cineform - as usual -is vague and diffuse and is trying to deviate from the real problems I have reported.

I don't really understand why it's posted here.

If David N are referring to basic luminance levels and chorma levels when he says "calibration" why are these errors not found by Cineform themselves *before* releasing updates?. And fixed. Why has basic level accuracy of a product like this becoma a topic here? It really shouldn't.

Again, these answers confirm that my choice this week was a good one. Even if I lost $ 129.- and lots of time.

Questions to David:

A) Can you fix the color, chroma so that the magenta cast goes away? A1) When?

B) Can you fix your codec so it plays back as smooth as MXF? B1) If so - when?

-------------------------------------------------------------

And the second post of David N. here:

David N: "Of course, the core compression quality has never been better,"

Lars: What is this? From what aspect? Do you mean the severe choma shifts? Do you mean the magenta cast in the latest update? We are talking about real problems with the codec and youre saying that it has "never been better"... (?)

Again: sales talk - "quality has never been better,"...

It still plays back slower than MXF. It has magenta cast. It took many hours for me of testing and revealed real problems. Then some were indeed improved. Had you found out yourself? Or must clients sit for hours test your product for every release?

David N: "we just have to make sure all video tools can see that with the pixel formats and colorspaces they prefer. For pixel formats and color space supported, we are now around 20-25 different types, Vegas one uses one of them.

Lars: ???? What is it you are trying to say. I fear most of the readers don't get a lot out of that. Please explain exactly what you mean. I paid for a product that does weird things when I use it and what you say isn't helping me I'm afraid...

----------------

To Laurence:

Laurence: "One more question Lars. Do you check mxf 422 and mxf 444 versions against each other? If so, how did you find they compared after multiple generations?"

Lars: Sounds like an intersting test! What settings do I use there you think. How do I get into the 444 mode? Or can you perhaps give it a go this time...? Perhaps David N can run this test and publish it here? He's the guy earning money adding knowledge to the fine art of manufacturing codecs... And shouldn't he know already...?


----------------------------------------

To Bob:

Bob: "My primary concern though is the test methodolgy. Res charts, Macbeth charts and color bars are all static images."

Lars: The primary concern whould be why *Cineform* aren't able to publish real tests and show what's happening! No reason Bob for concern over *my* limited test methods at all. I'm just a client and user who pointed Cineform to a severe problem. It's up to *them* to do the rest... And to *you* to do additional tests if you feel that that is required in order for you to carry on this discussion... Btw - test charts and static images are vital and very good *PARTS* of testing. Motion and noisy sources also are very good and necessary. And *YES* I have done such tests too btw. But for sure, just various colored text against variour colored backgrounds can be *very* revealing and hopefully this fuelled Cineform in taking action. So even one single test chart drawing the attention to a severe chroma problem in a codec can be very helpful and cause activity. As this thread indicates... Bob, I assume you made useful informative tests yourself with these codecs using other and "better" signal sources? It would be nice to take part of these as motion, noise, exposure changes while watching white / gray shaded surfaces etc and how the codecs we are speaking about are affect the quality is for sure very intersting. Looking forward to reading your results!

----------------------------------------------------------

1. Sometime really boring time consuming tests can be really revealing....

2. It seems that some companies don't make suffiecient testing before selling their products and it is only when it escalates to the point of embarresment that action is taken and quality is improved.



Best
Lars

Ok im not going to pretend to understand all that has been written on this thread because frankly some of it goes way over my head.
What I have read does concern me though as I bought into cineform to use with vegas 8 as i believed that it was the best codec to use.when converting my HDV footage.
Am I right in assuming from this that cineform is basically broken within vegas?
I didnt upgrade my Neo hd to version 4 because i thought the price was unfairly high.
If version 3+ is broken then woudnt it be fair to upgrade for free to a version that is fixed. or just update version 3 again.
I see david has said that an update has been issued and further work is on going then surely 3 should be fixed aswell or have i missed something here...thanks john