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
General / Re: How to reduce size of generated DEM geotiff
« on: February 10, 2023, 04:07:13 PM »
Thanks for bringing up this discussion!

As far as I understand it, the DEM geotiff basically stores a 32bit float value for every "pixel".
An Ortho in contrast has 24bit per pixel (8bit for R, G, B each + sometimes alpha) - but orthos can be compressed with extremely efficient lossy codecs like jpeg(XL) or webp.
The DEM in contrast can only be compressed losslessly.

In order to save more space, it would be amazing to have the option to store the data in half-precission 16bit-floats for example. Or even quantizise further down and map it to 8 bit integer.

Actually JPEG XL could also be the solution here...
It allows an arbitrary number of channels 1 to 4000+ and each of them can have either binary or integers and floats up to 64 bit. It also allows lossy compression even on floats...

2
Feature Requests / Re: Add AVIF support
« on: October 12, 2021, 03:45:54 PM »
Seems like there's another very promising image format coming.
According to the latest changelogs, experimental support for JPG XL was added. I'm actually quite happy with that!

3
Bug Reports / Re: EXIF Information not detected in WEBP images
« on: July 09, 2021, 05:40:15 PM »
Hi, I just once again wanted to follow up, if this ticket gets acknoledged or if anybody is working on this?
Thanks

4
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!

5
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

6
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

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

8
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!

9
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.

10
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.

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

12
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.

13
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.

14
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?

15
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!

Pages: [1] 2