Viewer for depthmaps
Moderators: rjlittlefield, ChrisR, Chris S., Pau
-
- Posts: 209
- Joined: Thu Dec 20, 2007 11:22 am
- Location: Swindon, UK
Viewer for depthmaps
The "digital microscopes" such as those by Keyence and Hirox allow the user to view the results of stacking laid on a 3D surface created from the depth/height field.
Does anyone know any other software that will allow this?
FWIW you can download the Hirox viewer here with some examples:
http://www.hirox-usa.com/dep.html
It might be possible to work out the file format but it would be nice to avoid reliance on this software.
Graham
Does anyone know any other software that will allow this?
FWIW you can download the Hirox viewer here with some examples:
http://www.hirox-usa.com/dep.html
It might be possible to work out the file format but it would be nice to avoid reliance on this software.
Graham
Funny that, in CG we use Heightfield map to create digital terrain. It's basically a black and white image file (BMP, JPG, TIFF, etc.) where the whiter area is higher than black. Mind you a heightfield map can only displace a surface up or down, for it to be truly 3D, you will have to take more photos from different angles.
Something like this.
One free 3D software which can do something like this is called Blender3D.
http://www.blender.org/
Something like this.
One free 3D software which can do something like this is called Blender3D.
http://www.blender.org/
-
- Posts: 209
- Joined: Thu Dec 20, 2007 11:22 am
- Location: Swindon, UK
-
- Posts: 209
- Joined: Thu Dec 20, 2007 11:22 am
- Location: Swindon, UK
Oh and up and down is fine, this is as much info as you can get from a stack anyway. Funnily enough I already have a solution for true 3D volumes:
http://en.wikipedia.org/wiki/Drishti
Works very well and now can import colour stacks
http://en.wikipedia.org/wiki/Drishti
Works very well and now can import colour stacks
- rjlittlefield
- Site Admin
- Posts: 23603
- Joined: Tue Aug 01, 2006 8:34 am
- Location: Richland, Washington State, USA
- Contact:
- rjlittlefield
- Site Admin
- Posts: 23603
- Joined: Tue Aug 01, 2006 8:34 am
- Location: Richland, Washington State, USA
- Contact:
Re: Viewer for depthmaps
You can talk CombineZM into exporting a depthmap.Graham Stabler wrote:view the results of stacking laid on a 3D surface created from the depth/height field. ... Does anyone know any other software that will allow this?
Import that into a package like MatLab or Mathematica for display.
There's almost certainly a plugin for ImageJ that will do it also, but I don't have a reference at hand. Try checking the list of ImageJ plugins. "3D Surface Plotter" might do what you want.
--Rik
-
- Posts: 209
- Joined: Thu Dec 20, 2007 11:22 am
- Location: Swindon, UK
Rik,
That is exactly why I am seeking software. To begin with the display of meshes in Matlab is terribly slow (this is the first thing I tried) and ideally I would have the stacked image painted on to the surface as they do in the commercial software.
P_T,
If you know blender would you consider a tutorial or some notes on how?
Graham
That is exactly why I am seeking software. To begin with the display of meshes in Matlab is terribly slow (this is the first thing I tried) and ideally I would have the stacked image painted on to the surface as they do in the commercial software.
P_T,
If you know blender would you consider a tutorial or some notes on how?
Graham
Sorry mate, I don't use Blender at all. I tried it back in the days but it was just too confusing. That said, it's getting very powerful now with its own hair/water simulation as well as a compositor. I suggest downloading the latest version. There are also plenty of Blender tutorials on the net but be warned, quite a steep learning curve.
-
- Posts: 209
- Joined: Thu Dec 20, 2007 11:22 am
- Location: Swindon, UK
Here's what Rik's hobo spider stack depthmap looks like in 3D.
As you can see, the 'stair stepping' seen in my previous terrain example is also evident in this render. It's because of the 8 bit nature of the depthmap, 16bit depthmap would give a much smoother result. All the roughness in the image is due to the hair.
At best, depthmap generated from photo stacking would give you similar result to Emboss filter in photoshop.
Depthmap really is quite limited in its application, which is probably why it's only used for fairly simple digital terrain seen from long distance shots in CG.
As you can see, the 'stair stepping' seen in my previous terrain example is also evident in this render. It's because of the 8 bit nature of the depthmap, 16bit depthmap would give a much smoother result. All the roughness in the image is due to the hair.
At best, depthmap generated from photo stacking would give you similar result to Emboss filter in photoshop.
Depthmap really is quite limited in its application, which is probably why it's only used for fairly simple digital terrain seen from long distance shots in CG.
-
- Posts: 209
- Joined: Thu Dec 20, 2007 11:22 am
- Location: Swindon, UK
- rjlittlefield
- Site Admin
- Posts: 23603
- Joined: Tue Aug 01, 2006 8:34 am
- Location: Richland, Washington State, USA
- Contact:
For my purposes, this second image of the hobo depthmap is much more useful than the first one.
It shows, for example, that the palps sit way out in front, with the chelicerae behind them. The legs to left and right are farther back than the palps, about the same depth as the chelicerae. The head slopes gradually away toward the back. There are two small areas of detail to the left and right of the head that come from the far background. (These are in fact spines on other legs, farther back.)
These same features can also be identified in the original stack, by treating it as a "movie" and sliding the "time slider" = "focus dial" back and forth. But the static picture provides an alternate and sometimes better presentation.
This image also shows some features of the depthmap that you have to be a connoisseur of stacking algorithms to appreciate. The "fins" sticking out from the palps and to a lesser extent from the legs are basically correct representations of large spines on those structures. The fact that the fins are broken indicates that the stacking algorithm did not identify the entire extent of many spines, but rather triggered off sharper background detail from place to place. The isolated sharp spike sticking way out, to the left of the left palp, is probably due to a spot of unusually large noise in some foreground frame. The generally smooth (though visibly stairstepped) curved surface in the top part of the frame indicates that this algorithm was not able to actually identify subject depth in that region, but rather was smoothly interpolating between areas where it could tell. (This behavior turns out to be one good way of reducing halo.)
In a PM, P_T asked
P_T also notes that the depthmap is "very VERY rough". Yes, it surely is. This roughness is typical of depthmaps constructed from subjects with hairs and spines.
Even if the depthmap were perfect, what you would see is a bunch of rapid transitions: a hair, some skin, a hair, some skin -- front, back, front, back, and so on. In other words, the depthmap would be rough.
In computer animations, it's common to construct a smooth depthmap and then paint some detail on it. This greatly simplifies the process of constructing the model, it makes the animation run a lot faster, and it often looks pretty good. But all that just makes an expedient approximation, not an accurate depthmap.
As a connoisseur of stacking algorithms, what concerns me about this image is not that it's rough, but that it has some significant errors. For example, I mentioned the breaks in some of those big "fins", where the algorithm picked background detail instead of a foreground spine. In the stacked composite, the effect of those breaks is to introduce visibility errors that generally have to recognized by eye and fixed by hand.
I believe I've mentioned before that it's far from simple to write stacking algorithms that do the right thing all the time. This depthmap illustrates some of the difficulties.
BTW, the depthmap that's illustrated here was produced by CombineZP using its Do Stack macro. The resulting composite image is similar but not identical to the composite image that HF produces, which is what's shown here, cropped to portrait format. To the best of my knowledge, current versions of HF won't export a depthmap, so when P_T wanted one, I had to run the original stack back through CombineZP instead.
Thanks for rendering this out -- it's very helpful!
--Rik
It shows, for example, that the palps sit way out in front, with the chelicerae behind them. The legs to left and right are farther back than the palps, about the same depth as the chelicerae. The head slopes gradually away toward the back. There are two small areas of detail to the left and right of the head that come from the far background. (These are in fact spines on other legs, farther back.)
These same features can also be identified in the original stack, by treating it as a "movie" and sliding the "time slider" = "focus dial" back and forth. But the static picture provides an alternate and sometimes better presentation.
This image also shows some features of the depthmap that you have to be a connoisseur of stacking algorithms to appreciate. The "fins" sticking out from the palps and to a lesser extent from the legs are basically correct representations of large spines on those structures. The fact that the fins are broken indicates that the stacking algorithm did not identify the entire extent of many spines, but rather triggered off sharper background detail from place to place. The isolated sharp spike sticking way out, to the left of the left palp, is probably due to a spot of unusually large noise in some foreground frame. The generally smooth (though visibly stairstepped) curved surface in the top part of the frame indicates that this algorithm was not able to actually identify subject depth in that region, but rather was smoothly interpolating between areas where it could tell. (This behavior turns out to be one good way of reducing halo.)
In a PM, P_T asked
This was stacked from 66 images. Even representing the depthmap as 8 bits could be considered overkill. The critical information -- which frame has sharpest detail at each pixel -- would almost fit in 6 bits.How many images did you use for that stack Rik? You don't have the 16bit version of that depthmap do you?
P_T also notes that the depthmap is "very VERY rough". Yes, it surely is. This roughness is typical of depthmaps constructed from subjects with hairs and spines.
Even if the depthmap were perfect, what you would see is a bunch of rapid transitions: a hair, some skin, a hair, some skin -- front, back, front, back, and so on. In other words, the depthmap would be rough.
In computer animations, it's common to construct a smooth depthmap and then paint some detail on it. This greatly simplifies the process of constructing the model, it makes the animation run a lot faster, and it often looks pretty good. But all that just makes an expedient approximation, not an accurate depthmap.
As a connoisseur of stacking algorithms, what concerns me about this image is not that it's rough, but that it has some significant errors. For example, I mentioned the breaks in some of those big "fins", where the algorithm picked background detail instead of a foreground spine. In the stacked composite, the effect of those breaks is to introduce visibility errors that generally have to recognized by eye and fixed by hand.
I believe I've mentioned before that it's far from simple to write stacking algorithms that do the right thing all the time. This depthmap illustrates some of the difficulties.
BTW, the depthmap that's illustrated here was produced by CombineZP using its Do Stack macro. The resulting composite image is similar but not identical to the composite image that HF produces, which is what's shown here, cropped to portrait format. To the best of my knowledge, current versions of HF won't export a depthmap, so when P_T wanted one, I had to run the original stack back through CombineZP instead.
Thanks for rendering this out -- it's very helpful!
--Rik