Recent colorspace conversion change
Swiss army knife of image processing
Brought to you by:
bfriesen
Hello Bob, I have a concern about the recent commit https://sourceforge.net/p/graphicsmagick/code/ci/8e342d89838cd3649c02b3725703050bfa69391f/
In integer arithmetic, the (foo + 1)/2 paradigm is used for rounding (and works for positive numbers only mind you).
When you switched to floats now, the "+ 1" is now actually introducing a bias, and thus, an error, no?
Thank you for double-checking the code. It is easy to introduce an error.
With this small test program I do not see a severe issue with results:
since I see these results from the program:
I am reminded that there is a MaxMapFloat value which could have been used.
My edits were a reaction due to using Visual Studio 2022's code analyzer to discover issues.
Thanks for following up Bob. While it is true there is no difference in this particular case with odd constant MaxMap, I feel the code just reads a bit weird and the intent is no longer clearly expressed after the change.
For future maintainability, may I suggest reverting back (or perhaps casting to float after the int rounding paradigm as (float)((MaxMap+1)/2) if all you want is to avoid VS warnings), or simply use ceilf(MaxMapFloat/2)?
I am not sure if the VS Analyzer will still be happy since it may (stupidly) be complaining about the MaxMap+1. It is too painful to verify that at the moment. Regardless, moving the cast seems fine to me.
Concern is addressed by Mercurial changeset 17288:7e7556380183. Thanks for inspecting the commits!
Thanks!