I'm still working through some numpy 1.x vs. 2.x differences to get mesmerize tests to pass. (Some of these are probably very trivial, but it's mostly floating point types not being promoted where they were previously, and there could be some places where the double precision is important, so I'm being cautious.)
One that I just realized this that the sort order for ties using e.g. np.argsort has changed (based on the notes, they switched to a faster implementation). We probably shouldn't rely on this specific order anyway, which is arbitrary. However, the cumulative-energy contour method currently cares about the order among ties, because tied pixels sorted as higher get a smaller cumulative energy number (accumulating from highest to lowest). We could just switch to the "stable" method, which would prevent issues in the future if the algorithm switches, but this strikes me as not the best solution because arbitrary ordering of tied pixels, stable or not, could lead to some pathological contours.
I think the most principled way is, as we accumulate energy from highest to lowest, for each set of tied pixels, add the total energy among all these pixels to each pixel (e.g., if the running total is 0.6, and the 3 highest-valued pixels not yet counted each have an energy of 0.05, each of them gets 0.6 + 3*0.05 = 0.75). My logic is that, for a given contour threshold (say 0.7), assuming some reasonable interpolation, we would add the same total pixel area compared to a threshold of 0.6 (2 pixels) but instead of picking 2 of them arbitrarily we would add 2/3 of each of the 3 that are tied.
I'm writing this to get the idea down first, then I will try implementing it and post some images here if it looks reasonable.
I'm still working through some numpy 1.x vs. 2.x differences to get mesmerize tests to pass. (Some of these are probably very trivial, but it's mostly floating point types not being promoted where they were previously, and there could be some places where the double precision is important, so I'm being cautious.)
One that I just realized this that the sort order for ties using e.g.
np.argsorthas changed (based on the notes, they switched to a faster implementation). We probably shouldn't rely on this specific order anyway, which is arbitrary. However, the cumulative-energy contour method currently cares about the order among ties, because tied pixels sorted as higher get a smaller cumulative energy number (accumulating from highest to lowest). We could just switch to the "stable" method, which would prevent issues in the future if the algorithm switches, but this strikes me as not the best solution because arbitrary ordering of tied pixels, stable or not, could lead to some pathological contours.I think the most principled way is, as we accumulate energy from highest to lowest, for each set of tied pixels, add the total energy among all these pixels to each pixel (e.g., if the running total is 0.6, and the 3 highest-valued pixels not yet counted each have an energy of 0.05, each of them gets 0.6 + 3*0.05 = 0.75). My logic is that, for a given contour threshold (say 0.7), assuming some reasonable interpolation, we would add the same total pixel area compared to a threshold of 0.6 (2 pixels) but instead of picking 2 of them arbitrarily we would add 2/3 of each of the 3 that are tied.
I'm writing this to get the idea down first, then I will try implementing it and post some images here if it looks reasonable.