Vegas Changing Colors of my Photos (with levels fix)?

LongIslander wrote on 5/14/2020, 3:24 AM

The "computer to studio levels" fix works perfect for my 0-255 content/videos.

However; I noticed my with my photos the rendered results come out slightly off.

Original .Jpg

https://www.dropbox.com/s/42x9n71d7kbbj1i/IMG_4697.JPG?dl=0

Imovie (iphone) upload to youtube (colors match)

Vegas upload to youtube XAVC-S (computer to studio levels) (colors are off compared to original jpg.)

ย 

Comments

Marco. wrote on 5/14/2020, 4:02 AM

Comparing the YouTube downloads with the leveled jpeg source it's the imovie upload which is slightly off.

LongIslander wrote on 5/14/2020, 4:05 AM

It is most definitely the opposite. ๐Ÿ˜•

Marco. wrote on 5/14/2020, 5:29 AM

I downloaded your YouTube clips and compared against your source photo (leveled to Studio RGB).

Source

Your Vegas Pro YouTube version

Your iMovie YouTube version

Black/white level and gamma of source and Vegas Pro version match visually. The iMovie version's black level is slightly higher, white level is slightly lower, gamma is slightly lower.

Musicvid wrote on 5/14/2020, 9:29 AM

It is most definitely the opposite.ย ๐Ÿ˜•

That is another reflexive, 100% incorrect statement based only on your expectations (and there have been dozens more in the last week). I hope you stop doing that soon.

New users sharing visual comparisons are reminded to include scope grabs, compositing difference tests, or RQMT results to support their impressions. Your eyes are not always your friend here, especially when a colorspace conversion is involved.

So let's follow through with a teachable moment. Below is an informal noise print from Marco's prints. Informal, because the difference composite is enhanced 10:1, and not quantified further by PSNR, SSIM, or RMSE. But the visual differences tell whole story. Less noise is better. More noise is worse.

It takes decades of experience to be able give an informed visual impression such as @Marco. , backed by tools and tests. This is a good point for you to begin learning to use them; "Begin" being the operative word here.

"Black/white level and gamma of source and Vegas Pro version match visually. The iMovie version's black level is slightly higher, white level is slightly lower, gamma is slightly lower."

Yep.

https://tools4vegas.com/render-quality-metrics-2/

ย 

Marco. wrote on 5/14/2020, 12:33 PM

One other thing to mention: The further the videos went, the harder is to find out what happened.
If you watch/analyse the video not till the end via the browser, there are so many factors affecting the result. Different browsers, different YouTube streams, different grafic device preferences, different YT decodings, different NLE encodings.
I'd tried best we could do: not letting different browsers and grafic device preferences affect the result and best as possible not different streams. But at the very least it would need to analyze the files which has been uploaded to YouTube, so we'd see if the YouTube encoding made the iMovie result differ or iMovie itself (I guess the latter).

Musicvid wrote on 5/14/2020, 1:17 PM

so we'd see if the YouTube encoding made the iMovie result differ or iMovie itself (I guess the latter).

I strongly suggest the latter; Youtube seems to be a K factor.

LongIslander wrote on 5/14/2020, 1:33 PM

For those who think itโ€™s YouTube render out the photo yourself and then open it youโ€™ll see Vegas and he doesnโ€™t retain the original colors.

appreciate all the help/feedback.

Marco. wrote on 5/14/2020, 2:18 PM

"And for those who think itโ€™s YouTube render out the photo yourself ..."

You missed to tell which render type/codec and which render settings you used.

Here is my render comparison having used Magix AVC (all before a YouTube upload):

Your Source Photo

My VP17 AVC Render Result

There's no difference in black, white, gamma, color, both visually and technically.

You should do vice versa. Put your iMovie output into the Vegas Pro timeline and compare this one against your source. Or offer both your VP and your iMovie render clip as download so we could analyze your particular clips.

LongIslander wrote on 5/15/2020, 1:45 AM

iMovie Render

https://www.dropbox.com/s/hex1hi5brvb1r9o/iMovie%20Render.MOV?dl=0

Vegas Pro Render (XAVC-S Profile with computer to studio levels)

https://www.dropbox.com/s/a7zcink7tftbvj5/Vegas%20Render.MP4?dl=0

Thanks for the help Marco; you should be able to see the difference here. Additionally I tried Magix; avc codec instead of XAVC-S; colors still shift. ๐Ÿ™ƒ

When the files are dropped into Vegas the preview also shows the color/contrast change. I noticed iMovie is using the BT709 color space and vegas is using YUV; perhaps thats why there is a slight shift in color?

LongIslander wrote on 5/15/2020, 2:44 AM

Figured it out, when I turned color space management off in faststone image viewer the photo now displayed exactly what was rendered in vegas. ๐Ÿ™. It seems iMovie is able to retain the photos "color space" profile when rendering a video, and vegas does not.

Marco. wrote on 5/15/2020, 4:17 AM

R.709 and R.2020 does not exclude YUV (or better said YCbCr), they go together and Vegas Pro applies for these standards and recommendations.

Marco. wrote on 5/15/2020, 5:34 AM

Is the photo you linked in your first post really the one we are talking about?

If I open this photo in FastStone Image Viewer and I toggle the CMS on and off the differences in black, white, gamma and color are so mininmal I could not see, only the histogram and vectorscop view let me see there's happening something. And if I compare that photo with having the CMS in FastStone Image Viewer turned on against the results of iMovie and Vegas Pro (with Levels attached) then still your Vegas Pro output is the one which looks much closer to the source photo as your iMovie output does (which is simply said "darker").

Are there other settings you used in FastStone Image Viewer which affects the photo?

This is your photo via FastStone with CMS turned on

And this is the verison with CMS turned off (and how Vegas Pro reads it)

Musicvid wrote on 5/15/2020, 9:04 AM

Absolutely, unequivocally, eternally, use an agnostic image viewer (Irfanview). This thread is a ridiculous testament to deferred disclosures. And horn-tooting. Thanks for willingness to test the improbable, @Marco.

Marco. wrote on 5/15/2020, 10:10 AM

One other thing that makes me curious - I tried many different tools now to find out which particular profile might be used for this photo, but I could not find any other information than "8 Bitย 4:2:0 YCbCr".

Switching to the camera profile (with no information what is is) in Vegas Image (or Imerge Pro), or turning CMS on in IrfanView or Affinity Photo outputs same result I had from FastStone - measurable but not visible and (almost) same as in Vegas Pro, but clearly different from the iMovie export.

LongIslander wrote on 5/15/2020, 12:12 PM

Is the photo you linked in your first post really the one we are talking about?

If I open this photo in FastStone Image Viewer and I toggle the CMS on and off the differences in black, white, gamma and color are so mininmal I could not see, only the histogram and vectorscop view let me see there's happening something. And if I compare that photo with having the CMS in FastStone Image Viewer turned on against the results of iMovie and Vegas Pro (with Levels attached) then still your Vegas Pro output is the one which looks much closer to the source photo as your iMovie output does (which is simply said "darker").

Are there other settings you used in FastStone Image Viewer which affects the photo?

This is your photo via FastStone with CMS turned on

And this is the verison with CMS turned off (and how Vegas Pro reads it)

Spot on; and yes the differences are minimal but I see them. You can really see the difference in the gold wheels. iMovie is rendering with the corect color space.
ย 

@Marco.ย if you go open the original jpg. in mediainfo and use a โ€œtext viewโ€ you will see the color space info that CMS uses. Faststone, irfanview, ios, andriod, will all display the color space and file correctly. Vegas does not read CMS of .jpgs. Resulting in the flatter colors.

ย 

Marco. wrote on 5/15/2020, 12:24 PM

MediaInfo says it is YUV (which actually is YCbCr).

Marco. wrote on 5/15/2020, 12:32 PM

And - yes, the color saturation is lower but this is a very slight difference compared to difference in black, white and gamma of the the iMovie version which really jumps into my eyes. To me, the iMovie version is still further away from the source as the VP version is.

Don't you see the iMovie version is darker?

LongIslander wrote on 5/15/2020, 12:34 PM

The difference is very minimal indeed. In fact the only way I can see it it going back and forth with the same photo in full screen; but; its there.

Microsoft edge, faststone, irfanview, google chrome, firefox, adobe photoshop, vlc player, windows movie maker, will all preview the original jpg. reading the ICC flag and displaying the correct color space.

Vegas does not read the icc profile flag of jpgs. which disregards the appropriate color space when previewing/and rendering. Photos that dont use these flags will preview/export perfectly in vegas with levels.

ย 

LongIslander wrote on 5/15/2020, 1:14 PM

I just converted the original jpg. to a .png in faststone which in turn removed the ICC flag and kept the appropriate color space. Vegas now properly read and rendered my PHOTO! ๐Ÿ˜ย  The Colors match identically.

@Marco.ย you are right about imovie; now when comparing the Vegas render against it. iMovie is way off; it did initially look better.

Here is the .png I saved my original .jpg from with faststone.

https://www.dropbox.com/s/yd0v5qa3ygo8d5l/IMG_4697.png?dl=0

And Here's The rendered product.

https://www.dropbox.com/s/pv37u8le5sf8ul6/Untitled.MP4?dl=0

Heres the rendered product before the jpg to png conversion (colors off because vegas cant read the ICC)

https://www.dropbox.com/s/a7zcink7tftbvj5/Vegas%20Render.MP4?dl=0

SOLVED! ย  Vegas team should really implement ICC flags!

@Musicvidย guess my eyes were my friend. So much for my "meaningless thread" ๐Ÿ˜

Additionally its worth noting CMS must be on (which is it by default) when converting the image format to png.

ย 

Marco. wrote on 5/15/2020, 1:45 PM

Yes, your last results equal my own results.

Kinvermark wrote on 5/15/2020, 1:59 PM

While we are on the topic...

Is there an NLE that uses ICC profiles? Maybe something like After Effects?

Seems to me that for better or worse, the ICC profile method of color management stems from the print design industry, whereas the video & television industry method is to standardize on an accurate device ( the "broadcast monitor") that content creators are supposed to use to validate their work. with the advent of color management systems like ACES, I don't see us going to ICC profiles. Comments?

Marco. wrote on 5/15/2020, 2:50 PM

I agree. ICC profiles are not for video editing purposes. Now that you mentioned this, I think the next base mistake here was to let the photo be viewed with an ICC profile in the picture viewer if in the end the photo is meant for the use in a video.

Musicvid wrote on 5/15/2020, 4:38 PM

Microsoft edge, faststone, irfanview, google chrome, firefox, adobe photoshop, vlc player, windows movie maker, will all preview the original jpg. reading the ICC flag and displaying the correct color space.

Vegas does not read the icc profile flag of jpgs. which disregards the appropriate color space when previewing/and rendering. Photos that dont use these flags will preview/export perfectly in vegas with levels.

Another headline-worthy claim being floated with not enough evidence.

And easily tested. ICC Profiles are for displays, scanners and printers, not for video, so the only question centers on how the still is decoded by whatever viewer or video buss.

  • The spoiler is that there is no ICC Profile associated with your downloaded JPG, other than the fallback RGB, (actually Display P3 in PS), and which coincidentally exists at the very foundation of Vegas!
  • If any part of the above claim were true, the screen images would be different between Photoshop, Vegas, and a control viewer. They are not, aside from slight indigent shadow noise.
  • Your experiments with applying random profiles in Fastone and viewing in iMovie are interesting, but not relevant enough to keep me from enjoying a little freedom today.
  • I run a lot of tests myself, and many of them are open for comment on the Off Topic forum, since they often stray from Vegas Pro peer support criteria, and in fact reflect personal interests and tools.
  • Your presence there with valid inquiries is invited; your eyes, your inferences, and especially your attributions will be fooled, time and time again. Reporting just the quantified data usually saves one from having to change his story later. But fifty years of imaging QA tells me you'll get there.

ย 

bvideo wrote on 5/17/2020, 6:24 PM

I am not intending to comment on the over all fixing of responsibility for expected vs resulting image differences in this thread. But ... I'm concerned about the implied conclusion that Vegas ignores (and should ignore) the color profile in a .jpg.

... ICC profiles are not for video editing purposes. ...

and

...

... ICC Profiles are for displays, scanners and printers, not for video, so the only question centers on how the still is decoded by whatever viewer or video buss.

...

I don't agree completely with the above. ICC profiles generally are not just for targets. ICC profiles need to be applied to sources when they are provided. When bringing a .jpg into a video, the color space in a .jpg source ought to be converted to the editing program's standard color space (in photo editing CMS called a "profile connection space") to make sense of it before sending it on to whatever process comes next. (By the way, we shouldn't confuse "color space", e.g. Display P3 or Adobe RGB, with "color model", e.g. YCbCr, or RGB e.g. using 3 numbers representing relative values within a color space). The "not for video editing" statement above is only true when considering video input or output, not stills as a source for video.

In handling ("decoding") .jpgs without processing the embedded ICC, there is no way for the videographer to reproduce the image's intended visual result just using the controls and plugins in Vegas. True, in many cases, depending on the subject matter and the embedded ICC, the videographer or viewing public might not notice color differences between .jpg sources and the Vegas preview or video displayed by a canonical player, but that doesn't always hold true.

In my opinion it is very unhelpful for Vegas to ignore the embedded ICC. The original photo linked in the OP has an embedded profile that instructs how to convert to e.g. CIEXYZ color space. When comparing the image as color- managed vs not, there are differences, admittedly small for this particular image. An image with a wider gamut ICC would not be handled well by Vegas.

I would agree that after the .jpg has been refactored into the video editing program's native color space, there is no further role for ICC.

Here is a test image that shows whether your viewer or other app is applying ICC:

http://www.color.org/images/browsertest.jpg

Try putting that on the Vegas timeline and also view it in your various viewers or browsers, with CMS enabled & w/o. This of course uses a "trick" ICC profile and is not representative of real photos. But a .jpg with AdobeRGB would certainly preview and render wrong from Vegas.

-- Bill