It’s been quiet here recently, and as is usually the case my work load is to blame. It’s not just that there is way more work than time to do it, but that I am currently doing a bunch of very tedious and a bunch of very thrilling things in parallel. The latter are mostly super-secret (sorry!), but I can tell you that a non-secret one deals with how fat dinosaur tails really were, and how their musculature was arranged. Yes, that old can of worms again. More on that soon!
The boooooooring stuff is, well, boooooring, so let’s skip right ahead. Let’s check out what remains in between totally exciting and secret and yawn-worthy: the latest developments in my digiS project. What I am currently doing for it has its tedious moments, but also some excitement, and a lot of quietly satisfying moments.
Recently, I showed the method for photographing bones I developed for the project. Well, it’s a method that has been shown to work very well indeed, thank you. But does it work reliably? What’s the percentage of failures? And how does it adapt to smaller bones, ones that can be set on a table instead of having to stay on the floor?
I’ve been busy photogrammetrizing more stuff, and trying to find out why my method works so well some of the time, and why I am admittedly getting some abject failures with it. My colleague Matteo Belvedere and I suspected that the cause of some of the failures I experienced was the lack of a sufficient number of overview images. What we saw were slight but noticeable offsets between the point clouds stemming from one set of photos showing one side of the bone and the other set showing the other side. Usually, I had been diligently trying to take photos at angles as low as possible in each set, so that the positions of some images in each of the sets were in fact near-identical – and still there was this odd offset.
Well, I must admit that I have solved the problem but not explained it with my latest tests. I simply took a lot more photos per set, and voilà! no more offset! But because these sets do not only include more photos, but also more overview images and more images of the bones’ “corners”, where th problem was usually most manifest, I can’t really tell what the cause of the issue was. Doesn’t really matter, though🙂 It’s not as if the additional photos take serious time to take.
Here’s an example of the bones of which “many” images were taken and that worked out just fine:
Yes, 23 million polygons. 23 MILLION! That’s from 117 images, taken in 2 minutes and 50 seconds, with a break in between to flip the bone over. In this case I spent nearly three minutes to do this, which means I was in fact talking to someone or doing something else. Typical flipping times are in the order of 20 seconds to one minute.
Let me say this in bold: Photographing this bone took less than 3 minutes!
I’ve also tried more difficult shapes, including a dorsal vertebra of Giraffatitan brancai. That took a lot longer, but then the bone is huge and has a complex geometry.
I really had to show this, just to get SV-POWer Mike Taylor salivating. As you can read on the mesh (no texture calculated) this is AR1, a posterior dorsal of G. brancai that was found isolated. I can’t access the collection database right now, so I can’t tell you the new collection number.
Let me give you a screenshot of part of the Excel sheet I use to document my work times:
606 images of the posterior dorsal took nearly 12 minutes to take, and the model is excruciatingly beautiful. Longbones are typically done in less than 6 minutes overall, despite some chatting in between – hard pressed I could on average do one every 4 minutes, provided they are set out on a table for easy access. In fact, the average photography time of anything classified as a longbone of the entire spreadsheet (with some more bones than in the screenshot above) is 4:17 minutes, and the typical breaks without interruption are less than 30 seconds.
Yeeha! This photogrammetry thing is really cool🙂