The Ecosynth Lab has been using and developing several software tools over the past couple of years and one of our next big projects is to figure out how to best get these tools into other people’s hands and make them worthwhile to use.
One approach that I thought might best help users interface with some of Ecosynth's software is to create an Ecosynth Python Package that contains modules of tools for each stage of the data-processing pipeline.
I've posted a more detailed explanation of how this package might be structured over on the Ecosynth Tools page at wiki.ecosynth.org.
I was wondering if anyone would be willing to share their thoughts and ideas on this thread about what they might like to see in the package and whether anyone would be interested in collaborating with us to test and develop the package.
A couple of questions that come to mind immediately:
Is there any particular functionality that you might find most useful with this package
Would it be useful if we operated a repository for the package on code.ecosynth.org similarly to typical open-source projects, in which anyone can submit a pull request and integrate their code back into the Ecosynth code?
Thanks for any input!
I think all of the above suggestions are great. Something as easy to use as PPT would be a major step forward. As it stands, Ecosynther is a bit of a beast to set up and run locally unless you happen to have some decent programming chops. Compiling and dealing with dependency hell is a major pain (I still can't get it to run), and doesn't bode well for uptake of what appears to be a promising open source SFM workflow.
I'd suggest packaging things up in a VM using a Vagrant/Docker approach. The latter might not allow for GPU acceleration, but it would be a big step forward in terms of getting things to "just work" out of the box, and increase mind share.
Dennis, this is great feedback.
Yes, I wasn't directly involved with the creation of Ecosynther, but your thoughts appear to all be on point. My impression is that Ecosynther depends on the CUDA framework and an EC2 instance was one way of working with that dependency while making it public, but the setup process is quite lengthy if you haven't worked with Amazon EC2 before. Were you saying that Vagrant might be a more portable option that also could plug and play with CUDA-equipped computers?
Just to clarify what I wrote in my first post and have since been working on, the Python library would provide tools to help users along the data-processing pipeline. For Ecosynther, it would help users pre-process and post-process data entering and exiting the Ecosynther SfM program, but it would remain separate.
If you want to take a look at what's gone on, here are some links:
- Source Code (under "develop" branch)
Installation instructions (Currently will work for Linux and OSX with Python 2.7, however it might try to compile the Numpy packages from source even if you have them pre-installed):
pip install ecosynth
To launch the HTML GUI:
python -m ecosynth
If you have any feedback, I'd love to hear about it.
Apologies for straying off the main thrust of your proposal, but since you asked, here's my response. I'm not a computer science guy, so take my response with a grain of salt:
Were you saying that Vagrant might be a more portable option that also could plug and play with CUDA-equipped computers?
I've only played with Vagrant for a short period, but it seems like a means of replicating and distributing one's development environment using a variety of virtualization software and environments (e.g., Virtualbox, EC2, etc.). The Vagrant website explains it in much more detail than I ever could, but it seems like a compelling approach, and certainly better than the download, compile, dependency hell routine I typically go through when working with some scientific software. While I admittedly find it "cool" to get into the nuts and bolts of compiling from source, I ultimately just want to use a tool to get a job done. I don't want to fight with a compiler for hours. There's also something called Docker, which appears to be an even lighter approach than spooling up VM environments using Vagrant.
As far as using Vagrant to allow PnP for CUDA-equipped computers, I'm not too sure. I'm guessing that since it's run as a VM, it would depend on the VM software's ability to access the underlying iron. From what I know on this front, it seems to be hit or miss when trying to directly access a GPU in a virtualized environment (at least with Virtualbox), but I've definitely come across some tantalizing examples of where it has worked.
Anyway, back to your proposal, which was the whole point until I sidetracked the conversation: I still think it would be highly relevant and a worthy endeavour, sans any Vagrant/Docker uptake. Anything that makes interacting with the underlying Ecosynther SfM modules would be a welcome addition. Certainly, a series of well documented Python scripts that fit into a larger work flow would be a great addition to Ecosynther.
Now, if I could only get Ecosynther compiled.... ;)
Thanks for the explanation. I'll look into these options more and do my best to make something of it if I can fit it into my schedule.
What stage have you gotten to for compiling Ecosynther? The creators recommend a clean installation of Ubuntu if that's possible at all. Either way, have you managed to run the EcosyntherDependencies.sh script and install the CUDA driver and toolkit?
I started a new discussion to separate the topics. Thanks!