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.

Topics - RalfH

Pages: 1 [2] 3
Feature Requests / Turn Off PC after Process is done
« on: February 01, 2013, 09:42:48 PM »
For batch processing, it would be great to have an option tick box for shutting down the computer after all processes are finshed. It would be even better if that tick box was available while batch processes are running (just in case I change my mind...).

General / de-activate CPU cores?
« on: January 29, 2013, 07:29:35 PM »
I am running PhotoScan standard 0.9.0 on a 8 core Windows Vista computer without using a GPU. Often I want PhotoScan to work in the background while I am doing other work on the same PC, so it is not good if PhotoScan uses all 8 cores. I tried to de-activate some CPU cores (under "preferences"), but PhotoScan still uses all 8 cores. Is there a way to free some CPU cores?

General / Best (cheap) way to perform texture unwrapping?
« on: January 24, 2013, 11:24:37 PM »
I have a textured 3D model of a sediment profile created in PhotoScan and want to use it as the basis for a stratigraphic sketch. What would be the best way (without using expensive software) to unwrap the texture without excessive distortions?

Simply exporting the expure atlas doesn't help much - depending on the model building quality setting, the texture is either more or less in one piece but distorted or it is fragmented into many pieces.  As you can see in the screenshot, it's not a simple object, so using an orthophoto texture atlas won't work.

General / photos aligned but without depth map?
« on: January 24, 2013, 06:10:35 PM »
I have a project with 114 photos, all of which are aligned, and refined camera calibration values look good (i.e., close to the initial values and with only small changes between photos). Building a model from the sparse point cloud also works well.

However, when I want to build a model using lowest, low or medium (haven't yet tried high and ultra), most photos are skipped and depth maps are build for only 21 cameras. What could be the reason for this?

General / 1D, 2D or 3D camera setup?
« on: January 22, 2013, 06:02:19 PM »
Has anyone compared PhotoScan output quality using different camera setups (e.g., linear array, planar 2D array or cameras distributed in 3D space)? Are there any systematic advantages/disadvantages to any of these setups?

General / RAW, JPG and different types of noise
« on: January 22, 2013, 05:55:10 PM »
As I occasionally see the opinion (in this forum and elsewhere) that RAW images are always superior to JPG images, I want to clarify a few issues here. Generally, digital photographs are affected by different types of noise which ultimately have relevance for using them for 3D modelling.

Sensor noise is caused by random fluctuations in the reaction of each sensor pixel to a given amount of photons. Thermal noise is responsible for a good part of the total sensor noise, so in theory cooling the sensor would help. Besides this usually not being feasible, my guess would be that we could at best reduce sensor noise by a few per cent within the range of temperatures in which our cameras are working. Increasing the sensitivity of the sensor (i.e., higher ISO number) means that sensor output for a given number of photons will be higher. Background noise remaining more or less equal, this of course means that this will reduce the signal to noise ratio (SNR).

Quantisation noise is caused by the mapping of an analog signal onto a digital range of values or by the mapping of a larger onto a smaller digital range of values. Primary quantisation in digital consumer cameras is usually 10 or 12 bit which means that the minimum brightness difference which can be detected (the least significant bit, LSB) is 1/1024 or 1/4096 of the recorded brighness range. The noise we see in a raw image is a combination of sensor noise and primary quantisation noise. Primary quantisation is usually not a big source of noise; it is much smaller then sensor noise. However, when the raw 10 or 12 bit data are re-mapped onto the 8 bit (values 0 to 255) scale used in JPG, there are again quanitisation errors. Their relative importance also depends on whether you are looking at darker or brighter areas of an image (or underexposed/well-exposed images): a change in the LSB in a dark part of an image (let’s say, average value of 10) is equivalent to a 10% change in brightness while a change in the LSB in a medium-bright area of an image (let’s say, average value of 127) is equivalent to less then 1% change in brigthness. Being able to detect small changes in brightness is of course important to be able to detect subtle features in an image (be it visually or by an algorithm).

When the resulting image with 8 bit colour depth is saved as a JPG by the camera, additional noise (or better, artefacts) are introduced, because JPG uses a lossy data compression. This can be best appreciated when splitting a colour JPG into hue, saturation and lightness (HSL) or hue, saturation and value (HSV) channels: the lightness or value channels look quite intact unless you use really strong JPG compression settings, but artefacts can often easily be seen in the hue and saturation channels. [At this point, it would be interesting to find out whether PhotoScan works with the RGB channels, with lightness or something else.]

In consumer cameras, sensor noise is often very noticable when looking at a raw image at full zoom. And because most consumers want to see nice clear pictures without a lot of noise, in-camera noise reduction is performed before converting the raw images to 8 bit colour depth JPG files. Depending on how much noise is produced by a given sensor, noise reduction will usually be more or less severe. I compared the low-cost Canon A3000IS with the more pricey Canon G12, and found that the raw images saved by the A3000IS had much more sensor noise than the raw images saved by the G12 and that the noise reduction in the A3000IS was much more severe than in the G12. Of course, noise reduction also removes image detail. Therefore, even with the same JPG compression strength a A3000IS JPG of the same object would be a smaller file than a G12 JPG (both are 10 MPIX cameras).

Now, what does all this tell us about using RAW or JPG in PhotoScan?

(a) The lowest possible ISO value should be used to reduce sensor noise.
(b) Underexposure and dark areas in images should be avoided because sensitivity to subtle brightness differences (and, as a result, feature detection) in dark areas is poor.
(c) RAW images suffer much less from quantisation noise and not at all from loss of image detail due to noise removal  and compression artefacts, but they contain all sensor noise (which can be severe). JPG images, on the other hand, often have less (visible) noise than raw images because of the in-camera noise removal and are much smaller files which are processed much faster. If your camera has very low sensor noise, RAW will be the better choice. For many consumer cameras, JPG may be the better choice unless you are able to apply a better sensor noise removal than the camera itself.
(d) In the end, it all comes down to SNR. You will always have some noise, and you should not only try to reduce noise but also to enhance the signal: a good lens, perfect focus, and an illumination which brings out as much fine detail as possible while not producing underexposed areas. In many cases, more photos taken closer to the subject will also help a lot.

Working on these points improves PhotoScan results much more than simply using RAW instead of JPG.

General / PhotoScan crash during "ultra" reconstruction
« on: January 16, 2013, 05:17:06 PM »
I sometimes experience PhotoScan crashes when trying to build models at "ultra" quality (height field mode, smooth). The error message says something about NVIDIA, something like "the hardware does not fulfil the requirements", and that PhotoScan will close. It happend after depth map computation, during meshing. A regrettable thing after 4 hours of processing...

The strange thing is that (because I don't have a powerful graphics card) I am running PhotoScan only on the CPU (8 cores). Therefore, I don't understand why NVIDIA would cause an error. In the PhotoScan preferences, I have not set a GPU. During processing, I am far from reaching the RAM limit (in the most recent case, it's only 36 photos of 10 MPIX, and PhotoScan only used less than 50% of the RAM).

What is the reason for this problem, and how can I avoid it?

Feature Requests / improvement of magic wand tool for masking
« on: January 13, 2013, 08:32:25 PM »
When using masks, this is often to get rid of areas that are shadowed, e.g. by the photographer and its equipment moving around or across the object (e.g., airplane/drone/kite/PAP rig). Often, the borders of these shadows are diffuse. That makes it somewhat difficult to effectively use the magic wand tool (which otherwise works really well): if the (dark) centre of the shadow is clicked, a slightly dark area around the shadow remains in the image around the mask; when the border (not so dark) of the shadow is clicked, large areas of the images are masked which should not be masked. Adjusting the tolerance level is only of limited help.

Therefore, I suggest adding a "buffer" option and slider to the magic wand tool which would automatically add a buffer with a selectable width (number of pixels choosen with the slider) to the selection made with the magic wand.

Bug Reports / Minor bug in masking tool behaviour
« on: January 13, 2013, 08:24:24 PM »
I just noticed that there is a minor bug in the behaviour of the masking tools in verison 0.9.0: When using the selecting tools rectangle and magic wand, they remain active after adding/subtracting the selection to/from the mask or when opening another image. When using the intelligent scissors tool, however, the tool becomes inactive and has to be activated again every time after applying to selection to the mask or opening a new image. It would be good if that tool would behave like the others (i.e., remain active).

General / memory consumption during texture generation
« on: January 10, 2013, 12:59:08 PM »
The Agisoft Wiki ( specifies memory (RAM) requirements for different processing steps (image alignment, building model, decimating model) at different settings, but not for texture generation.

Recently (after upgrading to version 0.9.0; don't remember this problem from before) I noticed that in many cases memory consumption for texture generation is comparable to or even higher than for model building (e.g., almost 14 GB for a medium quality meshed model of only 7 images of 10 megapixels; mosaic mode, atlas size 16000x16000, "fill holes" option checked). Even if, in addition to the texture atlas being created, full-sized texture atlases for all photos were constantly held in RAM during processing, this would only add up to 6 GB. Memory consumption for texture generation does not seem to be predictable (some much larger models with many more images require less RAM).

Did anyone else experience something similar, and is there any rule of thumb regarding memory requirements for texture generation?

P.S.: It does seem to be a 0.9.0 problem - I just opened a project with a model created under 0.8.5 for which I remember that building texture was not a problem, and now in 0.9.0 PhotoScan is using over 15 GB and Windows has been shuffling data between RAM and swap file (which has grown to more than 24 GB) for more than an hour already, no end in sight.

General / sequence of photo alignment
« on: January 08, 2013, 03:55:41 PM »
Still trying to get the best results out of PhotoScan, and still coming up with questions. This one is about the sequence of photo alignment.

In one of my recent PhotoScan projects, trying to align all photos in a single process resulted in a big mess. The cameras were scattered all over (even though they should have been more or less in one plane as I was photographing a desert surface while walking back and forth), and there were numerous modelled ground surfaces intersecting each other at different angles.

While playing with the project for a while I found that it can help to align a few photos (between 2 and 4 in this case). If they don't align as expected, reset photo alignment and try with another group of photos until a small number of photos aligns well. If I then individually (one by one) align the remaining photos, they are aligned to the existing well-modelled group, and the entire model comes out quite clean.

I find it quite strange that the sequence of photo alignment influences the modelling result.

My question now is what causes this behaviour and why PhotoScan is not able to achieve comparable results by itself and whether any a priori information (e.g., camera positions should be more or less in a plane) could be fed into a future version of PhotoScan to improve the results.

Bug Reports / orthophoto texture orientation and quality in version 0.90
« on: January 06, 2013, 08:01:16 PM »
When creating orthophoto texture in PhotoScan version 0.85, it was possible to control the plane of projection by manipulating (resize and rotate) the model region. The model had to be rebuild between modifying the model region and creating the texture (which was a time-consuming hassle), but it was possible to control the plane of projection for orthophoto textures.

In version 0.90, rotating the model region still controls the orientation of model coordinate axes (this can be confirmed by looking for vertical "artifacts" in the height field model), but it does NOT influence the plane of orthophoto projection. In fact, in addition to being oriented seemingly at random, the exported orthophoto textures are mirrored! Furthermore, there are sharp but also very blurred areas in the texture, even on relatively flat areas and irrespective of model resolution.

What is going on there, and how can I get at least the same features and quality that I had in the previous version?

Bug Reports / extreme memory consumption when creating texture
« on: January 04, 2013, 04:03:17 PM »
I have recently upgraded to version 0.9 and am now experiencing very large memory consumption when creating orthophoto texture (mosaic mode, atlas size 16000x16000, "fill holes" option checked). The data set is very small (only 7 photos of 10 megapixels), but memory consumption increases by almost 14 GB during the "blending textures" step. Is this a bug?

P.S.: Interestingly, in other projects (with many more images), memory consumption for texture creationg is lower (e.g. 8 GB for a set of 38 images, same texture atlas size). Memory consumption for texture creation does not appear to be predictable. Any idea why?

Feature Requests / Alignment of region
« on: January 04, 2013, 03:37:30 PM »
After photo alignment, PhotoScan creates a region around the object. This region also determines the plane of projection when creating an orthophoto texture. At the moment (version 0.9), there are only two ways of manipulating this region: resize and rotate. I think it would be very helpful if the possibilities for aligning this region could be improved, for example by using a small number of tie points (e.g., place 3 points onto the model surface to specify the plane of orthophoto projection).

[Background: I am using PhotoScan to create 3D models of pits excavated into a sloping surface; they commonly have three sides at approximately right angles. I now want to create separate othophoto textures for the three sides to use them as a basis for stratigraphic sketches.]

I think this would also be appreciated by people modelling buildings and other objects.

Feature Requests / dense point cloud only?
« on: December 23, 2012, 03:29:14 PM »
While processing a number of somewhat larger data sets (between 150 and 1000 photographs) I noticed that in many cases I can not achieve what I want because PhotoScan tries to do more than I want. Sounds odd? It's not.

What I really need in most cases is a dense point cloud. When giving PhotoScan the task to create a model, it computes such a dense point cloud, no problem, even at high resolution with hundreds of photographs.

The problem is that there is no way to stop the process right there and save/export this dense point cloud. Instead, PhotoScan goes on to try and create a meshed model, and this is the processing step which (for large data sets) requires a lot of memory and a lot of time. And in most cases, I am not able to process at more that low or medium resolution (in arbitrary mode) because PhotoScan runs out of memory. Why can't I save the dense point cloud? It's frustrating to see in the programme console that a dense point cloud with several hundred million points was successfully created, but then the programme quits because it wants another few dozen GB of RAM to create a meshed model which I do not need!

I suspect that many users of PhotoScan want a dense point cloud rather than a meshed model, because this would be much more suitable for post-processing with other software (e.g. to apply vegetation filtering).

It would be very great if there was an option to create only the dense point cloud (at the known resolution steps of lowest, low, medium, high and ultra) but skip creating the mesh. That way, it would be possible to achieve higher resolution results in less time with less RAM. At the very least, the dense point cloud should be saved to a temporary file before the meshing is attempted.

Pages: 1 [2] 3