troy_s

The link to the EXR in Aidy’s thing doesn’t use DWAA. Actually use files and you’ll discover that EXRs are superior in every way, even when compressed, which is an important point. Compressing an EXR at half is simply a no contest against PNGs, and better, the PNG specification itself is inherently problematic. Arguing any differently with the sole exception being that one is chained to trying to display on the web, is absurdity.

I don't think it will matter? It's too bad given that DPX was designed for log density encodings, and are quite efficient.

It’s not your bad. It’s Blender; the DPX handling is broken up to bits.

Leave it to manchildren developers to come up with ridiculous design solutions.

This is such an excellent answer. I just noticed your DPX samples, and sadly, because Blender has some archaic code and mishandles, the benefit of DPX log compression is lost. DPX is one of the few formats that can save as 10 and 12 bit, which when coupled with a log encoding, is an extremely tight file parcel for encoding scene referred files. Perhaps some day the file encodings will get mopped up, and PNG as default will be replaced with much more viable encodings.

I have no idea how to apply bounties then. I applied it, it was listed, then it expired.

I believe in most instances, a half float EXR will be smaller than an 8 bit PNG. All massive technical reasoning aside, PNG is also a failure on the bandwidth aspects.

Incredible, right?

I believe it would be rather eye opening for people to see how sloppy PNG is against a half float EXR with DWAA. It is rather eye popping.

@rjg Since you are including DWAA/B compression, it might be illuminating showing file size. It spirals into more work, but many folks don’t likely appreciate how compact the files end up, and despite being lossy, are still incredibly more valuable than PNG lossless at 8 bit. The results would probably shock people.

@hatinacat2000 That’s because the VSE is a broken mess of poor design in 2019. Most everyone understands that pixel manipulations, including dissolves and overs, must be applied on scene referred data, except the VSE hacked around proper operation as it doesn’t have a background rendered cache. As such, you’ll have to manually change the VSE color space to “Linear”, and change your view accordingly. It’s a broken mess though, so it is probably not worth bothering with.

It is folks like you who make investing time in answers worth it. Terrific answer on all fronts, and wonderfully explained. Well done.

The confusion over display linear versus scene linear is huge.

I think the worst part about sRGB and its 2.2 counterpart is what people think it does.

Well that is common.

There is a nasty nightmare regarding that OETF and the linear toe.

So to avoid quantisation artifacts, that little linear toe shoots straight until a certain range.

The theory (at least as far as I have learned) is that the linear toe was designed to avoid the lower values of a typical display where the hardware DAC could provide irregular results. Values collapse onto one-another down low, and at the low end, power functions in the display were not reliable.

An expensive Dreamcolor set to "sRGB Mode" is actually a pure 2.2 power function believe it or not.

@GiantCowFilms A power function of 2.2 is essentially the hardware curve of a typical sRGB display. The canonical sRGB OETF is a two part transfer function with a linear toe for complex reasons. So yes, your first answer is quite correct.

@GiantCowFilms So to answer this, yes absolutely.

They compress a potentially large range of values down into the 0.0 to 1.0 range.

Now normalized log transfer functions or fancy tone map functions are not at all like this.

So power functions are identical to transfer functions designed for the display referred domain; input values 0.0 to 1.0 always yiels 0.0 to 1.0.

Same goes for any power function. Take a value of 0.0 to 1.0 and you will always get back a value 0.0 to 1.0. Place 1.00001 through a power function? The value that comes back will always be > 1.0.

So even if you start with a scene referred set of values, no matter how hard you try, the sRGB OETF will never "see" values beyond value 1.0. We can of course roll a value of 193727 through it, but the value it yields will remain always above 1.0.

The important part of this to pay attention to with regards to your question is that no matter how much you try, the sRGB transfer function is anchored in being 0.0 to 1.0; there is no compressing of values beyond that range.

Below a certain display linear range, something happens, above, something else.

So sRGB is, in terms of a canonized transfer function, a two part function based on the input "ground truth" of display linear range.

That is, when you confuse a pure power function with some other transfer function such as a normalized log, the numerical ranges are vastly different.

Folks get really confused, and this is because power functions behave in very particular ways. They are essentially bounded functions.

So first thing first, use the term "gamma" only when referring to the transfer function of a display. It will help avoid confusion.

Sorry @GiantCowFilms, was in another window.

Yes. Been a bit busy.

Greets @GiantCowFilms.

(Even if we defined a fully sharp spectral value as a blue, we would have a very difficult time calling it a "pure blue" because there would still be a number of mixtures that could be used to derive precisely the same colour[1]. [1: The very tip of the CIE spectral locus notwithstanding, as it may be impossible to mix that particular value.])

I suspect all of this would be far more clear if you were to spend a bit of time learning about additive RGB colour encoding models.

@downvote-flagger Again, read above. There is no such thing as "pure blue". If you are attempting to suggest a "pure blue" relative to the additive light RGB colour encoding model, that too would be a misinformed statement as there are an infinite number of blues that could be defined with [0.0 0.0 0.5] for example.

@downvote-flagger Any link that purports to speak of "real yellow" is canonically incorrect. Yellows are yellows. They can be composed of a near-infinite number of different mixtures of light colours, and result in identical colours. RGB is not a set of colours. It is a colour encoding model. The actual colours for each of those reddish, greenish, and blueish lights is determined by the colourspace that the RGB lights reference.

@downvote-flagger Example: "Pure yellow" here is a misnomer. Assuming we define it as a strict xy coordinate in the CIE xyY system, we could arrive at it via a number of different mixtures. That facet is metamerism; the ability to use various mixtures of light colours to derive a colour that ends up looking identical to a perceptual system under identical contexts.

@downvote-flagger There are two things that make it challenging here in your question. The first is the difference between additive and subtractive (multiplicative) models. The second is in the nature of an N spectral count of lights versus three.

Sort of some neat stuff to muck with.

Just make the stripes or whatever roughly the spectral distribution within the limits of REC.709 or whatever reference you have setup for.

Yes you could.

ep.

It works with a magic texture too.

You can get away with a simple huesweep generated in any application I suspect.

LOL

But it does indeed work. Somehow.

I'm sure you can come up with ways to get nicer sharp caustics.