[Feature]: Explicitly scope image I/O (`K.io.read_image`, `decode_image`, `write_image`) as Python-only

🚀 Feature Description

This feature proposes explicitly documenting and enforcing that the image I/O helpers K.io.read_image, K.io.decode_image, and K.io.write_image remain Python-only APIs within kornia-py, and are intentionally not part of the Rust public API surface in kornia-rs.

This clarification follows up on discussions during the merge of PR #610 (Refactor: organize kornia-py submodules).

📂 Feature Category

Python Bindings (kornia-py)

💡 Motivation

During PR #610, which reorganized the kornia-py module structure, maintainers highlighted that:

• Image I/O utilities (read_image, decode_image, write_image) are Python-facing conveniences
• These functions rely heavily on Python ecosystem expectations (NumPy, file paths, bytes, decoding ergonomics)
• They should not be treated as core Rust-first APIs or expanded further in kornia-rs

However, this decision currently exists only implicitly in review discussion and code structure.

This issue formalizes that decision to:

• Make project boundaries explicit
• Avoid accidental Rust-side expansion of image I/O
• Guide future contributors reviewing or proposing I/O-related changes

Related PR:

• Refactor: organize kornia-py submodules #610

💭 Proposed Solution

1. Explicitly document that:

   • K.io.read_image
   • K.io.decode_image
   • K.io.write_image are Python-only utilities provided by kornia-py.

2. Clarify in documentation and/or code comments that:

   • These functions are not intended to be part of the Rust public API

   • kornia-rs should focus on:

     • Image processing kernels
     • Computer vision primitives
     • Performance-critical components

No new functionality is introduced; this is a design and scope clarification.

📚 Library Reference

• Kornia (Python): kornia.io
• PyTorch image I/O patterns
• OpenCV: separation between imgcodecs (I/O) and core processing modules

These ecosystems commonly keep file I/O at higher-level language boundaries.

🔄 Alternatives Considered

No response

🎯 Use Cases

No response

📝 Additional Context

No response

🤝 Contribution Intent

• I plan to submit a PR to implement this feature
• I'm requesting this feature but not planning to implement it