This has already been reported internally, but I thought you all should be aware. There is currently a bug with GCP tagging that will cause you to have to tag each point twice. Please reply if you come across this so we can get an idea if it is widespread or isolated to specific setups. Thanks!
Windows 10 (64-Bit)
Chrome 71.0.3578.98
The system seems to be unusually slow right now. I guess everybody is uploading their week 
It’s also happening in Firefox Quantum 64.0.2.
If you want to try you can always go back to an old tagging link. Just don’t submit it.
*Ugh, Firefox is pulling up completely different images than Chrome that aren’t correct. Even when you select find more images.
@MichaelL Thank you for catching this. I will escalate to my engineers. I will follow up via support email.
Thanks!
As a positive sidenote to this problem, I was under a time crunch to get the orthomosaic CAD overlay out for an owner’s meeting and despite this issue made it with 30 minutes to spare because of rapid processing. I had never used it before because of worries with accuracies, but in this case I need the map fast so I did turbo upload and medium speed/quality. We processed 110 acres (600 images) in right at an hour. Thanks DD! Still looks very good on screen. @Yusuf @Jamespipe @jono @Anya
GCP tagging is still experiencing issues, but DD is hard at it!
It appears that the glitch is actually that I do not have to tag twice, just moving to the next point and coming back to the main map will make the previous point go green. Still working on it.
Hi,
a GCP was added to calibrate the elevations seen in the elevation toolbox, and this seemed to work. Elevations seen in the histogram were transformed from a few tens of meters, to the local mean elevation of 1850 meters amsl.
When the elevation toolbox was used to export an elevation Geotif file though, it produces a 4-band RGB with bands 1,2,3 being the RGB using 8-bit 0-255 color table numbers, and the 4th band being all the one number 255 where there is imagery, with all nulls (0) located on the periphery of the DEM imagery.
Has anyone else seen this phenomena? Is there any idea where the amsl elevations ~ 1850 m have gone too? It looks they were not preserved upon export as a Geotif out of DD.
Any advice much appreciated,
Thank You
Was it a GCP or the single point calibration tool?
In DD GCP is the acronym for ground control point. The DD elevations can be calibrated manually with one control point or several, the elevation surface will then return numbers similar to the GCP numbers used to calibrate the raw DD elevation numbers.
For this example, the single point calibration tool, the one GCP was used, the resulting range of amsl numbers for the elevation surface then seemed a reasonable match to the local elevation across the flight area.
Sorry if I wasn’t clear. I am well versed in GCP’s as I have set thousands of them. What I was trying to ascertain is whether you processed with GCP’s and additionally used the single point calibration or processed without GCP’s.
Back to the question on point. Can you post a snippet of what you are seeing? Also, have you tried adjusting the slider to get a more appropriate elevation range?
Hi, no worries,
the Geotiff has no calibrated elevations upon export, it just returns the 8-bit 0-255 numbers for an RGB image when viewed in image processing software. This work was done last July, after calibration the GPS elevations could be seen across the image, numbers surrounding 1850 amsl.
Now, when the Geotiff is viewed in an image software, the surface numbers are not elevations, but the 0-255 8-bit color table numbers.
DD is used on monthly basis here when required, to show this now a monthly subscription would be required for a few minutes work.
I was curious if others have seen this, a calibrated elevation surface not returning the calibrated elevations upon Geotiff export, but the 0-255 8-bit color table numbers, is this a bug or does not DD export out to Geotiff the calibrated surface elevations? Or perhaps a setting was missed when exporting, to ensure the calibrated numbers were output.