Evizero / Augmentor.jl

A fast image augmentation library in Julia for machine learning.
https://evizero.github.io/Augmentor.jl/
Other
137 stars 48 forks source link

Support segmentation masks #87

Closed barucden closed 2 years ago

barucden commented 2 years ago

This PR introduces support for segmentation masks. The key principle is that we do not apply some operations on segmentation masks.

That being said, the implementation is not finished yet, and I would like to kindly ask for assistance. I am not sure how to implement the "operation skipping", or perhaps where to implement it. I am thinking maybe operation.jl#L57 and operation.jl#L60 so it would result in

for FUN in (:applyeager, :applylazy, :applypermute,
            :applyaffine, :applyaffineview,
            :applyaffine_common, :applyaffineview_common,
            :applyview, :applystepview)
    @eval begin
        function ($FUN)(op::Operation, imgs::Tuple)
            param = randparam(op, imgs)
            #map(img -> ($FUN)(op, img, param), imgs)
            map(img -> shouldapply(op, img) ? ($FUN)(op, img, param) : img, imgs)
        end
        @inline function ($FUN)(op::Operation, img::AbstractArray)
            #($FUN)(op, img, randparam(op, img))
            shouldapply(op, img) ? ($FUN)(op, img, randparam(op, img)) : img
        end
    end
end

But I am not convinced.

TODO:

Closes #85

johnnychen94 commented 2 years ago

To not break your dev workflow, I made a PR to https://github.com/barucden/Augmentor.jl/pull/1, you can review and merge if that looks good to you.

Ideally, we could do this in src/codegen.jl, but that's more difficult to handle. I'm not an expert in metaprogramming neither.

barucden commented 2 years ago

I had to explicitly define the type of img for all augment methods to remove ambiguities. I hope it's fine.

johnnychen94 commented 2 years ago

Looking good to me!

Fighting with method ambiguity isn't a very interesting journey, do you think we need to introduce some new function e.g., semantic_augment for this and all future extensions? This might make it more clear that augment is more faithful, and semantic_augment as an extension to augment allows more interpretations. The "semantic" in semantic_augment is not preserved for semantic segmentation, of course.

barucden commented 2 years ago

do you think we need to introduce some new function e.g., semantic_augment for this and all future extensions?

I am not sure. I can imagine that the ambiguity is an issue if more conventions (like the pair notation) are introduced. But do you think there will be more? As of now, I think it is manageable.

barucden commented 2 years ago

There was also an issue with Either. This "meta" operation needs a special treatment.

Evizero commented 2 years ago

done. welcome!

johnnychen94 commented 2 years ago

@barucden merge when you're ready.

barucden commented 2 years ago

@Evizero thank you for the invitation!

@johnnychen94 I am thinking I should add one more test to check all the remaining operations cooperate with semantic wrappers. Then I think it is safe to merge.

maxfreu commented 2 years ago

One last API thing: I think it is worthwhile to implement an augment version for named tuples, while you're at it. That would be super clear for users and I think also extensible. But either way, I'm already super happy with the current implementation - thanks for the effort!

barucden commented 2 years ago

Since we only support masks now, would this API bring something "new"? Seems like a more verbose version to the pair version:

augment(img => mask, pl) # can do now
augment((image=img, mask=mask), pl) # named tuple version

I can see it being useful once we support more targets (besides masks), so maybe we should decide the API when we implement additional targets?

johnnychen94 commented 2 years ago

Agreed. Adding support for NamedTuple can be considered when there is a new application that this PR doesn't cover. By then it can be easier to provide a justified API.

maxfreu commented 2 years ago

Thanks again mate! It‘s just a small PR, but a big step for julia adoption in my work :)

barucden commented 2 years ago

Glad to hear! Give it a try. It certainly needs some "battle testing" :)

johnnychen94 commented 2 years ago

@barucden in most cases, we follow the continuous release strategy. So I've made a patch release https://github.com/Evizero/Augmentor.jl/commit/ad9a3984921b51c36bb73a75fdba3097a70041f9

https://www.oxinabox.net/2019/09/28/Continuous-Delivery-For-Julia-Packages.html

barucden commented 2 years ago

Oh, okay, got it! Thanks