[Work Log] New undertaking: C++ render server, pixel-based likelihood

October 08, 2013
Project Tulips
Subproject Likelihood Server
Working path projects/​tulips/​trunk/​src/​likelihood_server
SVN Revision 15229
Unless otherwise noted, all filesystem paths are relative to the "Working path" named above.

Note on November 6, 2013: During the 5-day gap from the previous entry, I decided to go with "Option 1" proposed that day, namely construct a pixel likelihood that uses the rendered model, which should rule out bad candidates by penalizing missing data. Since OpenGL rendering this isn't possible in Matlab, realized I will need to implement rendering in C++ and somehow communicate to Matlab using some inter-process communication. To minimize latency, avoid polling, deciced on using synchronous TCP over localhost. Boost makes this pretty easy, and have implemented a proof of concept both in MEX and in KJB. The Matlab/MEX version constructs a socket on the heap, and returns its address as a uint64 to matlab.

At the point when the following was written, I had just begun implementing a render-server in opengl, which would receive a curve-tree and return the rendered pixels. I would later abandon this approach in favor of computing an edge-based likelihood in C++ and return the log-likelihood value to matlab.

Working on compiling render server.

Do I want to compute likelihood in C++ too?

Code exists for it. Maybe best to just re-use code from curve_sampling.cpp and abandon render server.

Lets do that.

Reviewing old curve sampling code

Pixel likelihood receives a pointer to linear array of reals that represent the pixel matrix.

Multi-view likelihood receives a renderable and handles all the rendering and pixel-retreival, and dispatches to pixel likelihood objects for computing. is constructed with one or more cameras. On evaluation it receives a renderable object, projects it under each camera, retreives the pixels, and passes to a pixel likelihood.

Refactor: Separate rendering into a "renderer" object, which can be split into its own process if needed. It will also make leapfrog pixel-reading simpler.

End product will

  1. receive message from matlab containing curves
  2. decode curves into vectors
  3. convert into gl_curves (renderables)
  4. pass to likelihood object
  5. convert log-posterior to message
  6. transmit back to matlab

all functionality is already implemented, just need to weed out code rot and put it together.

Getting weird link errors. For some reason, the build system is using gcc instead of g++ to link my main program. Will try re-running kjb_add_makefiles Refactor: specify all parameters at command-line (width, height, cameras, etc)

Meanwhile, I'm planning the program

inputs: * dimensions * cameras * likelihood parameters *

Steps * initialize likelihood * initialize TCP server

Abandoning GL_context from sampler_cpp. writing one-off offscreen-buffer class. writing new GL_context struct with just the stuff we need

Reducing dependence on perspective_camera object in favor of using modelview and projection matrices. We'll be working with matrices from matlab.

Updated Camera_render_wrapper to use matrices instead of camera.

Updated Abstract_mv_likelihood to use matrices in addition to cameras (for backward compatibility).

Posted by Kyle Simek
blog comments powered by Disqus