`SnapshotTool`: “Original size” option produces incorrect values and raises errors with reversed axes and `XYImageItem`

[LucienLehmann]

Describe the bug

The "Original size" option in the rectangular snapshot tool does not behave correctly under certain conditions:

• When the Y axis is not reversed
• When the X axis is reversed
• When using an XYImageItem

In these cases, the "Original size" preview may display negative values or incorrect dimensions. The computation appears to rely on axis scaling rather than pixel coordinates, particularly for XYImageItem.

Additionally, a ValueError is raised when either axis leads to negative values.

---

To Reproduce

Steps to reproduce the behavior:

1. Create a PlotDialog with a toolbar (toolbar=True)
2. Add an image of type ImageItem or XYImageItem (make.image)
3. Reverse one of the axes (via right-click)
4. Select the rectangular snapshot tool
5. Select a region of the image
6. Enable "Original size"

---

Expected behavior

The rectangular snapshot tool should compute the "Original size" using pixel coordinates, independent of axis orientation or scaling.

[PierreRaybaut]

Thanks @LucienLehmann for reporting this issue.

This has been fixed in the release branch. If you have the opportunity to test it, please do not hesitate to report back any additional issue.

For a quick "drop-in" test without checking out the branch, two files were patched:

• plotpy/items/image/misc.py — the "Original size" is now computed from pixel coordinates (via a new compute_image_items_original_size() helper) instead of axis units, and compute_trimageitems_original_size() is hardened against negative source sizes coming from reversed axes.
• plotpy/tools/misc.py — save_snapshot() uses the new helper and computes new_size from abs(p1 - p0) so the resize dialog no longer raises ValueError on reversed axes.

You can simply overwrite these two files in your local installation (under site-packages/plotpy/...) with the versions from the release branch to test the fix on your setup. Don't forget to restart your application afterwards.

[LucienLehmann]

Thanks @PierreRaybaut for the very quick response.

I’ve noticed a couple of minor issues:

• Cursor behavior: after using the tool, the cursor does not fully return to its normal state. It behaves correctly over the plot area, but is stuck in a cross shape (+) when hovering over the axes and the toolbar.

• Inconsistent behavior when selecting a region larger than the plotted image:

  • For XYImageItem, the "Original size" always corresponds to the full image minus one (e.g. 99×99 for a 100×100 image), regardless of the selection.
  • For ImageItem, the "Original size" depends on the selected region (e.g. 214×184 for a 100×100 image).

  In both cases, the exported image is padded with zeros. The case for ImageItem is more correct, but I’m not sure whether this is the intended behavior. It might be preferable to crop the selection to the actual image bounds, which would also make it easier to crop along the edges or at the corners of an image.

[PierreRaybaut]

Thanks @LucienLehmann for the feedback !

I've pushed a follow-up fix on the release branch addressing the second point:

Inconsistent "Original size" when the selection is larger than the image

The selection is now clipped to the image's bounding rectangle (in plot coordinates) before the original size is computed. For both ImageItem and XYImageItem, selecting a region that fully encloses a 100×100 image now consistently reports 100×100 (no more 99×99 off-by-one for XYImageItem, and no more oversized values for ImageItem). As you noted, this also makes snapping to edges/corners of the image much more intuitive. The export itself will still need to pad with zeros if the selection actually extends beyond the image - that's a separate behavior which I'd rather not change in a patch release, but feel free to open a dedicated issue if you'd prefer the exported image to be cropped instead.

Cursor stuck on axes and toolbar

I have been able to reproduce this one but no quick fix at this point (we'll investigate later).

[LucienLehmann]

Thanks again @PierreRaybaut for the very quick response.

My interpretation of "Original size" is "Original resolution", therefore, the oversized values for ImageItem appear correct to prevent resampling of the selection. However, I might be overinterpreting a very straightforward option name.

[PierreRaybaut]

Hey @LucienLehmann, thanks for pushing back on this: you're absolutely right, and on reflection your interpretation is the correct one. The whole point of "Original size" in the snapshot tool is to export at the image's native pixel resolution, so when the selection extends beyond the image the returned size must be larger than the image.

So my previous "consistency fix" actually regressed the useful behavior of ImageItem. I've just pushed a follow-up on release that reverts the clipping and instead aligns XYImageItem on ImageItem's historical semantics: both items now return the same native pixel resolution for a given selection, including when the selection overflows the image. The bugs from your initial report (negative dimensions on reversed axes and the wrong-units result for XYImageItem) of course remain fixed.

[PierreRaybaut]

Quick follow-up: the cursor issue you reported (cross cursor remaining stuck on the axes and toolbar after using the snapshot tool) is now fixed as well, in a separate dedicated issue (#58).