Should etc. error if a color component is outside the range [0, 1]?

Issue #1315 closed
hahawoo created an issue

Should (and other functions which set colors) error if a color component is outside the range [0, 1]?

I think it would useful for upgrading to 0.11.0, i.e. it would error instead of everything looking white.

Comments (14)

  1. Mi 28

    No it shouldn't. Sometimes math goes out of range ever so slightly so clamping is needed either way, and making users do clamping themselves is not necessary nor productive.

  2. Alex Szpakowski


    • Proper error reporting. It is actually effectively an error to go outside the range of [0, 1] for sRGB colours, it'd be good if LÖVE reported that (especially to help with transitioning to 0.11 as pointed out).


    • There may be a performance penalty in the non-floating-point formats of ImageData when setPixel and mapPixel are used. I will have to profile it.

    • As raidho says, at least some clamping is probably needed to avoid false positives. I am not sure if doing some clamping is really better than doing none.

    I haven't made up my mind yet.

  3. Mi 28

    If user uses math to produce color, it's pretty much guaranteed to produce values out of range, so clamping would be needed. Making users do clamping manually to stop game from crashing is not helpful. Making it error on out of range color is much like being pedantic just for the sake of being pedantic - there isn't anything to be gained from this.

  4. Alex Szpakowski

    Yeah sorry, I meant to write 'I am not sure if doing some clamping and some erroring is really better than clamping all the time' but I was distracted when writing.

  5. Alex Szpakowski

    Something like this:

    if (abs(component - 0.5) > 0.5 + smallvalue)
        return luaL_error(L, "Color components must be within the range of [0, 1] (value is %.3f)", component);
        component = clamp01(component);
  6. Mi 28

    But then you can't take advantage of that clamping: if your math can go out of range to large extents, you'll need to do clamping manually despite it being there anyway. Sounds like bad design.

    Let me reiterate my point: Doing without clamping completely will produce errors. So clamping is needed either way. Not doing clamping in the framework will make users do clamping manually - not helpful.

  7. Alex Szpakowski

    It's bad design for your math to go out of the defined range of a color space...

    For reference, in 0.10 and older going out of the range of [0, 255] was already effectively undefined behaviour.

  8. Mi 28

    Then why have clamping at all? You can't use half-measures, you either follow through or let go.

    Also, it most definitely a bad design to have users to produce boilerplate code where it could be avoided. Having users put clamping on every setColor falls into that category, clearly.

  9. Alex Szpakowski

    Then why have clamping at all?

    To avoid issues where the math is correct but floating point imprecision causes the number to go slightly out of the defined range. In 0.10 this was not an issue because LÖVE truncated the fractional part of the integer color component under the hood, so 255.00001 would become 255.

  10. Mi 28

    Now that I think of it, maybe there shouldn't be any clamping actually? E.g. if user intends on using HDR colors and shaders.

  11. Alex Szpakowski

    The sRGB color space is only defined for [0, 1] — sRGB <-> linear RGB color conversions don't really work outside of [0, 1].

  12. Bart van Strien

    I feel like the best solution is probably just to always clamp. I can see there's diagnostic value in throwing an error, but only throwing them past a threshold is.. weird. Plus, colour errors of any magnitude should be fairly obvious anyway.

  13. Alex Szpakowski

    Clamp all color arguments to [0, 1] in cases where values outside that range don't make sense (fixed-point color values & sRGB colors). Closes issue #1315.

    → <<cset a02441c31b4c>>

  14. Log in to comment