Interesting and confusing.
How did the camera make a JPEG with 4:2:2 chroma sampling?

A quick Google reveals that JPEG can use chroma subsampling !!
Apparently so the image can be losslessly rotated.

Sorry Grazie, this is interesting but all I can suggest is to forward your discovery to SCS.

Bob.

That's a new one on me, too.

Here's the MediaInfo Details on the Chroma SubSampling:-

JPG straight from camera = Vegas CHOKES using PanCrop



JPG after saving a straight copy<>size = Vegas GOOD using PanCrop



What do we think folks?

Grazie

I am guessing that the JPEG format has a lot of variations and that Vegas can't handle a particular variation on the format.

It's not just the chroma subsampling that can present problems... many formats such as TIFF tend to have obscure variations that some programs can't handle.

2- The chroma subsampling in the JPEG format is different than the chroma subsampling in video formats. For example, you cannot represent 255 0 0 in a JPEG because it uses a different form of Y'CbCr than video formats.
Anyways... I don't think that is relevant at all.

3- I really have no idea why Vegas is failing. It might be helpful to forward your JPEGs to the SCS team.

If converting your JPEGs fixes things then I would stick with that workaround until Vegas' issue is resolved.

A quick Google reveals that JPEG can use chroma subsampling !!

I don't think that the lossless rotation has much to do with chroma subsampling. Because the image is broken up into DCT blocks and those can be losslessly rotated without generation loss.

The JPEG export plugin for Irfanview lists 4:4:4, 4:2:2, 4:2:0, and 4:1:1 (my guess is that 4:1:1 means 4:1:0, and I have no idea about the 4:2:2 format). I have no idea about the 4:2:2 JPEG format... I've never heard of it before. (Which probably means that I don't know too much about JPEG.)

4:2:0 would be the most common format for JPEG, probably followed by (the much rarer) 4:4:4.

Thanks Glenn.

G

How odd that anyone would use anything but 4:4:4.

Maybe that's why JPEG gets such a bad rap in some circles?

Someone please correct me if I'm mistaken but I thought I read on this forum a long time ago that Vegas internally converts all stills to 4:4:4

Mike

What do you mean by "choke"?

Almost every digital camera out there outputs 4:2:2 for chroma subsampling. I have done stills with pan/crop/rotate in Movie Studio 12 and I currently have the vegas trial.

With higher megapixel images MS12 is fine but vegas pro 12 really gets slow and stuttery. Maybe this is your "choke" situation?

This is with 12MP images from my GoPro camera.

When resized to 7MP vegas seems to be fine. I only just started this test last night. Now I used Photoshop SaveAs "10" to batch resize and this setting uses no chroma subsampling. Maybe the problem was less about the MP and more about the subsampling!

Photoshop save as 8 and up use 1x1 (4:4:4) chroma. Below that PS uses 2x2 (4:2:0), which is like DVD and Blu-Ray.

Here is an article with more about chroma subsampling that you want to know.
http://www.impulseadventure.com/photo/jpeg-quantization.html

The photo editing software i use has a separate subsampling selection independent of JPEG compression amount. I set it to 4:4:4 the first time i saved an image with it and have never changed it since.

Below that PS uses 2x2 (4:2:0), which is like DVD and Blu-Ray.
It's not really the same. see

w.poynton.com/PDFs/Chroma_subsampling_notation.pdf

http://www.hometheaterhifi.com/technical-articles-and-editorials/technical-articles-and-editorials/the-chroma-upsampling-error-and-the-420-interlaced-chroma-problem.html

The short answer:
1- There is a big difference between interlaced and progressive. Interlacing and chroma subsampling can be an evil combination. 4:2:2 interlaced is fine, 4:2:0 in an interlaced format gets weird and complicated.
2- Chroma subsampling notation is often confusing and ambiguous.
3- There are some crazy technical details that aren't intuitive. How the chroma aligns with the luma is often different between formats and different between implementations. This is a huge, huge mess.
Some codecs do things one way, some codecs do things another way.
Most NLEs don't really handle this correctly.

NormanPCN " What do you mean by "choke"?"

Vegas hangs and stops working, to the point that I need to kill Vegas in Task Manager.

G

"Someone please correct me if I'm mistaken but I thought I read on this forum a long time ago that Vegas internally converts all stills to 4:4:4"

You are correct. Vegas and as far as I know every NLE converts everything to RGB (4:4:4) for display and processing..

That said I don't see how this is relevant to the problem here.
The problem here is that Vegas chokes on the process of converting a still image that uses a particular form of compression into an uncompressed frame.
The precise details of how this still image is compressed is moot. It uses a valid scheme within the JPEG specification. Vegas claims it can handle JPEG images with no caveats. Vegas has a bug.

Bob.

"The precise details of how this still image is compressed is moot. It uses a valid scheme within the JPEG specification. Vegas claims it can handle JPEG images with no caveats. Vegas has a bug."

+1 on that.
One thing I have speculated on is if Vegas is decoding the jpeg for each generated frame. This would be consistent with my experience that large jpegs cause stutter playback problems. One can infer than chroma subsample, adds some overhead since the chroma must be interpolated to full res.

You are correct. Vegas and as far as I know every NLE converts everything to RGB (4:4:4) for display and processing..
Not that this matters but some NLEs convert values to Y'CbCr internally. FCP can do this (FCP can convert values to RGB, Rec. 601 Y'CbCr, Rec. 709 Y'CbCr, and maybe some other formats).

2- Who knows what causes this bug? Hopefully it gets fixed.

Grazie

I can't reproduce your problem. Could you provide a few details please?

1 What are your project settings?

2 What version of Vegas are you using?

3 Is the project stills only, or do you have some video as well?

4. If there is video, what format?


All my four digital still cameras that I have or had take stills that Mediainfo reports as 4:2:2.

If I convert my DSLR raw images to JPEG in Photoshop, they become 4:4:4.

If I resize JPEGs using the Win XP Powertool, they become 4:2:0.

I put a series of each group at high resolution on the timeline of Vegas 12 with a 1920x1080 50i project and panned and zoomed on some of each type. Vegas didn't crash and played them somewhat jerkily.

I rendered the timeline to the AVCHD template, and the result played smoothly.

Thanks for going to all that trouble PD! Always "wise" to have another set of eyes on this.

OK, I reopened the Project and played the 4:2:2 offering and after 4 looping "plays" I got the "choke" and this report:

Description:

Now on to answering your questions:

1 What are your project settings?



2 What version of Vegas are you using?

VP12 Build 486 - The latest Version and Build.

3 Is the project stills only, or do you have some video as well?

It is ALL video with just one JPG, and that's this 4:2:2. If I swap it out to 4:4:4 it plays and renders fine.

4. If there is video, what format?

Here you are:-


OK, if I swap-out this 4:2:2 to a 4:4:4, I get your success you have with your testing.

Cheers

Grazie

grazie, see the other thread re thumbnails. maybe that's got something to do with it?

Grazie

I took a 24p MOV file from my DSLR and set the project properties to match plus other settings as per your post. I added a photo to it and panned and zoomed. I tried 4:4:4, 4:2:2 and 4:2:0. Everything was normal.

I can only think that there is something else different about your photo. Have you tried a 4:2:2 photo from a still camera?

I have. Photo(s) from a GoPro Hero3 black. 12MP 4000x3000 4:2:2.
I have had consistent lockups, and I hae figured out how to work around the VP12 issues so I can work.

I am a recent convert to VP12. I had been using Movie Studio 12. Built my slideshow project in MS12. Mega hours.
MS12 edited okay (GPU or not). Render was a 100% crash (GPU, CPU was okay). Reported this to support.

VP12 locks up almost instantly upon playback after opening the exiting MS12 .vf file when GPU is enabled.

With GPU off it stutters so bad it is unusable. Never used VP12 any amount to know if it locked up any percentage or not without GPU. It was unusable.

I resized the images in photoshop to 3000x2250 7MP hoping this would help. Things work fine now, mostly at least, to the point I can do some work.

I can cause a lockup if preview is at half instead of quarter.
My resize also changed the chroma to 4:4:4 from 4:2:2. If that has anything to do with this or not I do not know. I just know I got somewhat functional.

I installed VP12 Saturday and figured this workaround on Sunday. I have not yet put together a small reproducible project for a report to support.

It seems to me if I stress VP12 it will lockup. By stress I mean where the preview can't keep up (stutters) and needs to resync with audio. The more that happens the more likely it locks up. It locks up at variable points for me.

For example, even with the 7MP 4:4:4 files. If preview is half and I have a fast zoom in pan crop, I get lock ups more than half the time those images are shown. With preview at quarter, it can keep up on fast zooms and have yet to get a lockup.

i"ll try to put together a small project to show the issues I can reproduce.
I created a project that MS12 will lokup 100% with render if support ever responds to my bug report and wants something to dup the bug.

My profile has my machine config.

PeterDuke? : "Have you tried a 4:2:2 photo from a "

What do you mean a "still camera"?

G

I submitted a bug report to Sony. I supplied a sample project, 900MB, where VP12 b486 locks up on preview playback with my 12MP GoPro Hero3 photos.

My lockups only seem to happen when GPU is enabled AND dyanmic ram preview setting is non zero (normal). GPU and dynamic ram preview 0 was fine. CPU only was fine.

By fine I mean it did not crash. The stutter still makes the software unusable.
By fine I mean it made it through the 9 minute video without crashing three times.

My workaround is resize jpegs and remove chroma subsample. I can still lockup on three images that have a fast zoom, if my preview is at half. Quarter is fine there. Half fine everywhere else.