Hi Eino-Ville, On Tuesday 23 November 2010 00:18:18 Eino-Ville Talvala wrote: > On 11/19/2010 6:22 AM, Laurent Pinchart wrote: > > On Friday 19 November 2010 15:15:11 Guennadi Liakhovetski wrote: > >> On Fri, 19 Nov 2010, Laurent Pinchart wrote: > >>> On Friday 19 November 2010 14:42:31 Hans Verkuil wrote: > >>>> On Friday 19 November 2010 14:26:42 Laurent Pinchart wrote: > >>>>> Some buggy sensors generate corrupt frames when the stream is > >>>>> started. This new operation returns the number of corrupt frames to > >>>>> skip when starting the stream. > >>>> > >>>> Looks OK, but perhaps the two should be combined to one function? > >>> > >>> I'm fine with both. Guennadi, any opinion ? > >> > >> Same as before;) I think, there can be many more such "micro" > >> parameters, that we'll want to collect from the sensor. So, if we had a > >> good idea - what those parameters are like, we could implement just one > >> API call to get them all, or even just pass one object with this > >> information - if it is constant. If we don't have a good idea yet, what > >> to expect there, it might be best to wait and first collect a more > >> complete understanding of this kind of information. > > A few days late on this, but I wanted to add my two cents. > > When using V4L2 for still photography applications (like what's done on the > N900, or on our custom Frankencamera), it becomes a lot more important to > know what data is good or bad, when typically you capture only one or a > few frames at a high resolution, before dropping back down to a > viewfinding mode. One doesn't want to throw any frames on the floor if it > isn't absolutely neccessary ( 100 ms extra shutter lag for every frame you > have to drop, on the N900). So having some reasonable way to know when > the data becomes good is very helpful. I agree with this. To make things worse, as Guennadi noted, the world isn't black and white and we have lots of shades of grey between "good" and "bad". Depending on the use case the same image could be considered good or bad. That's why we will need to pass metadata to userspace at some point (providing the kernel can receive the metadata from the hardware of course). This patch aims at solving a subset of the good-bad problem, namely sensors that always produce a fixed number of completely corrupted frames when the stream starts. > Sensor data sheets are also often rather vague, and state things like > changing regions of interest, digital zoom, etc, 'may cause a bad frame'. > It'd be great if once somebody figures out what 'may' translates to, not > everyone has to figure it out again for every application. I totally agree. We would need better cooperation from sensor vendors. -- Regards, Laurent Pinchart -- 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
