Hi all,
as a scientific image user I have been reading along this difficult thread.
Let me first pay my respect that these difficult and, by nature, opinionated (which is good!) discussions are being performed in such a civil manner!
As someone who is member in a technical committee for Python software myself, I know how hard this can be..
Now to the issue at hand, I was wondering if this could be tackled as it's done in Space/Tech engineering, with a requirements documents that all should agree on, from which maybe the one and only obvious solution will emerge?
I wanted to mention my personal requirements for working with an image library.
Please forgive me if all of this already happens in skimage, but it's been a while since I was using it:
First, and for me the most important:
Pixel values are sacred and shall never be changed without letting the user know.
I'm almost sure that this is the case with skimage now, but in the early days I remember I was highly surprised, annoyed even, when some routine simply insisted that the input data needs to be so and so and the result will be this format, no matter what came in. It simply resulted in being less useful for me (no complaint, I know I could have done some PRs ;) ).
I will admit that us instrumentalists are completely ignorant of certain standards in proper image formats, we simply use them as co-located data containers.
This means they can be ANY format:
* Integers (both signed and unsigned)
- with counts as high as the digitized signal required for determining the dynamic range, sometime negative because some weird amplifier randomly would suck off electrons, who knows what the engineers are cooking with ... ;)
* Floats, often representing physical values after the integer format version was calibrated, but with absolutely no sensible/reasonable way to force them into some kind of range. The pixel values represent physics values, they don't care that a float image shouldn't be larger than 1.0
but the fact is, ALL of these pixel values are measurements with a meaning and they absolutely need to be preserved.
This statement needs to be qualified though with "within reason", as obviously some "wanted" operation like a median filter to remove noise will change pixel values, but is indeed range preserving and the meaning of the data isn't lost.
I understand that certain algorithms require the incoming image to be in a certain format and range, and if no "standard" wrapper can be identified that could transform and back-transform into the same range, then the user should be pointed to workarounds, but not left alone simply with the error message that the format doesn't match the algorithm.
I for myself am lucky that I do not have a lot of code that I would need to change, so I wouldn't really mind any import name changes, so I think it might be much more of an discussion for the maintainers which way minimize a convolution of maintainer_effort with user_pain, but honesty, knowing how hard it is to find extra time for a passion volunteer-effort project, I'd almost always go for "least effort", because I think the community will come around (as can be seen with cv2 and other examples).
I just wanted to emphasize how important the pixel values can be for us, as they literally represent the bearer of the truth from outer space, so to speak, and any change of their values shall be done only under full consideration of the consequences.
My 2 opinionated cents.
As always, thanks so much for everybody's effort for this project, we soon will have a technical-committee-reviewed package of many of my planetary science tools for data retrieval and data reading coming out, so I'm kinda feeling now how much damned work it is to design tools for the "community"...
Best regards,
Michael