Page MenuHome

Crashes with white balance filter
Closed, InvalidPublic


System Information
Windows 10
Intel HD 4600

Blender Version
Broken: 2.76.5
Worked: N/A

Short description of error
Blender Crashes when adding a white balance to an adjustment layer strip or meta strip.

Exact steps for others to reproduce the error

  • Add image strip
  • Add a second image
  • Add an adjustment layer above them
  • Add white balance filter to the adjustment layer strip
  • Re-do using meta strip

Event Timeline

Aaron Carlisle (Blendify) raised the priority of this task from to 90.
Aaron Carlisle (Blendify) updated the task description. (Show Details)
Aaron Carlisle (Blendify) edited a custom field.

Hey Thomas, can you please check? Afaik you added it. :)

Thomas Dinges (dingto) lowered the priority of this task from 90 to Normal.Jan 10 2016, 9:35 PM

Will check, but can't promise that I can do much this week (first week after holidays for me ;) )

Thomas Beck (plasmasolutions) triaged this task as 30 priority.EditedJan 10 2016, 10:16 PM

Just checked if I can redo it but can't... see

@Aaron Carlisle (Blendify) Always supply a file to make sure that I can redo it..
@Thomas Dinges (dingto) Did it crash on your side?

Greetings, Thomas

Please attach a blend file which fails (including image files).

Committed likely fix: rB60fa2644cbeff322a38bc3a1f01934df91de4e30, @Aaron Carlisle (Blendify) could you confirm?

@Thomas Beck (plasmasolutions), I noticed the division here can easily perform a divide-by-zero:;b211e4193f2ea1a1cffef6b4b76ae5597922fec2$199-201

It's casting nan to char in premul_float_to_straight_uchar,

Also, even for typical operation, this will cause channels to go above 1.0. For HDR renders this is useful to support,
but probably color correction shouldn't be pushing colors into HDR range?

Bastien Montagne (mont29) changed the task status from Unknown Status to Resolved.Jan 19 2016, 2:30 PM

Assuming this is fixed for now, we can always reopen if not…

Aaron Carlisle (Blendify) changed the task status from Resolved to Unknown Status.Jan 19 2016, 3:02 PM

I am still getting a crash but having trouble finding the limiting factor. And the scene is too big to share. I will try to get a backtrace later this week to see if that can show something.

Hi @Campbell Barton (campbellbarton),

writing from Sweden atm. - was urgently sent to a client last week as a programmer drone and therefore just saw your message. HDRs should indeed be able to go above 1.0, completely agree about the division by zero tough, that should be avoided! Do we have an internal division method that catches those cases or should I just do it manually (by never going beneath 0.00001 for every channel for example)?

I'll talk to @Troy Sobotka (sobotka) about the color correction as soon as I'm back... unfortunately won't be until Sunday this week.
@Aaron Carlisle (Blendify) As said, a file (as simple as possible) where I can reproduce issues helps here - if you find something, pack it into a file and upload it.

Greetings, Thomas

I haven't exactly looked at the code, but I'm pretty sure that it isn't a Bradford transform, which could be added later as a toggle.

"but probably color correction shouldn't be pushing colors into HDR range?"

This sort of operation has to be done blind. That is, it should assume that all images fed to it are scene referred, that is, ranging from zero to infinity with no concept of black or white. This aligns with Cycles internal model, and I don't see any adverse issue here?

@Campbell Barton (campbellbarton) do you see an issue I can't? I trust your wizened eyes on these sorts of matters. From a strictly colour transform side, there's not really much here.