Weird behaviour in 32bit mode with image sequences

LoTN wrote on 9/25/2010, 11:30 PM
I would like to know if someone is able to reproduce the issue I face. Import an image sequence in a 32bit project (either 1.0 or 2.22 gamma). I can see a big gamma difference with the image sequence. Individual images are not affected. This is with 9c x32 and 9e x64, 8c is ok.

Upper track contains individual images, lower track the same images as a sequence. I used pan/crop to show the differences in the preview (sequence is on the right). Test is done with jpeg and png. Same outcome.

8 bit mode


32 bit mode

Comments

Steve Mann wrote on 9/26/2010, 10:32 AM
Speaking from inexperience here, but I would look at the histograms instead of the waveform. My guess would be that the dynamic range of 32-bit images are "offset" toward black.
LoTN wrote on 9/26/2010, 11:26 AM
Hello Steve,

I used the histogram too and it confirmed the shift which is also visible with the waveform.

I already used 32 bit mode with 2.2 gamma for CG with regular footage and stills without any probelm. It's the first time I want to do it with a timelapse imported as an image sequence.

What is odd for me is that I do not have this with 8c and with 9c or 9e it happens with image sequences only.

Of course I can drop all stills on the TL in order to circumvent that issue but if it is a Vegas bug I think it may be useful to users to know about it.

Thanks
Steve Mann wrote on 9/26/2010, 2:07 PM
It's been a long time since I worked with image sequences, but... before we call it a bug,

Could it be a difference in colorspace? Is this new images or have you tried an image sequence from an earlier TL sequence?

Steve
musicvid10 wrote on 9/26/2010, 2:28 PM

Many PNG images contain header information that confuses other applications into doing an unwanted cRGB conversion.

I use "tweakpng" to strip the header information and return the files to normal.
LoTN wrote on 9/26/2010, 10:41 PM
The timelapse (fresh and unmodified) stills are coming from an HVR-A1, format is JPEG. During the tests, I converted them to PNG using GIMP without any transformation. I may be wrong but if the PNG header was the issue then I would get the same result with individual stills of the set and no problem with JPEGs, this is not the case. It also turns that this only occurs with the set imported as an image sequence on VP9. Using JPEG or PNG, what I get is:

VP8c

- 8 bit project:
* stills directly put on the TL: OK
* stills imported as an image sequence: OK

- 32 bit project
* stills directly put on the TL: OK
* stills imported as an image sequence: OK


VP9c x32 and VP9e x64

- 8 bit project:
* stills directly put on the TL: OK
* stills imported as an image sequence: OK

- 32 bit project
* stills directly put on the TL: OK
* stills imported as an image sequence: not OK

I can use a curve to get something very close to the original but I prefer to keep room and limit alteration above all.



I can't tell actually if it is a bug or a 'feature' with images sequences in VP9. This is why I asked if someone could waste a couple of minutes to check if this is reproductible.

Thanks.
FrigidNDEditing wrote on 9/27/2010, 1:56 AM
I just experienced this separately myself, so I'm glad I'm not the only one.

Dave
musicvid10 wrote on 9/27/2010, 9:22 AM
Is the render dark as well?
Does a Computer->Studio RGB correction fix it?

This may help point Sony to the cause.

Here's an in-depth article about 32-bit in V9 that may also shed some light on your observation:
http://www.glennchan.info/articles/vegas/v8color/vegas-9-levels.htm

Upload one of your fresh JPGs and its corresponding PNG from Gimp. I can peek at the headers and possibly see if that is contributing to what you are seeing.

LoTN wrote on 9/27/2010, 10:13 AM
The render is similar to what I get in preview. (Lagarith in RGB32 mode)

As one would expect, converting levels from computer to studio behaves as usual but does not fix the issue.

I already have read the great explanations from Glenn Chan some time ago but it will be a good idea to glance at them again.

Here are the files corresponding to frame 8 (all frames within a sequence have the same issue).

JPEG
PNG

Your help is very much appreciated but don't waste so much time on this. While testing, the more I think about it, the more I believe there's a bug with image sequences and 32 bit mode in VP9.
TheHappyFriar wrote on 9/27/2010, 10:15 AM
This may be nothing or related, but I was helping my dad with an image sequence because it was easier to do via image sequence vs a series of stills. I pan/cropped in & adjusted each frame on a 5 second image sequence to zoom on on some whales coming out of the water. Every time I would render it would render completely opposite vs what the preview said: the image would jump around, nothing was stable, etc. The preview showed everything perfect. If we did the exact same thing as a series of stills vs image sequence it would work fine.

That was in Vegas 6 so I assumed it's an old bug & didn't bother reporting it. Maybe for some reason the program is doing something to stills it doesn't normally do to video clips (which is what an image sequence is, kinda), or vice versa.
musicvid10 wrote on 9/27/2010, 10:21 AM
It's not your PNG header. Took me no time at all to determine.

HOWEVER, your JPG reports 8-bit, and your PNG was saved in 24-bit. Is there any difference if you save your sequence in 8-bit PNG (which will still be lossless)?

Even though I don't have V9 or use 32 bit projects, it will be interesting to hear your outcome. Keep us posted.
LoTN wrote on 9/27/2010, 11:15 AM
Actually my tests were done with an image sequence made with the original JPEGs from the HVR-A1 and the PNGs. Same result.

What puzzles me is that you see the JPEGs are 8 bit. On my side, a double check with GIMP, Vegas and Win7 explorer gives a 24 bit color depth.

Anyway, I did a colorspace conversion to 8 bit, got a very perceptible loss of quality but here we don't care. I've put the 8bit PNGs on the TL as individual stills and as an image sequence. I get exactly the same problem.

So:
- the image format is not the problem
- the bit depth is not the problem
- full range with gamma set to 1.0 doesn't change anything
- VP8c is okay
- it occurs only with VP9 in 32 bit mode using image sequences.

Support ticket filled.
musicvid10 wrote on 9/27/2010, 11:19 AM
I got this with MediaInfo from your JPG:

General

MediaInfo has sometimes misreported stills information for me, I might add.
Sounds like you are on your way to pinpointing the cause. Keep us posted.
LoTN wrote on 10/1/2010, 8:57 AM
Just got an answer from SCS support:

"This issue has already been logged by our development team, and they will be "

My actual workaround: use V8c when having to deal with images sequences in 32 bit mode. I don't know if it's ok with 9.0, 9a or 9b.
robwood wrote on 10/29/2010, 11:37 AM
great to hear u got a response, hopefully 10b will have the fix implemented.

i've been able to reproduce the problem with TIFF and PNG sequences. interestingly, all TGA sequences i've used do NOT have this occur.

and single frame TIFF/PNG/TGA all handle correctly whether they are 8/16/32bit. go figure.

~

meaningless speculation on my part figures this is because TGA is fixed 8bit while TIFF/PNG allow for higher bit-depths which require different (in this case incorrect) handling of RGB values.
LoTN wrote on 10/29/2010, 10:42 PM
I immediately checked with 10a when it became available and made SCS aware it's not fixed. I've been told it's logged and they working on this. Hopeful for fixed 10b too.
stephenv2 wrote on 11/8/2010, 5:50 PM
I just ran into this same problem trying to render out image sequences of a 32-bit project that does not use image sequences. I did some testing with the files in After Effects and I can confirm that Vegas writes the files out as linear gamma despite projects set to 2.2.