Hi everybody, I'm Richard, but a link is in the end of the video and I'll show you a proposal
on how to enhance flash control in video for Linux 2.
This presentation is covering LED flashes only, so if you're doing xenon, that's not an issue.
It's condensed because it's a lighting talk and I use open flashes, interchangeable terms for this thing.
Why wouldn't a better guy like me mess around with flashes?
It's because we're building autonomous driving logistics shuttles, which need to be localized and fine-positioned in a dark warehouse, so no artificial lighting.
Those shuttles drive on rails, those rails have 2D barcoats and engraved, and we have two global shutter cameras on this shuttle.
On the shuttle, which run at 120 frames per second, they have a flash attached, so we can light those barcoats.
The shuttle is moving at 2.5 meters a second, so we need to keep the exposure time low.
To not get any blurs on the image, and therefore we need flash support.
Of course we need to use a mainline Linux kernel, like everybody does, and therefore we need to get a mainline.
But let's first start with a few basics on flash, what's a flash?
It's the light limit in unit connected to a camera.
It may be some kind of next view, or small PCB with a few LEDs on it, or a camera flashes.
You know it, or even a studio stroke, it doesn't matter for the Linux kernel.
Regarding flash control components from a Linux kernel point of view, we have imaging sensor,
which, as you guess, takes the actual image, also takes care of doing exposure and stuff like that.
Then you have a stroke source, the thing which says, now you need to stroke, now we want some light.
This is often part of the imaging sensor.
Those stroke source signal then goes to the flash controller.
The flash controller consumes the signal, and may add some extra configuration on it, which I will show later.
And finally, you have a flash device that's behind the flash controller.
That's the thing we saw before, the thing actually emitting light.
Regarding timing, just to get you all on the same page.
For a rolling shutter camera that's the normal use case, you have a flash.
If it's the same length as the exposure time, just to get it evenly lighted.
If your flash is a little bit lazy, and as a little bit delay, on startup, you may want to add a flash offset.
So the flash is triggered a few microseconds, and another second, before the actual exposure starts.
So the flash can produce the light and get it out.
You can also do a flash offset, positive flash offset, so the flash files later than the exposure time.
And you may reduce the flash duration to be shorter than the exposure time.
For example, if you have a sensor already configured to the minimum exposure time, and the frame is still too light, or other use cases.
So in Linux 2019, which I guess will be released next week, we configure flashes using video for Linux 2 controls.
The first one is the flash LED mode, so you configure the flash system to be flashing, like, my screen.
You can, you must, you have to select the strobe source, so you have two choices here, a source software, which is an unsynchronized flash, so the software is in charge of figuring the strobe or an external source, so hardware strobe source.
For the anchors synchronized flash control, you enable the strobe using visual tool, a control, and develop using the stop.
The flash controller comes outside, you may configure a flash timeout, that's not the flash duration, because the flash timeout defines the hardware timeout for the flash, so the flash controller turns off the flash, after the given amount of time, just to save the flash from burning, that's the idea behind that.
So if your flash will burn after 5 milliseconds of lighting, because it's barely designed, or it's just the case, this control is for you to just limit the time, the maximum time it is allowed to flash.
And some flash controllers offer the possibility to configure flash intensity, which is mostly in milliamps, so you can control the amount of power going in.
I had a bunch of more controls and status and failure stuff, I don't mention here, because that's not that relevant for this talk.
A flash controller isn't always a complex device, like integrated circuit, which can be configured, it may even be just a transistor switching, the power to your LEDs.
So the proposal I'm doing has done is to introduce a flash stroke output enable signal, so we can tell the stroke source, so most typically a camera sensor, he's now allowed to stroke, to do stroke output based on its configuration, so this does not trigger a flash signal, like the control before in the engine,
it just enables the stroke source to stroke, and it's only valid for external stroke sources, I promise it's not my notebook.
Also, I propose to introduce a flash duration control, which is the time the stroke source should actually be flashing, so in this one may then be overwritten by the flash time out in the flash controller, but it's the configured, it's annoying, it's the configured time, the flash source, the stroke source should be flashing, it's typically implemented by the camera sensor.
And finally, as I might have guessed, because of the previous slides, it's a flash offset, a positive and negative time offset between the start of the exposure time and start of the stroke signal, for positive and negative offset, this may be implemented by a stroke source, when it's part of the camera sensor, because the only one in the system knowing when the exposure starts, beforehand, is the camera sensor, because a flash controller, which is,
behind the camera sensor, logically, is only able to do a delay of the exposure time.
So for visualization purposes, here the two configurable controls, you can shift the flash offset around the exposure time start and configure the duration using flash duration.
What's the status of this? The stroke output enable and the flash duration are submitted, are now in the cleanup branch of the maintainer, Sakari, and hopefully, it's now version 10 of the patch set.
Hopefully, it goes in for the next murder window, so Linux 620 or 70, I have no idea, and the flash offset, that's basically in development or done, and it will submit it to the mailing list as soon as the merge window is over and the flash duration.
If the user interface, the user, the API fits their needs, use it with the great to have a few more flash users in, and we for L2 API, if not, and hence it improve it, you know the deal, or just come talk to me.
And as a few lip camera guys are here, because I guess the next two dogs are lip camera, I have seen discussions on the lip camera mailing list about this, and of last year, so maybe there will also be an implementation, the stack upwards,
I'm certainly a camera, so no time for questions to test, but come and reach out, I'm here, personally, or we're one of those channels.
Thank you.