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 - JMR

Pages: 1 ... 30 31 [32] 33 34
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

JMR, Geobit

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.
best regards!

General / Re: What cameras/lenses are preferable for photoscan?
« on: October 15, 2013, 12:16:53 AM »
Hi, hengefjes
I have that lovely lens (zd7-14). You'll be amazed by its DOF . But I must admit i have no tried it with pscan. Ill take a bunch of photos and share them with you asap.
Btw, have you considered the same 7-14 by panaleica an available in mft mount? I have used it sometimes an its pretty good also. (It is not weather sealed nor that superbly well built as Zuiko, but is better balanced in a micro fourthirds body.

General / Re: 2D Line Drawing from Photoscan Model
« on: October 09, 2013, 01:37:17 PM »
The most obvious answer to yusakus question (2D drawings) is to export orthophoto of the desired views and just draw on the orthos as raster reference with any CAD, isn't it?


General / Re: UAV for Canon 5D
« on: October 09, 2013, 01:28:15 PM »
Octos are slower in reactions due to their much bigger size; this doesn't mean more stability but more inertia. IMHO the most responsive and robust flight is achieved by quads with four or eight rotors. The strongest point of Microdrones aircrafts is simplicity and endurance. The propellers are huge (75cm) and the motors have been designed specifically for this drone. The flight is not agile and it looks heavy just because changes in rotors speed are not very fast to allow quick reactions against wind or at pilot input. But in exchange it offers unbeatable endurance and very usable lift power. Many people think the price is ridiculously high... I must agree it costs a lot, but the price starts making sense when you use it every day and feel you can trust this robot for years while others are crashing every day. A crash in this business costs a lot more than just the repair and the bill of materials. One single accident can cause your bankrupcy, the ruin of your professional prestige, not to mention casualties, judgement, or complaints.
BTW, the Cinestar8 is a good frame, but I'd say frame quality just one factor among many others.
Regards JMR

General / Re: UAV for Canon 5D
« on: October 07, 2013, 10:16:53 PM »
I would encourage you to not use such a heavy camera... I think there is no good reason to put this beast on board of any drone.
The only reason could be its great video capabilities, but a if you are not a videographer you wont find any worse the cheaper and LIGHTER Panasonic hacked GH2 with the right lens. If you just want stills, what is likely your case, forget this camera and do a favour to yourself. Then you'll easily find dozens of nice multicopters and planes capable to provide over 15 mins of flight-time.
My choices would be:
Olympus EPM-2 + mzuiko 12-2.0, 17-1.8 or panaleica20-1.7 (Unbeatable IQ for the size, easy to trigger by wire)
Sony Nex7+ 16mm  (much higher resolution but not too many good lightweight lenses match that sensor)
RicohGR (great in all senses but fixed lens -that is not bad at all-)
SonyRx100 (cheap flexible option)

If you want further recommendations on multi-rotors please PM

Your beast+lens bundle is hardly to be under 1,2kg not to mention the money you put on risk. In case you are stuck to the canon, then I'd say Microdrones MD4-1000 is the most reliable drone in the civil market... its expensive too.

Don't ever fly over crowds, avoid built populated areas as much as possible, don't forget to check everything once again. 

General / Re: Keeping world coordinates a in zbrush
« on: October 02, 2013, 10:05:10 PM »
Yes, it is in Pscan Pro. Export model... then choose a filename and folder and a dialog then opens with the options for coordinate system and shift vector.

General / Re: Keeping world coordinates a in zbrush
« on: October 02, 2013, 01:05:55 AM »
Hi Gawin
In the export dialog you should choose the coordinate system of your project and write a traslation vector that brings your model to "near" (0,0,0). I usually take the integer part of the first GCP coordinates (with the same sign), take a screenshot of the dialog and save as "traslation.jpg" in the same folder as translated obj just in case.

Then go to zbrush and cook the mesh.

When you ar ready to reimport, use the very same coordinate system and vector including the same sign. If Zbrush does not change scale or anything else, I guess you will have the model back in its right world coordinates. Please tell us if works

Good luck

Feature Requests / Re: querying and extracting coordinates from a model
« on: September 18, 2013, 10:40:37 AM »
Hi simcklethwaite
That has always been posible. Just put markers in the model on desired locations once it has been georeferenced and see their estimated coordinates by clicking "view estimated" (second button from right in GC pane toolbar). You can also export their coordinates if you check "save estimated values".

Feature Requests / scale bars
« on: September 17, 2013, 11:25:27 AM »
1. Exportable to text file just like the rest of ground control actors.
2. Default name should be that of the two markers a scale bar links, for instance "point 1-point 2". A comprehensive link between a scale and the markers it has as end points, should survive to any renaming and/or must be explicit as a property of the scale bar
3. I'd rather prefer the old fashioned tool for picking scales on model window better than choosing two GCP and right click for calling contextual menu.
4. Scale bars could be exportable as segments in some cad formats. That would allow a primitive form of restitution.
Regards! and congrats for my favourite

Feature Requests / Re: Scale in Otrhophoto exporting
« on: September 17, 2013, 11:03:00 AM »
I'd suggest to have full printing capabilities built-in.
I'd love to have on board dialog for direct output to pdf, to system printer or to image file
It could boast a handfull of useful settings such as:
Resolution, scale, position on sheet, rotation, coordinate grid superimposition, scale bar, GCP on/off, etc.
Also print as point cloud with some options for handling point rendering and size would be just great. Dense point cloud printing for small scales sometimes yields to nice true orthos much better than those out from mesh-based orthorectification.

General / Re: twin cameras processing for aerial photogrametry
« on: July 01, 2013, 05:11:52 AM »
I guess the aerospace's question is not being well understood. If I'm right, the advantage he would want to exploit comes from the wider field of view as a result of the sum of that of a pair of divergent cameras that might overlap even by just a small but constant percent.
I would not expect this setup to work well in general because  Photoscan would try to orient each photo in the pair as an independent camera, not only in terms of intrinsic parameters but also exterior ones. The closeness of the two photo-centers in a pair would lead to weak resections with bad results.
The plan could work if you managed to split the projects in chunks that had no pairs inside. If the successive strips are flown in opposite directions then you could form chunks with every two successive pass halves.
==============}chuk one with R photos
==============}chunk two with L photos
...etc. This planning would require ground control for every two rows... And that sounds bad.
just thinking, a better solution could be to alternate trigger of left an right cameras so they did not fire simultaneously, this would work well if you let left an right camera overlap over 30% a variant that could also be possible with one single camera capable of tilt from left to right in cycles... Mmmm sounds feasible, but still much more complicated than shortening the focal length of your camera.
By the way, what cameras are you flying with?

General / Re: Simple workflow question - build geometry?
« on: April 09, 2013, 05:20:24 PM »
this is not correct. The actual bundle adjustment (which computes camera calibration and orientation parameters and creates the sparse point cloud) happens during camera alignment. The sparse point cloud contains true 3D points. Nothing 2D here.
Let me respectfully insist in that it is correct from my point of view.
Feature points are detected in every single image (2D) before orientation, and are paired by comparison of clusters of pixels (2D to 2D).
lots of statistically-approved couples (x,y) & (x',y') enter in equations that yield solutions to unknowns:  lens parameters and also center and attitude of cameras and at the same time x,y,z for the feature points are calculated (so, no role is played by the third dimension until now). So the result is 3D but features are two dimensional as they are just singularities in the appearance of a certain groups of pixels not necessarily linked to actual shape-features but to photo-features.

General / Re: Simple workflow question - build geometry?
« on: April 09, 2013, 02:33:01 AM »
Does "build geometry" improve the accuracy of the original point cloud points or does it just add more points/facets?
Yes. As far as the sparse cloud is built on matched "feature points", it does not have nothing to do with the actual terrain topography but just with some points identified as features because of their appearance in the photos (vicinity contrast or whatever that made them distinctly identifiable for some detection algorithm). You should understand this is just a 2D step
This nature makes them well-suited to provide optimal correlation values and thus are great for inner and outer camera orientation parameters estimation.
If you build geometry you should get a better terrain description even after a strong decimation (now the third dimension matters) to a number of points below the population of the initial sparse cloud.

I wouldn't expect to infer good breaklines from the sparse point cloud but on the contrary you would see them neatly rendered after dense model decimation.


General / Re: UAV photos look reversed after align (canon 1400sd)
« on: February 19, 2013, 04:34:08 AM »
1 yes it is normal... or let's better say it is the way it happens. I find it weird too
2 Not normal at all. Help Pscan with three or more pass-points (shared markers between chunks).

Pages: 1 ... 30 31 [32] 33 34