CHDK PTP interface - page 54 - General Discussion and Assistance - CHDK Forum supplierdeeply
« previous next »
Pages: 1 ... 49 50 51 52 53 [54] 55 56 57 58 59 ... 125   Go Down

CHDK PTP interface

  • 1240 Replies
  • 451006 Views
*

Offline ntstatic

  • ***
  • 246
Re: CHDK PTP interface
« Reply #530 on: 23 / June / 2011, 01:31:30 »
Advertisements
Quote from: mweerden on 22 / June / 2011, 09:50:09
Quote from: ntstatic on 22 / June / 2011, 08:52:31
@mweerden
is it possible by any chance to get a bigger preview image. i am getting a 360x240. any possibility, it can be around something like 640x480 or so  :)
Depends on what your camera provides and how much work you are willing to do.

For my ixus870 the actual size of the live image is 720x240 (so it is stretched) and I know the G12 has one that is 720x480. In my test app I just always scale the image (and overlay) to 360x240.

I'm pretty sure this format is fixed (i.e. per camera). The only way I see to get more is to somehow access the real raw data provided by the sensor. I have no idea about the possibilities of this. I do know that it means transferring more data and thus likely a (much) lower fps. Only solution to that would be compression before transfer, but that would mean figuring out how to use the camera's dedicated hardware for this or somehow letting the camera just take pictures/movies like normal and directly stream it to your PC. As far as I know the knowledge for these kinds of things is currently not available.
how do i go about knowing what my camera can provide. its a SX120 and in future i am planning to be working on a SX 130 ( it may be possible to get the SX 200 series ). 720x480 is still a 4 fold improvement and i can live with it for the moment :) if it is possible on the SX 120 or the 200 series.
Quote
Depends on what your camera provides and how much work you are willing to do.
there no problem with me putting in the effort. only problem is my limited exposure to this kind of source. still can you guide me what may be needed to do so that i can evaluate if it is in realm of my current capabilities ;).
Logged
*

Offline philmoz

  • *****
  • 3449
    • Photos
Re: CHDK PTP interface
« Reply #531 on: 23 / June / 2011, 01:42:38 »
Quote from: mweerden on 22 / June / 2011, 09:50:09
... and I know the G12 has one that is 720x480.

Are you sure?
The G12 has the same resolution live view buffer as all the other recent cameras - 720x240.

Phil.
Logged
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)
*

Offline ntstatic

  • ***
  • 246
Re: CHDK PTP interface
« Reply #532 on: 23 / June / 2011, 09:15:45 »
i would like to try and patch CHDK to provide two function in the tune of

enable_video_transfer()
disable_video_transfer()

the enable video transfer would provide a preview image or overlay at regular intervals.

can the gurus (mweerden, philmoz, reyalp ...)  guide me and point me if there is a background timer function or a system function which goes on in the background and which i can hook into to provide this.

i dont think this should be run as a lua script - pls correct me if i am wrong or if the whole idea is ridiculous

Logged
*

Offline mweerden

  • ***
  • 194
Re: CHDK PTP interface
« Reply #533 on: 23 / June / 2011, 09:38:25 »
Quote from: philmoz on 23 / June / 2011, 01:42:38
Quote from: mweerden on 22 / June / 2011, 09:50:09
... and I know the G12 has one that is 720x480.

Are you sure?
The G12 has the same resolution live view buffer as all the other recent cameras - 720x240.
Reasonably sure, but I admit I haven't checked it myself. My remote-preview code has been tested by someone with a G12. The code uses its own functions for widths and heights that default to 720x240 for the viewport. This gave only the upper half of the viewport. Changing the height to 480 gave everything. So unless I'm missing something crucial, the viewport should be 720x480 on the G12.
Logged
*

Offline funnel

  • ****
  • 349
Re: CHDK PTP interface
« Reply #534 on: 23 / June / 2011, 09:57:25 »
Quote
Are you sure?
The G12 has the same resolution live view buffer as all the other recent cameras - 720x240.

Phil.

 In sx220 the livefb buffer size is 960x720. I found the buffer size here
Code: [Select]
FF371D70 loc_FF371D70                            ; CODE XREF: sub_FF371C18+13Cj
FF371D70                 CMP     R2, R0
FF371D74                 BHI     loc_FF371D58
FF371D78                 STR     R5, [R8,#0xC]
FF371D7C                 MOV     R2, R6
FF371D80                 MOV     R1, R5
FF371D84                 ADR     R0, aMaxyLdMinyLd ; "MaxY %ld MinY %ld\r"
FF371D88                 STR     R6, [R8,#0x10]
FF371D8C                 BL      sub_FF15334C
FF371D90                 LDR     R0, [R8,#8]
FF371D94                 STR     R0, [R10]
FF371D98                 LDR     R0, [R8,#4]
FF371D9C                 LDR     R1, [R8]
FF371DA0                 MOV     R2, R0,LSL#2
FF371DA4                 LDR     R0, [R9]
FF371DA8                 BL      sub_FF060874
FF371DAC                 LDR     R2, =0xA8C00                //960x720
FF371DB0                 LDR     R1, =0x405D7980
FF371DB4                 LDR     R0, [R9,#4]
FF371DB8                 BL      sub_FF060874
FF371DBC                 MOV     R0, R4
FF371DC0                 BL      j_free
FF371DC4                 LDR     R0, [R8]
FF371DC8                 LDMFD   SP!, {R4-R12,PC}
Logged
*

Offline mweerden

  • ***
  • 194
Re: CHDK PTP interface
« Reply #535 on: 23 / June / 2011, 10:07:18 »
Quote from: ntstatic on 23 / June / 2011, 01:31:30
how do i go about knowing what my camera can provide.
Looking it up online, in the CHDK code or in the firmware. And by experimentation.

Regarding the resolution of the viewport buffer, if you didn't change the patch related to this and you're getting the full image, then it's 720x240. And, as said before, this is almost certainly fixed.

Quote
there no problem with me putting in the effort. only problem is my limited exposure to this kind of source. still can you guide me what may be needed to do so that i can evaluate if it is in realm of my current capabilities ;).
One thing you probably need is functions to send commands to the host instead of the other way around. This means disassembling the firmware and trying to find such functions (or functions that allow you to build it yourself). Unless you have quite some experience reverse engineering like this, I don't expect it is something that you can pick up easily.

As for timing, I guess you could start a separate task and just call msleep. It probably isn't very accurate or reliable though. I'm sure there are some other timing facilities elsewhere; I expect the firmware to need it as well.

Quote from: ntstatic on 23 / June / 2011, 09:15:45
pls correct me if i am wrong or if the whole idea is ridiculous
I wouldn't go as far as calling it ridiculous, but I really don't see the point. It's much easier to regularly pull from the PC and I can't see any advantage in pushing from the camera.
Logged
*

Offline ntstatic

  • ***
  • 246
Re: CHDK PTP interface
« Reply #536 on: 24 / June / 2011, 03:52:30 »
Quote from: mweerden on 23 / June / 2011, 10:07:18
Quote from: ntstatic on 23 / June / 2011, 01:31:30
how do i go about knowing what my camera can provide.
Looking it up online, in the CHDK code or in the firmware. And by experimentation.

Regarding the resolution of the viewport buffer, if you didn't change the patch related to this and you're getting the full image, then it's 720x240. And, as said before, this is almost certainly fixed.

Quote
there no problem with me putting in the effort. only problem is my limited exposure to this kind of source. still can you guide me what may be needed to do so that i can evaluate if it is in realm of my current capabilities ;).
One thing you probably need is functions to send commands to the host instead of the other way around. This means disassembling the firmware and trying to find such functions (or functions that allow you to build it yourself). Unless you have quite some experience reverse engineering like this, I don't expect it is something that you can pick up easily.

As for timing, I guess you could start a separate task and just call msleep. It probably isn't very accurate or reliable though. I'm sure there are some other timing facilities elsewhere; I expect the firmware to need it as well.

Quote from: ntstatic on 23 / June / 2011, 09:15:45
pls correct me if i am wrong or if the whole idea is ridiculous
I wouldn't go as far as calling it ridiculous, but I really don't see the point. It's much easier to regularly pull from the PC and I can't see any advantage in pushing from the camera.

ok thank you for the detailed explanation. i think for the moment i would try to optimize the routine pulling the image from the pc side, like you suggested. also my absolute requirement is only 5 fps and anything more is only for cosmetic purposes. :)

it is only that i was using the previous version - SX 110 and previous - with the canon sdk and it provided a fluent preview. i had SX110 worth a year's stocked but alas they are over. CHDK team and particularly you mweerden have been a lifesaver for me. thank you once again. previously i was thinking about using a video grabber and combining the cables for usb and video ( i used to do that in olympus a couple of years back when they were supported by their SDK ) but for the sx120, the problem is that the video out is not clean and there is at least an overlay of the focus rectangle and a +0 of the ev value. i need a clean video intermittently. i could do that by going to the Video Rec mode and keeping the shoot button half pressed for the duration i wanted to grab the low quality frames. getting a live preview with your patch is 100 times better

and, yes i am getting the whole image in the image preview so it is pretty much settled for the moment 720(360) x 240.

so i would try getting the overlay instead of the bitmap which should be around 3x smaller (like you mentioned). any pointers as to how i should locate the location for the palette in my camera SX120 ?

Logged
*

Offline mweerden

  • ***
  • 194
Re: CHDK PTP interface
« Reply #537 on: 24 / June / 2011, 10:58:26 »
Quote from: ntstatic on 24 / June / 2011, 03:52:30
it is only that i was using the previous version - SX 110 and previous - with the canon sdk and it provided a fluent preview.
Which also suggest the camera shouldn't be the bottleneck (although the firmware might have used compression; which might be interesting to look into). In any case, reversing the roles should have no (significant) effect on the speed.

Quote
so i would try getting the overlay instead of the bitmap which should be around 3x smaller (like you mentioned). any pointers as to how i should locate the location for the palette in my camera SX120 ?
The overlay is the bitmap and note that it does not contain the live image. I found the palette for my camera in the firmware by comparing it with where ewavr found it for other cameras, if I remember correctly. So you'll need two firmware disassemblies, one where you know where it is and the other of your own camera.
Logged
*

Offline reyalp

  • ******
  • 14000
Re: CHDK PTP interface
« Reply #538 on: 24 / June / 2011, 16:01:38 »
Quote from: mweerden on 24 / June / 2011, 10:58:26
Quote from: ntstatic on 24 / June / 2011, 03:52:30
it is only that i was using the previous version - SX 110 and previous - with the canon sdk and it provided a fluent preview.
Which also suggest the camera shouldn't be the bottleneck (although the firmware might have used compression; which might be interesting to look into)
I would bet that the canon firmware jpeg'd the live view before sending it, using something similar to whatever does the mjpeg for video.

In fact, there are references to this in canon (non-chdk) code in ptpcam (ptp.c)
Code: [Select]
* ptp_canon_getviewfinderimage:
 * This operation can be used to read the image which is currently
 * in the camera's viewfinder. The image size is 320x240, format is JPEG.
 * Of course, prior to calling this operation, one must turn the viewfinder
 * on with the CANON_ViewfinderOn command.
 * Invoking this operation many times, one can get live video from the camera!
It's not clear what generation of Canon camera this refers to.

This also shows that the Canon SDK probably used polling just mweerdens code. This isn't a surprise, AFAIK USB up to 2.0 doesn't really have device initiated communications, at the lowest level everything is initiated by the host, even though the software stack might expose it as an event. I could be wrong here, my understanding of USB is fairly limited...
Logged
Don't forget what the H stands for.
*

Offline ntstatic

  • ***
  • 246
Re: CHDK PTP interface
« Reply #539 on: 25 / June / 2011, 07:07:13 »
Quote from: reyalp on 24 / June / 2011, 16:01:38
Quote from: mweerden on 24 / June / 2011, 10:58:26
Quote from: ntstatic on 24 / June / 2011, 03:52:30
it is only that i was using the previous version - SX 110 and previous - with the canon sdk and it provided a fluent preview.
Which also suggest the camera shouldn't be the bottleneck (although the firmware might have used compression; which might be interesting to look into)
I would bet that the canon firmware jpeg'd the live view before sending it, using something similar to whatever does the mjpeg for video.

In fact, there are references to this in canon (non-chdk) code in ptpcam (ptp.c)
Code: [Select]
* ptp_canon_getviewfinderimage:
 * This operation can be used to read the image which is currently
 * in the camera's viewfinder. The image size is 320x240, format is JPEG.
 * Of course, prior to calling this operation, one must turn the viewfinder
 * on with the CANON_ViewfinderOn command.
 * Invoking this operation many times, one can get live video from the camera!
It's not clear what generation of Canon camera this refers to.

This also shows that the Canon SDK probably used polling just mweerdens code. This isn't a surprise, AFAIK USB up to 2.0 doesn't really have device initiated communications, at the lowest level everything is initiated by the host, even though the software stack might expose it as an event. I could be wrong here, my understanding of USB is fairly limited...

Canon most certainly compresses (used to compress - for thepowershots) the live feed as there were heavy compression artifacts in the image. and both your and mweerden's explanation makes me realize that it is indeed true that camera with a USB 2.0 should not be a bottleneck.

i think i must download the source for libptp and study it !. thank you for pointing it reyalp!

Quote
The overlay is the bitmap and note that it does not contain the live image. I found the palette for my camera in the firmware by comparing it with where ewavr found it for other cameras, if I remember correctly. So you'll need two firmware disassemblies, one where you know where it is and the other of your own camera.
i dont think i totally understand mweerden - "does not contain the live image" part. what does it contain. i was under the impression that get_bitmap and bet_overlay were .....

ok so the overlay returns what ever is overlaied on the live image ? please be patient if i am being soooo stupid ... ( a stupid student always taxes the wise teacher  ;) )

so the get image gets the live feed and the overlay the matter overlaied on the image on the lcd ??
Logged
Pages: 1 ... 49 50 51 52 53 [54] 55 56 57 58 59 ... 125   Go Up
« previous next »
 

Related Topics