Messages

1

General / Re: How to center and straighten up rotational models?

« on: April 22, 2022, 04:35:24 PM »

Could MS (Std & Pro) just have a 'Turntable' setting in the align dialog?  Or even a bit auto-detection?

Turntable scans are 'always' vertical (unless you're scanning on a lathe! lol)... which means the axis of every scan level should be vertical too, and should also be coincident (unless handheld)...  Which gives you the axis of the turntable itself.
Surely ms can calculate this axis of any level of aligned cameras, and then, as the 'Turntable' setting is checked, it would correctly orientate the scan vertically, and the right way up... ...using the assumption that most scans will be 'looking down' on the object...  but perhaps with an 'inverted' checkbox or tool, if the scan is say of a monument, scanned by hand, whereby all levels may be lower than the object.

MS should be able to correctly orientate almost every single turntable scan.  With the axis on the z axis.
There should be no need for any markers or any extra work to have these correctly orientated.

But again, IF we could have a subset of the reference system, with a few markers available in the Standard version, it would be so, so useful!!!

2

General / Re: Boost computation speed for photo subalignment

« on: April 20, 2022, 08:30:34 PM »

@geo_enth3
From HW perspective:  you are slightly loosing time in first phase(detecting points). Preparing data for GPU is single threaded task and If I am correct photos are decoded/resampled from JPEGs/... to uncompressed format in system RAM and from there data are sent to GPU. Your CPU has max. single thread clock 3.3GHz and according my tests detecting points speed is roughly linearly dependent. Latest desktop intel/amd CPUs has single thread clock attaking 5GHz and improoved internal caches, so preparing data for GPU is ~ linearly faster. Downside(maybe not) is support only 128GB(INTEL, did not check AMD) of system RAM. So for example: in detecting points phase you see very low GPU utilization.
As you mentioned, that you are adding just 100 images per day, then probably it is not worth invest into CPU which has high single threaded clock. But for completelly new project with thousands of images on day one it starts to make sense.

You can speedup image matching process if you enable use CPU when performing GPU processing in preferences. The speed increasment depends on how quick your cpu can prepare data for GPU and at the same time how many images can cpu cores process in comparisson with gpu.

Do not know if subalignment task needs selecting pairs and matching points tasks in such scale as in completely new project, but still, both tasks utilize heavily GPU, so you can only benefit...take graphics card which has higher raw GFLOPs performance.

If these tasks are single threaded...  are they doing/could they do concurrent decoding/resampling of multiple jpgs, to then feed the GPU?
If you have an 8C/16T cpu, could it spawn 8 or 16 decode/resample jobs, or perhaps only 4, or whatever, if it wasn't such a bottleneck?

If a task is stuck being single threaded, but working on discrete lumps of data (a photo), then spawning concurrent jobs seems to be obvious?
Possibly MS already does this...

My multi-day alignments could really do with some 'leaps' in processing performance to cut that time down... 

3

General / Re: Boost computation speed for photo subalignment

« on: April 20, 2022, 08:17:36 PM »

I'm doing something similar and there is one setting that I ignored until recently, but setting this value has made my alignment process much faster and more accurate: Capture Distance. Try setting that and see if it speeds up the next alignment you attempt.

You should also be using Estimated preselection in addition to Generic preselection.

Does Capture Distance help if there photos/camera don't have any geolocation info?  Like gopros, underwater?
If not, could it in the future?

4

Bug Reports / Re: Exported/Imported DEM Palette w/absolute values adds 00 to each value.

« on: April 18, 2022, 09:28:06 AM »

No, it comes in as 4000, 3100, etc...  So i have to delete two zeros from each.
And the Absolute values checkbox isn't set, so needs resetting...

So importing is fine.
It's the exporting that adds the two zeros...
And i guess the exported file doesn't include the state of the absolute values checkbox... And the importing doesn't set it.

Thanks

5

Bug Reports / Exported/Imported DEM Palette w/absolute values adds 00 to each value.

« on: April 10, 2022, 12:57:00 PM »

When i've exported a DEM Palette from the Set Palette function, and then re-imported it, It doesn't come in correctly.
* The 'Absolute values' option isn't restored if it was set when exporting the palette.
* Each absolute value has two extra zeros added, so 5 becomes 500... 30 becomes 3000.

Here's the contents of one of my saved DEM Palette .clr files:

Code: [Select]

ColorMap 1 1
-4000 91 0 0
-3100 170 0 0
-3000 0 0 255
-1900 0 85 255
-1800 0 85 0
-1300 0 204 0
-1200 0 85 255
-600 0 170 255
-500 0 216 0
0 0 106 0
In the above file, the orginal values should be absolute and would have been -40, -31, ... -6, -5, 0
Note, my values are negative, as this is an underwater scan.

Thanks

6

General / Re: DEM overlay to model

« on: April 10, 2022, 09:18:12 AM »

154,855,509 

From 17,441 cameras...
It's a big area, and is scanned at only 4-5m altitude...
The 17,441 cameras are what's left starting with 40,000 photos, each 'flight' aligned and thinned down using Reduce Overlap of 9, then all 15 thinned 'flights' combined, aligned and reduce overlap to 9 again...

Here's the extents of the scan so far.  Mantas & Divers photoshopped in for scale.
(click https://postimg.cc/K1sXypzs to see a bigger version)

7

General / Re: "Capture View" - Contour lines disappering when export high resolution image

« on: April 09, 2022, 05:41:26 PM »

I'm also facing this problem.
I need to make large format (A1-A0) physical prints at 100-300 dpi, so those lines just disappear.

Also, the DEM Palette values legend, scale bar and x,y axis disappear too.

Could these item sizes, thicknesses, be determined by a ratio/% of the viewport, rather than absolute pixel sizes?

Thanks

8

General / Re: DEM overlay to model

« on: April 09, 2022, 04:35:49 PM »

Please check, if it works as expected on your projects now.

This does work exactly as expected, thanks.

It sure does love RAM    I've finally found the function that actually requires the whole 64GB of my system ram.

9

General / Re: DEM overlay to model

« on: April 06, 2022, 06:09:16 PM »

For the Dive Site Map model we're working on, we're using absolute values...  So i've set colours at 0, -5, -12, -18, -30, -40, etc...
We'd likely only use the absolute values.

This would be awesome if it did just follow the DEM Palette...  We're experimenting with different shades of different colours for each of the depth bands...  This will make reading the map very, very easy for the dive guides, students, etc.

Thanks for looking into it!

10

General / Re: DEM overlay to model

« on: April 06, 2022, 03:50:57 PM »

Is there any way of changing the palette for the colorizing?

I've been trialling creating DEMs for our dive site maps, and we really need to show where set depths are (max depth for training levels, 5m, 12m, 18m, 30m, 40m, etc.)  So i've been playing with 'Set Palette' and getting exactly what we're looking for.

But we'd really like to also colorize the 3D Model vertices with this same palette... But instead, this scrip only gives a default rainbow palette, not obeying the default palette in Preferences, or the palette set in the DEM.

Any way to do this?

Thanks.

11

Feature Requests / Re: Build Depth Maps as separate Job? (or at least save after creating them)

« on: March 23, 2022, 02:54:27 PM »

I'm not sure when the feature was added, but i noticed that completed Depth Maps are now saved within the project if the meshing crashes, meaning i don't have to reprocess them all again...
Thanks for adding this!

I'd run out of disk space when it was saving the finished mesh, which is so annoying, but the Depth Maps where there!

Much appreciated.

12

Bug Reports / Re: FALLO EN EL PROCESADO POR MAPAS DE PROFUNDIDAD

« on: February 18, 2022, 09:24:01 PM »

I've reran the project as it was, to check, with both iGPU + dGPU, and it crashed as before.
I then ran it with only the dGPU (Quadro M2200) and it completed successfully.
I then ran it with only the iGPU (HD Graphics P630) and it crashed as before.

I'm running the latest Intel drivers for the Intel HD Graphics P630: 30.0.101.1340
And still running 13988

I'll try running a reduced model tomorrow to try the CPU only run, and to upload it.

Thanks

13

General / Re: Reset Model View Issues

« on: February 17, 2022, 05:49:16 AM »

Sorry, i didn't watch your video first...  As i've been frustrated by reset view myself a lot...  but yours seems to be acting even weirder!
Does changing the region affect it at all?
Are there tie points or animation tracks off out that far?

14

General / Re: Reset Model View Issues

« on: February 17, 2022, 02:11:40 AM »

What i've worked out is that it's dictated by the region..  NOT the points, mesh, model, data etc...
This for me, coming from a CAD background (Zoom Extents!) is completely confusing, and caused a lot of frustration, like you're enduring.
It does reset the axis as expected, so x horizontally, y vertically, z out of the viewport towards you.  That's logical.
But to make it crazy, it ONLY resizing the viewport to the extents of the region HORIZONTALLY!  Which is all fine and dandy, until you get an ultra-wide monitor, then your points/mesh get cropped off the top and bottom for seemingly inexplicable reasons.
You can see this working if you have the region visible, and you resize/rotate it and press 0 again, and then reduce the size of the viewport by dragging over the side of the workspace window, and pressing 0 more...  Oh, and another thing, it resizes it horizontally to the orthographic projection of the region, not the perspective view.  Press 5 to switch between the, and you'll see, and then change the perspective angle, by holding ctrl and scrolling the mouse wheel, to make it more extreme, then switching/pressing 5, you see it's touching the edges/corners of the region.  THEN it makes 'sense'.

We have a few posts about this already.
It could be a lot more intuitive if it was dictated by the point cloud, mesh, model dem, etc, etc, etc...  The data...  Not the region, not the camera track, none of that stuff, just the visible date.
AND that it would zoom to the extents of this data horizontally and vertically (so in x & y)
Or at least this should be an option to behave this way.

Then it should work as expected, we reset the view, and we can see the extents of our data.

So, for now, you want to resize your region, and it'll probably start behaving as hoped.

15

Bug Reports / Re: FALLO EN EL PROCESADO POR MAPAS DE PROFUNDIDAD

« on: February 16, 2022, 07:01:41 AM »

I tried 1.8.2 build 13988 pre-release and still get the error.