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 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 -- Hans Verkuil - video4linux developer - sponsored by Cisco -- 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
