Show Posts
1
Face and Body Scanning / Re: Ready made solutions for full body 3D
« on: December 19, 2014, 09:37:37 PM »
It's possible my observations are because of a lack of understanding of larger USB networks, or because the USB host hardware I'm using is not that stable. It's based on my own experience and the thoughts I exchanged talking with people who operate a studio with about 140 cameras.
Personally, I see this as an interesting problem to design a cool solution for
But it will probably be field tested on a real studio, so I'll probably be able to report real results some time in the near future.
The problem I know is that with too many devices connected to a single USB host, transfers can take a long time (up to a minute). I also think that it's beneficial to replace the computers with windows (and all the potential defects they can have) connected to the cameras, with very cheap microcomputers running an embedded software stack.
I only have experience with Smart Shooter, and while it performs well in good situations, I find that its scripting and customization support is a bit lacking. For example I can't get detailed control over how many images from where I download, or track from which camera those images are coming -- as images are labeled at the time they are downloaded, not at the time they are captured. Even if you can grab some information from the EXIF data afterwards, it feels like less elegant solution to me. Also, with SmartShooter, when capturing sequences of images, I get the occasional black image, I've heard from others they experienced the same thing. This might also be due to Nikon's buggy PTP implementation (yes, I've got those buggers -- too bad they couldn't do it right, like on the old D80 models), sadly I've no experience with Canons.
You might get good results with it, probably depends on how you use it, the overal transfer speed and how much time you can wait between captures.
The main reason why I try to do this differently, is to make capturing and identifying of images and downloading them asynchronous. Using a LAN network and a bit of adapted software, it's possible to determine what images belong together in one set, and where they reside (what camera, what network node) mere seconds after the cameras were triggered. Once the computer knows where these images are and how to group them together, it doesn't matter that downloading these images takes a little while longer. It can create a queue and download these images in the background, meanwhile the studio can be used again for making new captures. Even if a USB network can perform well, it can be outperformed by a gigabit ethernet network. Additionally there is no limit of 255 devices with ethernet (should that ever be required), it's very easy to scale the setup practically without limits.
Mainly I think this approach can help in simplifying the use and increasing the trust in a larger camera setup. A simple web interface keeps track of the state of the system, showing things such as the number of cameras detected, their current state and configuration, and shows real-time warnings when things go wrong, for example a camera disconnected, some images were missing or are black in the last capture (you could set an allowed threshold here), warn when someone left a lens toggle on "auto focus", among other things. The system generates an extensive set of log events that are captured by a single node, allowing to filter on interesting events, but it also allows to analyze aggregated log events: if for example the same camera failed 8 out of the last 10 captures, this might be an indication that it is defective.
Probably the most interesting aspect of it is that, because of the reduced maintenance required, it becomes easier to operate the studio, or makes it possible to create a mobile version of it, installed at a different location. Logs can be accessed remotely so that in many cases, remote assistance can be delivered.
While I personally only have a small testing setup, I am designing it so that it can easily scale to many hundreds of units without large performance penalties. The goal I have set now is to allow a 150 camera setup to make a capture every 5 seconds, while guaranteeing that all pictures will end up on a NAS store (correctly divided in sets for each capture) without the photographer having to worry about any of it (that is, until you fill up the buffer of your SD cards -- with 16GB I think you have more than enough -- in which case you just have to wait a bit until some captures finish downloading).
Aside from this task I am toying around with my own small DIY studio, with a rotating platform , a self-constructed trigger box, a timed trigger mechanism and 6 cameras. The main goal is bringing some of the merits of 3D scanning to the open source community. I am a developer at the MakeHuman project and hope that we can use scanned content to create virtual assets like clothing, hairstyles and skin details more quickly and with better detail than we were able to get before.
Personally, I see this as an interesting problem to design a cool solution for
But it will probably be field tested on a real studio, so I'll probably be able to report real results some time in the near future.The problem I know is that with too many devices connected to a single USB host, transfers can take a long time (up to a minute). I also think that it's beneficial to replace the computers with windows (and all the potential defects they can have) connected to the cameras, with very cheap microcomputers running an embedded software stack.
I only have experience with Smart Shooter, and while it performs well in good situations, I find that its scripting and customization support is a bit lacking. For example I can't get detailed control over how many images from where I download, or track from which camera those images are coming -- as images are labeled at the time they are downloaded, not at the time they are captured. Even if you can grab some information from the EXIF data afterwards, it feels like less elegant solution to me. Also, with SmartShooter, when capturing sequences of images, I get the occasional black image, I've heard from others they experienced the same thing. This might also be due to Nikon's buggy PTP implementation (yes, I've got those buggers -- too bad they couldn't do it right, like on the old D80 models), sadly I've no experience with Canons.
You might get good results with it, probably depends on how you use it, the overal transfer speed and how much time you can wait between captures.
The main reason why I try to do this differently, is to make capturing and identifying of images and downloading them asynchronous. Using a LAN network and a bit of adapted software, it's possible to determine what images belong together in one set, and where they reside (what camera, what network node) mere seconds after the cameras were triggered. Once the computer knows where these images are and how to group them together, it doesn't matter that downloading these images takes a little while longer. It can create a queue and download these images in the background, meanwhile the studio can be used again for making new captures. Even if a USB network can perform well, it can be outperformed by a gigabit ethernet network. Additionally there is no limit of 255 devices with ethernet (should that ever be required), it's very easy to scale the setup practically without limits.
Mainly I think this approach can help in simplifying the use and increasing the trust in a larger camera setup. A simple web interface keeps track of the state of the system, showing things such as the number of cameras detected, their current state and configuration, and shows real-time warnings when things go wrong, for example a camera disconnected, some images were missing or are black in the last capture (you could set an allowed threshold here), warn when someone left a lens toggle on "auto focus", among other things. The system generates an extensive set of log events that are captured by a single node, allowing to filter on interesting events, but it also allows to analyze aggregated log events: if for example the same camera failed 8 out of the last 10 captures, this might be an indication that it is defective.
Probably the most interesting aspect of it is that, because of the reduced maintenance required, it becomes easier to operate the studio, or makes it possible to create a mobile version of it, installed at a different location. Logs can be accessed remotely so that in many cases, remote assistance can be delivered.
While I personally only have a small testing setup, I am designing it so that it can easily scale to many hundreds of units without large performance penalties. The goal I have set now is to allow a 150 camera setup to make a capture every 5 seconds, while guaranteeing that all pictures will end up on a NAS store (correctly divided in sets for each capture) without the photographer having to worry about any of it (that is, until you fill up the buffer of your SD cards -- with 16GB I think you have more than enough -- in which case you just have to wait a bit until some captures finish downloading).
Aside from this task I am toying around with my own small DIY studio, with a rotating platform , a self-constructed trigger box, a timed trigger mechanism and 6 cameras. The main goal is bringing some of the merits of 3D scanning to the open source community. I am a developer at the MakeHuman project and hope that we can use scanned content to create virtual assets like clothing, hairstyles and skin details more quickly and with better detail than we were able to get before.
