Page MenuHome

Crashes with white balance filter
Closed, ArchivedPublic


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) set Type to Bug.
Aaron Carlisle (Blendify) created this task.
Aaron Carlisle (Blendify) raised the priority of this task from to Needs Triage by Developer.

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

Thomas Dinges (dingto) triaged this task as Normal priority.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) lowered the priority of this task from Normal to Needs Information from User.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) closed this task as Resolved.

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

Aaron Carlisle (Blendify) changed the task status from Resolved to Archived.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.