Good afternoon, Pix4DMapper forum,
I’m writing to you about a problem I’m experiencing on flights recently taken based on coastline surveys (this didn’t happen until a few years ago).
My problem is that, without prejudice to the flight settings of the drone (DJI Mavic 2 Pro) which remain the same for all flights, I have the problem that for some time the orthomosaic has been cut in the sea part, i.e. for question of graphic rendering, I would like the software not to cut the blue part of the sea, which instead it tends to do despite having carried out a flight strip towards the sea during the survey (maintaining reference points on the ground in the shots) to ensure that the sea area also stands out in the orthophoto.
Is there perhaps a setting I need to change in the processing settings?
I attach a screenshot of the latest processing to better understand the problem.
Thanks in advance for your courtesy.
Cordially,
Alfredo
Hi Alfredo,
It almost looks like an issue how Mapper is tiling the orthomosaic. You might want to see if your GPU driver needs updating.
Good morning Mike and thanks for the reply.
I’m not sure if I should update the graphics card driver because until some time ago, on both PCs on which I work daily the orthophotos came out with a good part of the sea.
With my post I wanted to know if there is any option within the pix4dmapper software that gives the possibility to cut or not cut the water/sea/lake part. As far as you know, is there a function of this type that perhaps unintentionally popped up and so I can restore it?
Thank you
PS: I will still check the graphics card for updates
First, water is always tough. It is expected that Mapper will cut much of it out. However, your screenshot looks very squared off, which typically isn’t so square. This leads me to think it could be a problem with the tiling process. Hence, the graphics driver. The only other thing that could cause the part to be clipped off would be if you created a processing area. But this would not happen unintentionally as it is something you have to draw. For the moment, please check your drivers.
Ok Mike, thanks, I tried updating the GPU dribers this morning and will try to rework a project later. However, I’ll show you how the projects came out some time ago:
This looks like it is tiled much better. Glad the drivers seems to be the issue.
no this last image was processed before the opening of this post and therefore before the image I posted in my first message here on the forum
This evening I’ll start the new process with the updated drivers and I’ll probably let you know on Monday
Hi Mike, I redid the processing of the first photo in the post after updating the GPU drivers and the result is the same, little sea 
Hi sterav,
I think the ultimate problem is the water. Water is difficult, and it is expected that Mapper will cut most of it out. What caught my eye were the sharp right angles in the orthomosaic. It had the appearance of a tiling issue. At this point, I do not think that was the problem. It is the water.
did this ever get fixed?
I have EXACTLY the same result on a coastal model
I appreciate that the data is essentially not there… but I am confused about the arbitrary east-west / north-south cutoff lines
Hi AP_Procurement,
unfortunately no I have not solved it, I also tried on different and more performing machines but I always get the same result, the sea is cut arbitrarily, something that did not happen to me a few years ago and I do not understand the reason.
it’s a shame… I understand it only happens where the model has poor keypoint identification… but in that case, I am still confused that the cutoff should follow an easting or northing line
I wonder if I ran the same process at a much lower “resolution” whether that might give me in-fill in the white areas…
Instead I think they can implement with a function that simply replicates the texture of the photos where the cloud points are sparse, so at least you have the “semblance” of what it “would be”. Because I actually fly over the water and I take enough notes to try to get it replicated in the model but it never seems to be enough
yes… essentially, you are suggesting a stitched ortho in these areas, similar to what is done by react and fields… instead of a projected model ortho for mapper and matic
This is just not going to happen… as mapper is not getting much in the way of change updates of this size.
I just wonder why it’s such a square hole!
This non-implementation will only push users towards other programs such as metashape or cloudcompare unfortunately