Check that all `maybe_process_in_chunks` are needed

[ternaus]

Motivation

Many AlbumentationsX image transforms rely on the maybe_process_in_chunks wrapper to overcome historical OpenCV limitations related to the number of supported channels.

Example:

@preserve_channel_dim
def box_blur(img: ImageType, ksize: int) -> ImageType:
    blur_fn = maybe_process_in_chunks(cv2.blur, ksize=(ksize, ksize))
    return blur_fn(img)

The wrapper checks the number of channels and applies the OpenCV function channel-by-channel when needed, then recombines the result. This was originally required because many OpenCV functions only supported a small, fixed number of channels (e.g. ≤4).

However, recent OpenCV versions may support a larger number of channels for some operations, which raises the question:

Are all current uses of maybe_process_in_chunks still justified?

If the wrapper is no longer needed in some cases, removing it could simplify code paths and improve performance by avoiding Python-level loops.

---

Goal

Audit all usages of maybe_process_in_chunks in AlbumentationsX and determine whether they are still necessary given current OpenCV behavior.

This issue focuses on verification, not removal by default.

---

What needs to be done

For each transform using maybe_process_in_chunks:

1. Identify the underlying OpenCV function (e.g. cv2.blur, cv2.GaussianBlur, etc.).

2. Test the function without maybe_process_in_chunks for:

   • different numbers of channels (e.g. 1, 3, 4, 8, 16, 32)
   • different OpenCV versions (document which version is used)

3. Check:

   • correctness (no errors, correct output shape)
   • numerical equivalence vs. chunked version

4. Document findings:

   • whether the wrapper is still required
   • from which channel count / OpenCV version it becomes unnecessary

5. If safe, propose removal or conditional bypass of the wrapper, with justification.

---

Acceptance criteria

• Clear, documented evidence for each audited transform
• No behavior regressions for multi-channel images
• No silent changes based on assumptions
• Benchmarks or minimal repro scripts are a plus

---

Notes

• The default stance is conservative: if behavior is unclear or version-dependent, keep the wrapper.
• This is intentionally scoped as an investigation task and is suitable as a first contribution.
• Please include links to OpenCV docs, issues, or PRs if relevant.

---

Why this matters

This is a classic example of technical debt caused by upstream constraints.
As upstream libraries evolve, periodically re-validating these workarounds helps keep AlbumentationsX:

• simpler,
• faster,
• and easier to reason about.

Thanks for digging into this 🙌