Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

AI-generated: macsima() uses the OME plane positions as pixel padding widths, truncated

Đang mở
  • Có gì không ổn?
#419 1 bình luận 0 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
45/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
python
Lĩnh vực
data

Hướng nghiên cứu

Bắt đầu trong src/spatialdata_io/readers/macsima.py tại _get_translations(), sau đó đọc MultiChannelImage._pad_images() và test_get_translations_returns_correct_values; xem lại readers/_utils/_utils.py để kiểm tra tra cứu kích thước vật lý hiện có. Xác nhận với các maintainer hoặc từ dữ liệu MACSima thực tế xem vị trí của các mặt phẳng là độ lệch theo pixel hay độ dài vật lý, sau đó thêm một kiểm thử hồi quy hoặc kiểm thử dựa trên dữ liệu bao quát cách diễn giải đã chọn và hành vi padding được làm tròn.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

[!NOTE]
AI-generated issue, opened from #418 and not verified against real MACSima data. The
code pointers are accurate; the question at the end needs someone who knows what the
MACSima software writes into these fields.

What the code does

_get_translations() reads the position of the first plane of the OME metadata and turns it
into an integer — src/spatialdata_io/readers/macsima.py:

translations = {"translation_x": int(position_x), "translation_y": int(position_y)}

The values end up on ChannelMetadata.translation_x / translation_y and are consumed by
MultiChannelImage._pad_images(), which normalises them against their minimum and uses the
result directly as da.pad widths, i.e. as a number of pixels:

normalized_translations_x = [metadata.translation_x - min_translation_x for metadata in channel_metadata]
...
pad_width = ((0, 0), (pad_y_prepend, pad_y_append), (pad_x_prepend, pad_x_append))
img = da.pad(img, pad_width, mode="constant", constant_values=0)
Two things look off

1. int() truncates towards zero instead of rounding. int(0.9) == 0 and
int(-0.9) == 0, so a plane at x = 10.7 is placed at 10 and the direction of the error
depends on the sign of the position. After the normalisation against the minimum the residual
is below one pixel per channel, so this alone is minor — round() would halve the worst case
and make it sign-symmetric.

2. The positions are physical coordinates, but they are used as pixel counts. In OME,
Plane.position_x comes with a Plane.position_x_unit, and Pixels.physical_size_x gives the
size of a pixel in the same kind of unit (17.0 µm in the OMAP test data). Nothing in the
reader converts between the two, so if a MACSima file writes stage positions in micrometres the
padding is off by the pixel size — a factor of 17 for these datasets — rather than by a fraction
of a pixel. If instead the software writes pixel offsets there (position_x_unit is
REFERENCEFRAME, the OME default, i.e. unspecified, in the files I looked at), the current code
is right and only point 1 applies.

Both small test datasets (OMAP10_small, OMAP23_small) have position_x = None on every
plane, so _get_translations() returns (0, 0) there and this path is exercised by unit tests
only, never by the data-based ones.

What a fix would entail

Depending on the answer to "what unit does MACSima write":

  • if the positions are already in pixels: replace int(...) with round(...) in
    _get_translations() and extend test_get_translations_returns_correct_values with a
    fractional case (e.g. position_x=10.7, position_y=0.9 → {"translation_x": 11, "translation_y": 1});
  • if they are physical lengths: read position_x_unit / position_y_unit and
    Pixels.physical_size_x / physical_size_y alongside the positions, convert to pixels
    (ome_types exposes the unit enums; parse_physical_size() in
    readers/_utils/_utils.py already does this kind of lookup for the physical size), and round
    at the end. _get_translations() currently only receives the OME object, which is enough for
    both. ChannelMetadata.translation_x stays an int, so _pad_images() is unaffected.
  • either way, it would be good to have a data-based test: none of the datasets currently in CI
    has plane positions, so this would need either a file with real positions or a synthetic TIFF
    written with tifffile.imwrite(..., metadata={...}) in the style of
    test_images_with_invalid_ome_metadata_are_excluded.
Context

#418 originally rounded the positions as part of fixing the regressions from #411, but that
changes reader output on a point nobody has confirmed, so it was pulled out of the PR and filed
here instead. The current behaviour on main is unchanged: truncation.

Ngôn ngữ chính
Python
Star
103
Fork
65
Merge trung bình
1 giờ 8 phút
Pull request đã merge (30 ngày)
3

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của scverse/spatialdata-io

Tất cả issue của scverse/spatialdata-io

Issue tương tự

Thêm issue về Python

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.