Linear Light, what a difference that can make.

farss wrote on 3/30/2015, 3:11 PM

I've never paid much attention to using Vegas's Linear Light option, after all apart from some esoteric differences when compositing which I rarely do in Vegas anyway it's just seems more grief than it's worth as one is forced to also use 32bit float. Then I watched the following video:

]

That's interesting, very interesting because in the example at the end it's not compositing, it's something as simple as a Blur that our software gets WRONG :(

I decided to try this in Vegas and the result was astounding, yes Vegas, Photoshop and After Effects by default cannot even do a simple Blur correctly My test was dead simple, try it for yourself.
Add the Checkerboard generated media to any timeline. Change the two colours from black and white to red and green. Now add a tiny amount of Gaussian Blur. The result is indeed just an ugly brown border between the red and green squares.
Now change your project properties Pixel Format to either of the floating point modes and select Compositing Gamma of 1.000 and hit Apply. Instantly the brown fugley borders become optically correct yellow and the blur looks real, I mean like what you'd see from something that was out of focus. I'm now wondering how much of the grief I've had with compositing things such as flames over the years can be attributed to the same thing.

Bob.

Comments

PeterDuke wrote on 3/30/2015, 6:32 PM

When doing any brightness or colour processing, the native camera law, whatever you call it (quasi linear to log with soft saturation and a pinch of gamma) should be converted to linear first, and then back to the non-linear after the processing. I am sure that many image editing programs, such as Photo-Paint, which I still use, take short cuts when processing, some if not all of the time.

I had noticed that if a photo was under exposed, just increasing the brightness within the program did not render the shadows the same as that in a photo that had been exposed correctly.

I took a series of photos of a plain white-ish object (my lounge room wall) at a series of exposures at 1/3 stop intervals and determined the coding law for my camera. (It was as I described above!) I then calculated what the tone curve should be to adjust brightness by 1 stop, 2 stop, etc. and used that to adjust my under exposed photo. Much better!

PS

These days I mainly shoot photos in raw mode and adjust using Adobe's camera raw preprocessor to Photoshop. It seems to do it correctly.

farss wrote on 3/30/2015, 10:59 PM

You're right, probably nothing works correctly if we don't switch to linear light however I was quite shocked to discover just how badly simple FXs such as Gaussian Blur performed so badly . I always use curves to adjust exposure that's probably why I haven't noticed an issue there.

Bob.

rmack350 wrote on 3/31/2015, 12:01 PM

Thanks for posting this, Bob. I just tried it out in Photoshop with 8-bit and 32-bit examples and 32-bit gives the result one would want. Also, the color dialogues in 32-bit mode are interesting and give a perspective on Vegas's use of 32-bit values in it's dialogues, although why Vegas does it while in 8-bit mode is a mystery to me.

Rob

farss wrote on 3/31/2015, 3:49 PM

[I]"why Vegas does it while in 8-bit mode is a mystery to me"[/I]

As the Minute Physics video explains because the average of two square rooted values is less than the square root of their average. To be mathematically correct the two values should be squared and then the average taken and then the square root of that number taken but pretty well no image processing software does this and the results are wrong.

In the case of red and green the average should be yellow but we get ugly brown, it looks wrong, it is wrong :(

Here's two examples:

Linear Light

The above looks correct, what would happen if a photo was take out of focus, done using linear light in Vegas.

Log Light

The above is exactly the same except this is using Vegas's default log light. The result is the ugly brown borders.

Bob.

rmack350 wrote on 3/31/2015, 4:22 PM

Right. Good examples.

I was being sloppy in my post. What I meant to say is that when Photoshop is in 32bit mode (which appears to be 32bit float) they describe color values as a range of zero to one. Photoshop switches back to 0-255 in 8bit mode.

Vegas uses a range of 0.0-1.0, even in 8bit color mode. That's what mystifies me. It doesn't seem appropriate, and obviously other programs can change their value scale when they change their bit mode. I'd like to see Vegas show the appropriate values and then also show a translation just to help people visualize the two sets of values.

Rob

Dawdle wrote on 3/31/2015, 4:52 PM

Effectively what's going on is that Vegas and other software is treating the 8 bit values as linear and gamma is being ignored. For us programmers, taking gamma into account has its problems and so it is typically not dealt with and we have been getting away with not dealing with for ages.

One problem is simply that gamma conversion takes time to perform and so any image processing would be significantly slower. This would be a big hit for video processing.

Working with 8 bits is also a problem. The precision is lousy and the extra work required to deal with gamma could introduce rounding errors which would look bad. Banding is a typical problem you get as a result of lack of precision.

It would be very helpful if the gamma curve was done away with. If cameras produced linear output and monitors displayed a linear output then images and video would be correct.

What's required is to make more people more aware of the issue and kick up a fuss to get the hardware and software manufacturers to address the problems.

PeterDuke wrote on 3/31/2015, 6:56 PM

"It would be very helpful if the gamma curve was done away with. If cameras produced linear output and monitors displayed a linear output then images and video would be correct."

Perhaps the time has come to increase 8 bit values with 12 or 16 bits. 8 bits is so firmly entrenched, unfortunately. It is not practical to revert to linear unless the bit depth is increased. In the audio world, telephone transmission uses 8 bits quasi log (A-law or mu-law) while CDs use 16 bit linear.

We may talk about gamma, but the three still cameras that I have looked at do not have a clear gamma curve. I would best describe it to be linear below 35 and log above 35 with a transition smoothing in the vicinity of 35. There may be a kink or two as well plus soft limiting near 255.

farss wrote on 3/31/2015, 7:45 PM

[I]"It would be very helpful if the gamma curve was done away with. If cameras produced linear output and monitors displayed a linear output then images and video would be correct."[/I]

That would still be expensive. There are video cameras that record RAW (sort of, they do use some compression) but the total cost of ownership is still high.

[I]" What's required is to make more people more aware of the issue and kick up a fuss to get the hardware and software manufacturers to address the problems."[/I]

I don't see why the issue cannot be fairly easily and cheaply addressed in software. CPUs are fast and the busses wide enough for us to be able to do the required calculation using more than 8 bits per channel. Converting the 8bpc to 32bit integer linear light values and having all FXs work on that shouldn't cause a huge slowdown in speed I would have thought. The final values can be converted back to 8 or 10 bpc video for the existing encoders.

Bob.

PeterDuke wrote on 3/31/2015, 9:17 PM

"Converting the 8bpc to 32bit integer linear light values and having all FXs work on that shouldn't cause a huge slowdown in speed I would have thought."

This could be readily achieved with a 256 entry lookup table. Conversion of coded to linear is direct access, while linear to coded would require a search but 256 is quite a small number, really.

Dawdle wrote on 4/1/2015, 7:46 AM

"I don't see why the issue cannot be fairly easily and cheaply addressed in software. CPUs are fast and the busses wide enough for us to be able to do the required calculation using more than 8 bits per channel. Converting the 8bpc to 32bit integer linear light values and having all FXs work on that shouldn't cause a huge slowdown in speed I would have thought. The final values can be converted back to 8 or 10 bpc video for the existing encoders."

This is what Vegas is already doing with its 32bit float mode. The speed difference is significant.

OldSmoke wrote on 4/1/2015, 7:52 AM

This is what Vegas is already doing with its 32bit float mode. The speed difference is significant.

I think speeds depends more on the codec and how well it's implemented in Vegas. For example; the XAVC-S 100Mbps files form AX100 will not run well on my system in 8bit, certainly not in 32bit. However, transcoding the files to XAVC-Intra with Catalyst made them playable and editable even in 32bit Full Range.