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

Pages: 1 2 [3] 4 5
Feature Requests / Report time.
« on: April 15, 2016, 01:47:49 PM »
The Report provides a big time/date of the report time on the first page.
It would be nice if also checked EXIF when available, and said:

Data collected  20/4/2015 09:40  ..  12:30

giving a clue on when this job was done

Why is it so, that when "Align photos" step is done, it's still possible to get some more photos aligned, just by selecting them and clicking ~"align photo" ?

Why is that not done automatically ?

Please see photos, zooming in helps with more details about the map. (sorry for not taking screenshots, but I wanted the process to be as uninterrupted as possible)
Efter selecting to export as tiff og bigtiff, all RAM is hogged - then swapping to a fast 160GB SSD starts, ultimately it will be full, and the process fails.

Why ? - as I understand it, the data is already there, and it's just a matter of writing it to a file.
The whole dataset, with pictures and all the processed data, is only 40GB

photos :

General / Re: RAM vs SWAP - can the job be done of you have enough swap
« on: January 13, 2016, 12:40:10 PM »
this thread moved a little away from the original subject (which is forgotten?)
Basically, I have never seen a job fail due to memory, after consuming all of SSD Swap.
Also, be it 64GB or 256GB of RAM, I think we are merely pushing the problem ahead for bigger jobs.
Should't it be possible to only process a chunk at the time in memory, then dump to swap/temp ?
If I can stitch 1km2  , then I should be fine to stitch 1000km2 , by processing an area, unloading most of it, keeping the border area to next chunk, then process that ?

Such processing would only require more tmp/swap , that can be fast on SSD stripe set with proper controllers, it would  remove the "never enough RAM" in a world where we only generate more data as sensors improve.

Feature Requests / Re: Please optimize geotif export
« on: December 19, 2015, 11:37:31 PM »
I closed Photoscan, so I had to reproduce again:
The log is very short; , so I added comment-lines starting with //

2015-12-19 21:02:18 Loading project...
2015-12-19 21:02:20 loaded project in 1.91816 sec
2015-12-19 21:02:20 Finished processing in 1.9186 sec (exit code 1)
2015-12-19 21:03:11 Exporting orthomosaic...
2015-12-19 21:03:11 generating 1 x 1 tiles
// at this point, RAM is filled within 5sec or so  , then swap starts to increase slowly until used swap is about same amount of GB that RAM. (there is much more SSD  SWAP available )- the total memory (+swap) use seems constant after about ~3 minutes.  .. then we wait ... the progress bar does not indicate any progress ultil the end ..
2015-12-19 21:28:11 Finished processing in 1499.6 sec (exit code 0)
// well, "finished" here means a small notification window with exclamation mark saying "Not enought memory" [OK]
2015-12-19 21:28:11 Error: std::bad_alloc

And there is no new file in destination folder.

Feature Requests / Re: Please optimize geotif export
« on: December 19, 2015, 10:06:50 PM »
where do I find the log ?  ~/.agisoft  had no files
I've taken Christmas vacation, but reproduced on a bit lower speced computer.

Feature Requests / Re: Please optimize geotif export
« on: December 19, 2015, 06:37:22 PM »
Yes, and many jobs still fail when exporting to one bigtif , while the same aea can be exported to tiled tifs regardless type.

Feature Requests / Please optimize geotif export
« on: December 19, 2015, 02:00:41 AM »
I can export geotif of huge/hires areas as tiles just fine.
- exporting to one .tif file file fails - it's "never" enough RAM for that.
please consider writing a tiled geotif - processing it as tiles, or export to tiles, then assemble to one big tif (in case that reduces the needed RAM)

I have 64GB RAM on Linux, with 96GB SSD Swap (which never gets close to filled anyway)

I gave it another thought, now I see that the monthly upload is too small for us.
The thing is, we provide very detailed maps at very low GSD, rather big areas, it's not given that the customer needs all that, but it is there if needed.  In an more active week this fall I generated >250GB of geotidff+DEM.
Should we go for the 100GB version, very few customers/target areas would be able to access their data at the same time, and 20GB monthly quota would make it impossible to upload more than a few flights anyway.  I just guess we are a bit ahead of the GSD most people are happy with.

Hi Adam, yes, I've actually seen 4Dmapper recently, but similar to another service like yours, it's pricing makes it completely useless for us.
100GB could be a short-term solution for a limited number of maps for few recent customers.
1TB would hold for a while, but is not even worth considering at $600/month.
Within few months we could get developed out own, self-hosted system. (and it seems like we are heading in that direction)

General / Re: Looking for open/free viewing software for DEM/geotiff
« on: November 15, 2015, 09:15:04 PM »
Thanks, Thile I am aware of Qgis, the problem is that  it is ridiculously slow to browse geotiff.  tiled or not, full redraw on every pan/zoom operation, and while my workstation load a given tile size in x seconds, qgis spends a lot more time to do the same job.

General / Looking for open/free viewing software for DEM/geotiff
« on: November 13, 2015, 10:43:42 AM »
Some end users does not have tools to view/do measurement on geotiff/DEM
can you please suggest open/free software that can view, and preferably do some basic measurements on data processed by Photoscan Pro (in any suitable format)?   - preferably multiplatform.

I am aware of the Agisoft viewer, it does great job viewing 3D .tls models but what if user needs to see it as orthophoto/meassure ?

So , would you say the total amount of CPU time spent for orthophotos + DEM is about the same, just differently distributed among processes ?
Also, you mention measurement - I would love to see a simple ruler/option to measure distance/area. abilityto actally see elavation(numbers) , like in mouseover, in Photoscan  - also

In current release version:
After creating dense pointcload, mesh  - I just go to export , and I am able to export til .las , dem, ortho.  ech step takes time..

with 1.2.0
After creating dense pointcload, mesh   .. I cannot export anything,
.NEW:.need to go to workflow and create dem and ortho (two longer prodcesses)- save psx,  (also longer)
only then can I export to ortho,dem,las ..

The new steps does seem to me to be extra steps, taking more time, I do not understand why I need to do them ?

Actually - I can open a psz project using 1.6.x , then just export
The same project opened in 1.2.0 requires the extra new steps, before export.

Please explain what is going on, and why it's needed.

Feature Requests / LAND XML format
« on: October 26, 2015, 01:36:08 PM »
- a customer is requesting export in this format

Pages: 1 2 [3] 4 5