Agisoft PhotoScan 1.4.0 pre-release

[Alexey Pasumansky]

Hi, I've had speed processing problems with Photoscan versions above 1.3.0 (about double or more the processing time for the same projects), so I tested 1.4.0 with dissapointing results... About 35hr to produce a 4mil. point cloud on an i7 6700k with 32gb ram and an r7 radeon. I'm attaching the log https://drive.google.com/file/d/0BzGCwRIMzzYsM0ZXTTBfUHdZcTg/view?usp=sharing in case something comes out

Do you have the processing log or at least Chunk info with the parameters and time spent from the previous version, where the processing time was adequate?

According to the log the depth filtering took very long time and it could be related to the excessive overlap, when most of the cameras are overlapping with a lot of neighbors.

I will provide this, since I can reprocess the job with 1.3.0. You're right there is probably much unneeded overlap in this project (it was an early one)

Hello cadm8,

In the version 1.3.0 the number of pairs for the depth filtering has a strict threshold: 50 pairs, in the later updates the limit has been removed.

[Alexey Pasumansky]

"optimizecameras" seems to produce random results, and messes up the camera alignment even with all tags set to "false" so that it should not really do anything.

Hello stephan,

Can you please specify, the issue is related to the version 1.4.0, or you are observing the same behavior in the version 1.3? In the latter case I can assume that there's incorrect coordinate data input either for cameras or markers. Or the coordinate system has not been selected properly.

[cadm8]

Hello cadm8,

In the version 1.3.0 the number of pairs for the depth filtering has a strict threshold: 50 pairs, in the later updates the limit has been removed.

Hi, that seems like a logical explanation! It's there a way to adjust the limit on the newer versions, or do you think there should be a change about this matter?

[Alexey Pasumansky]

Hello cadm8,

In the version 1.3.0 the number of pairs for the depth filtering has a strict threshold: 50 pairs, in the later updates the limit has been removed.

Hi, that seems like a logical explanation! It's there a way to adjust the limit on the newer versions, or do you think there should be a change about this matter?

You can use the following line input to the Console pane to limit the number of pairs:
   

Code: [Select]

PhotoScan.app.settings.setValue('main/depth_filtering_limit', N)Here instead of N you need to input some integer value, for example, 80. Hopefully, it would reduce the processing time considerably without any visible issues. I do not recommend to go under 50-60 pairs, though.
To return the value to the default (unlimited) value, please use "-1":

Code: [Select]

    PhotoScan.app.settings.setValue('main/depth_filtering_limit', -1)

[cadm8]

Appreciate it and I will try it immediately! Is there a more specific reason that the previous 50 pair limit got lifted? I mean,  can selecting more pairs lead to visibly greater results but only in certain cases, like say small object modeling?

[Alexey Pasumansky]

Appreciate it and I will try it immediately! Is there a more specific reason that the previous 50 pair limit got lifted? I mean,  can selecting more pairs lead to visibly greater results but only in certain cases, like say small object modeling?

For some projects, like building scanning from the copter (also with a lot of overlap) the limit caused the dense cloud reconstruction artifacts along the building corners.

[Smallpoly]

Wow, just read the release notes and there's some really neat changes in this one. Can't wait to try them out.

[cadm8]

Appreciate it and I will try it immediately! Is there a more specific reason that the previous 50 pair limit got lifted? I mean,  can selecting more pairs lead to visibly greater results but only in certain cases, like say small object modeling?

For some projects, like building scanning from the copter (also with a lot of overlap) the limit caused the dense cloud reconstruction artifacts along the building corners.

Hi Alexey, I've testet it, it has an effect, but it's not as quick as 1.3.0 when selecting 50 pairs for example. I believe it brings down processing time, but not as much

[bisenberger]

Hi Alexey,

If I adjust the 3D mouse settings (any of them), nothing changes in PhotoScan. Haven't had this problem with other software so far.

Regards,
SAV

Do you mean that the 3D mouse works in the same way both with checked and unchecked "reverse" option?

As stated, any (and all) changes to the 3DCONNEXION 3D mouse settings have no affect to how the device functions in PhotoScan. Also most of the 3D mouse functions in PhotoScan are reversed to what I'm accustomed to. For example move the puck left object pans to the right.

[Smallpoly]

Hi Alexey, really loving the new update.

I'm getting the "A media resource couldn't be resolved" issue with the vids from my Samsung NX500.  It outputs to MP4s with H.265 rather than the more common H.264. This is on 64 bit windows 10.

If it makes a difference, I'm also able to view the vids in various media players and extract frames using DVDVideoSoft's free tool.

If you want a test file to check out, I've uploaded a copy of a ~1 second video of the checkerboard calibration screen from Lens here:
https://www.uploadthingy.com/widget?c=worldviz.com&el=1783660.mp4

[stephan]

"optimizecameras" seems to produce random results, and messes up the camera alignment even with all tags set to "false" so that it should not really do anything.

Hello stephan,

Can you please specify, the issue is related to the version 1.4.0, or you are observing the same behavior in the version 1.3? In the latter case I can assume that there's incorrect coordinate data input either for cameras or markers. Or the coordinate system has not been selected properly.

Yep sorry about that, the coordinate system was messed up.

[macsurveyr]

Using 1.4.0 build 5097 on an iMac 5k. The camera icons and the thumbnails with view images are quite small. I have tried toggling High DPI mode but nothing changes.

Tom

[cadm8]

Hi, I've had speed processing problems with Photoscan versions above 1.3.0 (about double or more the processing time for the same projects), so I tested 1.4.0 with dissapointing results... About 35hr to produce a 4mil. point cloud on an i7 6700k with 32gb ram and an r7 radeon. I'm attaching the log https://drive.google.com/file/d/0BzGCwRIMzzYsM0ZXTTBfUHdZcTg/view?usp=sharing in case something comes out

Do you have the processing log or at least Chunk info with the parameters and time spent from the previous version, where the processing time was adequate?

According to the log the depth filtering took very long time and it could be related to the excessive overlap, when most of the cameras are overlapping with a lot of neighbors.

I will provide this, since I can reprocess the job with 1.3.0. You're right there is probably much unneeded overlap in this project (it was an early one)

I'm attaching the log from 1.3.0. Still a big difference in processing times (about 2-3 more time needed)

[stihl]

Appreciate it and I will try it immediately! Is there a more specific reason that the previous 50 pair limit got lifted? I mean,  can selecting more pairs lead to visibly greater results but only in certain cases, like say small object modeling?

For some projects, like building scanning from the copter (also with a lot of overlap) the limit caused the dense cloud reconstruction artifacts along the building corners.

Can anyone please confirm whether or not this will reduce the True Ortho artefacts near buildings/objects? It seems like this should. Longering the processing time but increasing the quality is definitely interesting.

[obw]

Appreciate it and I will try it immediately! Is there a more specific reason that the previous 50 pair limit got lifted? I mean,  can selecting more pairs lead to visibly greater results but only in certain cases, like say small object modeling?

For some projects, like building scanning from the copter (also with a lot of overlap) the limit caused the dense cloud reconstruction artifacts along the building corners.

Can anyone please confirm whether or not this will reduce the True Ortho artefacts near buildings/objects? It seems like this should. Longering the processing time but increasing the quality is definitely interesting.

Is this new in this Version 1.4, or was the number of pairs lifted in the current stable Version 1.3.4?