On Wed, Mar 4, 2020, at 15:01, Juan Nunez-Iglesias wrote:
I might not be getting the full picture here: returning Bunches instead of (in most places) NumPy arrays would in itself be a breaking change? Similarly, one of the big changes we are proposing is returning an array of floats that is *not* rescaled to [0, 1]. That is, we want to still return a NumPy array (whether that is the plain array or an attribute in the Bunch) but the values in the array will be different. I don’t clearly see how Bunch solves that problem?
There are at least two considerations here: - We want to stop coercing image data to a certain range based on the data type of the input. This will be a breaking change, overall, unless we introduce the `preserve_range` keyword widely. - We would like to make, consistently, most functions be of the form: output_image = function(input_image) This makes for easy construction of pipelines: output_image = first_func(second_func(third_func(intput_image)) In cases where additional calculations are made, we want signatures of the form: output_image, additional_namedtuple = function.extra(input_image) [Exactly how the calculation of additional_namedtuple is triggered is not set in stone; the `.extra` attribute on functions was one suggestion of how to do that easily.] The usage of named tuples / bunches / data objects will be an integral part of the design. Best regards, Stéfan