WIP: ILSVRC 2010 (a.k.a. ImageNet)

[dwf]

Putting this up so that the interested can have a look. In particular looking for some feedback from @vdumoulin, as well as @bartvm for the right place we could split this up in order to speed it up with multiple processes.

[vdumoulin]

Is ImageNet colloquial enough that we could use it as the name of the dataset without causing too much confusion?

[dwf]

Well, as test data for later year competitions become available, we'd like
to support evaluation on those too. There's also the 22k class "ImageNet
data release" version for which there is no standard train/valid/test set,
so...

My hope is that a lot of the same code will be applicable to other
"ImageNet-family" challenges, but we should probably name the class after
the official task.

On Thu, Apr 9, 2015 at 3:33 PM, vdumoulin notifications@github.com wrote:

Is ImageNet colloquial enough that we could use it as the name of the
dataset without causing too much confusion?

—
Reply to this email directly or view it on GitHub
#68 (comment).

[dwf]

@bartvm @vdumoulin I've got this converter into a near workable state now, and could use some eyes on it suggesting refactorings before I go and try to add unit tests.

I've adopted this kwargs-based approach to debug logging that I quite like, and think we could use a similar thing (or maybe a virtually identical thing) for passing information to a progress bar via logging calls.

[vdumoulin]

You should eventually think of moving the code to fuel.converters.ilsvrc2010.

In order to support kwargs in the converter itself, we should eventually refactor converter functions to use subparsers like downloader functions do. I can review that if you choose to make it part of your PR.

[vdumoulin]

Oh, nevermind, I just saw that this was already on your TODO list.

[dwf]

Yes, though I have a slight refactor I'll propose for the dispatched function, something like

from argparse import Namespace
from functools import wraps

def accept_namespace(func):
    @wraps(func)
    def wrapped(*args, **kwargs):
        if len(kwargs) == 0 and len(args) == 1 and isinstance(args[0], Namespace):
            return func(**vars(args[0]))
        else:
            return func(*args, **kwargs)
    return wrapped

That way you can write functions like this

@accepts_namespace
def foo(a, b, c):
    ...

and use it as a dispatch function for a subparser with matching argument names, while still having both a function that can be used programmatically without awkwardly instantiating a namespace and also can be documented more naturally.

[vdumoulin]

I like that idea!

[dwf]

@vdumoulin I've rewritten the history to put this file in fuel/converters/ (git filter-branch is neat). I also realized I hadn't included an entire file.

[vdumoulin]

Is it still useful?

[dwf]

Yep, I haven't pushed in a while but it is necessary for the valid and test
sets (yes, they distribute the ground truth for the valid and test sets
differently).
On Apr 20, 2015 1:39 PM, "vdumoulin" notifications@github.com wrote:

In fuel/converters/ilsvrc2010.py
#68 (comment):

•    The number of images the workers should send to the sink at a
  

•    time.
  
• """
• debug = make_debug_logging_function(log, 'MAIN')

• Read what's necessary from the development kit.

• devkit_path = os.path.join(directory, DEVKIT_ARCHIVE)
• synsets, cost_matrix, raw_valid_groundtruth = read_devkit(devkit_path)

• Mapping to take WordNet IDs to our internal 0-999 encoding.

• wnid_map = dict(zip((s.decode('utf8') for s in synsets['WNID']),

•                    xrange(1000)))
  

• Mapping to take ILSVRC2010 (integer) IDs to our internal 0-999 encoding.

• label_map = dict(zip(synsets['ILSVRC2010_ID'], xrange(1000)))

Is it still useful?

—
Reply to this email directly or view it on GitHub
https://github.com/bartvm/fuel/pull/68/files#r28710617.

[vdumoulin]

But it looks like you're building that later on (ilsvrc_id_to_zero_based, lines 123-124).

[dwf]

a69b35b.

[dwf]

@vdumoulin A very rough guide to ZeroMQ:

• A PUSH socket can have many PULLers, that's what's done with the ventilator/workers. Likewise, a PULL can have many PUSHers. This is what happens between workers and the sink.
• Atomicity is guaranteed, with a few caveats. That is to say, if you send a message on a zeromq socket, a client will get all of it or none of it. This also applies to sequences of messages where all-but-the-last message is sent with zmq.SNDMORE in the flags: this is used to tell zeromq that one or more further send calls are part of the same logical message, and should be received together. The only caveat I'm aware of is that if your process quits before all messages have been received, you may lose the last few messages; this is why I loop and sleep at the end of the ventilator function. (I'm not sure why this happens since zmq.LINGER should be infinite by default in my case...).
• The high water mark stuff is just to stop buffers accumulating ad infinitum.

[vdumoulin]

Should we use the sender.set_hwm setter instead?

[dwf]

hwm is a property which invokes set_hwm anyway, so no real difference.

[vdumoulin]

Good to know!

[vdumoulin]

@dwf I've gone through a superficial review of docstrings. I'm still reading the code to give it an in-depth review.

[vdumoulin]

Why do you need logger as argument when you immediately assign it here?

[dwf]

Good catch. 37e5f2b.

[dwf]

@vdumoulin I just pushed a pretty major update. Lots of new docstrings, and better factored.

[vdumoulin]

Add documentation for output_filename.

[dwf]

7f07f89

[vdumoulin]

@dwf and I did an offline test converting the ImageNet dataset, and it works! Coverage is down 1.2%, but considering the importance of this PR, I'm ready to merge right away.