Hello, Laurent, I Get the logic you have behind using cropping/scaling. The reason I wanted to use V4L2_CID_ZOOM_ABSOLUTE are that the application will have a simpler interface to control zoom level supported by the hardware (yet may be less flexible). In other words, the driver gives out the zoom range, and the application doesn't need to calculated different cropping windows. By doing this we don't add policies into the driver, because in our implementation the request is forwarded by the driver to a user space daemon, who in turn talks back to the driver to control the hardware. I guess I will need to conform to the cropping/scaling interface then. -Shuzhen -----Original Message----- From: linux-media-owner@xxxxxxxxxxxxxxx [mailto:linux-media-owner@xxxxxxxxxxxxxxx] On Behalf Of Laurent Pinchart Sent: Monday, November 22, 2010 3:35 AM To: Hans de Goede Cc: Shuzhen Wang; linux-media@xxxxxxxxxxxxxxx Subject: Re: Zooming with V4L2 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 :-) > > 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. -- 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 -- 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
