Messages

451

General / Re: Matterport (interior scanning)

« on: May 28, 2014, 08:47:31 PM »

As far as I know, the working principle of Matterport as well as Kinect, is structured light scanning. It is quite a simple ranging method based on triangles with known baseline and two angles, but their accuracy degrades very fast as distance to object increases.
It has a lot to do with photogrammetry and Photoscan fundamentals. Here a structured infrared pattern is projected onto object surfaces playing a similar role of the object's texture we exploit in Photoscan. The relative orientation between camera(s) and projector is fixed and well known, as it is camera lens intrinsic parameters, so there is no need for camera calibration nor ground control to solve a single shot.
The advantages are:

• it is an active sensor (no need for external illumination to get 3D)
• is non dependent on object's texture
• 3D from one single point of view (just apparently)
• Fast! very fast!

The disadvantages are:

• Bad accuracy and poor resolution at long range
• poor color rendition
• frame stitching on the fly, not easy to access raw data to improve alignment or use image-picked ground control

452

General / Re: TUTORIAL AGISOFT 1.0.4

« on: May 20, 2014, 02:45:15 AM »

Good day, have any tutorial or video for version 1.0.4 Thanks
Buen dia, tiene alguno un tutorial o video de la versi?n 1.0.4, gracias

si alguien sabe del programa y habla espa?ol excelente.

Hello: this is Jos? Mart?nez, from Geobit Consulting, Agisoft's reseller in Spain. I'd be glad answering your questions in spanish if you contact me at info@agisoft.es or here by private message. We do have some tutorials in Spanish that are up-to-date with recent releases. Regards

453

General / Re: Presenting hundereds of models

« on: March 27, 2014, 12:53:31 PM »

I think you are just talking about batch obtaining ortho views of your models rendered in monocrhome shaded mode at a known scale... am I right? this can be very easily done outside PhotoScan. Please, PM if you need support for that task
Regards

454

Face and Body Scanning / Re: 35mm for head scans

« on: February 27, 2014, 04:32:10 AM »

Lee, I can accept that your experience has brought you to choose normal primes as best option for face photo-scanning. I agree with your very valuable opinion that it gives better results. I admire your work and always tell my studens that you are a reference for anyone working with body and face scanning, so please don't look for criticism in my post.

Why wide angles seem to work bad for face scanning?
While normal and tele fotos give nice portraits, wides give unpleasing and weird portraiture. the exagerated perspective makes them ugly even with the most perfect lens in the world. But this is not the actual issue but the fact that any move in the camera makes face shape change rapidly and that consequently makes harder to pair feature points as they match worse.
Wides usually suffer noticeable distortions. True. But sistematic errors caused by distortion can be sistematically corrected, so the question is not the existence of distortion but our ability to measure it exactly. This makes it necesary that the object "collaborated" filling the whole frame and provided lots of well paired feature points even near the corners. Just the opposite we'll likely find in a human face photo: empty corners and rays being increasingly tangent to the head towards the borders.
So the actual problem does not fall on that practice did not follow theory rules, but on how hard it is to calibrate a camera from shots taken to a sphere-like shape when distortion is far from negligible. If you had used a well calibrated set of wide angle primes, you wouldnt have found any abnormal distortion in the point cloud but just poorer texture rendition, and thus probably a noisier mesh model.
Again congrats for your work and thank you for your enormous contribution to this forum.

455

Face and Body Scanning / Re: 35mm for head scans

« on: February 26, 2014, 06:25:34 PM »

Photogrammetry theory tell us that short focal lenght strengthen solution in terms of photo orientation quality, so Lee is (in theory) wrong  when he states short lenses give less accurate results.
Let me explain why with an analogy: Imagine a pyramid whose base measures 50x50mm and has a height of 25mm standing on your table. Now imagine that you put under one of the vertices of the base a block of 1x1x1mm size.
You can understand that the whole body may oscillate between two extreme positions resulting in the position of the apex varying by about 1mm.
You probably understand that if this pyramid was 500mm in height, the travel of the apex would be much longer.

Let see that block as an error of one pixel in the picture. Well understood that, although the photo (pyramid) covers the same footprint in de object, being the error identical in photo-coordinates, a longer focal lenght (pyramid height) determines greater uncertainty in the orientation.

On the other side, considering photos pair-wise, it is also evident that for a certain fixed baseline/distance, ray intersections for wide angles are better than for teles.

So imho Lee's statement is not right. What it is doubtlessly right in his statement is that normal prime lenses gather richier texture than wide ones if the latter are not set closer to the object to capture similar footprints.

456

Feature Requests / Re: Region Orientation, no fine control..

« on: January 27, 2014, 12:30:39 AM »

++++1

457

General / Re: Model is not on origin when importing

« on: January 20, 2014, 03:32:08 PM »

It might have to do with scale too. sometimes I edit my models in thirtd party software, and when I import the edited mesh, it comes scaled by 1000. You may try to open the file in meshlab and measure some a known distance to check if the model has diferent units than the original.

458

General / Re: non vertical images - make 3d point cloud?

« on: January 05, 2014, 12:42:41 PM »

Absolutely! in fact if your hill has very steep slope or scarps, oblique photos may deliver better models in general. Just avoid to take hotos with the orientation that sums the terrain inclination to that of the camera.
Regards

459

General / Re: Importing IMU

« on: January 04, 2014, 07:39:05 PM »

It is actually used since long time ago.
Add photos
select the coordinate system of your IMU data (likely Geographic WGS83)  import a file with photoname.jpg, lat,lon, elev (I'm not sure if yaw, pich and roll are also considered)
goto align step and choose "ground control" as method for preselecting pairs
this actually helps PS to skip photo pairs that are unlikely to overlap, but this is not a new feature.

In further processes, like orientation refinement, camera coordinates may also be used. In the ground control pane, you can see the photos with their coordinates that can be checked for the absolute orientation if you consider them good enough to participate in the external orientation. See that in the settings dialog you can fix the camera accuracy which is set to 10m by default, so even if checked, camera positions are usually low weighted in the bundle adjustment calculations.

I guess no new role for the IMU in this version

460

General / Re: Importing IMU

« on: January 04, 2014, 03:23:02 AM »

Hola Ola:

the IMU log contains recordings of all sensors that provide data to the flight controller. You may find them in many formats but you probably can have a parsed ascii file with a sequence of records formed as a selection of fields. If your system boasts a very good positioning system (gnss dgps) and you have accurate information about the offset between the camera center and the IMU origin then you could better estimate the photo-centers and use them as true ground control for the whole project.

But  even if it was inaccurate by some meters,  this a priori information can speed up considerably the alignment step if you import the photo geo-tags as ground control for pair preselection.

If your system has been well designed ("well" here stands for "for photogrammetric missions") probably your camera is commanded by the flight controller itself and is likely to exist a way to obtain an specific record for the shutter actuation along with the corresponding XYZ and camera attitude descriptors. This log is easily matched to a photo folder if the number of files and photo action records are coupled. So you just need to build a text file with photo names and positions

If this is not the case; I mean, your aircraft does not control the camera but is a time-lapse or the user who presses the shutter, the matching task becomes sometimes hard if not impossible to do, because you have to be able to know exactly when the photo was taken prior to know where was taken from, and time-stamp in photos is usually of poor time resolution (seconds in best case).

PD. According to the last information I can remember, Photoscan just makes use of camera coordinates and dismisses pose information so don't waste your time with that
Regards

Geobit

461

General / Re: Camera based chunks alingment

« on: January 04, 2014, 02:28:26 AM »

Hi, Osima: Have you made sure that chunk 1 is bold in the list within the chunk align dialog? if not double-click on it before alignment , this fixes it as anchor.
You might also have to check fix scale if you have already scaled the first chunk.

Regards

462

General / Re: Will a GPS camera improve the accuracy of DTMs?

« on: November 04, 2013, 06:55:05 PM »

I think having on-camera GPS can't improve results over decent GCP but CAN help to speed up alignment stage and  even to avoid not-aligned images. It would also help during GCP marking because model is roughly geo-located prior to entering them, so when you import points, they should appear floating somewhere near their actual position and you just have to drag them on each photo to their right projections.
But let me add that better cameras usually don't boast on-board GPS, so you'd better extracting rough(<2m?) photo coordinates out from the UAV flight log. That makes unnecessary any on-camera crappy(<5m?) gps and gives you better and broader camera choice.
Regards!

Jos?
GEOBIT

463

General / Re: Rendering mosaics of ndvi images

« on: October 22, 2013, 06:32:04 PM »

Hello Alvaro:
For some reason Photoscan does not find as easy to align NIR imagery as it does with visible.
I have tried too many times doing the same flight mission alternatively with NIR and Visible cameras. Same camera-lens combo, same height, same, day and almost same time... no matter what I've tried the fact is that Photoscan always succeeds orienting visible while very often fails with NIR datasets.

IMHO the problem comes from the lack of contrast and crispness in later photos. Take into account that most lenses are designed to deliver good images for visible wavelengths, therfore, most of them suffer from all optical diseases one would like to avoid (comma, chromatic aberration, focus point shift...) with regard to NIR radiation. It usually doesn't matter as hot-mirror filter cuts away NIR but... this is not gonna be the case of your modified camera.
Sometimes you have lenses that produce NIR images that are well focused in the center but are completey blurred near the borders, this is the case you most probably have, so make sure a particular lens works well before paying. Hot-spot is another very common issue; just take care!

Focus ring scale becomes useless and I see no rule behind that behaviour: In my beloved mZuiko 12mm, the lens is decently focused at infinite when the scale index is at 2m (yes, two meter equals to infinite !). On the contrary, in my Voightlander Color-Skopar 21mm the infinite focus is shifted in the opposite direction to a certain point beyond the infinite labeled mechanic limit of the ring, so I cannot get foccused photos at all but stopping down aperture a lot which carries worse problems on board of a plane.

So, I can say it is almost mandatory to have ground control from geo-tags as a priori help for Photoscan to align. Even in that case, you will likely find some photos not getting aligned that will need some "hand-work".

Best luck
PS: If you found a good lens whose rendition was good enough both in visible and NIR with reasonable angular, please tell me.

464

Bug Reports / Re: chunk normals inverted during merging.

« on: October 22, 2013, 02:15:11 AM »

Yes, Alexey, the problem is still there with latest build. I'll drop link to the huge project file by PM
Do just merge chunks and will see it for sure
Regards!

JMR, Geobit

465

Bug Reports / chunk normals inverted during merging.

« on: October 21, 2013, 05:57:38 PM »

Hi Alexey: I'm testing the beta 1745
I have a project with three chunks. All have been correctly oriented and all dense clouds and models show the right orientation, but the resulting model of a merging command yields to a dense cloud that shows one model (chunks 3) has been inverted without a good reason.
If I switch multiple chunks visible ON, the three originals are right while the merged is partially inverted.
https://www.dropbox.com/s/jj8hrzc9ahcxztp/CHUNK1.JPG
https://www.dropbox.com/s/zqan2dbzjc8dsvr/CHUNK2.JPG
https://www.dropbox.com/s/fqu2ubdd6fz2s0b/CHUNK3.JPG
https://www.dropbox.com/s/97pdrd6w0395ey9/MERGED.JPG
best regards!