Slashdot Mirror


MIT's Picture Language Lets Computers Recognize Faces Through Inference

itwbennett writes: MIT researchers are working on a new programming language called Picture, which could radically reduce the amount of coding needed to help computers recognize objects in images and video. It is a prototype of how a relatively novel form of programming, called probabilistic programming, could reduce the amount of code needed for such complex tasks. In one test of the new language, the researchers were able to cut thousands of lines of code in one image recognition program down to fewer than 50.

23 comments

  1. Line Count is Misleading by Anonymous Coward · · Score: 3, Insightful

    "...the researchers were able to cut thousands of lines of code in one image recognition program down to fewer than 50."

    How many lines of code were used to write the MIT Picture language? The article summary claims to have replaced thousands of lines of code in an existing application yet do not mention the line count of the Picture language.

    1. Re:Line Count is Misleading by TWX · · Score: 1

      Yeah, sounds like they've essentially developed a library that the programming language is dependent on.

      --
      Do not look into laser with remaining eye.
    2. Re:Line Count is Misleading by sexconker · · Score: 1

      More importantly, how flexible are those 50 lines of code vs the 1000 lines of code?
      If you're calling some functions for some MIT Picture Language object, then when you find a whole class of images where MIT's shit utterly fucking sucks, you're screwed.

      Faces = FindFaces(Image) is only one line! And it's recognizes faces in 68% of our test images wowowow!!!
      If 68% is not acceptable, your images aren't like MIT's test images, or you want to find faces of dogs instead of people, you're going to be writing your own code.

    3. Re:Line Count is Misleading by TsuruchiBrian · · Score: 2

      After reading the article, it seems that the language allows for the code to modify itself. So that seems pretty flexible. Most languages specifically prohibit this kind of flexibility (as it is prone to errors).

    4. Re: Line Count is Misleading by Anonymous Coward · · Score: 0

      know you mention it, we should all go back to programming in assembler or better even machine code. We have lost so much flexibilty with using high level languages! Duh

    5. Re:Line Count is Misleading by Penguinisto · · Score: 1

      Pretty much.

      I immediately thought of Quake1/2 as a parallel... the executable itself is relatively tiny (1-2MB or so, IIRC?), but the libraries it calls weigh in at hundreds of MB at least. Add in maps, image files, sound files, and meshes on top of that, and suddenly you have something that weighed in at the size of a nearly-full burned CD.

      --
      Quo usque tandem abutere, Nimbus, patientia nostra?
    6. Re:Line Count is Misleading by Sowelu · · Score: 2

      I don't see how that's misleading. So what if the program has all kinds of fancy algorithms--they're not waving around "look how smart we are!!". They're saying "Hey if you want to write image processing code, you can do it this easy". ...man, I miss my image processing class.

    7. Re:Line Count is Misleading by Anonymous Coward · · Score: 0

      Not to mention modifying itself is a great vector for malware.

      (I think this is interesting and certainly good research, and I'm sure they've considered some of the ramifications, btw)

    8. Re:Line Count is Misleading by TsuruchiBrian · · Score: 1

      I feel like any serious attempt at AI is going to have some pretty serious security vulnerabilities. I think facial recognition can probably be done better than a human without artificial consciousness, but if we want a human-like AI with creativity, and personality, etc, we might also get some pretty serious problems (like maybe it could be convinced to believe in causes and commit crimes or hurt people).

      In the safe world where control planes and data planes don't mix, we can be very secure and predictable, but that's pretty boring, and I might not ever like any songs or paintings created by such a computer or algorithm.

    9. Re:Line Count is Misleading by RNLockwood · · Score: 1

      I don't see that Mr | Ms | Mrs Coward's comment is pertinent. I sure don't want to need to code "y = z++" in assembly, much less binary, each time I need it. Computer languages are made up of symbols that translate to several to many lines of code and come with libraries of still more abstract code and the trend of higher abstraction appears to be continuing. It's good have routines coded once that that are used many times. Productivity increases.

      --
      Nate
    10. Re:Line Count is Misleading by msobkow · · Score: 1

      Probably about as many lines as the difference between software rendering in the original Doom vs. later games that used OpenGL and DirectX. But to be fair, they probably just linked in a shitload of libraries rather than writing them.

      --
      I do not fail; I succeed at finding out what does not work.
    11. Re:Line Count is Misleading by Half-pint+HAL · · Score: 1

      "...the researchers were able to cut thousands of lines of code in one image recognition program down to fewer than 50."

      How many lines of code were used to write the MIT Picture language? The article summary claims to have replaced thousands of lines of code in an existing application yet do not mention the line count of the Picture language.

      Your problem is that you're thinking to heavily in terms of C-like imperative programming. Picture sounds more comparable to Prolog to me -- an automated problem-solver. The core of Picture is an "inference engine" -- the core of Prolog is an inference engine too. The difference is that Prolog operates in pure predicate logic, whether Picture is a probabilistic language.

      Probabilistic programming in even a relatively high-level C-like (eg Python) would be a total pain, because you have to explicitly call all calculations. An inference engine will do the calculations implicitly and will prune any unsuccessful branches off your search tree without you having to worry about it. The end result is very complete solutions to problems with a low bug count, but (in general) relatively high execution times.

      This sort of very-high-level language isn't suitable for every task, but it serves its task exceptionally well.

      --
      Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'
    12. Re:Line Count is Misleading by Half-pint+HAL · · Score: 1

      Yeah, sounds like they've essentially developed a library that the programming language is dependent on.

      Even if you wrote wrappers to access all their libraries in (for example) Python, operating an inference engine and manipulating the results returned would be a complete pain. This is a high-level language designed as a problem-solver over a probabilistic domain. That in itself is a very far-removed abstraction from the processor's opcodes...

      --
      Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'
    13. Re:Line Count is Misleading by Anonymous Coward · · Score: 0

      function PROGRAM(MU, PC, EV, VERTEX_ORDER)
      # Scene Language: Stochastic Scene Gen
      face=Dict();shape = []; texture = [];
      for S in ["shape", "texture"]
      for p in ["nose", "eyes", "outline", "lips"]
      coeff = MvNormal(0,1,1,99)
      face[S][p] = MU[S][p]+PC[S][p].*(coeff.*EV[S][p])
      end
      end
      shape=face["shape"][:]; tex=face["texture"][:];
      camera = Uniform(-1,1,1,2); light = Uniform(-1,1,1,2)
      # Approximate Renderer
      rendered_img= MeshRenderer(shape,tex,light,camera)
      # Representation Layer
      ren_ftrs = getFeatures("CNN_Conv6", rendered_img)
      # Comparator
      #Using Pixel as Summary Statistics
      observe(MvNormal(0,0.01), rendered_img-obs_img)
      #Using CNN last conv layer as Summary Statistics
      observe(MvNormal(0,10), ren_ftrs-obs_cnn)
      end
      global obs_img = imread("test.png")
      global obs_cnn = getFeatures("CNN_Conv6", img)
      #Load args from file
      TR = trace(PROGRAM,args=[MU,PC,EV,VERTEX_ORDER])
      # Data-Driven Learning
      learn_datadriven_proposals(TR,100000,"CNN_Conv6")
      load_proposals(TR)
      # Inference
      infer(TR,CB,20,["DATA-DRIVEN"])
      infer(TR,CB,200,["ELLIPTICAL"])

      That's code to do 3D face reconstruction from a 2D photo.

      If you had any clue how to do 3D face reconstruction from a 2D photo, you'd understand why this is an improvement.

      But you don't, so shut the fuck up already.

    14. Re:Line Count is Misleading by Anonymous Coward · · Score: 0

      You just don't understand the difference between a library and a language.

      float myfunc(float x) {
          return sin(x) + cos(x);
      }

      There is no C library in the world that can take myfunc and analytically differentiate it. You cannot just say:

      float (*myFuncPrime)(float x) = differentiate(myfunc);

      It's a complete conceptual roadblock. Can't be done. You fundamentally cannot have this "differentiate()" operator in C. To implement it would require the compiler itself to analyze the DAG and perform analytic differentiation, creating a new DAG, and hence a new assembly function. That requires a new language with differentiate() as a compile-time operator.

      If you have a dozen functions like differentiate, some of which do end up calling insanely complex library functions in order to do their work, then you are scratching the surface of what Picture does for you.

    15. Re:Line Count is Misleading by Anonymous Coward · · Score: 0

      Are you an idiot?

      How about counting the lines of code in the underlying OS?

  2. But the lines were ... by CaptainDork · · Score: 2

    ... long.

    --
    It little behooves the best of us to comment on the rest of us.
  3. I get it by Anonymous Coward · · Score: 0

    I get it, 'relatively novel'. So novel that we've been doing it for several decades and it has been used by everything from the atomic weapons program and space program to teaching Samsung how to eavesdrop on our living room conversations.

    1. Re: I get it by Anonymous Coward · · Score: 0

      so, will you tell us about how you got here, from 2060?

    2. Re:I get it by Half-pint+HAL · · Score: 1

      I get it, 'relatively novel'. So novel that we've been doing it for several decades and it has been used by everything from the atomic weapons program and space program to teaching Samsung how to eavesdrop on our living room conversations.

      From TFA:

      “This is the first time that we’re introducing probabilistic programming in the vision area,” says Tejas Kulkarni, an MIT graduate student in brain and cognitive sciences and first author on the new paper. “The whole hope is to write very flexible models, both generative and discriminative models, as short probabilistic code, and then not do anything else. General-purpose inference schemes solve the problems.”

      Computer Vision research has been behind other AI areas in its use of generalisable code, but current AI and machine learning algorithms are effective and efficient enough that image processing with them is finally practical. That's the novelty.

      --
      Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'
  4. Example code? by Tablizer · · Score: 1

    Anybody have a coded example?

    1. Re:Example code? by Anonymous Coward · · Score: 0

      :)\____/(:
      {(@)v(@)
        {|~- -~|}
        {/^'^'^\}
      ==m-m==

      Whooo's asking?

    2. Re:Example code? by Psychotria · · Score: 1