Page MenuHomePhabricator

Meeting 9 - Fri 24 June 2016 - 12:30 UTC
Closed, ResolvedPublic

Description

Date: 24 June 2016
Time: 12:30 UTC
Type: IRC (channel #gsoc-catimages)

Description: 9th meeting (Week 5) to discuss the Midterm Evaluation and Measurable outcomes as well as the last 50% of the Project Plan accordingly

Agenda:

  • Midterm Evaluation, let's check on the Outcomes/Measurables
    • faces: haarcascade, generally
  • Consensus on plan and timeline (MVP is now!)
    • Project Plan, second 50%
      • ? learning? how time consuming? (not to spend too much time on something that we cannot finish - though a actually should be quite easy to have a first theoretically working script)
      • ? train the bot with images of persons we now in advance that they will appear in a dataset (e.g. generals or politicians during wars, etc.)
      • ? train the bot on the dataset itself at least after humans have gone over it
      • ? Docker
      • ? have 2 different bot run modes:
        • auto: be conservative - no false-positive not to annoy commons users with unreliable bot work (and give the maintainer a lot of work to fix stuff)
        • user-maintained: be more experimental - show ALL possible results (no matter how significant) and the user decides which ones are valid
      • ? brings me to the idea T138119: Use user-maintained bot run mode to gain stats and learn
    • Outcomes/Measurables to be finished (and redefined)
    • Milestones
  • News regarding beta-tests
  • video copyright project (jayvdb)
    • Brief status report (jayvdb)
    • we have to think about integrating it into this project (cross-language python and .NET)
    • after the MVP we will start to work together (hacking session, mettings/communication, etc.)

Minutes of the Meeting:

  • Midterm Evaluation, Outcomes/Measurables:
    • Have a pypi package "pypi-catimages" which can perform a minimal set of the functions that catimages.py could: in progress https://gist.github.com/AbdealiJK/a94fc0d0445c2ad715d9b1b95ec2ba03
    • Detect faces using haarcascades and landmarks (need to output positions of eyes, mouth etc. were possible)
    • Categorize based on metadata: in progress, needs to output categorization hints to console
    • Barcode and QR Code detection using zbar and zxing
    • Graphics detection code of catimages implemented and improved but not tested on a mixed/random set yet
  • Consensus on plan and timeline (MVP is now!)
    • need @jayvdb to decide finally
    • @AbdealiJK proposes T138121#2395622 and T138121#2403802 which look reasonable despite some pitfals (e.g. 2 and 4): we have to take care not to spend too much time on minor things
    • for next week
      • Graphic detection on random set
      • Do analysis for the ETH Zurich library images
      • Make dlib wheel
      • Figure out a better way to handle dependencies
      • Make a CLI script which is the official bot script
      • Handle EXIF face data
    • we should not forget the setup/install procedure for experimental/development version using Docker - other proposals are welcome too, but we should avoid spending too much time here now since may be we have to sort that out in another seperate project (proper implementation of externals as vendor package management)
    • have 2 different bot run modes:
      • auto: be conservative - no false-positive not to annoy commons users with unreliable bot work (and give the maintainer a lot of work to fix stuff)
      • user-maintained: be more experimental - show ALL possible results (no matter how significant) and the user decides which ones are valid
    • brings me to the idea T138119: Use user-maintained bot run mode to gain stats and learn
  • no beta-tests or new testers this week - what can we do to increase that number?

Event Timeline

A few ideas that I've had for the next phase of the project which have been inspired by various things I've seen in the past few weeks:

  • Implement a better interface to use the bot: (This makes using the bot easier)
    • Make the Media tagging bot framework jayvdb had mentioned and use the interface which jayvdb mentioned was already existing in pywikibot to open browser, edit diff, etc. Note that we'd have to add some extra actions like "show image" if the image has already been downloaded. (This would be useful if the user is going to see results while bot is running)
    • Make a script that creates these "log" like pages that we are currently using, and make a Template which adds buttons "Modify page with this info". When the user clicks on this button, a server on toolserver can get that request and actually edit the page. This is a nice user interface which is useful for bots that take a lot of processing time. (Very useful if the script will be run on toolserver and the user wants to check results only after it has completed running at the user's own leisure)
  • Work on JS libraries more: (This makes viewing results from the bot easier)
    • This includes figuring out how the metadata found by the script should be added to mediawiki. It would be either revamping FileContentsByBot to be more usable or merging it with ImageAnnotator, or whatever the community deems appropriate.
  • Work on new features / making features more robust: (This makes the bot more useful)
    • This was what I had originally proposed, i.e. Adding experimental algorithms and so on and also making it easier for users to train new datasets which can be used by the script. This could also include new things that can be detected, like what Fae has proposed earlier.
  • Make algorithms to work on existing files: (This makes the bot more useful)
    • I find that there must be some method to handle categorization on already categorized files better. We've been discussing this issue for a while and generally avoid it by saying "let's focus on uncategorized files", but it would be nice if a bot can reliably modify existing ones too. I think there *must* be some way of doing it. Probably we need to design an appropriate state machine which can handle this ?

Regarding Project Plan, second 50%, again: I think it would be worth it to spend some time revamping how the installation of dependencies happens (again).

I've gotten some inspiration from matplotlib, which has a generic [SetupPackages class](https://github.com/matplotlib/matplotlib/blob/master/setupext.py#L413). This makes things quite streamlined and easy to understand. It has a class (inherited from SetupPackage) for every dependency. I think this makes a lot more sense and makes it easier to manage,

This can remove the download() issues we have and can download everything with appropriate messages during pip install itself. (Which makes sense because installation/downloads shouldn't happen when running, it should happen when installing)

I agree in that installation of deps and the code in general is still an issue, but for this GSoC I think we should not spend too much time anymore - may be during buffer week. I would propose to:

  1. have a Docker/Vagrant procedure (image, etc) that allows us to deploy ANY version of the code no matter how nasty/weird/involved/ill defined the deps are at that moment - including a procedure (e.g. invoke) to build the Docker
  2. have a look at other approaches like matplotlib, wand, vistrails, etc. and make them usable to us
  3. I think at some point all those approaches have anyways to come together in a package that should replace pip and be able to gather info on the system, find packages needed on the web and propose actions to solve the issue to the user - this vendor package management external delivered in the past - this needs to be done as a separate project somwhere else

To understand the matplotlib approach right - it does work out and list the needed deps, right? It does not install them? And it does not know how the package is named (e.g. it says I need boost but has no idea how the package is called on the specific system)? As the later 2 are imporant for a user friendly system.

@DrTrigon Yes, matplotlib does not currently give suggestions. I've created https://github.com/matplotlib/matplotlib/pull/6575 for it

(... and that was 2 weeks ago already...)

What I like is; matplotlib is known and mature software - that way we have a good and broadly used solution! Perfect!