Resize and noise policies

[ducha-aiki]

Works only for cv::Mat stored databases.
@immars kindly rebased my branch to current master and added gaussian noise.
P.S. Travis is failing because of different OpenCV version, which does not have CLAHE function.
Adds different resize and noise policies to data_transformer like:

transform_param {
    crop_size: 227
    resize_param {
      prob: 0.5
      resize_mode: WARP
      height: 256
      width: 256
      interp_mode: LINEAR
    }
    resize_param {
      prob: 0.25
      resize_mode: BY_LARGE_SIZE
      height: 256
      width: 256
      interp_mode: AREA
    }
      resize_param {
      prob: 0.2
      resize_mode: BY_SMALL_SIZE_AND_PAD
      height: 256
      width: 256
      pad_mode: MIRRORED
      interp_mode: NEAREST
    }
      resize_param {
      prob: 0.05
      resize_mode: BY_SMALL_SIZE_AND_PAD
      height: 256
      width: 256
      pad_mode: CONSTANT
      pad_value: 104
      pad_value: 117
      pad_value: 124
      interp_mode: NEAREST
    }
    noise_param {
    prob: 0.6
    }
    noise_param {
    hist_eq: true
    prob: 0.2
    }  
    noise_param {
    decolorize: true
    gauss_blur: true
    prob: 0.2
    }  

[lukeyeager]

We've done something similar with DIGITS on the database creation side of things. I would love to see these options in caffe instead - nice work!

A few thoughts from our research:

1. Padding with REPEAT_NEAREST was terrible. The network learns to recognize those distinctive lines on the edge of the screen and it throws off the training. CONSTANT wasn't much better. We had better luck padding with random noise than anything else. By all means, leave REPEAT_NEAREST in there and let people try it for themselves, but I'd like to see RANDOM added as another option in the future.
2. Our go-to resize method is halfway in between your FIT_SMALL_SIZE (or "crop") and FIT_LARGE_SIZE_AND_PAD (or "fill") - something we call "half crop, half fill" (great name, I know). You might want to look into it.

Both of those are more suggestions than critiques. This looks like a step in the right direction!

FYI, here is what HALF_CROP with RANDOM noise looks like (resize code here):

[ducha-aiki]

Thanks for suggestions. From my experience, best padding is mirroring. Second - warping.
The third best was padding with mean pixel.

I like DIGITS, but resizing when creating dataset is too rigid compared to online data augmentation.

[lukeyeager]

resizing when creating dataset is too rigid compared to online data augmentation

Right, I agree. That's why I'm excited to see this going into caffe!

[ducha-aiki]

Have you tested mean or mirror padding?

[lukeyeager]

Have you tested mean or mirror padding?

I haven't. Mirror sounds promising. I'll check it out when I find some time.

[bhack]

/cc @mtamburrano

[bhack]

Just another PR is dying in natural drifting from master. Is this project alive?

[ducha-aiki]

@bhack more dead than alive. It is merged in my main branch elu https://github.com/ducha-aiki/caffe but separate headers haven`t merged yet there.

[bhack]

@lukeyeager is your team still interested?

[bhack]

@ducha-aiki It makes sense to rebase?

[ducha-aiki]

@bhack it is not question to me :) I can do rebase, but am not as patient as you with @mtamburrano ;)
so will rebase only if it is needed.

[ducha-aiki]

@bhack Actually, I agree with https://github.com/zer0n/deepframeworks/blob/master/README.md
caffe is nice as industry standard for deployment and fast training of standard models.

But not as suitable as before for experiments.

[bhack]

@ducha-aiki I'm not so patient ;) I've not contributed anymore until the MIA status of BVLC core devs will be clarified. Other frameworks are getting momentum so I think that there is more choice now. I'll try to use your fork directly instead of trying to rebase this.

[ducha-aiki]

@bhack if you give me a way to contact you, will notify when merge current master into my fork.
Btw, multiscale training is not always good, at least one I have tested :(
https://github.com/ducha-aiki/caffenet-benchmark/blob/master/Augmentation.md

[bhack]

Things like basic augmentation could be part of the industrial standard ;)

[bhack]

I think that Imagenet dataset is quite rich to cover scales. But in other cases, with a smaller dataset it could be useful.

[bhack]

@ducha-aiki Can be used with lmdb created with convert_imageset utility?

[ducha-aiki]

@bhack yes, but compressed (aka jpeg, png, etc ) only.

[lukeyeager]

@lukeyeager is your team still interested?

Yes. I think somebody around here implemented their own version of this, but it would be great to have it standard in BVLC/caffe.

[ducha-aiki]

@lukeyeager @bhack
rebased to current bvlc-master here https://github.com/ducha-aiki/caffe/tree/augmentations
not linted or wrote tests yet.

[ducha-aiki]

@shelhamer @ronghanghu
I have rebased this PR to current master in other branch and can write tests/expand/shrink number of features in augmentation branch, if caffe is interested in data augmentation.
If not, I will abandon this. Any feedback please?

[mtamburrano]

really useful PR, we already tested it and would be nice to see it merged on master.
Just my 2 cents

[TimZaman]

What a shame.. RIP PR