-
Notifications
You must be signed in to change notification settings - Fork 141
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Behavior of limits
#101
Comments
This addresses the initial problem discussed in #101
Yikes, I didn't know about that. In my personal view, the problem is not See if you like the solution in #102. What else? |
This addresses the initial problem discussed in #101
Sweet implementation :) I cannot really put my finger on what exactly it is that leaves a bitter taste. I keep wondering whether it's sensible/worth the effort to follow OpenCV and use saturation-arithmetics instead of overflow-arithmetics. And if so, whether it should clamp at the |
I haven't implemented this yet, but here's a mock-up that shows another way of thinking about this (carefully note the element types, and if you've used
Once you attach physical units to the intensities, it seems clearer to me that the limits should scale along with the values. |
The taste is gone, thanks. |
Continuing the discussion at #100 because it got off-topic.
limits
still leaves a bitter taste, because of behavior like the following:I'm not sure on how to best handle this, esp. in the case of
Uint16
images filling only 12 bits for example.The text was updated successfully, but these errors were encountered: