Forum

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

Pages: [1] 2
1
Same for GeoTiff export.
It seems like the GeoTiff standard also includes webp encoding now.
https://gdal.org/drivers/raster/gtiff.html

That would massively reduce the data size for many of your users!

2
Bug Reports / Re: GeoTIFF Problems with several layers
« on: April 16, 2021, 12:26:02 PM »
Hi Alexey,
yes the alpha channel is enabled in the export.

Best, David

3
Bug Reports / GeoTIFF Problems with several layers
« on: April 15, 2021, 03:08:21 PM »
I have a RGB+NIR orthomosaic and when I export it, it seams to have some faulty  encoding:

Every further processing step in gdal resports:
TIFFReadDirectory:Sum of Photometric type-related color channels and ExtraSamples doesn't match SamplesPerPixel. Defining non-color channels as ExtraSamples.

So there seems to be a problem in how the image is stored.
I'm running 1.7.3 build 12136

Best, David

4
Python and Java API / Re: Standalone Module Use in a Docker Container
« on: April 01, 2021, 02:27:05 PM »
Hi @bvriens and @bbbares!

I just wanted to ask if you were successful in setting up your projects and if you got everything running in the end?
I'm also interested in setting Metashape up in a docker.

5
Feature Requests / Re: pointcloud intensity import and export
« on: March 30, 2021, 04:50:48 PM »
Same here.
We're very glad LAZ imports are possible at all (because LASTools are very outdated and we didn't find any alternatives)
but it would be much better if we could also filter by intensity, because then we could seperate tree canopies from ground reflections.

Adding this feature would very much be appreciated!

6
Both the MBTiles and the Geopackage standard supports WEBP for the embedded image format and Metashape already includes the WEBP driver (for importing images).
Being able to export MBTiles/Geopackages with WEBP compression brings the added benefit of both having an alpha layer (like in PNG) and better compression compared to JPG.

7
General / Re: Agisoft Accuracy
« on: March 10, 2021, 12:25:38 PM »
I'd say this question can't be answered as it depends on many factors which are not under Agisoft's control, like image quality terrain structure, flight lines, stereo angles e.g.
We benchmarked a couple of softwares and for us Metashape had by far the best and most robust results.

8
Perfect, glad to hear that! Looking forward to the next point release then! You probably can't give an ETA right now, can you?

9
I attached the logs of a recent run of a smaller project. This contains only 45 cameras but one of the GPU fails anyways.
This runs in ultra settings.

10
In our workstation there is a 2080 and a 2080 super, both have 8 Gigabyte of VRAM.
I currently have the job running with Metashape 1.6.5, but once it's done I can reproduce the error in 1.7.1 and send you the logs and exact numbers of required RAM.

The project contains ~1800 images with 100 Megapixels each.
When I start the 'build DEM from Depth Maps' processing (in 1.7.1) it fails right away - interestingly It didn't matter if I had the ultra setting or high or medium. It always happended.
When I removed a part of the images the error did not occur right away. It did start to work fine and used both GPUs. However over time during the night the VRAM consumption grew and at some point it was saturated again and defaulted back to the CPU processing.

11
Feature Requests / Re: Add AVIF support
« on: March 03, 2021, 09:15:16 PM »
Okay, I stand corrected. Seems like I had outdated information. What do you think about de/encoding speeds?

12
We're having the same issue with our 100MP images. It seems the VRAM required is always just above what is available...
Our images are 8bit by the way. Current fallback solution is using 1.6.5 but I'd clearly prefer using 1.7.x with the new algorithm. The speed improvements are impressive!

13
Feature Requests / Re: Add AVIF support
« on: March 01, 2021, 10:01:08 PM »
In fact, another very viable option would be JPEG XL, which has a couple of benefits over AVIF:

  • Transcode JPEG images without loss of quality
  • Much faster encoding/deciding speed
  • Larger image dimension supported (AVIF only 8k x 4k)

with the same benefits as AVIF: Royalty-free, Much better compression than 'old' standards, more feature complete.

And the standard was succesfully finallized now.

One thing that comes to mind, which could be beneficial for AVIF is that the hardware encoders/decoders are much more matured and will probably be on most CPUs within the next 2 years. No such thing with JPEG XL yet.

 

14
Feature Requests / Re: Add AVIF support
« on: January 07, 2021, 07:52:48 PM »
There are also a Go-based version: https://github.com/Kagami/go-avif
or one, which uses the popular dav1d decoder from the VLC team: https://github.com/link-u/davif

Is there any chance you could look into that for a potential additional feature in an upcoming point release, @Alexey Pasumansky?

15
Feature Requests / Re: Add AVIF support
« on: September 29, 2020, 05:01:22 PM »
I deeply agree with this!
AVIF is clearly the best competitor to replace JPG in the long run, given it's clear licensing and wide support through all AV1 members both in hardware and software.
The gains in compression, features and quality are very remarkable and more and more software already supports AV1.

This would be an extremely welcomed addition!

Pages: [1] 2