YOUR ACCOUNT

Home > Forums > Bugs and Problems (Windows) > 

ugly black fields in elevation gradient (HDR values wrapping?)

Active Topics Search
Login or Register to post new topics or replies
Jon Watte
Posts: 30
Filters: 18
This is using FF2.
Look at the below screen shot. The input data is black-to-white, but the output data has ugly black squares where the input data is at its whitest.
Is this a problem where HDR data wraps from 255 back to 0? If so, is there a fix?
I've looked for a "RGB clamp" operator for a color map, but can't find it.
Posted: August 10, 2010 11:21 am   Details E-Mail
ThreeDee
Lost in Space

Posts: 1672
Filters: 112
Hi Jon,

Wow, that's truly messed up. It is definitely a bug.

I did find one way to fix it. Here you go:

Clamping.ffxml
Posted: August 10, 2010 11:57 am   Details E-Mail
tigerAspect
Posts: 222
Filters: 9
No, no fix, I cant't even get confirmation if this is a bug or not. I brought this up in the beta, and the official word is that an Elevation Gradient is apparently "numerically-unstable by nature". Go figure.

Discussion here: http://www.filterforge.com/forum/read...8&TID=7449
Posted: August 11, 2010 10:11 am   Details E-Mail
BenBeckwith
Posts: 136
Filters: 8
It appears to be a bug with the Contrast param in the noises. When the contrast reaches beyond 0-1 it clamps to 0, but seemingly only with the elevation involved, because it looks fine in the noise alone. If you want that much contrast, try using HDR in the colors rather than the contrast slider. The contrast slider maxes out around 33 for the blocks noise and 64 on perlin.
Posted: August 11, 2010 4:03 pm   Details E-Mail
tigerAspect
Posts: 222
Filters: 9
Nope, it's a bug in the rendering engine itself. Here's the official word so far, and the example referred to:



Quote
Unfortunately, the filter example is numerically-unstable by nature.
You have a border on the left side of gradient rectangle (actually gradient infinite stripe, but never mind =). There is 1 on the left side, 0 on the right.
In case you have any (even extremely little!) numerical errors, you cross the border and get a result which strongly depends on the error.
Of course, it is possible to fix that behavior for particular tests. However the "bug" will not dissapear =/ It will just "jump" from one test to another.


Posted: August 11, 2010 8:16 pm   Details E-Mail
ThreeDee
Lost in Space

Posts: 1672
Filters: 112
Quote
tigerAspect wrote:
No, no fix.


Do you have a situation that doesn't get fixed with the Tone Curve solution?
Posted: August 16, 2010 3:36 am   Details E-Mail
tigerAspect
Posts: 222
Filters: 9
Yeah, that's probably fine. smile:D I meant there seems to be no official big fix immanent.
Posted: August 16, 2010 10:11 am   Details E-Mail
Jon Watte
Posts: 30
Filters: 18
I'm a little late, but there is a code fix that should be simple: If the Elevation Gradient just clamped the input to the [0..1] range, instead of repeating, it would do fine. Specifically, there is a "repeat" parameter already. When that's set to 1, what reason is there to wrap instead of clamp for out-of-range inputs?
Alternatively, the output of the noise should clamp to [0..1] rather than wrap, if that is where the problem is.
Posted: September 13, 2010 3:46 pm   Details E-Mail

Join Our Community!

Filter Forge has a thriving, vibrant, knowledgeable user community. Feel free to join us and have fun!

33,711 Registered Users
+18 new in 30 days!

153,531 Posts
+36 new in 30 days!

15,347 Topics
+72 new in year!

Create an Account

Online Users Last minute:

16 unregistered users.

Recent Forum Posts:

Join our Forum Join our Forum
Over 30 000 members!
Join us on Facebook Join us on Facebook
Over 42 000 likes!
Follow us on Twitter Follow us on Twitter
Get updates quickly!
Follow us on Instagram Follow us on Instagram
Tag us #filterforge