Comparison: CHDKPTP vs Canon's RemoteCapture - page 3 - RAW Shooting and Processing - CHDK Forum
« previous next »
Pages: 1 2 [3] 4 5 6 7 8 ... 13   Go Down

Comparison: CHDKPTP vs Canon's RemoteCapture

  • 129 Replies
  • 39921 Views
*

Offline SticK

  • *****
  • 779
Re: Comparison: CHDKPTP vs Canon's RemoteCapture
« Reply #20 on: 24 / August / 2012, 00:00:16 »
Advertisements
DUMPS

Viewfinder 1:1 unchecked (small view)
http://www.sendspace.com/file/7rfhkv

Viewfinder 1:1 checked (big view)
http://www.sendspace.com/file/uxkjjw
Logged
*

Offline reyalp

  • ******
  • 14080
Re: Comparison: CHDKPTP vs Canon's RemoteCapture
« Reply #21 on: 24 / August / 2012, 00:16:44 »
Quote from: SticK on 23 / August / 2012, 23:33:26
For example, I might be able to track down and identify the error detector signals and for those that I could not provide an electrical state=good impostor for, perhaps you might know where the table is in firmware and disable the error detection for a specific signal.  That could possibly mean changing value(s) in Canon EEPROM.   Is that something in your sphere?
It's unlikely to be a single table. This thread may be of interest http://chdk.setepontos.com/index.php?topic=6725.0

As a rule, we do not modify camera ROM. Even though it could be useful in some cases, most of us don't have cameras to sacrifice, and even if we did, the odds of end users bricking theirs and blaming us would be too high for any sort of general distribution.
Quote
DUMPS
As i've said before, the size/aspect buttons don't affect the dump.
Anyway, here's the relevant output from gui_verbose
Code: [Select]
vp.buffer_width:nil->720
vp.visible_width:nil->720
vp.visible_height:nil->240
so it's 240 rather than 216. The extra 24 rows probably aren't worth it, and may be interpolated by the canon firmware anyway.

edit:
I'm not sure why you are seeing more jaggies than in still mode...
« Last Edit: 24 / August / 2012, 00:18:55 by reyalp »
Logged
Don't forget what the H stands for.
*

Offline SticK

  • *****
  • 779
Re: Comparison: CHDKPTP vs Canon's RemoteCapture
« Reply #22 on: 24 / August / 2012, 09:24:03 »
Thank you for the reminders and patience.  I will post only dump per incident from now.

Quote "This thread may be of interest http://chdk.setepontos.com/index.php?topic=6725.0"

Interesting.  This fella from Argentina hit it right on the money.  You refer readers directly here.  At the top of his thread, his targets are labeled **.  The first link at the top goes to his site where he shows some electrical mods.  That's the right idea ...
http://chdk.setepontos.com/index.php?topic=3409.0

Quote "Even though it could be useful in some cases, most of us don't have cameras to sacrifice, and even if we did, the odds of end users bricking theirs and blaming us would be too high for any sort of general distribution."

For those users perhaps it would be worthwhile to remind them in no uncertain terms what "H" stands for.  Folks are human and might forget.  In my case, I could send you a sacrificial lamb, already in a partially dismantled state, but electrically functional.  For example, I already have two SX110s // one is a spare.  The camera model could change now that I know the reach of CHDKPTP, and especially the new fact to me, that the camera does not have to support RemoteCapture in order to obtain the live view CHDKPTP which was my preconceived illusion before we met.

Quote "The extra 24 rows probably aren't worth it, and may be interpolated by the canon firmware anyway."

Can you explain this a bit more?  I don't know how relevant this is to what you are saying, but one thing I am certain is the 360x270 liveview in VIDEO_STD is now "crisp" meaning that it can be used effectively to focus my instrument.  In still mode, for the SX110 it would be at very difficult to focus effectively.

By the way, I simulated a few lua commands, eg AUTO, shoot_half, VIDEO_STD.  The response of the camera is subjectively for now, "very good."  Can you direct me to sample code that would allow me to do tests like this?
    M
   set ISO
   set Tv (and Av)
   shoot_half
   shoot
   VIDEO_STD
How long can a command line be?  Can I invoke a code text file to run with CHDKPTP ?  .... things of this nature.
 
Thanks.
Logged
*

Offline reyalp

  • ******
  • 14080
Re: Comparison: CHDKPTP vs Canon's RemoteCapture
« Reply #23 on: 24 / August / 2012, 16:53:56 »
Quote from: SticK on 24 / August / 2012, 09:24:03
Quote "Even though it could be useful in some cases, most of us don't have cameras to sacrifice, and even if we did, the odds of end users bricking theirs and blaming us would be too high for any sort of general distribution."

For those users perhaps it would be worthwhile to remind them in no uncertain terms what "H" stands for.  Folks are human and might forget.  In my case, I could send you a sacrificial lamb, already in a partially dismantled state, but electrically functional.
The thing is, no matter how many disclaimers you put on it people will still use it, and they will still blame us if it ends badly. People blame us when their camera dies for things completely unrelated to CHDK. That might be tolerable on it's own, but if people start bricking cameras, it could attract unwanted negative attention from Canon.

To me, this makes development that involves re-writing camera ROM a dead end (though I'd still like to play with it a bit at some point.)  Picking up sacrificial cameras on amazon/ebay is not the issue, the real cost is development time.

If you want someone to devote many hours of highly technical effort to something that is only applicable to your project, you may find volunteers hard to come by.
Quote
Can you explain this a bit more?  I don't know how relevant this is to what you are saying, but one thing I am certain is the 360x270 liveview in VIDEO_STD is now "crisp" meaning that it can be used effectively to focus my instrument.  In still mode, for the SX110 it would be at very difficult to focus effectively.
Going to video mode on your camera appears to change the viewport to 720x240 rather than 720x216. I wouldn't expect a huge jump in quality from this, but I suppose the Canon pipeline maybe be doing something different that ends up giving you better detail.

I would suggest comparing the unscaled, full res output (aspect correct off, viewport 1:1 on) of each to figure out what the differences are.

IIRC you mentioned earlier that halfshoot also switched the viewport to 240 (? or was it the post shot review ?), so you could perhaps use that instead of video mode.

Quote
By the way, I simulated a few lua commands, eg AUTO, shoot_half, VIDEO_STD.  The response of the camera is subjectively for now, "very good."  Can you direct me to sample code that would allow me to do tests like this?
...
The Camera side Lua functions available though chdkptp are the same as used for on camera scripting. I suggest you consult the wiki for information about that. http://chdk.wikia.com/wiki/Script_commands is a good starting point. http://chdk.wikia.com/wiki/Lua/PTP_Scripting has some of the PTP specifics. http://chdk.wikia.com/wiki/Lua has information specific to Lua on CHDK (ubasic and lua share most of the same CHDK scripting functions, but ubasic is not available over PTP)
The official Lua manual http://www.lua.org/manual/5.1/ is also very useful.

You should be aware that the scripting system is a hack, like all the rest of CHDK. In many cases, the behavior has subtleties which vary from camera to camera, are not well documented, and and may not be well understood by anyone. When in doubt, the best source of definitive information is careful experiment. chdkptp is quite useful for this, since you can interactively try stuff and see the results.
Quote
How long can a command line be?  Can I invoke a code text file to run with CHDKPTP ?  .... things of this nature.
There is no specific limit on the length of a command.
There are several ways you can execute file:
1) Upload a file to the camera and then use something like lua loadfile('A/CHDK/SCRIPTS/testprgm.lua')()
2) Use PC side Lua scripting to load your file as a string and send it to the camera to run. The 'rlib' module in chdkptp is one example of this.
Using either of the above, you can also start a script on the camera which reads messages over PTP, so you can build your own custom protocol / command set. There are some examples of this in the chdkptp lua files.

The PC side of chdkptp is very scriptable. In fact, the entire GUI and CLI are written in Lua. You can find all this code in the lua directory, plus some additional examples (multicam.lua and the extras directory)
Logged
Don't forget what the H stands for.
*

Offline SticK

  • *****
  • 779
Re: Comparison: CHDKPTP vs Canon's RemoteCapture
« Reply #24 on: 24 / August / 2012, 18:12:40 »
Quote "If you want someone to devote many hours of highly technical effort to something that is only applicable to your project, you may find volunteers hard to come by."

Very true and I'd be silly to think that.  Please recall from an earlier post that I did say something to the effect that you have the final decision in reference to this subject line // naturally // you are in that special position // basically // it's your call.  I only jumped in because you raised the topic earlier than I would have, and, I would have asked you differently.  Please note I am still in the process of evaluating the technical possibilities for a CCD.   Had it been me to raise the question which I would done after escalating CCD selection to acceptable level, I would have asked it in the context of community you are addressing.  And, by example, that I am also dedicating time interacting with you, is because I am interested in your help, but also, I am fully aware my requests are not permitted to be in a vacuum.   Nevertheless we've opened the topic for discussion and I don't feel it's a bad thing .. because I already see huge potential with CHDK+++.  So since you have an overview of the community's needs and desires, that of course would have to square with the needs of my own project, and I fully understand it.  Were you able to read the thread I linked you to?  It is important that you do because the context I am referring to is the fundamental objectives of my project that I feel are likely parallel to those in amateur astronomy, like what Leonardo did in his thread: technically, primary focal plane architecture gives the ultimate optical performance of a CCD, whether it's a telescope or microimager.  What he did is what I did with my S50 a few years earlier back of him, but of course I used a different topology.  I did describe the process as "horrendous" when you asked, and you can get an appreciation of what I meant by looking at his site link at the top of the thread.  And since I detected yesterday that you suggested an interest in your community for direct CCD access, I felt that a firmware solution would be far more elegant than butchering the hardware and attempting to fool error-free access that way.  But you see, I don't how generic that could be made.  Those are indicators only you could come up with after thinking it all through.  The other thing is "bricking"  ... this is the first time I hear this word and I assume it imeans "reverse engineering with the objective of modifying copyrighted code."  Let's say I am on the right track, then, lest one not forget, if my technical objective fits the community, would overwriting by a RAM position that holds the lens error variables by CHDK code, in principle, fall or not fall under that preventive "jurisdiction" of catching Canon's attention etc.  I think perhaps not.  What is your opinion of all this?

Quote "Going to video mode on your camera appears to change the viewport to 720x240 rather than 720x216"

Yes, that is correct.

Quote "IIRC you mentioned earlier that halfshoot also switched the viewport to 240 (? or was it the post shot review ?), so you could perhaps use that instead of video mode."

Yes, I tried this now and it works too.  Is there a lua command that will permanently keep shoot_half down, and stay in that state after a shot is taken?  Could be esoteric anyway if I choose a camera with a higher definition live view.

Thanks for all the great tips .. I have homework to do.


Logged
*

Offline reyalp

  • ******
  • 14080
Re: Comparison: CHDKPTP vs Canon's RemoteCapture
« Reply #25 on: 24 / August / 2012, 22:23:55 »
Quote from: SticK on 24 / August / 2012, 18:12:40
Quote "If you want someone to devote many hours of highly technical effort to something that is only applicable to your project, you may find volunteers hard to come by."
Were you able to read the thread I linked you to?
I'm pretty sure I read it when it was first posted.
Quote
And since I detected yesterday that you suggested an interest in your community for direct CCD access, I felt that a firmware solution would be far more elegant than butchering the hardware and attempting to fool error-free access that way.
My comment about community interest was just that, a comment. A fair number of people see the possibilities of CHDK, and ask about operating without lenses. A full software only solution is likely to be very difficult if it's possible at all.
Quote
The other thing is "bricking"  ... this is the first time I hear this word and I assume it imeans "reverse engineering with the objective of modifying copyrighted code."
No, brick, meaning transforming the camera from a picture taking device into an inert object (similar to a brick, but with inferior structural properties), by damaging the on-board firmware in an unrecoverable way.
Quote
What is your opinion of all this?
My opinion is that if a bunch of people try to RMA cameras they bricked with CHDK, or otherwise consume Canon support resources, that might change Canons current hands-off attitude.
Quote
Yes, I tried this now and it works too.  Is there a lua command that will permanently keep shoot_half down, and stay in that state after a shot is taken?  Could be esoteric anyway if I choose a camera with a higher definition live view.
If you hold it down all the time, you can't really do the normal shooting sequence. Certain things must be updated outside of half shoot, others must happen inside.

CHDK scripting does have the capability to send key presses and releases, using the press and release functions. However, the current scripting code releases any keys that were pressed when the script terminates. Since each lua command over ptp runs a separate script, this means a simple lua press('shoot_half') will not do what you want. That's why I had you use press('shoot_half');sleep(1000) earlier, it waits 1 second before allowing the script to end. You can also use a long running message based script if you need more control, multicam.lua has an example of this. Another alternative is to send key presses an releases using the firmwares own http://chdk.wikia.com/wiki/LogicalEvent system.
« Last Edit: 24 / August / 2012, 22:26:38 by reyalp »
Logged
Don't forget what the H stands for.
*

Offline SticK

  • *****
  • 779
Re: Comparison: CHDKPTP vs Canon's RemoteCapture
« Reply #26 on: 25 / August / 2012, 00:39:16 »
Second photo down, ie, getting the impostors in is no big deal, it's figuring out where the signal lines are and what voltage/current levels to use.  That's what I meant by horrendous ...
http://www.astrosanjusto.net63.net/taller/a60focoprimario/index.htm
The more recent cameras have more gadgets there, so even more so.

Quote "A full software only solution is likely to be very difficult if it's possible at all."

I had expected what you said, but, could you give it some more thought?  I am taking a guess that Canon boot loader starts CHDK first, CHDK initializes itself, and then transfers control back to Canon finish its startup.  If I'm correct, you could have a window of opportunity.  Here is my train of thought ... Ideally from the user's perspective, one would disconnect the lens electromechanics (ie, unplug the assembly, usually a few tiny connectors), then on PUP, CHDK would be the first to detect the error condition, write the impostors into memory, and Canon would think the lens assembly is there.  Alternatively, CHDK when booting could read a script that has the table entries identified and the user puts the "hard-coded" error condition override values himself and proceeds at his own risk.  Even if there are dynamic issues during normal operation that could clear the error flags, so long as the user does not attempt to mobilize any actuators by accident (focus, IS, zoom, aperture, shutter etc) then the fooled state might hold.   Error table(s) and activity are probably similar across models.  What I'm saying is admittedly simplistic and unquestionably it is a difficult proposition, so honestly I am not expecting miracles.

QUESTIONS

Q1.  Now that I understand chdkptp better, what is the frame buffer resolution of the liveview on the S90 and S95, in still mode?  I am considering these as potentially good CCD candidates for my instrument that will be driven by your FW/SW.  The CCD format in those is more appealing than the SX110.  The S90 has simpler lens electromechanics than the G12 as well.

Q2.  Events (I think the events you talked about are related to operating the camera, something different). General overview if you could please .... I am not sure but it seems FW/SW is not event-driven, in the textbook sense.  For example, once the server completes a 16 second exposure in the camera and finishes writing the file(s) to SD, it fires off an event to the client so it knows the operation was completed and can proceed or vector to the next operation, without the need for the client to poll or count time.  How does it work at present?  Do you foresee something like this in future FW/SW?

Logged
*

Offline reyalp

  • ******
  • 14080
Re: Comparison: CHDKPTP vs Canon's RemoteCapture
« Reply #27 on: 25 / August / 2012, 02:25:23 »
Quote from: SticK on 25 / August / 2012, 00:39:16
I am taking a guess that Canon boot loader starts CHDK first, CHDK initializes itself, and then transfers control back to Canon finish its startup.  If I'm correct, you could have a window of opportunity.
The CHDK boot process is a little more complicated, but that's not the main problem. To do any of the stuff you suggest, a large amount of the firmware needs to be reverse engineered. You talk about error tables and writing resetting variables in memory, but first you have to actually find all that stuff.

Most of the firmware is unknown. As a typical example, the firmware code on my D10 amounts to >2.5 MB of ARM machine code. Analyzing a function of a few thousand bytes can take hours, if it's relatively self contained. So even for those of us who have devoted many many hours to reverse engineering, the vast majority is terra incognita.

Now it's *possible* that there is a relatively limited number of things you would have to correct, or that you could cleverly hook or disable error handling somewhere, but just finding out would be a substantial effort. If I had lots of free time, I'd be game to try, but at the moment I don't. Maybe someone else does.
Quote
Q1.  Now that I understand chdkptp better, what is the frame buffer resolution of the liveview on the S90 and S95, in still mode?
According to the CHDK code, it looks like the s90 and s95 should both have 480 line viewports.
Quote
For example, once the server completes a 16 second exposure in the camera and finishes writing the file(s) to SD, it fires off an event to the client so it knows the operation was completed and can proceed or vector to the next operation, without the need for the client to poll or count time.  How does it work at present?  Do you foresee something like this in future FW/SW?
I'm not really clear what level you are asking about.

If you are talking about the CHDK PTP protocol (including the chdkptp client) it operates by polling. We don't have control of USB events on the camera, nor any other way to initiate communication from the camera side. It might be possible to reverse engineer, but in practice polling isn't much of a handicap. The live view also operates by polling: It's just a timer that periodically asks for a frame.

The CLI is obviously more limited:
'lua' (or '.') starts a script on the camera without waiting for it to finish.
'luar' (or '=') starts a script, blocks until it ends, and then prints any return values.
If you start a script with 'lua', you can get it's return values with 'getm'. If your script runs in a loop an uses the message API, you can also interact with it while it's running using 'putm' and 'getm'.
If you need to do something more complicated, you can write lua code that runs on the client.

The camera firmware itself has a multitasking operating system. Older cameras use vxworks, which you can find plenty of information about online. Very little about DryOS is publicly documented, but it seems broadly comparable to vxworks.
Logged
Don't forget what the H stands for.
*

Offline SticK

  • *****
  • 779
Re: Comparison: CHDKPTP vs Canon's RemoteCapture
« Reply #28 on: 25 / August / 2012, 10:44:09 »
Quote "Analyzing a function of a few thousand bytes can take hours, if it's relatively self contained... terra incognita"

I have no doubt, and can only marvel at your dedication and what you've already accomplished, on top of your day job! ... which hopefully is something a little different from coding to keep your sanity.  Most of us are happy to write a few lines of assembler to speed up our C code, but how many folks are there on this planet that have the skills you have, and ARM to boot? ...  not many, I am sure.

Quote "It might be possible to reverse engineer, but in practice polling isn't much of a handicap. "

You answered my question.

lua and luar

While studying the docs I noticed this.  Thanks for volunteering the explanation.

QUESTIONS

Script execution speed.  In principle, let us say I write a 200 line script and want to operate strictly from the client (from the user-perspective fully flexible remote), for example, modifying a few parameters and then re-issuing the code on the fly.  How do you handle this?  Do you execute each small chunk of a function on the client with handshaking?  Do you transfer the entire file to camera RAM (or SD temp file) and transparently execute from there?  How best should I handle this?  Eg, will the operation execute faster if I write the file to SD and give CHDK the command to execute it, or is there really not much difference from sending the entire script file from CHDKPTP?   How do I transmit a multi-line script to the camera from CHDKPTP?  Is there another way outside of CHDKPTP to do it?

LUA

In your docs you have an example titled "Universal Tv Mode."  Very basically, how would I have to simplify the code for a remote scenario where I give it a Tv parameter in a function I wrote, from the client?  Where/how do I find/extract the translation table of Tv index versus shooting speed (property case name?), for example?    I suppose get_prop() and set_prop() are at the core, but I have had some difficulty finding a detailed explanation of the syntax.  The most important dynamic parameters for me at the moment to test performance are set ISO, set Tv and shoot. Could you please direct me, or give me example code I could start with?  How would this look like in lua that I can try with CHDKPTP?
C-style Pseudocode ...
    my_set_ISO(iso) // where iso could be integers 100, 200, 400 etc
       {
       // ?
       }
    my_set_Tv(Tv)  // where Tv could be strings "64", "32", "16" ... "1/128" etc
       {
       // ?
       }

HARDWARE

Please don't dig for an answer if you don't have it at hand.  Question is related to image file transfer speed on a USB 2.0 port.  For example, the S50 is very slow, ~10s for a big 4 MB JPG.  The S70 which Canon promotes as sporting USB 2, is only marginally faster.  The SX110 on the other hand is super fast ... a split second for a 6 MB JPG.  Would you have an idea how the S90, S95, perform?
Logged
*

Offline waterwingz

  • ******
  • 12138
    • Waterwingz
Re: Comparison: CHDKPTP vs Canon's RemoteCapture
« Reply #29 on: 25 / August / 2012, 11:25:13 »
Quote from: SticK on 23 / August / 2012, 18:42:46
My instrument has been working with the S50 CCD for many years, but the job was horrendous, especially too when there is need to cool the CCD.
Many years ago I worked on a CCD line scan camera where we put a Pellitier effect cell between the back of the sensor IC and a huge heat sink.  While this greatly lowered thermal noise,  controlling humidity to avoid condensation on the sensor window was a huge problem.

Any hints on how you plan to handle humidity ?
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
Pages: 1 2 [3] 4 5 6 7 8 ... 13   Go Up
« previous next »
 

Related Topics