I'm pretty curious as to what you've discovered / worked on so far or have any interesting CV ideas you'd like to see?
Do we know the "gamma" curves, i.e. numerical intensity value as a function of light collected proportional to the number of photons?
67dB = 6.7B => brightest over softest intensity = 10^6.7 = 5 000 000
thats ln(10^6.7)/ln(2) = 22.257 bits, that's unheard of for camera sensors I have looked up, so I assume the reported values are "gamma" compressed before digitization.
Would you have interest in characterizing or collaborating on characterizing the exact compression function for the V1 and V2? Relevant literature seems to be Steve Mann's comparametric equations: https://en.wikipedia.org/wiki/Comparametric_equation
(I am interested in high dynamic range, and high monochromatic or color bit depth for an experiment, which will progress much faster if I can start out with a higher dynamic range and bit depth sensor, I will need to oversample to observe a phenomenon, and every bit of increased depth a sensor has compared with another sensor would mean the experiments can be run 4 times as fast...)
I'd probably like to have a go at replicating some of the Blue River, Bilbery ideas but on a budget. That is sensing weeds or crop issues on the move therefore requiring global shutter. Uniform light throughout the day/night is another issue I am thinking through.
Working through fastai when I get a chance but my biggest issue is finding domain specific datasets.
Really cool results, although that bullet catcher setup is slightly horrifying.
LOL, yeah, it looks pretty sketchy. It is a proper bullet trap though, in fact the very same one that Harold Edgerton used for his famous bullet through apple image :)
But yeah, I think you're right the title doesn't seem like it's related, suggestions for a better title?
It's a great project! We used to do this with modified Canon 5Ds at a company I worked for and it was very expensive to set up
"bullet time" was, at least, animated. I also understand that it is very possible that you can do that (just that are not showing it).
I guess what's different here is we're not using a $300 DSLR. We're using a $5 raspberry pi camera.
If we did the "let's take a bunch of high speed synchronized pictures with a strobe" on the cheap cameras, we'd see a single row of pixels worth of image, if we're lucky because of rolling shutter.
What we've done here is hack together some software to get a global shutter on these cheap cameras. Now that we can take pretty high speed pictures with $5, we scaled it up to get 16 cameras and took 16 angles of a bullet going though an apple, all at once. The "bullet time" examples in the repo are not computer graphics, they are 16 individual images played one after another.
I think you're getting so many confused people because of your new domain expertise in playing with strobes for the class.
Most people are assuming you're synchronizing a bunch of cameras at very low latency and high speeds with a long lived light, but it appears you're using a dark room with a strong, short strobe as a shutter instead.
The real hack (if I understand correctly) is using your global shutter to take in a consistent point in time.
Maybe adding a non-global shutter image to compare and contrast the value of that hack would work in conveying how it works? Maybe a video too? In infrared?
These two changes can really help quickly communicate the work you're doing and get more people interested.
Either way, great work, excited to see what else you make!
I think that your project is an incredible one. Any project that goes "We did this with $5 instead of $5000" is totally worth it, from whatever point of view you want to see it.
There's an interesting and IMO relevant trend I see in technology these days, where coupling open technologies with smart people like you ends up allowing what's considered "extreme high tech" to be available to the "normal" people.
I just wanted to point out that may be you're not showing up the full capabilities of what you did.
I take it that if the strobe light is fast enough, you could get the different cameras to fecth frames from different flashes, thus creating a "real" bullet time sequence?
The heart of it is just sending a few bytes down the I2C bus, but reverse engineering the register set was the challenging part as the datasheets are given only to OEMs.
What is the resolution/byte size of each frame versus the bandwidth of the I2C bus? Is there room on the bus for all that data?
Still super cool - the meat of what's novel here isn't the image assembly though, but rather the reverse engineering of the pi cams in a global shutter mode - I'm definitely interested in what the tradeoffs are around global vs. rolling shutter, if there's image artifacts or bandwidth issues, or what. Neat work gang!