Image sequences washed out

macgregor

macgregor

Veteran
Yep. When I export image sequences (any format) the gamma is way way off. Anyone experiences this?

Also when importing Jpgs and switching to 32bit mode, mneeeek, opposite problem: the gamma is changed - too dark.
 
Yeah, it's a bit like the result of a non-existing "hard" color standard for video... The problem exists for many other formats too. Different editors, decoders, encoders, players, are all using their own internal gamma values, not caring about the rest...

For now, try some of the "Computer RGB to..." Color Corrector templates, and see if that helps at all.
 
Nahh, I´m not talking about limited vs full range. The gamma is boosted up like x4. Completely crazy. Specially when the "save snapshot" works really well.
 
i had a similar problem. i have a nvidia graphics card, and by default it controlled everything video related on my PC, so things would be jacked up in almost every app i worked with, but then i found the option in the nvidia control panel to let each media player/editor control colors/gamma. no probs after that. not sure what hardware you have macgregor.

btw...love your work.
 
I think he is suggesting video card settings. But it seems you are only having this issue w/ image sequences only.
 
Video cards settings affect GPU video playback acceleration and how colours are displayed. It has nothing to do with Vegas rendering.
 
Last edited:
Ok, i just did more tests. The problem comes with 32bit image processing and image files.

Let me explain with more detail:

This is how my preview window looks like:
Image1.jpg


And this is how a frame looks when rendering as frame sequence (jpg, bmp, dpx...) at 8bit image processing:
009.jpeg

It looks the same. Good.

But now when switching to 32bits processing the frames look like this:
:
00932.jpeg

the gamma is all wrong.
 
Now the opposite effect happens when loading still images:

This is a random jpg:
DSC_2753.jpg


This is how it looks in my preview window in Vegas:
Image2.jpg

Same, good!

But this is how it looks when switching to 32bits processing:
Image3.jpg

Levels are crushed.

So it seems like the opposite issue is happening.

Now, all this gamma issues happen only with still image files. Any video format is fine.
 
The problem is vegas' preview window which decodes to "computer RGB" (0-255). The only accurate way of getting precision is to use a calibrated external reference monitor.

The graphics card *does* make a difference with the preview window, because it uses GDI interface, so the graphics card desktop settings can alter the preview. However, internally for vegas, it runs independent of the GFX card settings

When you take a screenshot of you preview window, it's not necessarily reflective of what vegas "sees" internally

Use your car image as input, 32-bit linear gamma settings, and render out a .png sequence and you will see this is the case. Compare this to your screenshot of your vegas preview, you will see it is different

Vegas behaves very differently depending on the input format, export format, and whether you use 32-bit project or 8-bit project

Nice reading
http://www.glennchan.info/articles/vegas/v8color/vegas-9-levels.htm


Now, all this gamma issues happen only with still image files. Any video format is fine.
Click to expand...
on the contrary, video formats are far worse, because of the myriad of combinations of input formats. Image formats are consistenly decoded to computer RGB. When you use Y'CbCr video, there is an RGB conversion, and that adds extra rounding error. The matrix vegas convert to and whether it's 16-235 vs. 0-255 adds a lot of confusion for many people. The export format matter as well, because there is another conversion; RGB=>Y'CbCr if you are using video (unless you use an RGB format). The only way of consistently allowing "passthrough" of levels is to use uncompressed Y'CbCr

Summary: there is a disconnect between what you see in the preview window, and what vegas "sees" internally
 
1. thanks for trying to help
2. you´re mixing concepts and I think you´re just copypasting. this is not a limited vs full range problem. I might sound like a douchebag but I´m pretty much an expert in video formats and how Vegas handles video levels. This is a gamma issue, not an input or remmaping values issue. It seems to me that Vegas is tagging image files as 32bit linear 1.0 even at 2.2 gamma spaces.
 
macgregor said:
2. you´re mixing concepts and I think you´re just copypasting. this is not a limited vs full range problem. I might sound like a douchebag but I´m pretty much an expert in video formats and how Vegas handles video levels. This is a gamma issue, not an input or remmaping values issue. It seems to me that Vegas is tagging image files as 32bit linear 1.0 even at 2.2 gamma spaces.
Click to expand...



For the video case, The Y'CbCr is a combination of full range and limited range problem, as well as how vegas treats the video. You are not in Y'CbCr colorspace internally anymore when the video is imported, it's in RGB (actually RGBA) colorspace

For the image case, the import as image sequence, and export as image sequence is as described above, computer rgb (there is no Y'CbCr because the image format is already RGB, and treated as such

For the image case, did you even try the little exercise above? The car is identical when rendered out.

If you don't understand, I can try to explain farther... Basically your mistake is assuming the video preview window is what you were going to actually get.
 
I never talked about YUV here. I´m not using YUV so why do you talk about YUV?
THe preview window is EXACTLY what you get if you are aware of limited range vs full tange video codecs. And that´s the beauty of Vegas.
 
If I've confused you , I'm sorry

Your post was unclear to me. I misread it as you imported video first, then exported images, and in the 2nd case imported stills, then exported stills.


When I export image sequences (any format) the gamma is way way off. Anyone experiences this?

Also when importing Jpgs and switching to 32bit mode, mneeeek, opposite problem: the gamma is changed - too dark.
Click to expand...


So forget I even brought up video.

Let's start over: if you import a still .bmp, 32-bit linear settings, export a .png, you will see levels and gamma the same. I don't see a problem here.
 
PDR said:
Regardless, if you import a still .bmp, 32-bit linear settings, export a .png, you will see levels the same. I don't see a problem here.
Click to expand...

Ummmm, no I don´t. That´s the problem I´ve been trying to explain here all this time.

;D
 
I´ll try to explain again:

INPUT: qt aja rgb10bits VEGAS: 32bit mode EXPORT: qt aja10bits RESULT: same

INPUT: uncompressed avi VEGAS: 32bit mode EXPORT: uncompressed avi RESULT: same

INPUT: bmp (or any image format) VEGAS: 32bit mode EXPORT: qt aja10bits RESULT: gamma shift (darken gamma, and this is not a studio-computer RGB conversion)

INPUT: bmp (or any other image format) VEGAS: 32bit mode EXPORT: bmp (or any other image format) RESULT: gamma shift (darken gamma, and this is not a studio-computer RGB conversion)

INPUT: qt aja rgb10bits VEGAS: 32bit mode EXPORT: bmp (or any other image format) RESULT: gamma shift (lighter gamma, and this is not a studio-computer RGB conversion)


Basically, when importing image files, their gamm is darkened, no matter the output. When outputting image files from video source files, no matter if they´re RGB or YUV, the gamma is raised. All this only happens at 32bits (1.0 and 2.2 gamma). At 8bit, everything works as expected.
 
EDIT: didnt' see your latest post. Thanks for clarifying

INPUT: bmp (or any other image format) VEGAS: 32bit mode EXPORT: bmp (or any other image format) RESULT: gamma shift (darken gamma, and this is not a studio-computer RGB conversion)
Click to expand...

This is very curious. I just repeated this several times on your .bmp images above, 32-bit linear gamma, exported .png, no shift....

What version of vegas are you using? OS ?
 
You must log in or register to reply here.
Back
Top