Improve and polish pycaffe

[shelhamer]

• fix input preprocessing configuration in picking up on Small improvements to pycaffe #733
• add console output with human-readable labels and a grayscale flag to classify.py courtesy of @petewarden's Add MNIST support to classify.py script #735 to be continued...
• fix Mean and scaling, C++ Caffe vs Python wrapper #525 by scaling data to [0, 255] according to Net.raw_scale, doing mean subtraction, and then input scaling
• make mean argument an array instead of a file path for flexibility
• update examples' outputs given correct preprocessing, always include caffe pythonpath, and reword classification + time on a gtx 770

[shelhamer]

@longjon please take a look. In 3cac223 I added the preprocessing option dicts as members on the C++ side–let me know what you think.

[shelhamer]

Let's not merge until sorting out #525 and we should probably address #613 too. @longjon if you have a chance to help, just push to my fork to update the PR.

[shelhamer]

@longjon a97a41b settles #525:

• pycaffe represents images as single in [0, 255]
• input feature scaling is done after mean subtraction
• image resizing behaves (with special cases for performance)
  • images (RGB or intensity) are resized by normalizing / denormalizing to the whims of skimage.transform.resize
  • general K channel images are resized by scipy.ndimage.zoom

[shelhamer]

I want to break the interface by changing Net.set_mean to take an array instead of a filename because that was a limiting mistake. @longjon thoughts?

[longjon]

Yes please. That interface in particular seems okay to break because it should go away when we finally have unified input preprocessing.

(I'll have a closer look at the rest of this soon.)

[shelhamer]

@longjon please review and merge. Further input preprocessing optimization can be a follow-up. I'd like to have the preprocessing fix in and release the fix to master soon since it's not the nicest bug.

[shelhamer]

Note the build is fine -- Travis just times out downloading CUDA.

[longjon]

Not sure what dtype=np.float32 is doing here... won't it just be promoted to float64 anyway? E.g.,

$ ipython --no-banner

In [1]: import numpy as np

In [2]: (np.array(5) / np.array(4, dtype=np.float32)).dtype
Out[2]: dtype('float64')

[shelhamer]

Right. This doesn't belong and I'll drop it.

On Monday, August 4, 2014, longjon notifications@github.com wrote:

In python/caffe/io.py:

@@ -40,7 +43,18 @@ def resize_image(im, new_dims, interp_order=1):
Give
im: resized ndarray with shape (new_dims[0], new_dims[1], K)
"""

• return skimage.transform.resize(im, new_dims, order=interp_order)
• if im.shape[-1] == 1 or im.shape[-1] == 3:

•    # skimage is fast but only understands {1,3} channel images in [0, 1].
  

•    im_min, im_max = im.min(), im.max()
  

•    im_std = (im - im_min) / (im_max - im_min)
  

•    resized_std = resize(im_std, new_dims, order=interp_order)
  

•    resized_im = resized_std \* (im_max - im_min) + im_min
  

• else:

•    # ndimage interpolates anything but more slowly.
  

•    scale = tuple(np.array(new_dims)
  

•                  / np.array(im.shape[:2], dtype=np.float32))
  

Not sure what dtype=np.float32 is doing here... won't it just be promoted
to float64 anyway? E.g.,

$ ipython --no-banner
In [1]: import numpy as np
In [2]: (np.array(5) / np.array(4, dtype=np.float32)).dtypeOut[2]: dtype('float64')

—
Reply to this email directly or view it on GitHub
https://github.com/BVLC/caffe/pull/816/files#r15795016.

[longjon]

Looks good except as noted. There were a couple kinda awkward things I noticed that existed before this PR:

• some might consider set_* functions unpythonic, since Python has properties and direct access is always overridable
• the mean wrangling in Detector.configure_crop duplicates Net.deprocess

In addition, I'm not totally sure why we have mnist_words.txt, since it's basically the identity. I suppose it does serve as a simple example, so that's fine.

These things said, I'm happy to merge any PR that is a strict improvement, and I'd rather merge something incremental sooner than make everything just right eventually.

[shelhamer]

Rebased to address comments and hold off on integrating @petewarden's changes -- they will be included in a follow-up once this fix is in.

@longjon please take a last look and merge.

[longjon]

Should raw scale be noted here?