Skip to content

Image type, fluorescence or RGB, in step 2 and the manifest (P4) - #28

Merged
IvanHCenalmor merged 1 commit into
mainfrom
claude/p4-image-type-648ec4
Oct 27, 2026
Merged

IvanHCenalmor merged 1 commit into
mainfrom
claude/p4-image-type-648ec4

Conversation

@IvanHCenalmor

Copy link
Copy Markdown
Contributor

Follow-up P4 of the normalization plan (docs/followup_preprocessing.md §P4 in morphobricks-normalization; its contract §5 and decision N34): the image type, fluorescence or RGB, suggested from the metadata, confirmed by the user and recorded in the run manifest. Plan §12 question 29.

Summary

  • metadata: TiffMetadata.rgb_samples, read from the header: True for a TIFF whose first series is photometric RGB with three samples per pixel (axis S). RGB with alpha, grey samples and OME-Zarr images are False.
  • image_type (new): FLUORESCENCE, RGB, check_image_type; review_image_type(metadata, review) gives the suggestion (RGB only when every analysed image is RGB colour with the confirmed C role on its samples axis, and RGB is possible), the reason, channels_from_rgb_samples, the channel count and why RGB is not possible (the normalization brick's check_rgb: three channels of an integer type); image_type_issues gives the error rgb_not_possible.
  • axes: channel_count is public (was _channel_count).
  • run: run_experiment(..., image_type=None) records the type; rgb for images that cannot be RGB is rgb_not_possible (nothing written); any other value raises ValueError. RunResult.image_type.
  • manifest: optional top-level keys image_type (null without one) and channels_from_rgb_samples; manifest version 1. Changing the type is not a rebuild reason, so nothing is recomputed.
  • cli: run --image-type fluorescence|rgb; without it the suggestion is used and printed with its reason and how to choose the other type (or why RGB is not possible). check prints the suggestion. run_summary names the type.
  • notebook_ui / notebook_style: step 2 gets an Image type card once the axis roles are confirmed: radio buttons with the suggestion preselected, a blue note with the reason (amber when the user picks the other type), and the yellow question with Yes, this is the right image type / Undo. When RGB is impossible the choice is disabled at Fluorescence with the reason (ipywidgets cannot disable a single radio option). Changing the axis roles or the folder resets it. Step 3's checklist gains "Confirm the image type (step 2)", "What will happen" names the type, and "What next?" asks for it. ConfirmToggle.confirmed_text is settable so the green message names the type. The card is the same when step 2 is embedded (question 26).
  • Notebook file: step 2 instructions, quick workflow and a common problem for the new button/message.
  • Docs: contract §8 (error), §9 (manifest keys), new §13 (image type); user guide §4–§9; README; plan §10 and §12 question 29; AGENTS.md.

Decisions

Asked of the owner before coding: the manifest key is channels_from_rgb_samples (next to image_type, both top-level and optional). Taken from the spec: never applied without confirmation; RGB needs three integer channels; manifest stays version 1; changing the type recomputes nothing. Taken here and recorded in question 29: run_experiment takes the type optionally (null in the manifest without one), like the experiment design; RGB is suggested only when every analysed image has RGB samples on the C axis.

Notes for review

  • plane_histograms.csv and experiment_design.csv are unchanged; no schema or manifest version change.
  • Mixed experiments (some RGB, some grey) are suggested fluorescence with the reason "not every image is stored as RGB colour on its channel axis"; RGB stays selectable if the images are three integer channels.
  • check_rgb's rule (any integer type) is used; its message says "8- or 16-bit", as does ours.
  • Widgets tested headless; step 2 rendered with embed_minimal_html and looked at in a browser (standalone renders lack JupyterLab styles and icons). Not looked at in a real JupyterLab.

Tests

  • Locally (Windows 11, Python 3.12, zarr 3.4.2, notebook and zarr extras): 965 passed, 2 skipped (the 2 skips are POSIX-only file-system tests); ruff check . and ruff format --check . clean; LF line endings.
  • New: tests/test_image_type.py (header flag, suggestion, RGB rule, run and manifest, reruns read nothing); CLI, manifest round-trip and notebook tests (suggestion preselected but not used until confirmed, RGB disabled with the reason, reset on role or folder change, embedded step 2 gating).
  • CI: GitHub Actions (lint; tests on Ubuntu, Windows, macOS with Python 3.11 and 3.13) — see the checks on this PR.

🤖 Generated with Claude Code

Step 2 asks for the image type once the axis roles are confirmed, with
RGB suggested for TIFF images stored as RGB colour on the channel axis
and confirmed with a yellow question; RGB needs three integer channels
(the normalization brick's check_rgb). The manifest records image_type
and channels_from_rgb_samples as optional keys (version 1); changing the
type recomputes nothing. The command line takes --image-type or prints
the suggestion. Plan question 29.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@IvanHCenalmor
IvanHCenalmor merged commit cc8d961 into main Oct 27, 2026
7 checks passed
@IvanHCenalmor
IvanHCenalmor deleted the claude/p4-image-type-648ec4 branch October 27, 2026 18:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant