...perfectly matching the PNG original colours.

That's all you need to say. The solution for most still images is to apply the Computer->Studio RGB Levels preset to the still events. Note that the preview will not match the output in this circumstance.

Explanation: Vegas, even in an 8 bit Full Range Project, does not read still images in sRGB color space; instead, it imports them as Unmanaged. Therefore, the automatic levels correction for output does not happen.

This doesn't apply only to sRGB stills. Vegas doesn't honor AdobeRGB, ProPhoto, or ColorMatch images, either; the developers are aware of this.

Explanation: Vegas, even in an 8 bit Full Range Project, does not read still images in sRGB color space; instead, it imports them as Unmanaged. Therefore, the automatic levels correction for output does not happen.

Hold on, I thought version Vegas 18 and later fixed this issue, and now uses the full 0-255 colour range instead of just 16 - 235? Or was it not a full implementation?

Anyway, I tried what you suggested, and the image is now too muted/grey, and some parts are still too bright. Compare:

ORIGINAL:

MAINCONCEPT AVC CODEC (with added "Levels->Computer RGB to Studio RGB" event FX), and then shown in Media Player or Chrome etc.:

Bear in mind, I have Vegas 20, and that when I saved out via the Intel QSV codec (instead of MainConcept), it worked perfectly.

Very interested to see how you'll respond...

Could you make an image available for download (not through the forum, want an original PNG). Do you know what color space the original image is? How was it generated?

Happy to test it here.

@RogerS - now you're asking. It's been through at least a few transitions. Being rendered on the Amiga 1200 ages ago via the Imagine 3D software, then I'm guessing went through Irfanview to convert to PNG, and then finally went through the C++ FreeImage library to convert the frames to stereoscopic vision using my own program. Or did you just want the latest transition? No idea of the colour space, apart from I assume it's 24 bit RGB colour.

I can give you the original source file, but bear in mind, the problem happens with JPG and BMP too, so the above should be sufficient. However, just for you: https://i.imgur.com/3NWNckX.png

Wow, Amiga 1200, that is a blast from the past. It did have that kind of Amiga demo scene retrofuturistic feel : )

This is from days before color management. Even if it had an assigned ICC profile, Vegas has no idea what the gamut is of these images. As a first step I assigned it widegamut RGB in Photoshop. Then converted to sRGB.
I don't know if that is a reasonable match for the source file so if not assign an appropriate gamut and then convert to sRGB for Vegas. It's really vivid.

Here are screenshots comparing a straight render from Voukoder (x.264) to MagixAVC with Mainconcept to MagixAVC with QSV. It's done in VP 19.550 as I've had stability issues with more recent versions and don't have time to troubleshoot crashes now.

In Photoshop I used the color sampler droppers to see if the colors at a given point in the image are the same and they appear to be between x.264 and Mainconcept and NVENC. I also don't see a difference toggling between the full screen in Vegas and a maximized video player with x.264.

But don't take my word for it take a look at the screenshots.

https://www.dropbox.com/s/f2uknzsbbph32vx/Screenshot%202022-08-31%20202229.png?dl=0

https://www.dropbox.com/s/x19cmo2uoloqw0z/Screenshot%202022-08-31%20202323.png?dl=0

These were done in 8-bit full at best render quality with other settings as defaults. Adjust source media is unchecked. Media settings are relevant for 32-bit full mode.

Very interested to see how you'll respond...

Thank you! Something may have changed silently in VP20, and it bears retesting.

[Edit /]Yes, it appears to have been fixed in VP20, at least with 8-bit RGB stills and the Magix AVC encoder. I have marked a previous bug report as Resolved.[/]

Wow, Amiga 1200, that is a blast from the past. It did have that kind of Amiga demo scene retrofuturistic feel : )

Haha, you ought to see the whole video. 60fps tube run through sorta animation.

This is from days before color management. Even if it had an assigned ICC profile, Vegas has no idea what the gamut is of these images.

But if that's true, then why does it display perfectly in the preview window? All of this is so, so confusing. Is there some way I can view what colour profile a picture or file is supposed to have?

But don't take my word for it take a look at the screenshots.

They both look overly saturated though compared to my original version. By the way, I've tried the Voukoder codec myself a few days ago, and the colours on that turned out even worse (darker overall) than the MainConcept render:

Original: https://i.imgur.com/ypvoLUE.png

Voukoder: https://i.imgur.com/U01ytw5.png

Magix; Mainconcept AVC: https://i.imgur.com/MWM5Zqr.png

@Musicvid said:

Yes, it appears to have been fixed in VP20, at least with 8-bit RGB stills and the Magix AVC encoder. I have marked a previous bug report as Resolved

Do you mean in the version 20 Build 139 I have? As you know, it's broken for me. Has it since been fixed, or do you mean there was never a bug in the first place, and it's just a problem with the PNG I'm using? I've been trying the same test on other images now and am getting mixed and inconsistent results. At one point I saved a Bing backdrop photo, and the colours rendered from Vegas fine, then converted it to PNG via Irfanview, and it wasn't fine, but I can't seem to reproduce this problem, and now even the converted PNG from Irfanview seems to produce a correct-colour render from Vegas.

Really feels like I'm working blind. And in a dream where the map changes without me knowing :) I'm more confused than when I started...

But if that's true, then why does it display perfectly in the preview window?

Well, I don't know what it looked like on the Amiga. If you are happy with the preview window than no profiles are needed. I had imagined the original was more saturated as a synthetic image from the '90s.

What settings are you using in Voukoder? It is outputting video levels, right? Color space is on defaults?

I included a few color samplers (see the right info tab).

Here's a Voukoder vs original comparison:

Here's Voukoder vs your original image as posted to imgur (color managed Firefox browser)

When comparing photos in a color managed app (Photos) and a video player (MPC Classic Black Edition) there will be some minor differences. Not sure why our Voukoder renders look different:

How did you make these screenshots? By saving frames from Vegas or with Windows? Were they all made on the same display? If you take screenshots on different displays that can result in different colors.

My renders were were with 19 as it's the version I'm using at the moment. If there is an issue with 20.139 do you have 19 to test with?

Well, I don't know what it looked like on the Amiga. 

Ah, when I said "display perfectly in the [Vegas] preview window", I meant it displayed identically colour-wise as when Chrome, Firefox, or Irfanview displays it. So I'm using those three as my benchmark here.

I'll get to Voukoder in my next post...

@RogerS

As a reality check, I tried rendering the Voukoder project again, and it's still as dark as ever. Here are all the screenshots (5) I can think of to show the settings I use in the Voukoder-based project:

https://imgur.com/a/ZTtqDQn

I also tried the default .MOV instead of .MP4 in the Voukoder "Output" tab, and it made the colours slightly closer to the original, but not perfect.

Honestly, I'd love to use Voukoder instead of AVC-MainConcept, because Voukoder allows full 4:4:4 rather than AVC-MainConcept's forced (and awful) 4:2:0 chroma subsampling, which completely ruins the stereoscopic effect. I also have a feeling the overall quality's better with Voukoder too.

The only reason why I focused on AVC-MainConcept originally is because that's a default that Vegas comes with, and people are more likely to know more about that. Also it may be I have to fix the colour problems with that before moving on to fixing the colour problems with Voukoder.

How did you make these screenshots? By saving frames from Vegas or with Windows? Were they all made on the same display? 

Same display. After rendering the video from Vegas, I loaded them into Classic Media Player and saved out using the "Save image" menu option from that. I made sure they matched the mp4 file from playing within Classic Media Player.

Let me know if you need any more info.

Thanks for the details.

How you are making the screenshots seems fine.

For project settings, in full resolution rendering quality I'd try "best" and uncheck adjust source media.

I don't think you get benefits from 10-bit output if Vegas itself is using an 8-bit timeline and the source media is also 8-bit anyway.
I have not tested 10-bit x.264 or 444 with Voukoder as I don't use AVC for intermediate type files. Does the 8bit 4:2:0 preset in Voukoder also have a difference in gamma? I'd try the first preset (or no preset) to start with as it should still be better quality than MagixAVC with Mainconcept. Stay in mp4 for now (there's no alpha, right?)

I'm curious to see your finished video, too.

For project settings, in full resolution rendering quality I'd try "best" and uncheck adjust source media.

Okay, tried that. No luck unfortunately.

I don't think you get benefits from 10-bit output if Vegas itself is using an 8-bit timeline and the source media is also 8-bit anyway.

You'd be surprised. I tried both, and the 10 bit version has noticeably better quality. This MIGHT have something to do with the conversion from RGB to YUV back to RGB and thus throwing a lot of colour information away (about 75%) due to the way YUV is wasteful when using its 24 bits. Interesting thread here about that.

Here's a comparison of 8 vs 10 bit: https://imgur.com/a/G8a0Dqi

Does the 8bit 4:2:0 preset in Voukoder also have a difference in gamma?

Unfortunately, I can't get any of the 4:2:0 versions to work, not even the lossless version or when I try using .MOV or .AVI outputs. It renders and gets to 100%, but doesn't save out the file.

I'd try the first preset

As above, won't render. ( "4:2:0 General purpose, 8 bit projects" ).

 (there's no alpha, right?)

Not sure. Where would I find that?

Here is a testchart you can use, specifically to illuminate the chroma subsampling differences in the conversion from your 4:4:4 RGB image to 4:2:0 Y'(cBcR) delivery using your Magix and Voukoder AVC codecs. Also try Animation Tune in Voukoder x264.

RGB output would be a lot better, of course, but it's not really deliverable these days, making it more of a toy for hobbyists.

10-bit chroma smoothing from processing an 8 bit original is an urban superstition, arising from the introduction of frequency domain noise into the unpopulated lower two bits, and which is not clipped out during dithering from float to to 8 bit integer output. Nod your head, and tuck the thought away for another time.

https://www.belle-nuit.com/test-chart

@Musicvid - Thanks for that test chart. I'm getting a bit closer now, at least for the MainConcept codec. Turns out that colour space is probably not the issue for this one after all! First off, here's the render of the test chart: https://i.imgur.com/kLAUevu.png

Perfect (apart from the 4:2:0 thing of course creating darker reds in the middle, but that's taken for granted).

To try and get MainConcept to work, I had the bright idea of rendering my problematic 3D tube image at a high resolution instead of its default 350x283 res, and it worked - the colours matched to the original! 700x566 (double the original) didn't work, but 1400x1132 (quadruple size) worked fine. I'm now pretty certain, this is a full-on bug with Vegas or the codec, since changing resolution in the codec settings should make no difference to the colours.

Unfortunately, Voukoder is still as bad as before, both with my higher resolution 3D tube image, and also with the test chart. Here's the test chart for that (4:4:4, lossless, 10 bit, mpg): https://i.imgur.com/RPJ33au.png

As you can see, the whites and blacks are flooded out, just as I experienced before with my 3D tube image. Other variations (such as 420, 8 bit and .mov instead of .mpg) had the same problem.

Musicvid and @RogerS - Do you know of a fix for either of the two codecs? It would be so nice to obtain a single working Vegas-compatible H264 codec to do everything consistently.

10-bit chroma smoothing from processing an 8 bit original is an urban superstition, arising from the introduction of frequency domain noise into the unpopulated lower two bits, and which is not clipped out during dithering from float to to 8 bit integer output. Nod your head, and tuck the thought away for another time.

Oh are you saying I was mistaken with what I said about the conversion from RGB to YUV back to RGB losing colour information? If so, I'm glad I emphasized the word "might" in my comment.

Oh are you saying I was mistaken with what I said about the conversion from RGB to YUV back to RGB losing colour information?

No. I was referring to processing 8 bit depth in a 32 bit float pipeline, you are talking about color spaces. They are separate, unrelated functions of video editing.

...tuck the thought away for another time.

For project settings, in full resolution rendering quality I'd try "best" and uncheck adjust source media.

Okay, tried that. No luck unfortunately.

I don't think you get benefits from 10-bit output if Vegas itself is using an 8-bit timeline and the source media is also 8-bit anyway.

You'd be surprised. I tried both, and the 10 bit version has noticeably better quality. This MIGHT have something to do with the conversion from RGB to YUV back to RGB and thus throwing a lot of colour information away (about 75%) due to the way YUV is wasteful when using its 24 bits. Interesting thread here about that.

Here's a comparison of 8 vs 10 bit: https://imgur.com/a/G8a0Dqi

Does the 8bit 4:2:0 preset in Voukoder also have a difference in gamma?

Unfortunately, I can't get any of the 4:2:0 versions to work, not even the lossless version or when I try using .MOV or .AVI outputs. It renders and gets to 100%, but doesn't save out the file.

I'd try the first preset

As above, won't render. ( "4:2:0 General purpose, 8 bit projects" ).

 (there's no alpha, right?)

Not sure. Where would I find that?

 

Alpha just means transparency in the original. There probably isn't.

For Voukoder that it doesn't render at all with 8 bit is surprising. Can you uninstall and reinstall the latest connector and also the program (11.3.1)? It really should work!

Alpha just means transparency in the original. There probably isn't.

Ah, you mean in the picture itself. Thought you meant an option within Vegas. Anyway, yeah I don't think I even recall alpha transparency in the Amiga days (other than maybe the very expensive video toaster / OpalVision / TVPaint?). And yeah, no alpha transparency on mine as you guessed.

For Voukoder that it doesn't render at all with 8 bit is surprising. Can you uninstall and reinstall the latest connector and also the program (11.3.1)? It really should work!

I think you would have found it broken too using my tube image, but the good news is I just figured it out! I need to use 350 x 284 resolution instead of x283. I don't think the Voukoder codec likes odd numbers when using 4:2:0.

Anyway, to answer your earlier question from some posts ago, I've just tried 8 bit 4:2:0, and the colours are still wrong with Voukoder sadly :( And to reiterate again, even if use a 1920x1080 image (either via the project settings, or by scaling up my 3D tube image), the colour mismatching problem still occurs.

EDIT: The Vouker codec even renders the 1920x1200 Bing backdrop jpeg I downloaded incorrectly. I don't think any picture works with it. Perhaps this is due to what Musicvid was saying about Vegas not using sRGB color space and instead importing it in as Unmanaged. Does this limitation apply to Voukoder too, or just Vegas default MainConcept codec? And if the former, then why does it render correctly for RogerS?

I gotta say I am a bit baffled by this. Perhaps it's a VP 19 vs 20 issue. I'll test 20 after the next update comes out. Perhaps something with Voukoder on this system; you could post that to the Voukoder forum. Feel free to include my screenshots too.

I don't think it's as crude as a video vs computer levels issue as that's pretty obvious.

Vegas ignores all color spaces in 8 bit full mode (and 32 bit full is just color managed for video color spaces) and that is okay as it's untagged/unmanaged anyway and you're okay with it being viewed as sRGB in Photoshop or REC 709 here.

Most encoders require even numbers so definitely feed them that.

1, I'm shocked why people are so busy with an ancient image even older than the VCD Era!
  OK, it's not my problem if people interesting at images in 2 pixels depth.

2, Please! No investigation, NO statement.

VEGAS at least from Version 18 identifies 2 major spaces: HLG and HDR10.
VEGAS knows exactly the luma of HLG and adjusts this kind source material automatically into the editing space you are using:

8bitlegacy, 8bitfullRange, HDR10

VEGAS also knows the luma of HDR10 and adjusts possibly the source into 1000 nits or 2000 nits level according to its metadata infos. You can edit it directly in HDR10 space or you need a LUT filter in 8bit space.

Being rendered on the Amiga 1200 ages ago via the Imagine 3D software, then I'm guessing went through Irfanview to convert to PNG, and then finally went through the C++ FreeImage library to convert the frames to stereoscopic vision using my own program. Or did you just want the latest transition? No idea of the colour space, apart from I assume it's 24 bit RGB colour.

Probably not. Maybe 18 bit AGA with 256 indexed colors.

After doing my own test renders with various encoders, I recalled that Amiga had a different interleaved color byte order and gamma than IBM or MAC.

https://en.wikipedia.org/wiki/Amiga_Advanced_Graphics_Architecture

The original metadata has long since disappeared, and was overwritten with each subsequent generation of conversion. The PNG you gave us is generic, and gives no clue about its beginnings.

Frankenfiles such as yours come in two flavors: those that can be reverse-engineered back to their original state, and those that can't. Your example is not unusual by any means; Youtube is full of this stuff. Unfortunately, I'm working on a family project and won't have time to help you sort it. Early fails are one of our best teachers. Here's my take on the Frankenfile monster.

Here's more background reading for you:

https://www.xtof.info/loading-a-modern-image-on-an-amiga500.html

Planar Modes

The Amiga does not represent images in memory as modern machines do. They use a chunky representation, meaning that one or many bytes are dedicated to describe one single pixel.

For instance:

24-bit images: [R][G][B] [R][G][B] [R][G][B] …

32-bit images (+ alpha channel): [R][G][B][A] [R][G][B][A] …

256-color indexed: [index] [index] [index] [index]

But Amiga can only display 32 colors, indexed from a palette of 4096. Using one full byte of memory to encode one of 32 indexes would be a waste of memory. So instead of a chunky representation, the Amiga uses a planar representation.

@Yelandkeil -

1, I'm shocked why people are so busy with an ancient image even older than the VCD Era!

The image was last modified via a relatively modern C graphics library, so it's irrelevant where/when it was first created, since I'm not trying to replicate the colours from how it appeared on the Amiga, just to match how it appears in Chrome/Irfanview today.

Besides that, the colour matching bug happens with the test chart image (that Musicvid provided), when I reduced the resolution down to 350x284 (though not with the original 1920x1080 size), so that's a bug with Vegas. For me, the colour matching bug ALSO happens with the Vokouder codec at any size sadly. When you have something so fundamentally wrong, its is absolutely worth mentioning and indeed... investigating.

But don't take my word for it: Try the image yourself, first downsizing it to 350x284, and render, and I'm sure you too will witness how the shades/hues don't match how the picture originally appeared in Chrome/Firefox/Irfanview.

Something which is even older than the VCD era is 4:2:0 chroma subsampling. I'm amazed that hack of a compression that too often ruins text and sharp detail is not just kicking around today, but is actually enforced by the MainConcept/H264 and Intel QSV codec within Vegas. I can't wait until the day that 4:4:4 is standard for everything. It'll make life a lot simpler, and improve video for everyone, creators and consumers alike.

@Musicvid

Unfortunately, I'm working on a family project and won't have time to help you sort it. 

No worries, and I appreciate your insights thus far.

Probably not. Maybe 18 bit AGA with 256 indexed colors.

I meant the format it's in now. Older formats are irrelevant as (and I can't stress this enough), I'm only trying to match the Vegas output to how the PNG appears in Chrome/Firefox/Irfanview, *not* to how it appeared on the Amiga. As I said to Yelandkeil, even when I render your test chart image from Vegas, it also fails to match the colours if I downsize it to 350x284 first (it's okay if I keep it at 1920x1080). And it fails the colour match for me using Voukoder at ANY SIZE.

When you said earlier "does not read still images in sRGB color space; instead, it imports them as Unmanaged", why does the image render out from Vegas/MainConcept okay if I render at higher resolutions such as 1400x1136 or 1920x1080? It only breaks at 350x284 and similar resolutions, so this has to be a Vegas/codec bug, and not really to do with unmanaged colour for importing images.