ofColor and clamping

[kylemcdonald]

ofColor_:operator+= currently calls clamp() when it's done doing the +=

i imagined one of the applications of ofFloatColor would be for averaging or summing ofColor, which normally requires non-saturation semantics for +=. i could also do a / or * every += operation to avoid overflow. this doesn't have to be a bug, but it should at least be documented clearly when we discuss ofColor.

[ofTheo]

yeah that is strange.
I could imagine that this could be part of something that allows you to set the range of the color you are working with.

ie: myColor.setRange(0, 255, true); //clamp at 255
myFloatColor.setRange(0, 1.0, false); //no clamping

[DomAmato]

I think this is fixed and can be closed as they are handled by a specific clamping function depending on the type of operation performed

[kylemcdonald]

alternatively, casting ofColor to ofVec4f would be a workaround for the cases where you want unclamped colors. right now, this is still broken in my opinion:

#include "ofMain.h"

int main() {
    ofFloatColor a(1., 0., 1.);
    ofFloatColor b(0., 1., 1.);
    ofFloatColor c = (a + b) / 2;
    ofLog() << c;
}

[notice ] 0.5, 0.5, 0.5, 1

[DomAmato]

what should the output look like?

[kylemcdonald]

this is the correct default behavior, but there should be a way of making some small modification so the output is 0.5, 0.5, 1 (i.e., the addition was unclamped). this could be by changing the behavior of the colors, or by converting them to ofVec4f like: ofFloatColor c = ((ofVec4f) a + b) / 2;

[DomAmato]

sounds like we will need a function to handle that? how else should we signal the operator to do an unclamped addition followed by a clamped division other than casting, which certainly seems like that would be something that would be application dependent

[oxillo]

Hi,

We are trying to clean out the many issues that we have.
Many versions of OF have been released since this was issued.

Can you help us by checking if this feature is still requested for a next OF version ?

In case of inactivity, we'll close this issue by end of january, 2020.

Thanks

[Teatoller]

alternatively, casting ofColor to ofVec4f would be a workaround for the cases where you want unclamped colors. right now, this is still broken in my opinion:

#include "ofMain.h"

int main() {
    ofFloatColor a(1., 0., 1.);
    ofFloatColor b(0., 1., 1.);
    ofFloatColor c = (a + b) / 2;
    ofLog() << c;
}

[notice ] 0.5, 0.5, 0.5, 1

Hi, @kylemcdonald, @DomAmato
May you confirm if this matter ("ofColor and clamping #728") was resolved?

Regards
Steven Ennis

[Teatoller]

Hi @ofTheo
Is @kylemcdonald & @DomAmato active on the project?

Regards
Steven Ennis.

#include "ofMain.h"

int main() {
ofFloatColor a(1., 0., 1.);
ofFloatColor b(0., 1., 1.);
ofFloatColor c = (a + b) / 2;
ofLog() << c;
}

[notice ] 0.5, 0.5, 0.5, 1

Hi, @kylemcdonald, @DomAmato
May you confirm if this matter ("ofColor and clamping #728") was resolved?

Regards
Steven Ennis