Re: [RFC] snapshot mode, flash capabilities and control

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, 27 Feb 2011, Sakari Ailus wrote:

> Hi,
> 
> Guennadi Liakhovetski wrote:
> > On Fri, 25 Feb 2011, Sakari Ailus wrote:
> > 
> > > Hi Guennadi,
> > > 
> > > Guennadi Liakhovetski wrote:
> > > > In principle - yes, and yes, I do realise, that the couple of controls,
> > > > that I've proposed only cover a very minor subset of the whole flash
> > > > function palette. The purposes of my RFC were:
> > > 
> > > Why would there be a different interface for controlling the flash in
> > > simple cases and more complex cases?
> > 
> > Sorry, not sure what you mean. Do you mean different APIs when the flash
> > is controlled directly by the sensor and by an external controller? No, of
> > course we need one API, but you either issue those ioctl()s to the sensor
> > (sub)device, or to the dedicated flash (sub)device. If you mean my "minor
> > subset" above, then I was trying to say, that this is a basis, that has to
> > be extended, but not, that we will develop a new API for more complicated
> > cases.
> 
> I think I misunderstood you originally, sorry. I should have properly read the
> RFC. :-)
> 
> Your proposal of the flash mode is good, but what about software strobe (a
> little more on that below)?
> 
> Also, what about making this a V4L2 control instead?

These are two things, I think: first we have to decide which functions we 
need, second - how to implement them. Sure, controls are also a 
possibility.

> The ADP1653 driver that
> Laurent referred to implements flash control using V4L2 controls only.
> 
> A version of the driver is here:
> 
> <URL:http://gitorious.org/omap3camera/mainline/commit/a41027c857dfcbc268cf8d1c7c7d0ab8b6abac92>
> 
> It's not yet in mainline --- one reason for this is the lack of time to
> discuss a proper API for the flash. :-)
> 
> ...
> 
> > > > > This doesn't solve the flash/capture synchronization problem though. I
> > > > > don't
> > > > > think we need a dedicated snapshot capture mode at the V4L2 level. A
> > > > > way to
> > > > > configure the sensor to react on an external trigger provided by the
> > > > > flash
> > > > > controller is needed, and that could be a control on the flash
> > > > > sub-device.
> > > > 
> > > > Well... Sensors call this a "snapshot mode." I don't care that much how
> > > > we
> > > > _call_ it, but I do think, that we should be able to use it.
> > > 
> > > Some sensors and webcams might have that, but newer camera solutions
> > > tend to contain a raw bayer sensor and and ISP. There is no concept of
> > > snapsnot mode in these sensors.
> > 
> > Hm, I am not sure I understand, why sensors with DSPs in them should have
> > no notion of a snapshot mode. Do they have no strobe / trigger pins? And
> > no built in possibility to synchronize with a flash?
> 
> I was referring to ISPs such as the OMAP 3 ISP. Some hardware have a flash
> strobe pin while some doesn't (such as the N900).

Of course, if no flash is present, you don't have to support it;)

> Still, even if the strobe pin is missing it should be possible to allow
> strobing the flash by using software strobe (usually an I2C message).
> 
> I agree using a hardware strobe is much much better if it's available.

Again - don't understand. Above (i2c message) you're referring to the 
sensor. But I don't think toggling the flash on per-frame basis from 
software via the sensor makes much sense. That way you could also just 
wire your flash to a GPIO. The main advantage of a sensor-controlled flash 
is, that is toggles the flash automatically, synchronised with its image 
read-out. You would, however, toggle the flash manually, if you just 
wanted to turn it on permanently (torch-mode).

> > > > Hm, don't think only the "flash subdevice" has to know about this.
> > > > First,
> > > > you have to switch the sensor into that mode. Second, it might be either
> > > > external trigger from the flash controller, or a programmed trigger and
> > > > a
> > > > flash strobe from the sensor to the flash (controller). Third, well, not
> > > > quite sure, but doesn't the host have to know about the snapshot mode?
> > > 
> > > I do not favour adding use case type of functionality to interfaces that
> > > do not necessarily need it. Would the concept of a snapshot be
> > > parametrisable on V4L2 level?
> > 
> > I am open to this. I don't have a good idea of whether camera hosts have
> > to know about the snapshot mode or not. It's open for discussion.
> 
> What functionality would the snapshot mode provide? Flash synchronisation?
> Something else?

Also pre-defined number of images, enabling of the trigger pin and trigger 
i2c command. Just noticed - on mt9t031 and mt9v022 the snapshot mode also 
enables externally controlled exposure...

> I have to admit I don't know of any hardware which would recognise a concept
> of "snapshot". Do you have a smart sensor which does this, for example? The
> only hardware support for the flash use I know of is the flash strobe signal.

Several Aptina / Micron sensors have such a mode, e.g., mt9p031, mt9t031, 
mt9v022, mt9m001, also ov7725 from OmniVision (there it's called a "Single 
frame" mode), and, I presume, many others. And no, those are not some 
"smart" sensors, the ones from Aptina are pretty primitive Bayer / 
monochrome cameras.

> Flash synchronisation is indeed an issue, and how to tell that a given frame
> has been exposed with flash. The use of flash is just one of the parameters
> which would be nice to connect to frames, though.

Hm, yes, that's something to think about too...

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux