Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Normalize path for Image #54

Closed
wants to merge 2 commits into from
Closed

Conversation

darsnack
Copy link
Member

@darsnack darsnack commented Oct 5, 2021

This adds a dispatch so that Normalize can be used on an Image (i.e. colorant array). Useful when you need to normalize data then apply augmentations on top of that without converting back and forth.

test/preprocessing.jl Outdated Show resolved Hide resolved
@lorenzoh
Copy link
Member

lorenzoh commented Oct 6, 2021

Hey Kyle, thanks for the addition!

Did you test this for colors that are not stored as Float32? I think there could be some issues with clamping. Also, the normalization stats will probably be floats, so maybe it's best to restrict the argument of the item to Image{N, <:Colorant{<:AbstractFloat}} (or something similar) and require an explicit element type conversion with ToEltype.

Out of curiosity, what is your use case for this?

@darsnack
Copy link
Member Author

darsnack commented Oct 8, 2021

I see what you mean about the clipping. The main use case here is when you want to normalize your images, but the augmentations don't compose with the normalization placed at the end of the pipeline. For example, I am doing zero padding before a random crop. If I normalize after the padding, then the pixels will no longer be zero. So either the normalization needs to understand Image or the other augmentations need to understand ArrayItem.

@darsnack
Copy link
Member Author

darsnack commented Oct 8, 2021

Okay thinking about this more, I don't think the goal of the PR makes any sense. Even floating point backed colors don't make sense as negative values even if the library implementation doesn't auto-clip things.

I guess in the case where the normalization statistics are provided pre-augmentation, then having variations of RandomCrop, Flip, etc. that accepts a dims argument and applies to ArrayItems would be the appropriate solution.

@darsnack darsnack closed this Oct 8, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants