📋 [TASK] Dataclass-based Input/Output in Anomalib

[samet-akcay]

Implement Dataclass-based Input/Output in Anomalib

Background

Currently, anomalib handles inputs and outputs using dictionaries. While functional, this approach has several drawbacks, including lack of type safety, potential for typos in key names, and reduced code readability. We propose transitioning to a dataclass-based solution to address these issues.

Proposed Change

Replace the current dictionary-based system with a hierarchy of dataclasses:

1. DatasetItem: Represents a single item in the dataset
2. Batch: Contains multiple DatasetItem objects
3. Dataset: Contains multiple Batch objects

Example Transformation

For example, current approach in a video dataset is as follow: Same will be applied to other modalities.

{
    "image": clip,
    "mask": self.get_mask(idx),
    "video_path": video_path,
    "frames": clip_pts,
    "last_frame": self.last_frame_idx(video_idx),
}

Proposed approach:

DatasetItem(
    image=clip,
    gt_mask=self.get_mask(idx),
    video_path=video_path,
    frames=clip_pts,
    last_frame=self.last_frame_idx(video_idx),
)

Benefits

1. Type Safety: Dataclasses provide built-in type hints, reducing runtime errors.
2. Code Readability: Explicit attribute names improve code comprehension.
3. IDE Support: Better autocomplete and refactoring capabilities.
4. Validation: Opportunity to add custom validation logic within dataclasses.
5. Extensibility: Easier to add methods or derived properties to data structures.

Implementation Steps

1. Define the dataclass structures (DatasetItem, Batch, Dataset).
2. Update dataset loading and processing functions to use these new structures.
3. Modify model input/output handling to work with the new dataclass objects.
4. Update documentation and examples to reflect the new approach.
5. Implement backward compatibility layer (if necessary) for existing code.

Potential Challenges

• Ensuring backward compatibility with existing code and APIs
• Performance considerations (if any) when switching from dictionaries to dataclasses
• Updating all relevant parts of the codebase to use the new structures

Discussion Points

• Should we include any additional fields in the dataclasses?
• Do we need to implement custom __post_init__ methods for validation?
• How should we handle optional fields?

Next Steps

• Create detailed technical design document
• Implement proof-of-concept in a separate branch
• Discuss potential impacts on existing features and integrations
• Plan for gradual rollout and testing strategy

[samet-akcay]

PR Link: #2098