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

Pages: [1] 2 3 ... 46
General / Re: "Zero Resolution" Error
« on: August 05, 2020, 11:55:37 AM »
In that case my guess is it's probably something like this

If the focal length was wrongly estimated then that could potentially compress the z values of everything so even an undulating or badly aligned surface could come out flat and the camera altitude could also be compressed, leading to positions on or close to the surface. At least that's how i explain it to myself without being very aware of the maths involved!

If you look in the camera calibration window, and compare the initial and adjusted focal lengths, they should be fairly similar, assuming the initial estimate was sensible, but if metashape has estimated a really dodgy focal length it could be wildly different. My guess from the numbers you gave is that it should be about 3500px.

In that case perhaps if you have a previous project that worked well with this drone/camera you could export the camera calibration from it to use here, or otherwise i believe it is possible to manually enter and fix the focal length. I'm a bit out of practice so don't remember the exact procedure, and don't have the software handy to look at - i normally just trial and error these things anyway!

Other things to try might be enabling rolling shutter correction (i found it worked best enabling this at the alignment stage, rather than only in subsequent optimisation), if your drone camera is of that type. Also maybe unchecking/discarding camera orientation (yaw/pitch/roll) values in the reference pane if they exist and are likely to be inaccurate at all (i'm not sure if that helps but i'd try it if it was me!)

General / Re: "Zero Resolution" Error
« on: August 04, 2020, 05:13:16 PM »
it seems like Metashape thinks, that the images were taken from below the ground (“Screenshot CameraPosition”).

Where metashape thinks the images were taken from is the 'free' end of the black lines, i.e. not the end with the blue rectangle. The blue rectangle just shows the direction. It's not clear in your screenshot if the 'free' ends of the black lines are above or below ground. if you turn the mousewheel while holding either shift or ctrl (i can't remember which) it will scale the camera symbols which might help it look more like what it ought to.

With that tie point cloud I am able to calculate the dense point cloud but it looks like “Screenshot DenseCloud”, which obviously is rubbish.

I think that the zero resolution error is to do with insufficient data within the bounding box or 'region'.

If your bounding box was not set properly it might not contain all of the data, and would explain why your screenshot shows a dense cloud of very few bits, which just happened to fall inside the misplaced 'region'. Your first screenshot, showing the cameras, seems to show the bounding box/region set appropriately, but it may have been subsequently moved, or left in place while all the data moved, somehow, maybe. You can use the 'reset region' command somewhere in the 'model' menu, i think, to reset it to include most of the data, which might allow you to build a proper dense cloud.

General / Re: Huge marker error (over 1000 KM)
« on: August 03, 2020, 06:00:33 PM »
i think i get it now.

the 4 positions where it shows the cameras bunched together are the 'source' coordinates for those images. for whatever reason there is some rounding error which 'snaps' them to those 4 positions. perhaps it has a built in gps which is only precise to a few 10s of metres or something, which also explains why it's rounded differently in x (eastings) to y (northings).

the other 'ends' of those ellipses show the 'estimated' camera positions which matches with and are correctly shown in the 'survey data' section of the report. i've overlaid the two plots attached to show that.

you should go to the cameras section of the reference pane and 'clear' the coordinates for the drone pictures. (select the rows and right click-clear).

the list of markers you showed me... are they the source coordinates or estimated coordinates? if estimated then perhaps the above will sort those out. if there are the source/input coordinates for the markers then that is also contributing to your problem as there is such a discrepancy in the locations given for the first four markers compared to the other six.

General / Re: Scanning small objects
« on: August 03, 2020, 05:45:14 PM »
i searched google for "5cm shiny orange plastic piece" and "5cm shiny jet black plastic piece" images, and the results were invariably things that would not be reconstructed well via photogrammetry due to the lack of surface texture.

have you had success with non shiny-small-plastic pieces? If not, then i suggest that's where you start, because shiny pieces are notoriously difficult and so are small pieces, so small shiny pieces are going to be even harder.

If you're sure that your photo quality is not the issue, and that you are getting sufficient detail, and that you are doing the masking things correctly, then i would suggest you increase the number of photos, maybe even hundreds as opposed to dozens, so that each one has a greater chance of matching with an adjacent similar looking one, which may have been why the video thing worked.

Other general things to try include adding a non small-shiny thing in the scene to help the software find matching points, such as a sheet of newspaper underneath. Make sure the frame is filled as much as possible with your object as opposed to the background. Also try adding more light or working outside rather than increasing exposure time.

General / Re: Duplicated points in dense cloud
« on: July 29, 2020, 12:30:18 PM »
Could it be that the data you are exporting just doesn't have enough precision to differentiate between very close points?

Assuming that you are exporting it to find the duplicates, maybe try increasing precision in the export options to increase the number of decimal points in the data.

General / Re: Huge marker error (over 1000 KM)
« on: July 24, 2020, 01:16:38 PM »
In the reference pane, you can right click on the markers with the high errors, and select 'show info' (i think) and i think this will then list the error in each image for that marker. this could help you track down the problem if only a small number of images have a very large error.

Alternatively, it looks in the report as if a large number of images were taken from identical positions (the ones with the big ellipses). If the particularly bad markers 1-4 only appear in images from one of those single vantage points then they will actually be fairly useless and the errors completely meaningless.

General / Re: Planning before Merge Chunks Question
« on: July 23, 2020, 02:41:54 PM »
If the chunks are not georeferenced you will need to run 'align chunks' before you merge them.

You can specifiy 'by markers' as the method to align your chunks, and you will need at least three common markers in each pair of chunks you try to align.

And yes each marker that represents the same position, i.e. 'a rock',  should be named identically in each chunk in which it appears in order for the align chunks method to detect which markers to match between chunks.

General / Re: Measure Volume - Units
« on: July 17, 2020, 04:48:18 PM »
That's all there is, as far as I'm aware  :(

General / Re: Measure Volume - Units
« on: July 17, 2020, 11:36:09 AM »
You can change the units that measurements, including volume, are displayed in by setting the measurement units in Tools -> Preferences -> General -> Measurements -> Units

The difference can be seen if you check in Tools -> Mesh -> Measure Area and Volume

I'm not sure where else volume might be displayed so I haven't checked anywhere else.

General / Re: Orientation and Scale
« on: July 15, 2020, 01:15:01 PM »
If you have the 3 sets in separate chunks in the same project, then you can quickly align them to the same scale and alignment if you do 'align chunks' using the 'camera based' method.

This assumes that your cameras are well distributed in each of the 3 sets, i.e. not just in a straight line.

General / Re: Question about the line
« on: July 15, 2020, 11:37:40 AM »
I believe that's an epipolar line.

See figure 3 from here, attached below.

The 3D point X is only placed in one aligned image (the left hand one) as x, so all that you can say about it in the right hand image is that it must fall on epipolar line l'.

(All epipolar lines in the right hand image originate at/intersect the epipole e', which is the point at which the point from which the left hand image was taken appears in the right hand image, although in practice this is not necessarily within the right hand image's field of view.)

So all it means in your example is that 'point 6' has only been placed in a single aligned image, and in the aligned image you are looking at it should appear somewhere along the indicated dashed line. Once you place it in that image there will be enough information to locate it as a 3D point in space, and so subsequent aligned images will show it in that location, rather than as a line of possible locations.

Feature Requests / Re: Workflow - New Instance option
« on: July 10, 2020, 01:11:29 AM »

Also, related to this request, I think

Bug Reports / Re: Color correct - meta shape
« on: June 30, 2020, 11:25:59 AM »
The four filenames shown in the 'quad picture' correspond to the different blending modes/parameters available in the Build Orthomosaic dialog.

They don't correspond to the colour correction modes which have now moved to the Tools -> Calibrate Colors... menu.

Please try using Tools Menu -> Calibrate Colors option before orthomosaic or texture generation process.

Not contradicting anything that Alexey said, and this may be out of date, but assuming you do have "auto-rotation" disabled in the camera I believe that it is still generally a good thing to have images taken in both landscape and portrait orientation, so long as those images all have the same pixel dimensions, enabling them to be treated together in the same calibration group.

the mix of portrait and landscape orientated photos [...] is generally a good advise for camera calibration

But regardless, if you get good results doing what you are doing, then the benefits of going out of your way to do this are probably very small.

General / Re: precision in export dialogue box
« on: June 19, 2020, 05:23:04 PM »
It's the number of decimal places used to store the coordinates of model vertices.

I sometimes use it to reduce file size if i don't need 6 decimal places, i.e. if my project units are meters, and the polygon size is in the order of centimeters, then i may not need sub-millimeter precision so could turn it down to 3.

Conversely if you're working on a geographic scale, with degrees lat and long instead of local coordinates, then 6 decimal places might only give you centimeter level precision and you may have to increase it depending on your application.

Pages: [1] 2 3 ... 46