| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
|
Yeah, understood. This is the dumbest solution. I don't quite understand why this rescaling is necessary, despite the nice comments.... |
Sorry, something went wrong.
|
OK, I only used the bigger float64 if the amin-amax > 1e8. |
Sorry, something went wrong.
|
I think(?) you probably care more about maxabs/minabs. |
Sorry, something went wrong.
|
Hmmm, not at all sure, because I once understood all the low-level reps of floats etc, but not so good at it anymore. Happy if someone wants to pick this up and do it better. But, I think the error comes in when we do: matplotlib/lib/matplotlib/image.py Lines 389 to 390 in 884060a and the resulting float doesn't preserve all the bits in the unit32. |
Sorry, something went wrong.
|
This is a reasonable approach. The scaling is to be able to track the over/under pixels and get around ringing in the interpolations. |
Sorry, something went wrong.
|
Discussed this on the phone call. Will investigate
|
Sorry, something went wrong.
|
Test added, and changes requested above made... Thanks! |
Sorry, something went wrong.
There was a problem hiding this comment.
Working and slow is better than broken and fast. Happy to merge a future PR that keeps things working and makes it faster.
Sorry, something went wrong.
Backport PR #10133 on branch v2.1.x
| Back | FazBrowse Home | New Git URL |
PR Summary
This fixes #10072.
The problem was that for a uint32 image, the dynamic range was too high for a float32 to properly represent. Simply changing to float64 fixes the issue. I suppose someone could use a unit64 image, but...
Test coming: code:
PR Checklist