Open lbestock opened 4 years ago
Discussed briefly today the need to store folders of images that have not yet been processed into models but need to retain their relationship with one another in order to one day be so processed. They have zero point as individual images; they matter only because they can be processed collectively to form a model. But one doesn't just do that, one waits until one needs something from that model. See also Alex's response about Pompeii and how they deal with gaps in the recording, #31. They, too, use models extensively, even to the point of ignoring elevation in excavation because it can be recovered from the models. To get elevation data from the model requires GIS. But to use the file repository to store and then find the files to produce the model of a context is something we will want to support, I am really pretty sure. Those files need to not only not go back into the recording system, they also need to not clutter an image search for a context in the file repository. This is why I think of a folder "Modeling shots Locus FA-001, Opening" or some such. Searching FA-001 then gives you all the locus photos you expect from the recording system and the QR codes, but rather than showing you the individual shots to be turned into a model you just see the folder on a search. One would need, too, then, to be able to download them in bulk rather than individually.
This is in fact a somewhat separate issue from how to deal with models themselves once they are produced, except that models cannot exist without reference to their photos and file paths on this front have always been a nightmare. How would a folder in the file repository (something we have not even discussed previously so I don't know if it can exist!) with the images to model interact with a model once made? I was thinking of downloading the images and then producing the model. Are there other options (and really, ones that do not burn the entire Amazon every time a team member wants to look at the model?)
Candace and Tyler, can I ask you please also to make notes here on anything that Connor comes up with regarding how to access Brown's roving license for Photoscan, and what workflow is for model making given that software usage here?
First of all this is a matter of space and bandwidth. One can use a container format like zip and put it all in there and the zip is stored in the file repository. But think about online servers. Not doable from my perspective. Or at least I really don't believe the benefits are worth the effort. People will always still have to organize their local storage. Otherwise we would be creating a new file system. Currently I am not convinced that's a goal worth pursuing and I have my doubts one could get there.
If we talk about local severs only (and I really wish we did because these online servers create the illusion that it could all happen online) I can imagine that instead of moving stuff to the file repository one could store links to local storage places outside of the file repository. That way the system would know about the information but does not have to store and duplicate it. Also one does not have to transfer it to the system and back over and over again. That really does not make much sense.
I have deleted the Before next season because it won't happen before next season. I doubt that I'll make it there within the remaining year.
see #133 #138 #43
Took this out of USTP as it is a more general question that is not high on our list
How can we store 3D models? For USTP they are a major part of the recording. Can they be stored in a useable way without storing the photos they are made from? But in fact, don't we want to store the photos they are made from? We do NOT want those photos to end up anywhere in the recording system, nor do we want them to come up in FR image searches. But if the FR is to hold all the project's files... But huge.