Deliverables different form expected and from past projects

Thanks. To be clear, the kmz altitude problem is not the same as mentioned in these posts at point b. above. I have experience with adjusting the altitude to bring the 3d map to the surface and this is different; the overlay is sitting at a consistent height above the ground, no matter what altitude setting I change it to, even clamped to sea floor. 

EDIT: I have just remembered that in two of the uploads I included a ground reference photo, something I had not done before. The outcome is that on the kmz which I didn't include the ground reference photo, came out below ground level and acn be adjusted to the surface, whereas the two with the photo included results in the kmz sitting above the surface some way and can not be  lowered to ground.

My images where collected between 1:15 and 1:45 pm and we are practically in winter here in Australia, so a low sun angle anyway.  If I had of rotated the direction of the fly to east/west, would this have helped? Is there anything I can do with these photos to get the result I need? The ortho photos look fine, with no sign of the reflection or ripple.

I am still unsure as to why the overlap reports look so different and the consequent DEM is so corrupted and different in all three upload attempts.

I have emailed you with images showing the different overlap reports and also the 3D jpg image which is markedly different in different upload attempts and to past projects.

The KMZ flatness is the same issue as the that of the 3D model and elevation layers. You need to follow the instructions in a couple of those posts to slide the offset up and down as needed. 

Solar noon is solar noon. It exists at all times of year. Yours was 12:16 at the time of collection. It being winter makes it so that 1.5-2 hours is more like 1-1.5. At your latitude, -38 degrees you are still going to get the shadow with the Mini 2 which has a fairly high field of view. You would be better off keeping the North/South passes since the vertical field of view of the camera is narrower than the horizontal. 

The JPG image you sent is the 3D model texture file, not the normal JPG. The image you want to use is the second down in the list of downloadable files. 

The overlap reports show points on the model and how many times they were imaged. For the flat models it is a smoother and more featureless surface so there are less points. The image density is the same, there are just fewer reporting points. 

Thanks Zane,

the kmz flatness and altitude problem are two different issues at my end:

As I said in my EDIT above the ground point photo seems to have messed with the altitude. Coincidentally, when I lower the altitude at absolute to -60m, the overlay reaches ground level. The height at which I was flying was exactly 60m, so I believe that including the ground point photo seems to have skewed the altitude of the output by exactly that amount. Now that I know you can do negative altitude points in GE Pro, this is no big deal but thought I should explain clearly what was happening.

As for the "flatness" of the model, I am referring to the fact that on this project the kmz and obj outputs have no 3D quality too them, they are flat like a .tif or jpg file. Ordinarily, these files have been a 3D mesh with corresponding 3D images overlaid. - That is what I am referring too with .jpg which I attached to the email. I realise it is not the jpg image to be viewed as a regular image, but it does not contain the 3D detail required to overlay 3D mesh as it normally would. It normally looks like a jumble of pixels, this one is clear, like an orthomosaic, but blurred around the edge. The first of the three uploads outputted the correct style of .jpg. For this upload I had flatmap failover and trimmed edges selected but no ground photo. Despite this, the kmz and obj still have no 3D quality to them and the output is of a very low resolution anyway, which is what triggered me to re upload and try again with different settings.

I don't won't to be a pain in your neck, I just want to get back to the outputs which I am used to. Is there anything I can do to upload these photos in a way which would result in a 3D ortho? Mainly what I want is a DEM which can be used to produce contours, at the moment I don't have that.

The flatness is caused by the quality of the camera and the sunspot. The Mavic Air frequently has the same issue. This is why we say not to use images with sunspots in them. It makes it so the feature appear different in every adjacent image. In such cases we optimize the photo map accuracy over that of the elevations. 

The altitude of the KMZ is never going to be perfect. It will be close if you use a Ground Reference image or it could be off by up to 100 meters if you are not. The numbers will be completely unreliable when the model is not accurate (flat). 

The majority of the issues come down to the sunspot issue. You can mitigate that in the future by mapping at times a bit further off from solar noon or by using a circular polarizing filter. 

As noted previously, if you just use the North/South passes it might turn out better. There isn't much else that can be done. 

Thanks for explaining, I guess I will try to re-fly the mission on an overcast morning or afternoon. This is the first time I have any trouble with this.

The reason I flew the grid was because, in the past, that helped develop a more accurate 3D model. 

Hi again, I thought I had better write a follow up.

FYI I had absolutely no problem generating a DEM and 3D obj with Pix4D using these same photos. 

I gotta say I am pretty annoyed that you made it seem like the photos couldn't be used to create these outputs, because of sunspots etc. I made it very clear to you what I was trying to achieve and asked if there was some other way to do this, but you refused to acknowledge that it was in the processing that the problem lay, but instead nearly had me out re-flying the mission to get photos that could be used to create the outputs I needed.

As I said before I had, to date, been satisfied with the outputs of MME and I am impressed with the quality of the 3D models you seem to be able to produce. In future when someone comes to you with a problem with their outputs, which they have paid for, I suggest that you try to help them find a solution instead assuming that they are wrong or blaming them for not collecting photos properly.

The Data Collection guidelines are there for a reason: to give users input as to how the images should be collected based on what we know works and what does not for our system. This has nothing to do with what may or may not work using other software. We just know what works for users using our software.

The Mavic Air has been problematic since it was released. It works just OK as long as everything else is done perfectly. This is not us blaming you or the images. This was us telling you what we know works and does not work on our system. We have considered not allowing uploads for that camera for paid jobs due to its limitations. Are we going to try to adjust things in our system to meet the needs of the lowest spec camera that is flyable? Probably not.

This is why we have these guidelines. They are a recipe for success in using our system. If you don't follow the recipe when you are cooking you are not likely going to be happy with the result. Call it a problem with our processing if you want but don't blame us for being "pretty annoyed" when the guidelines are not followed and the results are questioned.