3.5 Beta 2 - Glare takes longer to compute with intensity mask

[LudvikKoutny]

Hi,

I've found something really odd I can't wrap my head around. If I use LensFX glare in latest stable beta, enabling intensity mask slows down glare computation. That does not make any sense at all. Intensity masking should reduce the amount of pixels glare is computed on, so it should actually vastly speed up glare calculation, like it does in pretty much any other glare generator. Yet in LensFX, enabling intensity mask actually slows down the glare.

[^Lele^]

Can i see samples and timings?
Ideally, of the same input image, and the same output results.
And that's non-trivial, in itself, as each engine isn't a mathematical copy of another, and the algorithms and results do vary a lot.
But since you seem sure it's not the case, i'd really like to see where a correct luma mask operation which drives the shape of glare bleeding later makes things quicker elsewhere.
It may well be the case, don't get me wrong, but it may well also be due to both special cases (make the intensity mask white noise, your lensfx rendertimes WILL go up.), and different order of operations, or approach to masking (it can be done cheap, and ugly, or right, and pretty, but slower.).
In the case of V-Ray is trivial to verify your intensity mask acts as a series of virtual camera apertures, and masking changes the shape of the resulting glare, it's not a cutout on top.
So intensity masking will add calculations, and will change the shape (and fringing) of the glare much like an obstacle image would (that too is added time. and beauty.).

[vlado]

The lens effects will print the timings for the bloom/glare effects in the V-Ray log. Can you show them? In any case, the intensity mask option requires an additional pass through the image to calculate the mask in the first place, and it makes the final composite between the original image and the post-processed one more complicated, so it's somewhat normal that the additional calculations slow down the rendering. It can probably be optimized though.

Best regards,
Vlado

[LudvikKoutny]

Here is the log screenshot:


The first bunch of 500ish times are with intensity mask off, just randomly shuffling around the weight and size parameters. Then, the 1000ish numbers are as soon as I enabled intensity mask at 1 and doing the same parameter shuffling. Third bunch of 1200ish numbers are after I increased intensity mask to 3.

Sorry to bring up Corona again, but it can generate glare on single core of CPU faster than LensFX can on GPU, and I think it's mainly due to computing glare only from intensity masked pixels, not entire image. There, if I lower intensity threshold to 0, it slows down to crawl. But exactly same applies also for Mental Ray's Lume Glare shader, for Fusions Highlight glare node, and for ArionFX. As soon as any other generator computes glare from entire image, it slows down to crawl. So I hope that if LensFX got optimized in a similar manner, it could approach realtime framerates given how fast it generates glare without intensity mask.

[^Lele^]

Besides any optimisations the code may need and want (6/9/1200ms is a long time? We have different standards, but then again, maybe i'm just an old and slow geezer.),

The first bunch of 500ish times are with intensity mask off, just randomly shuffling around the weight and size parameters. Then, the 1000ish numbers are as soon as I enabled intensity mask at 1 and doing the same parameter shuffling. Third bunch of 1200ish numbers are after I increased intensity mask to 3.

was explained to you here:

In the case of V-Ray is trivial to verify your intensity mask acts as a series of virtual camera apertures, and masking changes the shape of the resulting glare, it's not a cutout on top.
So intensity masking will add calculations, and will change the shape (and fringing) of the glare much like an obstacle image would (that too is added time. and beauty.).

And you kindly verified it: a low intensity mask makes one big diffraction aperture, a higher value will block more of the image, generating more finer points to calculate patterns through.

Sorry to bring up Corona again, but it can generate glare on single core of CPU faster than LensFX can on GPU, and I think it's mainly due to computing glare only from intensity masked pixels, not entire image. There, if I lower intensity threshold to 0, it slows down to crawl. But exactly same applies also for Mental Ray's Lume Glare shader, for Fusions Highlight glare node, and for ArionFX. As soon as any other generator computes glare from entire image, it slows down to crawl. So I hope that if LensFX got optimized in a similar manner, it could approach realtime framerates given how fast it generates glare without intensity mask.

It's clear the code between the apps is different (i think i mentioned this in my previous post too.).
Why would you want us to conform, i wonder, when we're offering you a choice the others apparently do not (if one has to infer from the identical behaviour of their algos, as you put it.)?

I would be extremely interested at seeing a comparison of the results for identical renders (a few lights would likely do fine, provided they all were of the same rendered intensity.) with the different engines, and nice, solid numbers and image analysis to spot differences.
You seem to know them all well, so why not do one and share that?

[LudvikKoutny]

I can definitely do some better test when I have time. Now I am occupied with a V-Ray job, and I keep finding these issues as I am building the scene. Once job is done, I will definitely try to make some comparison.

As for why I would like LensFX to conform to others... Who wouldn't want it faster? Not only do other solutions render those glares faster, they also render them better looking.

Lastly, yes, 1000ish millisecond times are not long, but it was measured on 1280*720 images. It's gonna grow up on something like 3508*2480 image

[^Lele^]

I can definitely do some better test when I have time. Now I am occupied with a V-Ray job, and I keep finding these issues as I am building the scene. Once job is done, I will definitely try to make some comparison.

Ah thanks for that.
I'll wait until you're ready to provide actionable data.

As for why I would like LensFX to conform to others... Who wouldn't want it faster? Not only do other solutions render those glares faster, they also render them better looking.

*I* wouldn't want it faster, if it cheated instead of using top notch algos.
"Fast" as you seem to define it, is time.
I define it "Efficiency" and express it as work done per unit of time.

"Pretty" is subjective, you see, and never up for debate.
Hence me calling for YOUR image analysis of them all, so at least to glimpse what are YOUR parameters to define something so sternly good or bad.
Read above: i'll wait for the right time.

Lastly, yes, 1000ish millisecond times are not long, but it was measured on 1280*720 images. It's gonna grow up on something like 3508*2480 image

It will grow by exactly the same amount as the image area (or MPx) will, and very linearly so.
So by my maths, if 1 Mpx takes 1000ms, you can expect the same image at 9 Mpx to take nine times longer, or nine seconds.
Likely less than it takes Photoshop, or Max!, to open from cold, for that matter. ^^
Given if it was made realtime at 1Mpx it would come to a ninth of the required 60FPS (i'd assume. more?) at 9MPX, what's the target resolution you'd be happy with for realtime operations?

[vlado]

So I hope that if LensFX got optimized in a similar manner, it could approach realtime framerates given how fast it generates glare without intensity mask.

Keep in mind that in the real world, there is no intensity mask. The bloom and glare *are* actually applied over the entire image. Most lens effects applications ignore this fact and focus on the bright regions only, but this is not, strictly speaking correct (you could say that it is biased, in a way...)

Best regards,
Vlado

[LudvikKoutny]

Keep in mind that in the real world, there is no intensity mask. The bloom and glare *are* actually applied over the entire image. Most lens effects applications ignore this fact and focus on the bright regions only, but this is not, strictly speaking correct (you could say that it is biased, in a way...)

Best regards,
Vlado

Yes, I do understand that. But AFAIK, intensity mask in LensFX does the same thing, doesn't it? Limiting LensFX to be generated only from data above intensity threshold, right?

In case of glare generation, I think artistic control has edge over physical accuracy ( <- I am talking strictly in relation to glare here. I have very opposite opinion about rest of the rendering aspects ) in the same manner that for example Volumetric fog tends to generally look better when it does not scatter GI, as the godrays get a lot more pronounced and at the same time it calculates a lot faster. So it often ends up being win/win scenario

Even when I had an option to apply glare over entire image range, I rarely did. Intensity masked glares always looked better and calculated faster

Also, I don't think we need to consider bias here too much. I mean if we had to get really unbiased glare, we would have to simulate all the glass in the aperture, to get things like lens flare patterns, and so on...