Jump to content
Maarten Witberg

Color grading based on field value

Recommended Posts

Maarten Witberg
it allows for easier changes if there was a new band added.

 

That remark in this thread by david Head (post #5) set me off thinking, what if you could devise a way to simply determine a value range and a desired number of bands, and then have Filemaker compute equidistant bands and make a gradient color range for a band?

uh....

I think I kind of succeeded in the first part. But the gradient color range has let me run into a brick wall.

 

What I set out to do:

the idea is that ultimately I have two custom functions: one that determines a graded range of bands within a color (for instance, three bands of purple, at 33%, 66% and 100% of the saturation) and another one that recursively calls the first one to determine a set of these ranges - say a greenish set, a blueish set and a reddish set, based on threshold values. May sound using a cannon to shoot a fly but I think it may be useful e.g. for creating map legends.

 

The first custom function so far looks like this:

 

 

ColorBanding

(

LowerThreshold ; UpperThreshold ; NumberOfBands ; TargetValue ;

RedOffset ; GreenOffset ; BlueOffset

)

Let(
[ OffsetColor=RGB(RedOffset;GreenOffset;BlueOffset);   
  //build the color
 Increment=(UpperThreshold-LowerThreshold)/NumberOfBands  
  // determine the distance between bands
]
;
Case
( 
 LowerThreshold=<TargetValue and TargetValue< UpperThreshold;  
    // to see if TargetValue falls into the range, =< and < more or less arbitrary
 TextColor (TargetValue ; OffsetColor / Div(TargetValue-LowerThreshold;Increment)) 
    // to determine in which band TargetValue falls
 )
)

 

What it does do is color code ranges of values; what it doesn't do is create a graded range of colors. I was way too simplistic in my thinking about that. Being used to CMYK color system, I thought I could simply halve the values to get half the saturation of any RGB value, but alas, this is not the case. I tried to see if there's method to the madness, but I can't spot it.

Another problem, which is major or minor, depending how you look at it, is that since the increment is not always a whole number, the ranges will not always be exactly equidistant. Rounding will result in + or - one position.

 

Well, I hope someone knows how to compute saturation values using RGB.

Otherwise this is a nice trick at best but as you can see in the sample, with little or no control over the resulting colors. Any tips, links or calculations greatly appreciated. smiley_cool

 

maarten

 

sample removed, see post #9

Share this post


Link to post
Share on other sites
Maarten Witberg

Given enough time on a commuter train, anything's possible. Here's a revised version, it will produce a graded range of colors from an offset color.

 

Saturation values can be determined by

 

RGB((RedOffset+GreyValue) ; (GreenOffset+GreyValue) ; (BlueOffset+GreyValue) )

 

I found that here.

 

The CF now runs

ColorBands ( LowerThreshold ; UpperThreshold ; NumberOfBands ; TargetValue ; RedOffset ; GreenOffset ; BlueOffset ; SourceValue )

 

Let(
[ OffsetColor=RGB(RedOffset;GreenOffset;BlueOffset);   //build the color
Increment=NumberOfBands ;// (UpperThreshold-LowerThreshold)/NumberOfBands ; // determine the distance between bands
SatStep=Div(SourceValue -LowerThreshold;Increment);
Saturation= RGB(
(RedOffset+Increment*SatStep); // /2; the division by two comes from the site. I'm looking into the reason for this. 
(GreenOffset+Increment*SatStep); // /2;
(BlueOffset+Increment*SatStep) // /2
) 
]
;
Case
( 
 LowerThreshold?SourceValue and SourceValue< UpperThreshold;  // to see if SourceValue falls into the range, ? and < more or less arbitrary
 TextColor (TargetValue ; Saturation) // to determine in which band TargetValue falls
)
)

 

Please note there is now a sourcevalue and a targetvalue, in the targetvalue I stored the block character from Wingdings 2.

Also to prevent non-integer increment steps, I changed the parameter from the desired number of bands to the desired distance between each threshold.

 

Edit it still behaves weirdly if the range is wide.

 

sample removed, see post #9

Share this post


Link to post
Share on other sites
comment

I'm afraid the site you rely upon doesn't have a clue. Desaturation is NOT achieved by mixing with gray. If it were, a completely desaturated picture would be a uniform gray. In fact, a picture with zero saturation is 'gray scale' (commonly called 'black and white'- like old TV).

 

I'd write more, but I cannot concentrate in this racket. And it's really off any FM topic.

Share this post


Link to post
Share on other sites
Maarten Witberg
Desaturation is NOT achieved by mixing with gray.

Maybe but I still managed to get a result - it may not be called desaturation, but the effect is the initial color peters out to white.

See the attached. The weird results of the previous version were caused by two things:

- the offset R, G or B value must not be odd

- the resulting R,G or B value must not be over 255.

Once I fixed this, it seems that there will be a neat sequence for any starting color in any range of values. Nevertheless, in large ranges there will be lots of white bands - not good. Also, it would be nice if the range could also run from light to dark. Either evades me at the moment.

I'm going to try to make the color ranges distribute evenly, not just increment them. I suspect a different approach is necessary.

 

 

And it's really off any FM topic.

I politely disagree. Since you can boss around colors in Filemaker, why is it off topic to try to find out how color calcs behave?

 

I cannot concentrate in this racket

Take it easy, I'm probably the only one who thinks this is urgent....

 

 

Maarten

 

sample removed, see post #9

Share this post


Link to post
Share on other sites
comment

I am not too sure what your file does. I was responding more to the part you referenced in your link. In any case, I tried (in your latest file) to specify pure yellow (255;255;0) as the initial color, and I got a progression of grays.

 

You cannot really "boss around colors" in Filemaker. All you can do is specify a color in the 8-bit RGB color space of your computer. You could also say that "you can boss around numbers in Filemaker" - but that doesn't turn algebra into a Filemaker topic.

Share this post


Link to post
Share on other sites
Maarten Witberg
I got a progression of grays.

 

oops. you hit a glitch. In the cf, BlueSat has the same definition as GreenSat *)...i posted a fixed version in the previous post and added a condition that if either color starts at 0, it should stay that way. But I'm afraid all this is just the result of trial and error, I'm starting to understand a bit better how RGB values behave when you change them by increments. Like I said before, I'm more used to CMYK which seems more intuitive to understand when you play around with color sliders.

but that doesn't turn algebra into a Filemaker topic.

 

True, but that does not mean it's not sometimes necessary to learn something about it -or about any non-fm topic- if you want to do something in filemaker.

 

 

 

maarten

 

 

*) "sat" as a suffix is probably not correct. ah well.

Share this post


Link to post
Share on other sites
comment
that does not mean it's not sometimes necessary to learn something about it

 

Yes, but you asked some very broad questions - e.g. if there's a method to this madness. There is, but it is quite complex, and we'd have to start somewhere - just like with algebra.

 

In a nutshell, you cannot do this in RGB (nor CMYK). That is, IMHO, the basic flaw in your approach. If you like, I can let you have the necessary formulae, but I am not too keen on posting these publicly.

Share this post


Link to post
Share on other sites
Maarten Witberg

Thank you for replying - and thanks for the offer. I had begun to suspect that this was all too simplistic. I'll give some thought to your offer. I'll let you know tomorrow. For now, good night.

Share this post


Link to post
Share on other sites
Maarten Witberg

Here's a complete sample that gives - I think- a satisfactory sequence of graded colors, through a user (well... a user that knows what he's doing) specified range of threshold values, RGB values and grades per intervals (i.e. the distance between any two threshold values.

 

As Comment has noted, the result is not progressive saturation, but rather an incremental change of the specified color for an interval. an improvement with respect to this is that the CF now computes the increment for each R, G and B value and does this independently for each of the three. The result is that the available color bandwidth for each specified RGB value ( 255 minus the specified value) is now better used.

 

The major change is that a second cf is added that, as stated earlier, recursively computes in which interval each source value falls, by calling the original cf and testing if this is empty.

It may not be the most efficient recursion available to solve this...

 

Trying to avoid confusion, I have removed earlier samples. The old cf is still in place in the current sample though. I'm relying on you guys to find the next stumbling block within twenty seconds of opening the sample... smiley_cool

 

Edit: sample now contains extra CF that use smoke and mirrors to return the inverse gradients. So a lower value will typically have a lighter color.

 

 

colorbandingIMG.jpg

Share this post


Link to post
Share on other sites
This thread is quite old. Please start a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.




×
×
  • Create New...

Important Information

Terms of Use