[Sad Catapella B7][Type validation] RGB check accepts int32/int64 inputs despite stating 8- or 16-bit only #23

Scope

Normalization v0.3.2 (f784c95e3049483f87466150ffc5764375fa631d) as consumed by preprocessing Batch 7 (d7a538e56d41ac1093ba79adcad397c21b3dfd32). Confirmed code-vs-error-message/test-policy inconsistency, scientific consequences for high dynamic ranges need testing.

Evidence

• check_rgb, lines 77–100 validates any integer subtype via np.issubdtype(..., np.integer), then accepts three-channel int32, uint32, int64, uint64 images, while its docstring/error explicitly says RGB needs 8- or 16-bit color channels.
• Contract §9.1 repeats the 8-/16-bit message, but RGB tests only test uint8/uint16 successes and floating failures. Preprocessing _rgb_problem delegates to check_rgb, permitting type rgb for three-channel 32-/64-bit TIFF or NGFF data; preprocessing contract §13 instead says an integer pixel type, so documentation differs across bricks.
• apply_rgb converts input to float32, potentially losing representable distinctions for 32-/64-bit integers; whether that is acceptable is a decision, not demonstrated corruption.

Fix / acceptance

Choose one contract consistently: (A) RGB restricted to 8/16-bit integer (possibly decide signed behavior) with early refusal and precise messages in both bricks, or (B) explicitly support 32/64-bit integer RGB, revise docs/messages and test precision/equivalence against the intended CSBDeep semantics, including values >2^24 and >2^53. Add parameterized direct check_rgb, preflight/type review, run and application tests. Never silently downcast without a documented numerical policy. Numba is not a fix. No tests executed.