Re: soc_camera dynamically cropping and scaling

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



OK!

Thanks

Paolo

2011/3/30 Guennadi Liakhovetski <g.liakhovetski@xxxxxx>:
> On Wed, 30 Mar 2011, Paolo Santinelli wrote:
>
>> Hi Guennadi,
>>
>> Am I wrong or do  I have to add some functions ?
>>
>> I have hand applied the changes at the soc_camera.c and soc_camera.h
>> files. At a fist glance to these files seems that I have to add the
>> function:
>>
>>  .set_livecrop()
>
> Yes, I think, I mentioned this in my last mail, that's what my sh-ceu
> example should have illustrated.
>
>>
>> and probably even something more:
>>
>>   CC      drivers/media/video/soc_camera.o
>> drivers/media/video/soc_camera.c: In function 'soc_camera_s_fmt_vid_cap':
>> drivers/media/video/soc_camera.c:545: error: implicit declaration of
>> function 'vb2_is_streaming'
>> drivers/media/video/soc_camera.c:545: error: 'struct
>> soc_camera_device' has no member named 'vb2_vidq'
>> drivers/media/video/soc_camera.c: In function 'soc_camera_s_crop':
>> drivers/media/video/soc_camera.c:799: error: 'struct
>> soc_camera_device' has no member named 'vb2_vidq'
>> make[3]: *** [drivers/media/video/soc_camera.o] Error 1
>
> You have to use current sources. 2.6.39-rc1 should be ok.
>
> Thanks
> Guennadi
>
>>
>> What about vb2_is_streaming and vb2_vidq ?
>>
>> Any tips regarding these functions ?
>>
>> Thanks
>>
>> Paolo
>> 2011/3/30 Paolo Santinelli <paolo.santinelli@xxxxxxxxxx>:
>> > Hi Guennadi,
>> >
>> > thank you very much for the patch. I am going to apply it in order to
>> > start toying with the new capability. I think it is a  useful
>> > capability.
>> >
>> > I'll let you know.
>> >
>> > Again thank you.
>> >
>> > Paolo
>> >
>> > 2011/3/30 Guennadi Liakhovetski <g.liakhovetski@xxxxxx>:
>> >> 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/
>> >>
>> >
>> >
>> >
>> > --
>> > --------------------------------------------------
>> > 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
>> > --------------------------------------------------
>> >
>>
>>
>>
>> --
>> --------------------------------------------------
>> 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/
>



-- 
--------------------------------------------------
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
--------------------------------------------------
--
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


[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux