Return position

[tarokiritani]

ijroi.read_roi now returns the z position (slice number) of a roi.

[coveralls]

Coverage increased (+0.1%) to 95.652% when pulling 4e5346b on tarokiritani:return_position into 73f1d43 on tdsmith:master.

[tdsmith]

Sorry for the delay and thank you for your interest in the project. I have a few concerns with this approach:

• Changing the return type of the function from an array to a tuple of arrays would break any existing code that relies on ijroi. I would prefer to avoid a breaking change.
• Please add tests that exercise this functionality, i.e. where the slice number is not zero.

Is it correct to think of the slice number as a z coordinate? Perhaps it makes sense to return a nx3 array if e.g. slice_number_as_z=True (perhaps there is a better name) is passed as a keyword argument.

[tarokiritani]

Thanks you for your reply, and I think you made a good point.

Yes, the slice number here is the z coordinate of the roi. It is true that my approach breaks the existing code. However, returning an nx3 array may not be the best approach because roi files contain coordinate information in 5d (xyz + time + color).

x and y positions are always used, but coordinates in the ztc space are not. I guess this is why xy and ztc coordinates are treated differently in the RoiDecoder.java. If I am not mistaken, ztc positions in a roi file are just stored as single numbers, whereas in xy, we have arrays.

I thought it might be more natural to return xy and z separately (and eventually t and c as well). Alternatively, we could return a nx3 (or nx5) array depending on the keyword args? What do you think?

I will work on the test soon.

[tdsmith]

If we extend it that way, an option might be to rename read_roi to e.g. read_roi_5d and write a read_roi wrapper function that maintains the current API.

I should maybe check to see if anyone is actually using this code before I sweat API breakage too much, though :)

[tdsmith]

x and y positions are always used, but coordinates in the ztc space are not. I guess this is why xy and ztc coordinates are treated differently in the RoiDecoder.java. If I am not mistaken, ztc positions in a roi file are just stored as single numbers, whereas in xy, we have arrays.

I thought it might be more natural to return xy and z separately (and eventually t and c as well).

Looking at RoiDecoder, I agree.