Pixel conventions

[dschodt]

Some core pieces of smite are using the pixel convention that the center of a pixel is coordinate 0.5. As in, if we have a one pixel image, the left edge is coordinate 0 and the right edge is coordinate 1. We had previously discussed using the convention that the center of a pixel is the index (i.e., left edge is coordinate 0.5 and right edge is coordinate 1.5). Do we still plan to make this switch? If so, what needs to be changed?

From what I've seen, changes will be needed in:

• smi_core.GaussMLE
• smi_sim.GaussBlobs
• smi_sim.SimSPT (and maybe smi_sim.SimSMLM)
• smi.SPT (for density calculations)
• perhaps several smi_vis classes (e.g., GenerateMovies)

[kalidke]

Do SimSPT and SPT use GaussBlobs or their own generators? Everything should use gaussblobs.

[dschodt]

SimSPT only generates trajectories, but the trajectories get restricted to the frame size using the pixel convention (i.e., a frame size of 1 pixel restricts trajectory coordinates to [0, 1] instead of [0.5, 1.5]). SimSMLM seems to work the same way.

smi.SPT (and several other classes) use the pixel convention to convert from localization coordinates to image indices.

[kalidke]

Status: Design Discussion - Needs Decision

This issue raises a fundamental design question about coordinate conventions throughout smite.

Current Convention (mostly):

• Pixel center at index value (e.g., pixel center at 1.0, 2.0, etc.)
• For 1-pixel image: left edge = 0.5, right edge = 1.5
• Documented in CLAUDE.md: "Coordinate (1,1) = center of top-left pixel"

Alternative Convention (proposed):

• Pixel center at 0.5 offset from index (e.g., pixel center at 0.5, 1.5, etc.)
• For 1-pixel image: left edge = 0, right edge = 1

Areas Affected (from original issue):

• smi_core.GaussMLE
• smi_sim.GaussBlobs
• smi_sim.SimSPT / SimSMLM
• smi.SPT (density calculations)
• smi_vis classes (GenerateMovies, etc.)

Related Issues:

• FindROI.plotBox tends to display boxes with the localization at the NW corner #11 (plotBox display offset) is a manifestation of coordinate convention confusion with imshow

Recommendation:
This requires a design decision from maintainers:

1. Keep current convention (document more clearly)
2. Change to alternative convention (requires extensive refactoring and validation)

Either way, the convention should be consistently applied and clearly documented. The current state has inconsistencies that cause confusion.

Related to: #11 (visualization coordinate mismatch)