In 2008 I was hired by a game studio to build a HW/SW system for synchronizing a Canon EOS 1D Mark III and a series of studio flashes. The idea was to use its ability to take ten pictures a second to take a rapid succession of images with very different lighting. The images were then processed by a series of tools I'd helped develop the previous year.
The timeline was pretty tight, so I had to begin development before I had the camera. I contacted Canon support to confirm that the 10 pics per second was only when given a continuous signal and to ask which speeds it could reach when taking separate pictures via remote trigger. Their support tech insisted it was irrelevant since I couldn't possibly press the button that fast. I tried, to no avail, to explain that it was a computer sending the signal and it could do so (with the hardware I had) a thousand times per second. Reluctantly, he forwarded the question to their technical support, who never answered.
I ended up using a continuous signal and having my program listen to the remote flash connector. It worked splendidly.
Any manufacturer that’s even remotely serious wouldn’t need to test their own product to find out how it works. Each component in the chain, from trigger button to storage I/O, had presumably been tested and its tolerances documented. Responding to such a query could (should?) be as easy as checking the specs. “In theory this camera can support up to N triggers per second, which is the limit for part X, but you will need your storage to sustain writes at speed S or the buffer will fill up, and by the way this wasn’t tested end-to-end and will void your warranty.”
It’s more likely they just wouldn’t tell for whatever reason. A mass manufacturer probably doesn’t want to give an impression that they encourage a way of using the units not explicitly mentioned in the manual to avoid any complaints/lawsuits. Also, some companies require tech support staff to respond to a certain minimum number of tickets per hour (effectively penalizing personnel for doing anything beyond provided checklists, which consulting part specs definitely would be).
It's more likely still that the person answering emails didn't know the answer, and either was unmotivated or unable to put the question in front of someone who did know the answer and then follow up with them to respond.
This is when having contacts inside a company helps. Either be a big enough customer to warrant their attention by default, or make friends with the company rep when she calls or stops by. If you aren't a large enough customer to have either of those options available to you, then you get the attention they feel you are worth as an end user.
I suspect its 1000x easier to just wire an arduino to the trigger and have it pulse rapidly than it is to pour over spec sheets and only end up with a "It looks like it should work"
Are you saying that testing is a huge amount of work, and looking at specs is further 1000x harder?
Tech support staff might not have a test bench at hand at all times (and an Arduino unit out of the blue might’ve required a month to approve and purchase), but they don’t need any equipment to pull specs for a part from internal documentation, which support staff must be very adept at scanning by the nature of their job. I believe this is what tech support more or less for, in a better world.
They probably had an answer at their fingertips without any need for testing, but communicating it was against their/company’s interests.
I doubt a support person from a camera company even has the skills to understand the datasheets. 99.9% of their job is explaining things in the public manual and handling product returns. The only people with the skills to understand it would be the engineers and it would be a waste of time assigning them to investigate this unsupported hack.
I know some tech support folks and consulting docs and specs is more than comfortably within their reach. In fact, it’s what they do at better companies where management does not preclude them from doing their job properly and provides access to relevant data.
> A mass manufacturer probably doesn’t want to give an impression that they encourage a way of using the units not explicitly mentioned in the manual to avoid any complaints/lawsuits.
That, or they may have a product line which is designed for that usage case, and they don't want to hurt its sales.
>Because they don't know off the top of their heads and would have to test it to be sure which is a huge amount of work they don't have to do.
And that's called... poor customer service.
Had I been faced with that behavior and had the freedom to switch vendors as OP I would have -- meaning that support behavior isn't without flaw, they lose a certain threshold of customers.
This is just self-aggrandising. No mass production vendor would do R&D for your bizarre use case unless there's clear PR potential or you are ready to pick the tab.
Yeah I used to be in a weird position where most of my time was spent figuring out how to use and abuse a bunch of off-the-shelf things to build out one-offs of whatever crazy crap people could come up with. Lots of hardware and software reverse engineering and integration.
I’d never in a million years expect a company to do my R&D/integration work for me when I’m buying one mass-produced consumer item and using it outside of its intended use-case.
Not a single company is going to recreate your unsupported setup to see what would happen and let you know unless there was a huge payment being made. Since the only reason OP is doing this is to save time, it would make no sense to spend weeks going around to each vendor trying to work out which one to pick.
And often support people give wrong info, you may eventually find a vendor that just says "Sure you can do that" and then you get it and find out you cant.
They literally did say that it wasn't possible to do what OP is asking using the provided interface. Its not the support persons job to explain what would happen if you hack the device to work differently.
The supplied interface was actually a connector for remote trigger, which is what I used. The only hack was sending the signal from a programmable device rather than a manual button press.
If you capture an object with light from various angles you can "re-light" it in post-processing. Drop it into different scenes and have realistic lighting coming from different angles. https://augmentedperception.github.io/therelightables/
That's correct. I can't say too much about the details. It ended up working really well but wasn't used in production for reasons of internal politics.
The guy who had the original idea for the system, a former classmate of mine, later went on to start his own company, Quixel, based on similar ideas.
Given the author's other post about a similar technique going on to be used at Quixel, presumably they were inferring normal maps from lighting data, and later metallic, AO, smoothness etc maps for PBR.
In 2008 I was hired by a game studio to build a HW/SW system for synchronizing a Canon EOS 1D Mark III and a series of studio flashes. The idea was to use its ability to take ten pictures a second to take a rapid succession of images with very different lighting. The images were then processed by a series of tools I'd helped develop the previous year.
The timeline was pretty tight, so I had to begin development before I had the camera. I contacted Canon support to confirm that the 10 pics per second was only when given a continuous signal and to ask which speeds it could reach when taking separate pictures via remote trigger. Their support tech insisted it was irrelevant since I couldn't possibly press the button that fast. I tried, to no avail, to explain that it was a computer sending the signal and it could do so (with the hardware I had) a thousand times per second. Reluctantly, he forwarded the question to their technical support, who never answered.
I ended up using a continuous signal and having my program listen to the remote flash connector. It worked splendidly.