Post

2 followers Follow
0
Avatar

Busy Server or other issue?

I loaded up a small job and it is saying it could take up to 4 days till ready.

I have a certain goal for the project and it is not at all time sensitive so I don't care about the time.  It's just the first time I have ever seen that long so I thought I'd report it in case you think it needs attention.  If it's fine, then great.  One other strange thing is I received a "completion" email for the project and when I log on, it's says Jan. 6.

Happy New Year.

Dave Pitman

Official comment

Avatar

Ha! I just put a note on your job. We are still working some issues with processing stuff that comes in over the Classic workflow after our big 1.1.21 update. 

The ETAs have been adjusted since you submitted this but that doesn't get recalculated when we set it to reprocess. 

Zane
Comment actions Permalink

Please sign in to leave a comment.

11 comments

0
Avatar

The issue appears to be that some of your images have XMP tags in them and others don't... that breaks stuff now. We will try to accommodate it. Just another corner case...

Zane 0 votes
Comment actions Permalink
0
Avatar

That is strange. They are all out of the same P4P mission. I'll have to look at them when I'm on that machine next.

Dave Pitman 0 votes
Comment actions Permalink
0
Avatar

Image DJI_0001.JPG (with caps JPG) has no XMP data in the tags. The rest of the images DJI_0118.jpg through DJI_0254.jpg (lowercase jpg, lots of skipped numbers) all have the full tag set. 

Looks like you burgled a ground reference image from another dataset.

Zane 0 votes
Comment actions Permalink
0
Avatar

Okay, DJI_0001.JPG is the ground image.  The rest were edited and then the original exif cloned back on with exiftool.  I'll have to see how it can be adding something when it's supposed to just clone the set of originals.  Was it unexpected by the app because it had the tags or because some did and some didn't?

For what it's worth, Metashape and Reality Capture didn't raise a fuss.

The missed ##s is fine.  I only needed a small section and tried to grab enough overlap for that only.  In a previous extensive comparison of MME with the top local solutions, MME did fine on volume estimates.  Someone in a user forum was saying they felt that MME's volume calcs were way off and I let them know about my results.  I don't think that actually did much meaningful testing. So, I'm just running this small set to grab the volumes from a couple of piles to compare with Metashape which I used for this job.

 

Dave Pitman 0 votes
Comment actions Permalink
0
Avatar

We are doing a lot of stuff behind the scenes with the various tags. We do things a certain way if the tags are there and another way if they are not. The mix of the two didn't fly with the new stuff we added. We will fix that. XMP is pretty hard to copy around but it looks like the bulk of the images had it. It was just the one ground image that did not.

The volume measurements are only as good as the source model and the polygon that gets drawn. There are a lot of ways to mess it up but based on the jobs we see coming through I would say it is working for people since stockpile work seems to be a fair portion of what we see. People love to not follow instructions and then wonder why things aren't working...

Zane 0 votes
Comment actions Permalink
0
Avatar

My bad. It is the other way around. The 0001.JPG is the one that has the EXIF. The rest of the images do not. 

Zane 0 votes
Comment actions Permalink
0
Avatar

I just compared an original image's meta with it's copied version and they are not the same. So it looks like it's not cloning the meta exactly like I thought it was.  Like I said, the photos processed in the other engines but if it's a pain in MME with the resulting meta from this process, I just won't do that anymore is the easy solution.

Dave Pitman 0 votes
Comment actions Permalink