Hello, On 11/22/2010 12:53 PM, Hans Verkuil wrote: > On Monday, November 22, 2010 12:34:50 Laurent Pinchart wrote: >> On Monday 22 November 2010 12:34:04 Laurent Pinchart wrote: >>> On Monday 22 November 2010 12:23:49 Hans de Goede wrote: >>>> On 11/22/2010 11:59 AM, Laurent Pinchart wrote: >>>>> On Sunday 21 November 2010 00:50:59 Shuzhen Wang wrote: >>>>>> Hello, Laurent, >>>>>> >>>>>> Thank you for the reply. >>>>>> >>>>>> In our case, most of the time the sensor outputs bigger image size >>>>>> than the output size, so the ISP hardware does downscaling. >>>>>> When zooming in, we can do cropping, and less downscaling to achieve >>>>>> the same output size. All these happen under of the hood of ISP >>>>>> driver. That's why I said it was like optical zoom to the >>>>>> application. >>>>>> >>>>>> So if "digital zoom == cropping and upscaling", then I don't think my >>>>>> case fits in digital zoom category. >>>>> >>>>> Digital zoom is cropping and scaling. Whether it's downscaling or >>>>> upscaling (or even no scaling it all for a specific resolution) is not >>>>> really relevant here. It depends on the output resolution but it's >>>>> still digital zoom that should be implemented using the crop API. >>>> >>>> Not sure I agree with this, given that AFAIK no application actually uses >>>> the crop API, and that almost no mere human seems to understand the crop >>>> API, >> >> Oh, and if our current crop API sucks, let's make a new one :-) > > What is needed is some clarification in the case of digital inputs. Most if not > all of the nastiness in this API will fall away in the digital case. > > The problem is not so much with the API as it is with how it is described in > the spec. > > What we *do* miss is an API to do cropping after scaling. Right now crop comes > before scaling (for capture, it's the reverse for output). I would like to second that. In Samsung S5P SoCs camera capture devices can do cropping at both sensor and DMA output side. The current V4L2 capture API let us to configure cropping only at image sensor side (host interface input). It there were means to define cropping on captured buffer the cropping and scaling could be configured by the application at required points to obtain desired behaviour. And in general I support Laurent's opinion that it could be better to improve cropping API rather than replace it with the zoom controls. Regrads, Sylwester > >> >>>> I would like to advocate for exporting digital zoom as a separate >>>> control (for those cases were the hardware adds something to merely doing >>>> this in software). >>> >>> I disagree with that :-) >>> >>> The purpose of V4L drivers is to let userspace control the hardware. If we >>> added a digital zoom control drivers would then need to implement policies >>> (for instance how do you configure crop settings to get a linear zoom value >>> ?) and that doesn't belong to kernelspace. >>> >>> If the hardware can perform cropping and scaling, let's expose that to >>> applications as cropping and scaling. Whether they use it to implement >>> digital zoom, or for an entirely different purpose, is up to them. I don't >>> want to see drivers exposing cropping and scaling as zoom, pan and tilt >>> CIDs. > > I agree with this. > > Regards, > > Hans > -- Sylwester Nawrocki Linux Platform Group Samsung Poland R&D Center -- 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
