On Tue, 29 Mar 2011, Paolo Santinelli wrote: > Hi Guennadi, > > thank you for the quick answer. > > Here is what I mean with dynamic: I take "live" one frame at high > resolution, for example a picture at VGA or QVGA resolution, then a > sequence of frames that depict a cropped area (200x200 or 100x100) > from the original full-resolution frame, and then a new full > resolution image (VGA or QVGA) and again the sequence of frames that > depict a cropped area from the original full resolution, and so on. > That means takes one frame in 640x480 and than takes some frames at > 100x100 (or 200x200) and so on. Ic, so, if you can live with a fixed output format and only change the input cropping rectangle, the patch set, that I've just sent could give you a hint, how this can be done. This would work if you're ok with first obtaining VGA images scaled down to, say, 160x120, and then take 160x120 cropped frames unscaled. But I'm not sure, this is something, that would work for you. Otherwise, unless your sensor can upscale cropped images to VGA output size, you'll also want fast switching between different output sizes, which you'd have to wait for (or implement yourself;-)) Thanks Guennadi > > The best would be have two different fixed-output image formats, the > WHOLE IMAGE format ex. 640x480 and the ROI format, 100x100. The ROI > pictures obtained cropping the a region of the whole image. The > cropping area could be even wider than 100x100 and then scaled down > to the 100x100 ROI format. > > Probably it is more simple have a cropping area of the same dimension > of the ROI format, 100x100. > > In this way there is a reduction of the computation load of the CPU > (smaller images). > > Thank you very much! > > Paolo > > 2011/3/29 Guennadi Liakhovetski <g.liakhovetski@xxxxxx>: > > On Tue, 29 Mar 2011, Paolo Santinelli wrote: > > > >> Hi all, > >> > >> I am using a PXA270 board running linux 2.6.37 equipped with an ov9655 > >> Image sensor. I am able to use the cropping and scaling capabilities > >> V4L2 driver. > >> The question is : > >> > >> Is it possible dynamically change the cropping and scaling values > >> without close and re-open the camera every time ? > >> > >> Now I am using the streaming I/O memory mapping and to dynamically > >> change the cropping and scaling values I do : > >> > >> 1) stop capturing using VIDIOC_STREAMOFF; > >> 2) unmap all the buffers; > >> 3) close the device; > >> 4) open the device; > >> 5) init the device: VIDIOC_CROPCAP and VIDIOC_S_CROP in order to set > >> the cropping parameters. VIDIOC_G_FMT and VIDIOC_S_FMT in order to set > >> the target image width and height, (scaling). > >> 6) Mapping the buffers: VIDIOC_REQBUFS in order to request buffers and > >> mmap each buffer using VIDIOC_QUERYBUF and mmap(): > >> > >> this procedure works but take 400 ms. > >> > >> If I omit steps 3) and 4) (close and re-open the device) I get this errors: > >> > >> camera 0-0: S_CROP denied: queue initialised and sizes differ > >> camera 0-0: S_FMT denied: queue initialised > >> VIDIOC_S_FMT error 16, Device or resource busy > >> pxa27x-camera pxa27x-camera.0: PXA Camera driver detached from camera 0 > >> > >> Do you have some Idea regarding why I have to close and reopen the > >> device and regarding a way to speed up these change? > > > > Yes, by chance I do;-) First of all you have to make it more precise - > > what exactly do you mean - dynamic (I call it "live") scaling or cropping? > > If you want to change output format, that will not be easy ATM, that will > > require the snapshot mode API, which is not yet even in an RFC state. If > > you only want to change the cropping and keep the output format (zoom), > > then I've just implemented that for sh_mobile_ceu_camera. This requires a > > couple of extensions to the soc-camera core, which I can post tomorrow. > > But in fact that is also a hack, because the proper way to implement this > > is to port soc-camera to the Media Controller framework and use the > > pad-level API. So, I am not sure, whether we want this in the mainline, > > but if already two of us need it now - before the transition to pad-level > > operations, maybe it would make sense to mainline this. If, however, you > > do have to change your output window, maybe you could tell us your > > use-case, so that we could consider, what's the best way to support that. > > > > Thanks > > Guennadi > > --- > > Guennadi Liakhovetski, Ph.D. > > Freelance Open-Source Software Developer > > http://www.open-technology.de/ > > > > > > -- > -------------------------------------------------- > Paolo Santinelli > ImageLab Computer Vision and Pattern Recognition Lab > Dipartimento di Ingegneria dell'Informazione > Universita' di Modena e Reggio Emilia > via Vignolese 905/B, 41125, Modena, Italy > > Cell. +39 3472953357, Office +39 059 2056270, Fax +39 059 2056129 > email: <mailto:paolo.santinelli@xxxxxxxxxx> paolo.santinelli@xxxxxxxxxx > URL: <http://imagelab.ing.unimo.it/> http://imagelab.ing.unimo.it > -------------------------------------------------- > --- 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
