RandAugment implementation differences.

[sebastian-sz]

I'm reading keras_cv RandAugment implementation and feel like there are some differences with TF implementation referenced in the paper. I'm still reading this layer so I might not have understood everything, but here it goes:

• Missing Posterization op in RandAugment - reference TF Implementation.
• Missing Sharpness op in RandAugment - this op is present as a Random Layer in keras-cv.
• Missing Rotate op in RandAugment - discussed also in #402 .
• Missing random magnitude negation in shear and translate ops - reference TF implementation randomly negates magnitudes for these ops, and it looks like it's also used in RandAugment.
• Different behaviour for Random* layers, e.g RandomBrightness is used instead of Brightness, but the function behaves differently in keras and differently in TF implementation. Perhaps this is marginal.

Are those differences intentional / are the missing operations not so important or should they be added in the future?

[bhack]

I don't know how many points was covered in private threads ~https://github.com/keras-team/keras-cv/issues/84~ https://github.com/keras-team/keras-cv/issues/169

[sebastian-sz]

@bhack If those differences were discussed and accepted maybe they could be described in the docstring.

For example: the Identity operation is also missing but it's mentioned that this is substituted by the rate parameter.

[bhack]

I've correctly updated the wrong mentioned ticket

[sebastian-sz]

I see, #169 is closed but there is no mention whether it was decided to ignore or include Posterize. I still believe that a docstring mention would be good to have for such cases.

Also I can't find information/discussion regarding presence of other ops: Sharpness & Rotate.

[bhack]

Yes, I think also that some underground information/choices could also be linked to this kind of arguments https://github.com/keras-team/keras-cv/pull/294#discussion_r848820525

[LukeWood]

I actually discussed this heavily with Ekin and am confident that our implementation is correct and that the others are actually NOT correct!

I can take an action item to discuss this in a "why KerasCV doc"; I am actively working with several original authors to verify our implementations of various components.

[sebastian-sz]

@LukeWood thank you for the answer.

I did not know about internal work or discussions and was simply worried that there are quite few differences between keras_cv and other existing implementations in various libraries. If they were discussed and even approved by original authors then it sounds solid to me.

[bhack]

I can take an action item to discuss this in a "why KerasCV doc"; I am actively working with several original authors to verify our implementations of various components.

Also if more correct and documented I suppose that it could be still a risk for the community until we will cover our "flavour" with a full reproducibility of the train protocol. As you know the devil is in details (and in other hyper-parameters :smile:) so we need to claim and document our reproducibility to trust the community.