Forum

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - ozbigben

Pages: 1 2 3 [4] 5
46
General / Re: Obtaining pixel coordinates
« on: June 11, 2014, 05:31:00 AM »
Don't have the Pro version yet so I don't know whether PS allows you to specify repeatable coordinates for tiles, but if it doesn't then you should be able to script this with a GIS application e.g. GlobalMapper. That would give you the consistency you'd need for a database comparing multiple time frames.

That would also give you the option of just creating a single geotiff of the whole area, or larger chunks, whichever is more efficient for PS to process.

47
General / Re: dense point cloud format
« on: June 11, 2014, 05:19:41 AM »
what about export ply and convert to xyz? Easy to reverse.. no wait, checked the menus. That would make importing the dense cloud a feature request ;)

48
General / Re: dense point cloud format
« on: June 10, 2014, 08:46:01 PM »
It might have helped if you started by mentioning your goal then. What format of data do you need for your external editor?

49
General / Re: How far can a GoPro go...
« on: June 10, 2014, 08:33:09 PM »
Hi Paul. That's an interesting system, although technically that's a significant modification to the Gopro so it's not an entirely fair comparison. 

I did save a calibration for the normal view but I haven't done one for wide yet.  I use a specific target (a laneway with a brick wall and cobble stone paving) and camera orientations for my calibrations. It's still a little agricultural but follows a similar principle to the process I use for calibrating my lenses for stitching 360° panoramas.  I found that this can improve the quality obtained from image sets that are not "ideal".

50
General / Re: importing cameras
« on: June 09, 2014, 03:28:19 PM »
Well that was interesting   ???
http://photosynth.net/edit.aspx?cid=891ba374-f8c3-4d5a-bd0c-14bc8c362b05
Uploaded 121 images (every 1/3rd image of a set), 118 were aligned.
5 point clouds were created using various combinations of the images for a total of 199 cameras (114,41,28,14,2).
Every camera has a unique position and focal length/distortion parameters, despite the fact that there are 81 duplicate references to images. I downloaded a few images and they were the same as the original. I suspect in the other download I did I got corrected images which would explain the duplicates with slight distortion differences. I'm not too sure how much value you'd get from importing just the camera positions from the largest point cloud in a synth given that there appears to be a lot of distortion optimisation going on to make the points fit.

51
General / Re: importing cameras
« on: June 09, 2014, 09:24:58 AM »
Are we talking the old photosynth or the preview version. There are a few differences in the available data with the preview. CSV I get using SynthExport (http://synthexport.codeplex.com/) contains these fields:
ImageId, PositionX, PositionY, PositionZ, RotationX, RotationY, RotationZ, AspectRatio, FocalLength, RadialDistortionK1, RadialDistortionK2
0, -0.0073282, -0.0138619, 0.0106463, -0.0236492572237913, -0.00460469355218319, 1.46217268368253, 0.666667, 17.971, -4.11466E-05, 4.11466E-05


Not sure if other plugins/sources that people are using get the same data, but there are some significant differences in what is available with the preview version of photosynth (corrected images only , point cloud and no camera export) This would make it far less useful for people who are using it to reprocess their own data.

It would be interesting to know what results people got.  I'm uploading one now as a comparison. I've had a closer look at a synth by someone else and it's all pretty weird for a good looking mesh.  There are pairs/triples of images that look almost identical but the images have (in some cases) very different focal lengths in the camera export. Given that each image has its own lens settings it may not be that practical to import them into Photoscan

52
General / How far can a GoPro go...
« on: June 09, 2014, 02:14:14 AM »
First off let me start by saying that I know a GoPro is not the ideal camera for photogrammetry and I wouldn't consider using it in future. I bought mine for cycling/hiking videos and I've taken a few image sets to try out in 123D Catch before getting Photoscan.  As part of getting familiar with PS I've been seeing how good a model I could get using a GoPro and the standard version of PS. It's taught me a lot and I thought I'd share my findings.

1. Lower your expectations  ;)

2. Forget "wide". The "normal" fov may only result in a 7mp image, effectively being just a crop of the 12mp wide image, but it avoids getting a lot of distant stuff in your sparse point cloud which you end up cropping out, reducing the number of points for the next steps in the workflow.

3. You need a lot more images and need to photograph a lot closer than you might think. I shot these sets on timelapse at 0.5secs per frame

4. Mask the sky.  I set up a photoshop action to mask out most of the sky before starting. I try and shoot on lightly overcast days so the sky is usually white.
  • Add a white border to the image
  • Magic wand select the top left corner with a tolerance of about 20
  • Invert the selection
  • Create an alpha channel from the selection
  • Remove the white border
  • Save as TIFF
This provides a reasonably good starting point for creating masks.  Adding the white border lets the selection grow around trees/other objects that extend to the edge of the frame. Might look at using Imagemagick for that as it might be quicker (and simpler)

5. Create a sparse point cloud with at least 500,000 points
Remove "bad" points using gradual selection: Reprojection error 0.5, Reconstruction uncertainty 50 ( I know I've been exploring other values for these settings, but these seem to be consistent for my GoPro image sets)

From there, do everything at as high quality settings as you can cope with, export and clean up the mesh.

Attached a screengrab of the latest test. 360 images (shot as 12mp, wide) around the sculpture in the middle (I didn't chose that number, just a coincidence after removing under-exposed frames)  This is the actual location: http://www.360cities.net/image/sheep-shape-behind-the-arts-centre-melbourne-victoria/#288.71,1.34,63.1

Sheep sculpture: http://studio.verold.com/projects/5394f586372e88020000043d (easier to see the mesh quality without texture)

Tree trunk (~180 images) http://studio.verold.com/projects/5392aa11eef3b50200000077

53
General / Re: Clarification of Reconstruction uncertainty
« on: June 08, 2014, 05:07:12 PM »
I'll blame Alexey for explaining them in the wrong order  ;)

Yes, I meant reconstruction uncertainty. I've been increasing the size of the sparse point cloud already, although for no real reason so at least now I have one.  If the point cloud was too sparse I saw things like sections of flat walls becoming waved, particularly in areas where there were fewer overlapping images.  Given enough points I think I'd aim for something in the order of 50-100.

The percentage of points does seem to increase with the complexity of the object/scene rather than potential distortion errors. Using image sets from a GoPro on "wide" most of the bad points were taken out by the reprojection error, with relatively few points being taken out using an uncertainty of 50 after that (but those that were removed were mostly around the edges of image pairs. With images from my DSLR the spread of points was more even and I chickened out at 70 as they were much more evenly scattered but it may have still been a comparable increase in quality.

It may be worth adjusting the size of the initial sparse point cloud to suit the scene complexity with the goal of using a single value (or at least more consistent values) for reconstruction uncertainty. Something to keep an eye on while I get some more experience.

54
General / Re: Prepare Models For 3D Printing
« on: June 08, 2014, 06:53:50 AM »
That is a nice workflow for creating a shell.  We've been using Meshmixer and extruding the surface. This was reasonably practical but only with some manual editing of the inner surface to remove problems that just doesn't occur with this which is a big time saver.

55
General / Re: Clarification of Reprojection error
« on: June 08, 2014, 04:13:39 AM »
So far I've found significant improvements in the range of 150-50, although at lower values it might take out too many points causing other problems. If there are significant gaps in the sparse point cloud using 50, this seem to be an indication of not enough images from different positions for those areas, which might make a useful quality check while shooting objects/buildings(?)

Definitely a big help for buildings and I'm starting to get some promising results. (http://studio.verold.com/projects/53939f62ac832c020000039f)

56
General / Clarification of Reconstruction uncertainty
« on: June 07, 2014, 07:25:15 AM »
I'm working through improving the quality of the dense point cloud and found this helpful explanation.

"Reconstruction uncertainty". In case you have only two cameras and a point is being triangulated by intersection of two rays there is a direction in which the variation for the point position is maximal and another direction with the minimal variation. Dividing one on another (max to min) we've got reconstruction uncertainty value. Mostly this criterion is designed for visualization and estimating the errors. In general this value characterizes the accuracy of positioning points in cloud.

"Reprojection error" demonstrates the accuracy of point positioning and is specified in pixels. We recommend to remove points with huge reprojection errors before optimizing photo alignment.

This has been really useful and is probably worth putting in the wiki.  I'm just trying to properly understand how the numerical value for Reprojection error Reconstruction uncertainty relates to quality (and thus what a practical minimum value would be). Is it relative to the input image size or does it relate to the size of image pattern that PS uses to "recognise" features.

I've managed to remove too many points a couple of times which is handy as I now know what effect that has on the dense point cloud.

57
General / Re: How to show online high resolution maps?
« on: June 05, 2014, 01:30:00 AM »
duh... forgot Leaflet  http://leafletjs.com/features.html + omnivore plugin to read kml https://github.com/mapbox/leaflet-omnivore

58
Don't worry, I'm well aware of the requirements for shooting panoramas. I was a beta tester of PTGui, and helped determine a practical order for optimising image parameters for auto-alignment  ;)

Yes it can be done with pano stitching (even though autofocus will fail at times), but in order to do it to the necessary standard requires a great deal of precision which complicates the equipment setup. I'd love to use a Rodeon but for this collection we're only looking at 0.5% of the images requiring this technique, and this drops dramatically when you look at all of the material that we scan. I couldn't even justify the expense and effort to my self let alone sell the idea to our execs.

With this method I can get a fully functional prototype for under $1K including the software upgrade using mostly available equipment. The usage of that can then establish whether there is a case for investing in additional equipment to streamline the process.  From what I've read here there may not be a 16bit workflow at the moment but there is a 32bit workflow.

59
@Marcel: I thought about moving the print as well. Both methods have their challenges.  Ultimately, moving an A0 foldout attached to a thick A2 book with binding falling apart would require a very sturdy platform to avoid any changes in the position of the foldout. I think moving the camera will be simpler for our purposes.

With the Canon 5D we'd be (hopefully) looking at imaging A4 sections of the print. At the angle used in this test I think you're right. The depth of field was pretty good but there was a bit of drop off in sharpness across the image. We have wired releases for our camera, and for this test I was using the self timer to avoid camera shake. Getting rails built shouldn't be too much of a problem but I will have to make a case for it and it will take a bit of time.  A counter-weighted pole might be a better interim method for positioning the camera while we sort out the exact specifications for a set of rails.

@Mfranquelo: I'd considered a 400mm lens and a motorised telescope mount run via Papywizard, but apart from that being a few extra pieces of equipment to purchase without a proof of concept, our experience with stitching A1 scans of large maps with folds in them (also using PTGui) is that the small perspective differences can be problematic. While there are workarounds for these I think the principle of photogrammetry is a better fit for this particular application.

60
Thanks guys, that's very helpful.  I had considered making a rig when we were looking ay pano stitching software but the fact that these aren't perfectly flat ruled out moving the camera in that instance. A rig would be more sensible in the longer term, but I'm looking at a proof of concept to get the ball rolling for now.  The angle of the camera at least does not cause problems with depth of field across the individual images. I exported an ortho image from the standard version and it looked really good, although I'll have a closer inspection when I get in tomorrow. Now I'm excited... again  ;D

I also don't have the RAM to handle the resolution I really want so our 100mm macro will suffice for now rather than my personal 70-200mm zoom. It's also our sharpest lens so we'd use that with a rig setup. One less thing to buy.  Looks like I'll be talking to our high performance computing guys for a virtual machine with lots of RAM.

Pages: 1 2 3 [4] 5