CropModel enforces ImageNet norm weights

[bw4sz]

As part of #1313 we are expanding how users can add CropModels, there is no reason that the weights have to follow ImageNet normalization.

Allow custom image normalization in CropModel

Problem

bounding_box_transform() in src/deepforest/datasets/cropmodel.py hardcodes ImageNet normalization, making it impossible for users to supply models pretrained with different normalization stats.

# Line 32 - no way to override this
data_transforms.append(resnet_normalize)

A user passing a custom model via CropModel(model=my_model) that expects different preprocessing will get silently wrong results.

Proposed Fix

Add an optional normalize parameter to bounding_box_transform and thread it through from the CropModel config:

def bounding_box_transform(augmentations=None, resize=None, normalize=None):
    if resize is None:
        resize = [224, 224]
    if normalize is None:
        normalize = resnet_normalize

    data_transforms = []
    data_transforms.append(transforms.ToTensor())
    data_transforms.append(normalize)
    data_transforms.append(transforms.Resize(resize))
    if augmentations:
        data_transforms.append(transforms.RandomHorizontalFlip(0.5))
    return transforms.Compose(data_transforms)

Users could then pass custom normalization via config:

cropmodel:
    normalize:
        mean: [0.5, 0.5, 0.5]
        std: [0.5, 0.5, 0.5]

Or normalize: false to disable it entirely.

[musaqlain]

am interested and looking into this issue

[vickysharma-prog]

Hi @bw4sz,

I'd like to work on this. Here's my approach:

Changes to bounding_box_transform() in cropmodel.py:

• Add optional normalize parameter (default: resnet_normalize for backward compatibility)
• Support normalize=False to skip normalization entirely
• Support custom transforms.Normalize() objects

Config integration:

• Thread normalize through the CropModel config in model.py via get_transform()
• Accept dict with mean/std keys, None for default ImageNet, or false to disable

Backward compatibility:

• Existing configs with no normalize key will continue using ImageNet defaults
• No breaking changes to current API

Tests:

• Default (ImageNet) normalization
• Custom normalization values
• normalize=False (disabled)

Also, should this target #1313 or main? Happy to coordinate since the CropModel expansion is already in progress there.

Happy to submit a PR once you clarify which branch to target.

[musaqlain]

Hi @bw4sz, I'd like to work on this! Should this be based on top of #1313 or against main? moreover, I have explored last year project NeonTreeClassification for quite some time, and I understand it very well,

here is high level approach to my proposed solution:

1. Add a NormalizeConfig dataclass in schema.py (defaults to ImageNet, null to disable)
2. Thread it through bounding_box_transform() in datasets/cropmodel.py
3. Update CropModel.normalize() and get_transform() in model.py to read from config

All backward-compatible — existing configs keep ImageNet defaults. Happy to submit a PR once I know which branch to target.

[abhayrajjais01]

hi @bw4sz,
i would like to work on it.
here what i will do-

1. Add config fields to CropModelConfig in schema.py:

   • normalize: bool = True (set false to disable)
   • normalize_mean: list[float] = [0.485, 0.456, 0.406]
   • normalize_std: list[float] = [0.229, 0.224, 0.225]

2. Update CropModel.normalize() in model.py to read from self.config["cropmodel"] instead of hardcoding values. Return identity transform when normalize: false.

3. Update bounding_box_transform() in cropmodel.py to accept an optional normalize parameter, so the prediction/inference path also respects the config.

4. Thread the config through BoundingBoxDataset so it forwards normalize settings when no custom transform is provided.

5. Update config.yaml with the new fields and documentation.

defaults match current ImageNet values, so this is fully backward compatible if this alligns with your thought i will submit a PR for this.

[henrykironde]

Since @musaqlain requested it first, it’s fair to give him the chance to submit a fix. That said, the goal is for everyone to learn through open-source collaboration, so others can still try their own versions. You don’t need to open a PR—just add a commit referencing #1347 to the branch and we can review it later, or wait and comment on the first PR with suggestions or alternatives.