CHDK Forum
CHDK Development => General Discussion and Assistance => Topic started by: reyalp on 27 / March / 2011, 20:47:24
-
Edit 2017-03-5:
There's a lot of old discussion in this thread, see https://app.assembla.com/spaces/chdkptp/wiki/Home for chdkptp documentation and builds
---
I've started an assembla space for my alternative PTP client. https://www.assembla.com/code/chdkptp/subversion/nodes (https://www.assembla.com/code/chdkptp/subversion/nodes)
I've put this in it's own space because it's not really part of CHDK. Any chdk or chdkde developers interested in working on this, please add yourself as a watcher and let me know. I'm happy to give anyone who wants to work on it commit access. If you want to do major reorganization/rewriting, either discuss it first here or make a branch.
This is in a very early stage still, so it isn't a replacement for ptpcamgui. It is functional enough replace ptpcam cli (and is much more convenient for a lot of things)
Overview can be found in https://www.assembla.com/code/chdkptp/subversion/nodes/trunk/README (https://www.assembla.com/code/chdkptp/subversion/nodes/trunk/README)
Usage information can be found in https://www.assembla.com/code/chdkptp/subversion/nodes/trunk/USAGE.TXT (https://www.assembla.com/code/chdkptp/subversion/nodes/trunk/USAGE.TXT)
Documentation is minimal, I suggest looking at cli.lua and chdkptp.c
The low level USB/PTP part is based on the ptpcam code, but I'm cutting out the stuff that isn't related to CHDK. The entire CLI and GUI are written in lua. A lua API is provided for CHDK PTP functions. The current GUI is mostly just proof of concept.
Goals
- GUI. Eventually should have camera control, live view like chdkcam, file browsing/transfer etc. GUI is based on IUP http://www.tecgraf.puc-rio.br/iup/ (http://www.tecgraf.puc-rio.br/iup/)
- Cross platform. I haven't built on linux yet, but all the parts are very portable.
- Flexible, extensible. Users can easily interact with the PC side lua, extend the lua code, script interaction between pc lua and camera lua, or replace it with their own custom code.
A windows build of the current version is available from the files section: https://www.assembla.com/spaces/chdkptp/documents (https://www.assembla.com/spaces/chdkptp/documents)
-
That's a very nice new project.(https://chdk.setepontos.com/proxy.php?request=http%3A%2F%2Fwww.smiles.kolobok.us%2Ficq%2Fgood.gif&hash=a06e392cac20e6d2d108bf12007f50fa)
I tested all basic functions with the current CHDK-DE version. The connection is very fast. Everything works as expected.
I think for the general users is the GUI the most important part. The interface should include the following functions:
- upload CHDK related files (maybe with download from autobuild servers)
- download all media files
- camera control, remote functions
- some usefull elementary applications (time lapse, bracketing ...)
- a multiline script console (for script testing)
- optional other gui languages (maybe dependent from camera language)
- live view (difficult to realize for all the cameras)
For more feedback should be the ptp interface enabled for all cameras in trunk like in CHDK-DE.
msl
-
Great :)
I gave it a quick try on Ubuntu. Some changes were needed to Makefile and libptp-endian.h for it to build (using libusb-1.0-0-dev libusb-1.0-0 liblua5.1-0-dev liblua5.1-0), diff attached. I couldn't get the gui part to work in a minute, but the interactive cli seems to connect and up/download properly. My Makefile modifications are especially quick and dirty, but here's a diff anyway in case someone finds it useful...
-
hi fudgey,
unfortunately I'm only an ubuntu user - no experience with compilation of code.
Could you pls help me with step by step instructions.
I'd like to capture pics from my A430 on the PC.
The A430 works fine with ptpcam.exe on windows but I would prefer to run a script on linux. gphoto2 was also working fine with my cam, but here is no support for capturing.
thx
Gerhard
-
MSL, thanks for the feedback. All good suggestions.
I've started adding the stuff to the planner http://www.assembla.com/spaces/chdkptp/tickets/agile_planner?id=chdkptp (http://www.assembla.com/spaces/chdkptp/tickets/agile_planner?id=chdkptp)
This is just a way to collect/organize all the things that are wanted or needed, don't take the milestones seriously.
I've also added most the developers I recognize from the watcher list as editors. You are welcome to hack the code or add / change stuff in the tickets and planner.
I realize it's a bit of a mess now, and probably not clear where things are going. Hopefully I'll get it to a state where it's a bit more useful and well organized so others will be motivated to hack on it. :)
Fudgey:
Good to know. I'll try to get basic linux support in the makefile, and see if I can get IUP working.
-
hi fudgey,
unfortunately I'm only an ubuntu user - no experience with compilation of code.
Could you pls help me with step by step instructions.
I've updated the Makefiles to work a bit better for cross platform builds, and update the readme to describe how to set it up. Rough instructions
Install the required packages. At a minimum, you will need
* subversion
* gcc
* libusb-1.0
* libusb-dev (may be called something like libusb-1.0-dev)
* liblua-5.1
* liblua-5.1-dev
check out the source using subversion:
$ svn co http://subversion.assembla.com/svn/chdkptp/trunk (http://subversion.assembla.com/svn/chdkptp/trunk) chdkptp
copy config-sample-linux.mk to config.mk
build it with
$ make
If it works, you will end up with a file called chdkptp
When you run it, you probably need to adjust LUA_PATH so it will pick up the .lua files.
Assuming you are starting in the source directory, Something like this should work:
$ LUA_PATH="./lua/?.lua" ./chdkptp -i
If you are using ubuntu 64 bit (or possibly other 64 bit distros), you may also try the binary I built, which can be found in http://www.assembla.com/spaces/chdkptp/documents (http://www.assembla.com/spaces/chdkptp/documents)
You will still need to install the library packages (libusb-1.0, liblua5.1). You shouldn't need the -dev variants.
-
I've managed to build it with IUP support on linux, instructions added to readme.
-
I'd dearly love to get this working under OSX on a Mac, but I think may not be possible because the OSX version of libusb has problems claiming a usb device (because OSX gets exclusive control as soon as you plug a USB device in). This is certainly true for some devices (e.g. mass storage devices like disks and cards, as well as HID's) does anyone know if it's untrue for cameras?
-
I'd dearly love to get this working under OSX on a Mac, but I think may not be possible because the OSX version of libusb has problems claiming a usb device (because OSX gets exclusive control as soon as you plug a USB device in). This is certainly true for some devices (e.g. mass storage devices like disks and cards, as well as HID's) does anyone know if it's untrue for cameras?
The libusb page says
Darwin (Mac OS X) implementation has one limitation. If the OS has an interface driver that matches the characteristics of a device, it will seize the interface and the kernel driver cannot easily be detached. So libusb will not be able to use that interface. This is a particular problem with generic HID devices. For HID device, HIDAPI is recommended.
No idea if this applies to PTP devices. If so, maybe a higher level API you can use for PTP commands ? In the long term, I hope to make things modular enough that you could change the underlying communication layer to something other than libusb. You'd expect that there should be some mechanism for camera vendors to support their PTP extensions in their own apps. It looks like there are remote capture apps for Mac (e.g. for Canon cameras that can do remote capture using the Canon SDK), so you might look into how those work.
IUP also does not have native support for OSX. I don't know if it runs under X11. Native OSX support is on their TODO list.
-
Thanks for that Reyalp. I've already read that page about Darwin (after I'd spent several hours trying (and failing) to get a simple libusb program to turn off the bright white led on my Seagate FreeAgent external drive!).
I've also used the OSX IOKit framework to write a simple app to transfer photos. That worked, but it requires extensive delving into the Objective-C libraries to do anything like PTP and so far I've resisted making the effort to get to grips with that. I guess I'll either have to bite the bullet or live with Windows.
-
Some progress:
- The gui now has a very alpha file browser. You can
* browse files. directories with very large numbers of files might cause the camera to run out of memory, we really need an alternative to os.listdir that lets you iterate over a directory instead of dumping the whole thing into a table.
* download selected file. Multiple selection and whole directory downloads aren't implemented yet
* upload files to a selected directory. Multiple section is supported, directories/recursive uploads are not
* delete files (but not directories)
* crash the camera, crash the client, and maybe trash your files :haha
- ls command in CLI
- and a bunch of useful supporting code: listdir shows how the ptp message stuff is intended to be used, serialize/unserialize makes passing values between lua and pc super easy.
(https://lh3.googleusercontent.com/_UDetsZvPfqQ/TaubnRN2JpI/AAAAAAAAA30/Di5ZgJj5PcU/s640/chdkptp-gui-filebrowser-1.jpg) (http://picasaweb.google.com/lh/photo/eZ3XJcvybp-SH_Z1Vt1mGA?feat=embedwebsite)
edit:
binaries are here http://www.assembla.com/spaces/chdkptp/documents (http://www.assembla.com/spaces/chdkptp/documents)
Actually, the C code has not changed since the last build I posted. All of the above was done entirely in lua. I did update the win32 version to use IUP 3.4
-
This is a very sophisticated work - respect.
My first test was successful. With installed Lua for Windows it's easy to start the GUI. The camera functions are working properly. The file browser represents a new quality of ptp communication. The connection between computer and camera is fast and stable.
msl
-
My first test was successful. With installed Lua for Windows it's easy to start the GUI.
Not sure if I'm understand, if you mean http://code.google.com/p/luaforwindows/ (http://code.google.com/p/luaforwindows/) it's not needed.
The windows binary I posted is completely standalone, IUP and lua are statically linked into chdkptp.exe. Assuming you have libusb, you can just unzip and run. The linux binary is dynamically linked, so you would need IUP and lua .so files
If you want to compile, then you need IUP and lua libraries to link to.
Still lots to do, my goal is to make it useful enough that other people want to work on it ;)
-
Not sure if I'm understand, if you mean http://code.google.com/p/luaforwindows/ (http://code.google.com/p/luaforwindows/) it's not needed.
Yes, this was my mistake. I've tested some iup sample scripts with Lua for Windows. The client works without this installation.
msl
-
With protocol version 2, we now have a pretty much transparent remote procedure call from lua. chdku.exec with the appropriate options returns a status, plus the camera functions return values, e.g.
con 1> !return chdku.exec("return get_mode()",{wait=true,libs={"serialize","seri
alize_msgs"}})
=true,false,false,513
con 2> !return chdku.exec("return os.listdir('A/DCIM')",{wait=true,libs={"serialize","serialize_msgs"}})
=true,{
[1]="100CANON",
[2]="CANONMSC",
}
con 3> !return chdku.exec("return os.listdir('A/doesnotexist')",{wait=true,libs={"serialize","serialize_msgs"}})
=true,nil,"A/doesnotexist: error",0
:D
edit to add:
practical application
./chdkptp -c -i
con 9> !t=chdku.listdir('A/DCIM/100CANON',{match=".JPG$"})
con 10> !for i,n in ipairs(t) do chdk.download("A/DCIM/100CANON/"..n,"img/"..n) end
-
Will Revision 36 work with A570?
If so is there any docs? Especially what is working and what is Not.
Checked http://www.assembla.com/spaces/chdkptp/documents (http://www.assembla.com/spaces/chdkptp/documents) but was unable to get details.
Also status of project and next release?
Thanks
Ken
-
Will Revision 36 work with A570?
Should work in with any recent CHDK or CHDKDE build. If ptpcam/ptpcamgui work, then this will too. If you use it, I suggest using the latest .lua files from SVN http://trac.assembla.com/chdkptp/browser/trunk/lua (http://trac.assembla.com/chdkptp/browser/trunk/lua)
The executable hasn't changed, so you can just replace the .lua files.
If so is there any docs? Especially what is working and what is Not.
Checked http://www.assembla.com/spaces/chdkptp/documents (http://www.assembla.com/spaces/chdkptp/documents) but was unable to get details.
Not much yet. You can see http://trac.assembla.com/chdkptp/browser/trunk/USAGE.TXT (http://trac.assembla.com/chdkptp/browser/trunk/USAGE.TXT) and comments in the source code. All the CLI commands should work, as should all the chdk.* API functions. The GUI is not really useful yet. The main advantage over ptpcam right now is the ability to easily script interactions with the the camera (look at chdku.downloaddir and chdk.deletefiles for example)
Also status of project and next release?
Not really. You can see some of the things I plan to do in http://www.assembla.com/spaces/chdkptp/tickets (http://www.assembla.com/spaces/chdkptp/tickets)
The "milestones" are just to organize order and priority, just because something appears in "alpha 1" doesn't mean there will be an "alpha 1" release with those things in it. There is no schedule, my time to work on personal projects is limited and unpredictable right now.
-
Hi reyalp,
Thanks for your detailed explanations.
Checked all the links and the only way I can help at present is to test if works on my A570.
I had not seen mention of CHDKDE so did some searching and found
http://chdk.setepontos.com/index.php?topic=5456.0 (http://chdk.setepontos.com/index.php?topic=5456.0)
Since you are the chief developer of chdkptp is there any advantage of using CHDKDE instead of the standard CHDK?
Also is it possible to be notified when the GUI becomes usable?
Thanks
Ken
-
Hi reyalp,
Question: every time I turn off my A570 the Drive mode changes back to single from continuous.
Is there any way CHDK, CHDKDE or CHDKPTP can change the default drive mode from single to continuous?
Seems many other Canon P&S have this same problem
http://www.digitalcamerainfo.com/content/Canon-PowerShot-A720-IS-Digital-Camera-Review-15944/Modes.htm (http://www.digitalcamerainfo.com/content/Canon-PowerShot-A720-IS-Digital-Camera-Review-15944/Modes.htm)
Thanks
Ken
-
Since you are the chief developer of chdkptp is there any advantage of using CHDKDE instead of the standard CHDK?
Some additional functions are available in chdkde lua. If you need them, then it's an advantage. This isn't specific to use with PTP clients like chdkptp.
Also is it possible to be notified when the GUI becomes usable?
I will certainly post here.
Question: every time I turn off my A570 the Drive mode changes back to single from continuous.
Is there any way CHDK, CHDKDE or CHDKPTP can change the default drive mode from single to continuous?
Not conveniently as far as I know.
You can script button presses, so you could switch it to continuous mode by pressing func set etc. You can have a script run at startup, but this means you can't have another script selected. Also, it would only work in record mode, and might have trouble if the canon firmware remembers the position in the menu.
At some point it would be nice to make some "autoexec" scripts that run on certain events, like startup or switching between rec and play.
This is all off-topic for chdkptp, since it isn't specific to USB. I'm sure this problem with continuous mode has been discussed many times on the forum.
-
Using windows pre-built R57 version of chdkptp.exe (from https://www.assembla.com/spaces/chdkptp/documents (https://www.assembla.com/spaces/chdkptp/documents)) with the latest lua files (R58) gives the following error when I try and connect to my G12.
C:\CHDK\chdkptp>chdkptp.exe -i -c
pcall failed 2
error C:\CHDK\chdkptp\lua\chdku.lua:799: attempt to index local 'con' (a boolean value)
Using the R57 lua files doesn't have this problem.
Phil.
-
Yes, you'll need to build a binary if you use the latest lua files. I've started some major reorganization which is not complete.
I'd suggest sticking with r57 for the moment. The svn head should generally work, but I'm not making any promises.
-
reyalp,
Thanks for your answer in my post!
i am really interested in this proyect! because i want to implement a live view in the pc and a remote shot from the pc too.
I have some questions, so i would be very greatful if you could help me answering them:
I try to excecute the chdkptp.exe and it didnt work cause i dont have the libusb0.dll, so... where i can get it?
it is posible with this ptp client to do what i need (live view a remote shot form pc)???
which camera (not really expensive, max 500 dollars) would be the best option???
Thanks you in advance for your help, and sorry for all the questions, i am noob and want to learn and develop with this tools...
-
i am really interested in this proyect! because i want to implement a live view in the pc and a remote shot from the pc too.
Please understand that the chdkptp client is in an early stage of development, and the entire CHDK PTP project is quite experimental. If you want something that just works out of the box, this is probably not the solution for you.
I try to excecute the chdkptp.exe and it didnt work cause i dont have the libusb0.dll, so... where i can get it?
You need to install and configure the libusb-win32 driver. This is discussed somewhere in the ptp development thread: http://chdk.setepontos.com/index.php/topic,4338.0.html (http://chdk.setepontos.com/index.php/topic,4338.0.html)
Someone should really clean the instructions for this and put them in http://chdk.wikia.com/wiki/PTP_Extension (http://chdk.wikia.com/wiki/PTP_Extension)
it is posible with this ptp client to do what i need (live view a remote shot form pc)???
Live view over USB is currently not supported in CHDK.We plan to add this eventually, but there is no schedule.
which camera (not really expensive, max 500 dollars) would be the best option???
I have no opinion on this.
-
wow !! thank you very much !!
i tried this with a SX120 CHDK DE version and every thing seems to work ok. although i have not used it thoroughly it seems very quick - quicker than ptpcamgui at least - anyways thank you once again
the most important thing on my wish list now becomes a live preview 'mweerden' reports that
'At GitHub you can now find my patch for remote live preview as well as a CHDK PTP .NET library (+test app)....'
although ive not tried it im hoping it works
-
Hi,
I am trying to use chdkptp to control an sx130is and am not having much luck. I built the latest version from the svn repository on ubuntu lucid and can connect to the camera. Whenever I try to set the shooting mode or call shoot(), I get unexpected return code error. Sometimes the camera also needs to be rebooted. For example:
con 7> =return require("capmode").get_name()
8:return:'PLAY'
con 8> =return require("capmode").valid("M")
9:return:true
con 9> =return require("capmode").set("M")
unexpected return code 0x2ff
unexpected return code 0x2ff
ERROR: failed
Incidentally, I am able to control this camera using the latest chdk-shell/ptpcamgui application on WinXP. Thanks for your assistance!
-drew
-
con 7> =return require("capmode").get_name()
8:return:'PLAY'
con 8> =return require("capmode").valid("M")
9:return:true
con 9> =return require("capmode").set("M")
Before you can change shooting modes, you must first switch to record mode, using switch_mode_usb(1)
-
[/quote]
Before you can change shooting modes, you must first switch to record mode, using switch_mode_usb(1)
[/quote]
Trying to execute 'luar return switch_mode_usb(1)' also produces the unexpected return code 0x2ff error and causes the camera to disconnect. This probably isn't the forum for it, but are there any examples of lua scripts that work on the sx130?
-drew
-
Trying to execute 'luar return switch_mode_usb(1)' also produces the unexpected return code 0x2ff error and causes the camera to disconnect. This probably isn't the forum for it, but are there any examples of lua scripts that work on the sx130?
That's odd. What CHDK build are you using ?
In any case, if ptpcamgui works with this camera, it suggests the problem isn't entirely due to the port.
AFAIK John1234 in this thread http://chdk.setepontos.com/index.php?topic=6355.0 (http://chdk.setepontos.com/index.php?topic=6355.0) was using s130. He had some problems, but definitely had mode switching and shooting working.
I just tried the current version of chdkptp from on my linux system and didn't have any issues with mode switching my d10
When you say the camera disconnects, does it shut down, or simply stop talking to the client ? the 0x2ff error is just a generic error you get from libusb when it isn't able to talk to the camera, it doesn't really say anything about the cause.
-
That's odd. What CHDK build are you using ?
In any case, if ptpcamgui works with this camera, it suggests the problem isn't entirely due to the port.
AFAIK John1234 in this thread http://chdk.setepontos.com/index.php?topic=6355.0 (http://chdk.setepontos.com/index.php?topic=6355.0) was using s130. He had some problems, but definitely had mode switching and shooting working.
I just tried the current version of chdkptp from on my linux system and didn't have any issues with mode switching my d10
When you say the camera disconnects, does it shut down, or simply stop talking to the client ? the 0x2ff error is just a generic error you get from libusb when it isn't able to talk to the camera, it doesn't really say anything about the cause.
Currently using 101f-1.1.0-734 built on August 6, 2011. After the 0x2ff error, the camera stops communicating and needs to be turned off and back on. I finally got things to work, however. It seems the camera is sensitive to when you plug it into the usb port. If we plug in before chdk is loaded, bad things happen ;) Thanks for your help.
-drew
-
I finally got things to work, however. It seems the camera is sensitive to when you plug it into the usb port. If we plug in before chdk is loaded, bad things happen ;) Thanks for your help.
Glad you got it working. That sounds like a bug, or at least something that could potentially be improved.
Does it have the problem if you power on the camera with the cable plugged in ? That's usually what I do, and I haven't noticed the kind of problem you describe.
-
Hmm...now I am not so sure what the cause of the problem was. It seems to work regardless of whether I power it on plugged in or wait to plug it in. I'll keep fiddling with it.
-drew
-
hello dj,
i have been using ptp with the SX 130 and have never found any problems i have currently around 25 pcs and none have given the problem.
however if your camera is sensitive and hangs if you rapidly zoom in zoom out and capure from the ptp interface, turn off the continous auto focus. i have noticed that turning off the continous autofocus solves most of the hanging problems during a ptp session not only in the SX 130 but even in the 5 pieces of SX 120 that i used.
-
From the ELF thread:
..
) | chdkptp -c -i
..
Should that be :
..
) | chdkptp -c -e
..
No, the -i is correct. Even though it's taking input from a pipe, it's taking a sequence of "interactive" commands. -e executes a single command, so you could generate a -e"u ..." for each file.
In any case, there might be a problem with bombarding the ptp interface with repeated transfers ?
I found that there are problems if you invoke chdkptp multiple times in succession, it can fail to connect. Sending multiple commands to the input of one session should be fine.
My previous script worked like this:
#!/bin/bash
chdkptp -ec -e"u bin/DISKBOOT.BIN"
sleep 1
pushd core/modules
for f in *.flt ; do
chdkptp -ec -e"u $f CHDK/modules/"
sleep 1
done
popd
the sleep 1 was enough on my system, but YMMV
-
..
) | chdkptp -c -i
..
changed it to
..
) | ./chdkptp -c -i
..
so that it would find chdkptp in the current directory. Once I did that it ran fine in the CHDK-Shell bash command shell environment.
I found that there are problems if you invoke chdkptp multiple times in succession, it can fail to connect.
That's what I found too - 3 to 5 invocations in a row is about all it will do. Putting a short or long sleep between calls did not help.
-
Awesome reyalp! Can we expect a Mac port? Can I be of some assistance? I'd love to get ptp working with onlocation cs5 for Mac. Let me know if there is anything I can do. I'll be watching this and may start tinkering but two heads (or more) are always better than one!
-
I've posted a new binary snapshot. An overview of the changes, along with links to binaries can be found at
http://www.assembla.com/spaces/chdkptp/wiki/Changelog (http://www.assembla.com/spaces/chdkptp/wiki/Changelog)
The main user-visible changes are
* Multiple file uploads / downloads, in both gui and CLI.
* Multiple camera support. Select which camera to control, and from the script api, control multiple cameras simultaneously.
* Improved performance functions that execute code on the camera.
The multi-file command options are somewhat clunky at the moment. They probably won't behave exactly what you'd expect if you are used to windows or linux command lines.
The build upload shell scripts discussed earlier can be replaced by
chdkptp -c -e"mup bin/DISKBOOT.BIN A/" -e"mup core/modules -fmatch=%.flt$ CHDK/MODULES"
There have been extensive changes under the hood, if you used local lua scripts (! command, or your own .lua files running locally) they will probably not be compatible.
@051r15
Missed your post the first time around. I don't have a Mac, so I don't have any particular plan to make a Mac port, but if someone else did the code I'd be happy to include it. I plan to convert to autoconf eventually, which should make it easier to build on any vaguely unix-like system.
I've heard differing reports about using libusb for PTP on Mac, but apparently some people have got it to work. At present, the IUP GUI library does not natively support Mac, but is reported to work X. chdkptp can also be built without the GUI.
-
New snapshot, changes in http://www.assembla.com/spaces/chdkptp/wiki/Changelog (http://www.assembla.com/spaces/chdkptp/wiki/Changelog)
This includes a very experimental module for controlling multiple cameras simultaneously. This is not exposed in the cli or gui, but you can use it with ! commands.
To test the level synchronization, I made a function (mc:testshots() that schedules a shots 300ms in the future, and then prints the time difference from the scheduled shooting time every 20ms. Aiming the cameras at the output gives you an idea how close together they shot.
There's a lot of room for error here: monitor/display refresh latency, latency between printing in a cmd window and having it show up etc. All that said, I think the results are not too bad. Over 4 shots, the time values shown varied by 40ms at most. This is no substitute for the usb remote sync, but good enough for if you want pictures at approximately the same time.
I'm not sure how it will scale to lost of cameras, but the sync accuracy shouldn't change. The time required to prepare shoot will increase.
Interestingly the d10 (on the right) had a lot more trouble shooting at the screen, and was also generally later than the a540.
-
Over 4 shots, the time values shown varied by 40ms at most.
For tethered indoor work that is OK.
For outdoor work and action we typically need a fraction of a ms.
For general outdoor work with moving people, vehicles,water,foliage, etc just a few ms.
There are reasons to believe cameras newer than the S95 have very poor synch, for unknown reasons.
Incidentally, my A620 does not return a serial number.
When you broadcast a message to multiple cameras, how do you handle their replies ?
reboot and reconnect fail with an error if they connect to a different camera, as detected by model name, product id and serial number (if available)
So, it is not possible to connect to my two A620's (and maybe other cameras) as they do not return a serial number ?
-
For outdoor work and action we typically need a fraction of a ms.
That would be very difficult if not impossible to do with PTP
For general outdoor work with moving people, vehicles,water,foliage, etc just a few ms.
Anything less than 10ms would be very difficult, since there is not (AFAIK) a clock with greater resolution available on the camera. Even 10ms would be very hard, since the clocks on each camera wouldn't be synchronized.
Out of curiosity, how do you measure the accuracy of sync ?
One thing that could help is a script controllable delay where the wait_for_remote code is called.
Incidentally, my A620 does not return a serial number.
Yes, it appears older cameras don't return it. D10 does, A540 does not. If you were using a lot of cameras without, it would probably be useful to store a unique camera ID on the SD card or something...
When you broadcast a message to multiple cameras, how do you handle their replies ?
Loop over all the cameras checking for messages. This doesn't need to happen right away. (mc:wait_status_msg, which is called if you use mc:cmdwait)
So when you do a mc:cmdwait('preshoot') it sends the pre-shoot command to all the cameras, then waits for each one to send a message that indicating that get_shooting is true (or something failed)
So, it is not possible to connect to my two A620's (and maybe other cameras) as they do not return a serial number ?
No, it just won't notice if it connects to a different camera when you use reconnect or reboot. The issue is that the usb dev/bus can change when the camera is (it's not tied to the physical USB port). So if you reboot and try to reconnect, you might end up connected to a different camera.
the mc lib doesn't really care about uniquely identifying the cameras, it just connects to them all and identifies them by the order in which they were connected.
-
Out of curiosity, how do you measure the accuracy of sync ?
http://stereo.jpn.org/eng/sdm/crt_synch.htm (http://stereo.jpn.org/eng/sdm/crt_synch.htm)
A friend tested the S95 a few days ago :-
http://bit.ly/wnK2Ff (http://bit.ly/wnK2Ff)
a good result except 25% of the time other tasks interrupt the capture sequence, I assume.
He has asked if we can disable interrupts until after capture.
The S95 may be the last camera we can achieve decent synch with.
The SX230HS has an error of about 50msec (!) and philmoz confirms the IXUS310 and SX40 are similar.
Something new is happening in the capture sequence, unless porters have 'wandered down the wrong path'.
-
Out of curiosity, how do you measure the accuracy of sync ?
http://stereo.jpn.org/eng/sdm/crt_synch.htm (http://stereo.jpn.org/eng/sdm/crt_synch.htm)
A friend tested the S95 a few days ago :-
http://bit.ly/wnK2Ff (http://bit.ly/wnK2Ff)
a good result except 25% of the time other tasks interrupt the capture sequence, I assume.
He has asked if we can disable interrupts until after capture.
The S95 may be the last camera we can achieve decent synch with.
The SX230HS has an error of about 50msec (!) and philmoz confirms the IXUS310 and SX40 are similar.
Something new is happening in the capture sequence, unless porters have 'wandered down the wrong path'.
Although we've diverged a bit from the main topic here I just wanted to add my experience in case it is useful to anyone else.
I've been testing slightly differently with a single camera.
I record the current tick count at the end of 'wait_until_remote_button_is_released' and then again at the very start of 'capt_seq_hook_raw_here' and display the difference.
Using a 1/1000th sec shutter speed and enabling remote synch I would expect to see fairly consistent results in the value displayed.
On the G12 and SX30 this is the case - the value is consistent most of the time with an occasional difference of 1 (preumably when the shot happens just as the clock is ticking over).
On the IXUS310 and SX40 the variance in the value can be up to 50, since the tick count is milliseconds, this is equivalent to a 1/20th second variation from the time the usb remote is released to the time the picture is taken.
I'm experimenting with different locations for the functions; but so far I've only managed to reduce the variance to 40ms on the SX40.
Phil.
-
Some progress
(https://lh3.googleusercontent.com/-Y1ftF08oa0I/TzoECK8YNxI/AAAAAAAAA9U/PR8jCrFiOFM/s800/IMG_1028.JPG)
-
Please pardon the newbie question, but exactly how does one download the files at http://trac.assembla.com/chdkde/browser/trunk/tools/ptpcam/ (http://trac.assembla.com/chdkde/browser/trunk/tools/ptpcam/)
Or from https://github.com/jrabbit/libptp-chdk.git (https://github.com/jrabbit/libptp-chdk.git)
I want to download to a dockstar (a headless Arm device), so can I use something like "wget" or "svn"?
I've read through many threads, on this and, on the German forum using Google Translate, but haven't found an answer.
So if someone could tell me how to download the files, and compile the project, I would appreciate it.
I've also downloaded, with svn, chdkptp to my /usr/src directory. How do I now do a cli compile of the project (I've installed the following: build-essential subversion libusb-dev lua5.1 liblua5.1 liblua5.1-dev).
-
Please pardon the newbie question, but exactly how does one download the files at http://trac.assembla.com/chdkde/browser/trunk/tools/ptpcam/ (http://trac.assembla.com/chdkde/browser/trunk/tools/ptpcam/)
svn co http://subversion.assembla.com/svn/chdkde/trunk/tools/ptpcam/ (http://subversion.assembla.com/svn/chdkde/trunk/tools/ptpcam/)
(you can find the svn url from http://www.assembla.com/spaces/chdkde/trac_subversion_tool (http://www.assembla.com/spaces/chdkde/trac_subversion_tool) )
Or from https://github.com/jrabbit/libptp-chdk.git (https://github.com/jrabbit/libptp-chdk.git)
git clone ....
or down load the zip linked on that page. You can probably copy the url in your desktop browser and then wget it on your headless box (assuming you have a putty or something you can paste into)
I've also downloaded, with svn, chdkptp to my /usr/src directory. How do I now do a cli compile of the project (I've installed the following: build-essential subversion libusb-dev lua5.1 liblua5.1 liblua5.1-dev).
copy config-sample-linux.mk to config.mk, edit to suit your configuration.
CHDK_SRC_DIR must point to a directory such that -I$(CHDK_SRC_DIR) will allow the source to include <core/ptp.h>. You can get a copy of ptp.h from http://trac.assembla.com/chdk/browser/branches/release-1_0/core/ptp.h?format=txt (http://trac.assembla.com/chdk/browser/branches/release-1_0/core/ptp.h?format=txt)
then type make
Beware that both chdkptp and the ptpcam in chdkde were originally made from a butchered copy of ptpcam with the autoconf stuff removed, so they might not work for you if your platform isn't close to what they were configured for. Moving chdkptp back to autoconf is on my TODO list.
-
Thank you very much. This could hardly have been easier for ptpcam. I downloaded from github into /usr/src/ptpcam:
git clone https://github.com/jrabbit/libptp-chdk.git
I had already downloaded into /usr/src/chdkptp with svn from /usr/src:
svn co http://subversion.assembla.com/svn/chdkptp/trunk chdkptp
I copied ptp.h into both /usr/src/ptpcam and /usr/src/chdkptp with:
wget http://trac.assembla.com/chdk/browser/branches/release-1_0/core/ptp.h?format=txt
I copied /usr/src/chdkptp/config-sample-linux.mk to config.mk in /usr/src/ptpcam
In /usr/src/ptpcam, I ran "make". This resulted in a ptpcam executable.
I copied it to /usr/bin, plugged in and turned on the camera (an A590is), and did the following:
mode 1
lua set_zoom(3)
lua shoot()
mode 0
download A/DCIM/133CANON/IMG_7429.JPG IMG_7429.JPG
This worked. Now I can use my dockstar to take photos remotely. Congratulations and thanks to everyone involved.
I have not been successful yet with chdkptp, but I think I'm close. I copied ptp.h into /usr/src/chdkptp/core and ran make. This is the output. Something simple is missing, I think, maybe a ".h" file, but I don't know what it is.
make[1]: Entering directory `/usr/src/chdkptp/lfs'
make[1]: Leaving directory `/usr/src/chdkptp/lfs'
gcc -MMD -DCHDKPTP_OSTYPE=\"Linux\" -g -I/usr/include/lua5.1 -I/usr/src/chdkptp -c -o ptp.o ptp.c
ptp.c: In function 'ptp_chdk_get_memory':
ptp.c:1650: error: 'PTP_OC_CHDK' undeclared (first use in this function)
ptp.c:1650: error: (Each undeclared identifier is reported only once
ptp.c:1650: error: for each function it appears in.)
ptp.c:1652: error: 'PTP_CHDK_GetMemory' undeclared (first use in this function)
ptp.c: In function 'ptp_chdk_set_memory_long':
ptp.c:1672: error: 'PTP_OC_CHDK' undeclared (first use in this function)
ptp.c:1674: error: 'PTP_CHDK_SetMemory' undeclared (first use in this function)
ptp.c: In function 'ptp_chdk_call':
ptp.c:1692: error: 'PTP_OC_CHDK' undeclared (first use in this function)
ptp.c:1694: error: 'PTP_CHDK_CallFunction' undeclared (first use in this function)
ptp.c: In function 'ptp_chdk_upload':
ptp.c:1717: error: 'PTP_OC_CHDK' undeclared (first use in this function)
ptp.c:1719: error: 'PTP_CHDK_UploadFile' undeclared (first use in this function)
ptp.c: In function 'ptp_chdk_download':
ptp.c:1761: error: 'PTP_OC_CHDK' undeclared (first use in this function)
ptp.c:1763: error: 'PTP_CHDK_TempData' undeclared (first use in this function)
ptp.c:1775: error: 'PTP_CHDK_DownloadFile' undeclared (first use in this function)
ptp.c: In function 'ptp_chdk_exec_lua':
ptp.c:1806: error: 'PTP_OC_CHDK' undeclared (first use in this function)
ptp.c:1808: error: 'PTP_CHDK_ExecuteScript' undeclared (first use in this function)
ptp.c:1809: error: 'PTP_CHDK_SL_LUA' undeclared (first use in this function)
ptp.c:1821: error: 'PTP_CHDK_S_ERRTYPE_NONE' undeclared (first use in this function)
ptp.c: In function 'ptp_chdk_get_version':
ptp.c:1830: error: 'PTP_OC_CHDK' undeclared (first use in this function)
ptp.c:1832: error: 'PTP_CHDK_Version' undeclared (first use in this function)
ptp.c: In function 'ptp_chdk_get_script_status':
ptp.c:1849: error: 'PTP_OC_CHDK' undeclared (first use in this function)
ptp.c:1851: error: 'PTP_CHDK_ScriptStatus' undeclared (first use in this function)
ptp.c: In function 'ptp_chdk_get_script_support':
ptp.c:1867: error: 'PTP_OC_CHDK' undeclared (first use in this function)
ptp.c:1869: error: 'PTP_CHDK_ScriptSupport' undeclared (first use in this function)
ptp.c: In function 'ptp_chdk_write_script_msg':
ptp.c:1891: error: 'PTP_OC_CHDK' undeclared (first use in this function)
ptp.c:1893: error: 'PTP_CHDK_WriteScriptMsg' undeclared (first use in this function)
ptp.c: In function 'ptp_chdk_read_script_msg':
ptp.c:1912: error: 'PTP_OC_CHDK' undeclared (first use in this function)
ptp.c:1914: error: 'PTP_CHDK_ReadScriptMsg' undeclared (first use in this function)
make: *** [ptp.o] Error 1
-
Something simple is missing, I think, maybe a ".h" file, but I don't know what it is.
See line 870 here http://www.assembla.com/code/chdkptp/subversion/nodes/trunk/ptp.h?rev=158# (http://www.assembla.com/code/chdkptp/subversion/nodes/trunk/ptp.h?rev=158#)
// include CHDK ptp protocol definitions from a CHDK source tree
#include <core/ptp.h>
-
I'm afraid I don't understand. I downloaded ptp.h rev 158, but could not find a reference in it to PTP_OC_CHDK or PTP_CHDK. Where are those defined?
-
Line 13 :
http://trac.assembla.com/chdk/browser/trunk/core/ptp.h (http://trac.assembla.com/chdk/browser/trunk/core/ptp.h)
-
Ok, now I get a ton of errors from properties.c--2,500 lines worth. But they're all similar, so again it's probably something simple that I'm lacking. What would that be?
properties.c:65: error: expected specifier-qualifier-list before 'uint16_t'
properties.c:68: error: 'PTP_DPC_Undefined' undeclared here (not in a function)
properties.c:68: warning: excess elements in struct initializer
properties.c:68: warning: (near initialization for 'ptp_device_properties[0]')
properties.c:68: warning: excess elements in struct initializer
properties.c:68: warning: (near initialization for 'ptp_device_properties[0]')
properties.c:69: error: 'PTP_DPC_BatteryLevel' undeclared here (not in a functi$
properties.c:69: warning: excess elements in struct initializer
properties.c:69: warning: (near initialization for 'ptp_device_properties[1]')
properties.c:69: warning: excess elements in struct initializer
properties.c:69: warning: (near initialization for 'ptp_device_properties[1]')
properties.c:70: error: 'PTP_DPC_FunctionalMode' undeclared here (not in a func$
properties.c:70: warning: excess elements in struct initializer
properties.c:70: warning: (near initialization for 'ptp_device_properties[2]')
properties.c:70: warning: excess elements in struct initializer
properties.c:70: warning: (near initialization for 'ptp_device_properties[2]')
properties.c:71: error: 'PTP_DPC_ImageSize' undeclared here (not in a function)
properties.c:71: warning: excess elements in struct initializer
properties.c:71: warning: (near initialization for 'ptp_device_properties[3]')
properties.c:71: warning: excess elements in struct initializer
properties.c:71: warning: (near initialization for 'ptp_device_properties[3]')
properties.c:72: error: 'PTP_DPC_CompressionSetting' undeclared here (not in a $
properties.c:72: warning: excess elements in struct initializer
properties.c:72: warning: (near initialization for 'ptp_device_properties[4]')
properties.c:72: warning: excess elements in struct initializer
properties.c:72: warning: (near initialization for 'ptp_device_properties[4]')
properties.c:73: error: 'PTP_DPC_WhiteBalance' undeclared here (not in a functi$
properties.c:73: warning: excess elements in struct initializer
properties.c:73: warning: (near initialization for 'ptp_device_properties[5]')
properties.c:73: warning: excess elements in struct initializer
properties.c:73: warning: (near initialization for 'ptp_device_properties[5]')
... and so on.
-
I'm afraid I don't understand. I downloaded ptp.h rev 158, but could not find a reference in it to PTP_OC_CHDK or PTP_CHDK. Where are those defined?
Look carefully. You need the ptp.h from the CHDK source, and it needs to be in a directory called 'core', otherwise include "ptp.h" would just pick up the chdkptp one. This defines the protocol. For ease of development, I just include it from my chdk source tree. Yes, this isn't user friendly, I should probably keep a default copy in the chdkptp source.
I've added a new binary snapshot r160. The previous one was missing ustime.lua, so wouldn't actually run. Thanks to begin_astro for pointing that out to me.
-
OK, I got it, thank you for your patience.
When I first ran chdkptp I got the following:
/usr/lib/chdkptp --help
pcall failed 2
error [string "require('main')"]:1: module 'main' not found:
no field package.preload['main']
no file './main.lua'
no file '/usr/local/share/lua/5.1/main.lua'
no file '/usr/local/share/lua/5.1/main/init.lua'
no file '/usr/local/lib/lua/5.1/main.lua'
no file '/usr/local/lib/lua/5.1/main/init.lua'
no file '/usr/share/lua/5.1/main.lua'
no file '/usr/share/lua/5.1/main/init.lua'
no file './main.so'
no file '/usr/local/lib/lua/5.1/main.so'
no file '/usr/lib/lua/5.1/main.so'
no file '/usr/local/lib/lua/5.1/loadall.so'
I noticed that there was a "main.lua" in /usr/src/chdkptp/lua, so I switched to that directory and executed the program successfully. I assume there is a configuration setting which tells the program where to find "main.lua", but I wasn't sure which that was--one of the two lua configuration settings in config.mk or something else.
I executed the program with "/usr/bin/chdkptp -i -c" and got connected. I did "h" for help. I especially appreciate the "ls" command--it's good to be able to get a directory listing easily.
I didn't notice anything like ptpcam's "mode 1" and "mode 0" commands, so I didn't know how to get to where I could "lua set_zoom(3)" and then "lua shoot()"--how to you take a picture with this program in command line mode?
Very good work. I will be glad to have this program and it's successors running on my little dockstar.
-
OK, I got it, thank you for your patience.
When I first ran chdkptp I got the following:
...
I noticed that there was a "main.lua" in /usr/src/chdkptp/lua, so I switched to that directory and executed the program successfully. I assume there is a configuration setting which tells the program where to find "main.lua", but I wasn't sure which that was--one of the two lua configuration settings in config.mk or something else.
Actually, it's not a make config problem, see chdkptp-sample.sh. On linux, the Lua files are not automatically located relative to the program path.
This is one of many loose ends that I still haven't got around to dealing with yet.
I didn't notice anything like ptpcam's "mode 1" and "mode 0" commands, so I didn't know how to get to where I could "lua set_zoom(3)" and then "lua shoot()"--how to you take a picture with this program in command line mode?
There isn't cli commands for switching mode, but you can easily call the camera function directly:
=switch_mode_usb(1)
Very good work. I will be glad to have this program and it's successors running on my little dockstar.
Glad you are finding this useful. I noticed http://wiki.openwrt.org/toh/seagate/dockstar (http://wiki.openwrt.org/toh/seagate/dockstar) says the dockstar is big endian (but can be configured as little ?) It's possible you will run into some endian issues with a big endian host.
-
I hope it's not premature. I put up wiki articles for ptpcam and chdkptp. It took me a couple of days of research to find out what I was looking for, and then to learn how to set it up. Hope these can save time for others.
http://chdk.wikia.com/wiki/Ptpcam_in_headless_linux_Dockstar (http://chdk.wikia.com/wiki/Ptpcam_in_headless_linux_Dockstar)
http://chdk.wikia.com/wiki/Chdkptp_in_headless_linux_Dockstar_-_remote_control (http://chdk.wikia.com/wiki/Chdkptp_in_headless_linux_Dockstar_-_remote_control)
-
Hi reyalp,
you add palette function for a540 in rev. 1684. Sorry, I don't test LiveView in this moment.
Do you have seen this post (http://chdk.setepontos.com/index.php?topic=2361.msg80993#msg80993)? Your a540 have an similar routine on 0xFFD23838 and a convert buffer on 0x5ED8. You get a valid channel value for each channel (A, Y, U, V) by (val1 + val2)div 2.
Hint: White color on a590 use Y=$E0. A test with Y=$FF shows a brighter white on camera display.
rudi
-
Hi reyalp,
you add palette function for a540 in rev. 1684. Sorry, I don't test LiveView in this moment.
Do you have seen this post (http://chdk.setepontos.com/index.php?topic=2361.msg80993#msg80993)? Your a540 have an similar routine on 0xFFD23838 and a convert buffer on 0x5ED8. You get a valid channel value for each channel (A, Y, U, V) by (val1 + val2)div 2.
Hint: White color on a590 use Y=$E0. A test with Y=$FF shows a brighter white on camera display.
rudi
Hi rudi, thanks for that, I hadn't noticed it. The code I have for decoding it in chdkptp (r177-r180) seems to work pretty well but I'm not sure it's totally correct.
Live view is progressing well. I can now play tetris using my camera as a controlling and my computer as display ;)
I've (re)discovered some interesting things about the a540 frame buffers
- normal display is actually 704x240 (or sometimes 264 ?), for both bitmap and viewport. Displaying a 720x viewport shows garbage on the right side. This presumably also affects MD and histogram.
- in 640x480 video mode, the live viewport is 704x528, i.e. the viewport pixels are effectively square instead of 2:1. I believe srsa_4c mentioned this elsewhere.
- in stitch assist mode, it's tiny.
- if you have a video selected in playback mode, live buffer function returns null (ewavr discovered this a long time ago)
-
I've uploaded a new binary snapshot (r192) to the files area http://www.assembla.com/spaces/chdkptp/documents (http://www.assembla.com/spaces/chdkptp/documents)
This includes support for the live view protocol in the reyalp-ptp-live branch. See http://www.assembla.com/spaces/chdkptp/wiki/Live_view_GUI (http://www.assembla.com/spaces/chdkptp/wiki/Live_view_GUI) for details. I can post builds from the branch if anyone needs, just give your camera model and canon firmware version.
The linux version requires that you have the CD libraries available on your LD_LIBRARY_PATH. The windows version is statically linked, so all you need to do is unzip and run the exe.
In order to make it easier to support cameras I don't have, I've added a feature to record and play back dumps of the live data.
This is far from finished, don't be surprised if it crashes or exhibits other odd behavior.
-
Hi,
Just tested on SX130 IS 101c chdkptp live view -r192 with compiled CHDK zip from the reyalp-ptp-live.
Working OK with checked viewfinder and UI overlay.Tested with 5 to 30 FPS - on the Gui screen
all is OK - any motion is perfect in Gui window....start/stop Recording e.t.c.
But can't dump to file and check in play mode.DCIM 2 Folders on SD card are empty.
•To record, click on the debug tab, and check “Dump to file”.
No such tab on Gui interface, nor exactly such tab and in CHDK folder..There is Dump data display: Props Params None
What I'm doing wrong ?
I'v compiled reyalp's ptp-live unziped files with Modules in the core folder.Is this wrong ?
BTW these Modules made me nervous...allways... >:(
EXELENT JOB is this CHDKPTP live view !Thanks reyalp !
And Statistic: Cam was in video mode 1280x720
10 Fps 30 Fps
Running: yes yes
Fps avg: 9.97 19.36
Frame last ms: 30 30
T/P avg kb/s: 4190 8765
X/fer last ms: 20 20
X/fer kb: 421 421
X/fer last kb/s: 21065 21065
YES !
I get it working in play mode too.Debug tab appears after deleting old CGHDK.CFG I'v made copy/paste it from previous CHDK folder-normal build 1659...Either I was blind and I've never seen it ..
On both 10 Fps and 30 Fps (Cam was fixed on the table) all is Fine !(of course 30 Fps is around 20 but this is nice speed too).
-
Great work!
Tested with A720 1.00c - works fine.
Tested with SX220 1.01a - works not really.
I have create a SX220 liveview dump, maybe usefull for the analysis: edit: deleted because wrong link , see next postings
msl
-
Tested with SX220 1.01a - works not really.
Yes, the newer cameras will need some additional work. I think the dumps I got from philmoz will help me sort most of those out, but more samples is always good.
I have create a SX220 liveview dump, maybe usefull for the analysis: http://www.box.com/s/58j5asaidvrjr02g740r (http://www.box.com/s/58j5asaidvrjr02g740r)
I think you linked the wrong file, that says a620update100f.zip
I get it working in play mode too.Debug tab appears after deleting old CGHDK.CFG I'v made copy/paste it
The debug tab I'm talking about appears in the CHDKPTP client, inside the live view tab. You can see it in MSLs screenshot. I don't know what you are looking at in the chdk screens, but it won't help with this.
-
I think you linked the wrong file, that says a620update100f.zip
Sorry, here is the right link: http://www.box.com/s/3ckge952o7big3cnm74c (http://www.box.com/s/3ckge952o7big3cnm74c)
msl
-
I've uploaded a new binary snapshot (r192) to the files area
Great progress reyalp! :D
I tried this binary snapshot it on a570 100e and 64-bit Ubuntu 10.04, reyalp-ptp-live rev 1700.
Live view seems to work well.
In normal shooting modes, a few rows in the bottom are dynamic garbage but in normal video mode the live view fills the entire gui window with correct data. In stitch mode, just a small top left area is active, but looks good (with rest of the live view showing previous image). In other video modes only left side of screen is updated and aspect is incorrect. Overlay seems to work fine as well. I suppose Canon's menus are not even supposed to be shown (not that I care for them, really)?
When live view is enabled, camera is slow to respond to commands from the UI buttons (several seconds for commands to get through) unless target fps is reduced to 4 or lower. That 4.9 fps in the attached screenshots is about the maximum I get.
-
Thanks for testing and detailed report :)
In normal shooting modes, a few rows in the bottom are dynamic garbage but in normal video mode the live view fills the entire gui window with correct data. In stitch mode, just a small top left area is active, but looks good (with rest of the live view showing previous image). In other video modes only left side of screen is updated and aspect is incorrect.
Much of this is due to not having the added functions that get the real dimensions of the viewport. You can see some of these commented in the a540 code in my branch. You can probably find most of these in the old chdkcam code for your camera, although the function names have changed. However, if you use them for the regular frame buffer dimensions used elsewhere in chdk they may have side effects, which is why they are currently commented in my a540 code. In reality, we should use these for md, histogram etc, because otherwise these will be influenced by the garbage areas.
The video modes are odd on these older cameras, some changes in the framebuffer specs will be required to support this.
Overlay seems to work fine as well. I suppose Canon's menus are not even supposed to be shown (not that I care for them, really)?
If you have overlay enabled, it should show exactly what is on the camera screen. However, if you don't have vid_get_bitmap_active_buffer then you will sometimes see an old version of the bitmap.
The palette will only be correct if *vid_get_bitmap_active_palette() and related functions are implmented. However, the code currently falls back to using a hard coded version of the a540 palette, which is probably pretty close on your camera. Canon menus change the palette though, so they will be wrong.
When live view is enabled, camera is slow to respond to commands from the UI buttons (several seconds for commands to get through) unless target fps is reduced to 4 or lower. That 4.9 fps in the attached screenshots is
What sort of system is this on ? On my laptop (dual core athlon 64 @1.8ghz) it starts to have trouble around 10fps with a540. On linux I've found that it starts acting badly if the total time for the frame (frame ms + xfer ms) approaches the time required to make the target frame rate (1000/fps). I should probably make it start dropping frames when this happens. Actually the whole scheduling is pretty hokey...
D10 does significantly higher frame rates on my cam, because the xfer time is much lower. (20-3ms for a full frame vs 90ms on a540). Oddly, xfer times on my windows box are quite a bit lower with the a540. I also noticed that they are higher in rec mode vs. play. I assume this is because the camera CPU is busier, since the data is the same size.
There's room for improvement in the performance if the drawing part, I'm not going to worry too much about that until we have the functionality sorted out.
-
If you have overlay enabled, it should show exactly what is on the camera screen. However, if you don't have vid_get_bitmap_active_buffer then you will sometimes see an old version of the bitmap.
Ah, I gave up on it too soon... I played around with the menu more and it did draw after navigating in the menu. Palette is incorrect (but readable) as expected. No vid_get_bitmap_active_buffer for a570 I believe.
What sort of system is this on ?
Intel E8400 (dual core 3 GHz) desktop, cam on USB 2.0 port without a hub. I used the Linux26g4_64 binaries from sourceforge for CD and IUP.
-
Wrote a long reply here, but got logged out while testing.
Anwyay, tested this on my Ixus 100IS (SD780) and works perfectly.
Built and ran on windows using CHDKShell (though I couldn't get it to pickup revision 1700, am stuck on 1686).
- 30 FPS target averages at 21 FPS with no noticeable CPU/memory usage on my i7.
- The overlay colours are very strange: the grey gradients become rainbow coloured.
- The only big thing I found that doesn't work is that after shooting, the preview mode it goes into throws off the liveview. It starts "snowing" or goes black, and stays that way till the camera goes back to record mode.
If there's anymore info I can help with, let me know. There's something about a raw palette dump?
(you might want to start a seperate thread btw, the info about live view is kind of spread out across two threads)
My use case is a photobooth: the live view will save me lots of time/money getting hold of a ExtUSB plug for video and routing the video through a TV tuner into my PC. It would be cool if your client had some sort of "general use scripting" (respond to keystrokes, basic automation, etc). Best would ofcourse be some sort of API to build applications off of, but assume that's a ways of.
-
Intel E8400 (dual core 3 GHz) desktop, cam on USB 2.0 port without a hub. I used the Linux26g4_64 binaries from sourceforge for CD and IUP.
Well that certainly should be faster than my laptop. However, looking at your screenshots, "last xfer ms" is ~250, which is a lot. If xfer time is really 250 ms, then 4 fps is all you can get :/
Can you check the value of xfer ms when target frame rate is below the point where things start to slow down ?
Is there other software that might be trying to talk to the camera ? (desktop integration etc)
- The overlay colours are very strange: the grey gradients become rainbow coloured.
This is expected until the palette functions are implemented.
- The only big thing I found that doesn't work is that after shooting, the preview mode it goes into throws off the liveview. It starts "snowing" or goes black, and stays that way till the camera goes back to record mode.
If you mean this happens while shooting, I think this is expected. The "live" view buffer shares the same address space with the raw buffer on many (most ? all ?) cameras.
If it happens in recreview mode (e.g. if you set review time > 0, or hold the shutter down after shooting) then that might be fixable, but will require yet another live view address be found.
If there's anymore info I can help with, let me know. There's something about a raw palette dump?
Yes, but first the function to get the palette needs to be implemented for your camera. If I get time, I'll look into finding that for your camera.
Best would ofcourse be some sort of API to build applications off of, but assume that's a ways of.
In fact, the entire gui and most of the application logic is written in lua (using http://www.tecgraf.puc-rio.br/iup/ (http://www.tecgraf.puc-rio.br/iup/) and http://www.tecgraf.puc-rio.br/cd/ (http://www.tecgraf.puc-rio.br/cd/) ), so you can customize it to your hearts content, or roll your own gui from scratch. But you probably want to hold off on that until the code is modularized and documented a bit better. It is certainly my intention to make it easily customizable.
I plan to rework the gui a lot at some point, what's there now is mostly thrown together to test various things. Just need to quit my day job... :haha
-
Yeah, saw it's all lua after I posted that.
Just tested it on my A560 and works well there too, as much as can be expected. The A560 doesn't have working PTP in record mode, it always stays in preview mode, but that's a seperate issue.
If it happens in recreview mode (e.g. if you set review time > 0, or hold the shutter down after shooting) then that might be fixable, but will require yet another live view address be found.
Yes, should have explained that better, but the screen goes black/snowy during the review time, and recovers afterwards.
-
Yes, should have explained that better, but the screen goes black/snowy during the review time, and recovers afterwards.
OK, that means there is yet another live view address that needs to be found. Possibly worth checking if the normal playback one works. I'll try to investigate this on my cameras later.
I've uploaded a new binary snapshot (r201). The main change is in how the display area is sized. It now uses the maximum buffer size, and displays the live view within that. In cropped / letterboxed views, the surrounding area will be white. This is wrong for video in cameras like the a540, where the actual viewport buffer gets bigger.
I've fixed some issues related to different display aspect ratios/letterboxing etc. Most should now see a comprehensible image, but the aspect ratio is likely to be wrong for many.
Another known issue: The ui is always cropped to fit inside the liveview, which is wrong for non-full screen displays.
I added a "quick dump" button, which makes a dump with just 5 frames. This should be sufficient for most diagnostics. There is also a cli command, dumpframes, which can be used to record the live view stream without using the gui at all.
Dump playback is changed such that the viewport and ui checkboxes will control whats drawn. Of course, if one of the buffers was not recorded, it won't be drawn no matter what. Playback doesn't work correctly if you are connected to a camera.
-
I have create a SX220 liveview dump, maybe usefull for the analysis:
Do zebra and edge overlay work on this camera ?
Looking at the dump, the camera is claiming the viewport is an ordinary 720x240, but the data seems very wrong. There is image there, so it's not completely the wrong address, but it seems like the dimensions are off.
-
Do zebra and edge overlay work on this camera ?
Yes & no.
Zebra works.
Edge overlay don't work. The dimensions are ok (tested with 4:3 & 16:9), but is it more a solid color area. I can not detect some contours, evt. some vertical stripes.
Tested with CHDK-DE, CHDK (release 1.0 branch) & live view branch, everywhere the same result.
Some time ago edge overlay works fine. Unfortunately I don't know which version. It is difficult to review all changes.
msl
-
Several Pic's (SX130IS 101c) with reyalp's Live_view soft.
Cam was in 2 video modes 1280/720 and 640/480 - both native using 30 Fps.All test was made with Target Fps 30.On low values going fine.Yelow/orange overlay colors are black on the Cam's LCD...seems colors are little bit reversed ..??
In Rec mode, record process continued exactly 30 seconds (both Viewfinder + UI Overlaye checked, or only Viewfinder). This is strange why....
Then record stoped, and needs restart with Rec Tab..and so on every 30 seconds.
Screen shots was made during live view recording and some values in statistic changed quickly especialy Frame last ms: 10 to 30
--------------------------------------------------
BTW - 2 Ghz old Processor / 1 GB RAM ... SX130IS doing well...
-
Edge overlay don't work. The dimensions are ok (tested with 4:3 & 16:9), but is it more a solid color area. I can not detect some contours, evt. some vertical stripes.
Thanks for checking. The aspect ratio settings will affect live view in chdkptp, so maybe one of them works.
Cam was in 2 video modes 1280/720 and 640/480 - both native using 30 Fps.All test was made with Target Fps 30.
You should not expect this to work at 30fps. Note 421kb per frame * 30 fps = 12.6 megabytes per second.
In your second screen shot frame ms + xfer ms = 60. 60ms between frames = 16fps.
(in theory, we should do the rendering and USB transfer in parallel, but that will require some significant reworking...)
On low values going fine.Yelow/orange overlay colors are black on the Cam's LCD...seems colors are little bit reversed ..??
As I said before, the palette isn't implemented on most cameras yet (including yours, I can see in the console palette_buffer_size 0), and chdkptp only supports one of the variants. Until this is implemented, the overlay will be wrong.
Then record stoped, and needs restart with Rec Tab..and so on every 30 seconds.
I'm not sure what you mean. Do you mean you were trying to record a video on the camera ? If so, it's not at all surprising that trying to transfer 30 fps over USB would break things, it puts a lot of load on the camera CPU.
-
@reyalp,
Many Thanks for Answers.
Do you mean you were trying to record a video on the camera ?
To clarify - when I'v checked Viewfinder and (or not) UI Overlay and then Push Record Tab,
the time before Live view "freeze"..(stop to recording) ..is only 30 seconds.Every time exactly 30 sec.Debug and dump to file not checked.
Same thing and with 5 or 10 Fps.May be the problem is in my Cam ...?
Cam stay connected and another push on Rec tab, Live view continue another 30 seconds.Thats all.
Cam responds to other commands...
Maybe this will help.
chdkptp-r201 and your live_view trunk_1700 - My build .Maybe here I'v made something wrong too.
-
To clarify - when I'v checked Viewfinder and (or not) UI Overlay and then Push Record Tab,
I don't understand what you mean by "record tab". There is no tab named "record" in the app, and there are no tabs in the camera UI. The "tabs" are the things labeled "Console" "Files" "Live" in the main window, and "Statistics" "Debug" in the Live tab. There are no other tabs anywhere.
Do you mean the record button on the camera ? Are you or are you not trying to record a video on the camera ? I wouldn't be at all surprised if transferring live view disrupts the video recording process.
-
Think he means the lag between pressing the Record button on the interface and the actual live view stopping to start recording... Someone else mentioned that earlier during testing.
-
Think he means the lag between pressing the Record button on the interface and the actual live view stopping to start recording... Someone else mentioned that earlier during testing.
The rec button switches the camera to record (shooting) mode. It does not "start recording". Pressing it again when you are already in rec mode might have side effects...
The live view should not (and on my cameras, does not) stop when you switch from play to rec, outside of a brief hiccup in the actual transition.
I'm still completely baffled as to what is being described here.
-
Well that certainly should be faster than my laptop. However, looking at your screenshots, "last xfer ms" is ~250, which is a lot. If xfer time is really 250 ms, then 4 fps is all you can get :/
Can you check the value of xfer ms when target frame rate is below the point where things start to slow down ?
Is there other software that might be trying to talk to the camera ? (desktop integration etc)
In short tests at 4 fps, xfer ms varied between roughly
100 ms and 220 ms with Viewfinder only,
120 ms and 230 ms with VF and UI overlay,
90 ms and 250 ms with UI overlay only (on average seemed to be much less than with vf).
The camera was gphoto2 mounted while I tried this earlier, but unmounting doesn't speed it up, nor does disabling automounting (gconf-editor: /apps/nautilus/preferences/media_automount), nor 'chmod a-rx /usr/lib/gvfs/gvfs-gphoto2-volume-monitor'.
lsusb gives 'bcdUSB 2.00' for this so I suppose it's using USB 2.0.
This was with build r192, but I quickly tried the new r201 with similar results.
-
In short tests at 4 fps, xfer ms varied between roughly
100 ms and 220 ms with Viewfinder only
by that, do you means transfer of the YUV data or also its conversion to an image ?
You would think transfer time of the data is the same on all cameras that use USB2.0.
Presumably, no tasks can interrupt the USB transfer ?
-
In short tests at 4 fps, xfer ms varied between roughly
100 ms and 220 ms with Viewfinder only,
120 ms and 230 ms with VF and UI overlay,
90 ms and 250 ms with UI overlay only (on average seemed to be much less than with vf).
Thanks, that explains the symptom, but doesn't really explain why...
Do you have something else on usb that would be using a lot of bandwidth ? Ethernet, wifi
Your OS is Ubuntu 10.04 ? If you have windows on the same box, it would be interesting to know what results you get. My windows box transfers a bit faster than my laptop but it's also much faster hardware.
This was with build r192, but I quickly tried the new r201 with similar results.
Yeah, I wouldn't expect any difference there.
-
by that, do you means transfer of the YUV data or also its conversion to an image ?
xfer ms only includes the time for the PTP command + related overhead to complete.
You would think transfer time of the data is the same on all cameras that use USB2.0.
This definitely not the case. My d10 tranfers much faster than a540. But I'd expect a540 and a570 to be roughly equal, and fudgey appears to be getting < 1 mbyte/sec, which is fairly pathetic.
-
Of course, how do you know if the PC is transferring at USB 2.0 speeds ?
Without me changing anything, my PC sometimes reports "this device can operate much faster.For a list of available ports click here."
There is never anything I can change.
-
@reyalp: tested some more stuff today and made a few quick dumps that are bundled in this ZIP: http://dl.dropbox.com/u/12392488/IXUS100ISDumps.zip (http://dl.dropbox.com/u/12392488/IXUS100ISDumps.zip)
Let me know if you're looking for anything in particular, but:
- Video mode seems fine
- Tried stitch mode, works ok, but the preview is shown in the top left corner. Then on the second picture, due to the review screen problems, the background is black/snow.
- Edge detect seems to work fine, the color on the overlay is a little weird but works ok.
- Need to look into Zebra mode, not sure what that even does.
- As someone mentioned earlier, while all the CHDK menus show fine on the preview, on the actual device they go orange instead of black/grey, slightly weird. The weird colored menus stay around even after a device off/on and being disconnect.
-
Gent's,
Well -You say button ..buttons - Agree.My mistake with this Tabs - bad english, apologize every one.
How to see moving people on the window in GUInterface ?
Checking Viewfinder - nothing happens.Cam is in preview mode.I must push only and only rec button, Cam to extend his Lens, and to see moving people in window FOR FIRST TIME. And after 30 seconds these people freeze.
After that, any button of all upper right (exept play and erase) clicked, returning Cam in Live view (rec button is not in pushed state) and I can see moving objects in front of the Cam - for another 30 seconds.
NO LAG on my CAM after button was pushed and action - if persist it is too small.
If there is another way to activate the CAM, and to see myself walking like a model in front of
the Lens not only for 30 seconds - PLS tell me .
Very sorry for caused inconvenience with my stupied Qustions.Excuse me please.
-
Do you have something else on usb that would be using a lot of bandwidth ? Ethernet, wifi
Not really. Just a hub or two with nothing connected to them, an empty card reader and an idle RS-232 converter (speread over several buses). Speed is the same via a hub too.
Your OS is Ubuntu 10.04 ? If you have windows on the same box, it would be interesting to know what results you get. My windows box transfers a bit faster than my laptop but it's also much faster hardware.
Yes (and I even rebooted it since yesterday, now that doesn't happen often...), and it's the only OS.
Btw, I was testing with a slow 32MB MMC card, which slows down file downloads a lot, I didn't think that could affect PTP live view? From a 4GB Transcend Class 6 SDHC card a quick try via ~/.gvfs/gphoto2 mount gives
dd if=MVI_9232.AVI of=/dev/null; bs=1M
59937920 bytes (60 MB) copied, 9.7563 s, 6.1 MB/s
which is way more than 12 Mb/s, so at least gphoto2 gets me data in USB 2.0 high-speed mode.
-
And Surprise:
In my DCIM Folder on SDHC card I found MVI_0019.MOV file /99757 KB 1 min 12 sec duration
created during my last tests 1 hour ago.I don't know with what buttons combination was created - sometime I tested many buttons one after other...Records seems are posiible and with 30 Fps..
My Video Editor/Convertor say's:
See attachment...
-
Well -You say button ..buttons - Agree.My mistake with this Tabs - bad english, apologize every one.
It's ok, just trying to figure out what we are talking about. I'm certainly worse in every other language.
How to see moving people on the window in GUInterface ?
Checking Viewfinder - nothing happens.Cam is in preview mode.I must push only and only rec button, Cam to extend his Lens, and to see moving people in window FOR FIRST TIME. And after 30 seconds these people freeze.
After that, any button of all upper right (exept play and erase) clicked, returning Cam in Live view (rec button is not in pushed state) and I can see moving objects in front of the Cam - for another 30 seconds.
This sounds like it could be some camera sleep feature. In chdk miscellaneous menu you can try "disable LCD off" always.
I want to add an option to this for when USB is connected.
There are some power saving modes that can be triggered by software on the PC too I think, but I'm less clear about how they work.
Very sorry for caused inconvenience with my stupied Qustions.Excuse me please.
Not stupid, just not clear :)
-
- Edge detect seems to work fine, the color on the overlay is a little weird but works ok.
- Need to look into Zebra mode, not sure what that even does.
Sorry, my question to MSL about edge and zebra was specifically for his camera *without* PTP. No particular need to test this over PTP, if the bitmap stuff is correct it will work the same as everything else.
- As someone mentioned earlier, while all the CHDK menus show fine on the preview, on the actual device they go orange instead of black/grey, slightly weird. The weird colored menus stay around even after a device off/on and being disconnect.
Are you saying that the color are wrong on the actual camera screen, not the display on the PC ? This should not have anything to do with chdkptp...
-
Mr. reyalp, SIR.
There are some power saving modes that can be triggered by software on the PC too I think...
Great! My problem is solved! Thanks for that.I'v disabled Power saving in camera main menu.
It was ON , and display to go OFF was 30 sec.Now disabled in CHDK also.
And now all is Fine.Simple, but but one must be remembered in time :) -Thanks.
Realy was stupid from my side...
-
- As someone mentioned earlier, while all the CHDK menus show fine on the preview, on the actual device they go orange instead of black/grey, slightly weird. The weird colored menus stay around even after a device off/on and being disconnect.
Are you saying that the color are wrong on the actual camera screen, not the display on the PC ? This should not have anything to do with chdkptp...
Yes, the camera screen has a yellow/orange color instead of black, while the overlay being previewed on PC is the correct black color. It's only for the CHDK menus and overlay however.
-
Are you saying that the color are wrong on the actual camera screen, not the display on the PC ? This should not have anything to do with chdkptp...
Yes, the camera screen has a yellow/orange color instead of black, while the overlay being previewed on PC is the correct black color. It's only for the CHDK menus and overlay however.
And it doesn't do this without being connected to USB ?
Does it happen if you don't use live view, e.g, just connect the camera, press the chdkptp REC button ?
It's possible the camera doesn't switch to it's normal record palette when mode switched over USB I guess.
-
I've tried compiling this on Ubuntu 11.10 myself, but got the following errors:
/usr/lib/libcdlua51.so: undefined reference to `lua_tointegerx'
/usr/lib/libcdlua51.so: undefined reference to `lua_pcallk'
/usr/lib/libcdlua51.so: undefined reference to `lua_tonumberx'Them seem to be functions from lua5.2 according to the changelog...
Was awful BTW: compiling CD and IUP from source is no fun (binaries aren't available for 3.0 kernels)
Do you have any idea what I'm doing wrong?
-
I've tried compiling this on Ubuntu 11.10 myself, but got the following errors:
/usr/lib/libcdlua51.so: undefined reference to `lua_tointegerx'
/usr/lib/libcdlua51.so: undefined reference to `lua_pcallk'
/usr/lib/libcdlua51.so: undefined reference to `lua_tonumberx'Them seem to be functions from lua5.2 according to the changelog...
Was awful BTW: compiling CD and IUP from source is no fun (binaries aren't available for 3.0 kernels)
Do you have any idea what I'm doing wrong?
chdkptp is currently meant to run against lua 5.1, so if you are building with 5.2, that might be your problem. If you did want to build with 5.2, you need to change the cdlua*51 libraries to *52, but I suspect other changes would be needed as well.
There are linux kernel 3.0 libraries available for CD http://sourceforge.net/projects/canvasdraw/files/5.5/Linux%20Libraries/ (http://sourceforge.net/projects/canvasdraw/files/5.5/Linux%20Libraries/)
It looks like IUP does not have kernel 3.0 libraries yet.
-
Snapshot r215 uploaded.
The main user visible changes are:
1) The GUI starts by default if invoked with no options.
2) Added a bunch of checkboxes to control how the live view is displayed. These will get re-organized or go away later.
If "Scale for A/R" is checked, the live display width will be determined by the viewport width (after applying the "Viewfinder 1:1" option) , and the height will be scaled for the cameras physical lcd aspect ratio.
If "Overlay fit" is checked, the bitmap overlay will be scaled to exactly the size of display area.
If both of the above are checked, the viewport and overlay should be the correct aspect ratio, and have the same relationship they do on the actual camera display. "Viewfinder 1:1" will give you a larger or smaller display.
Assuming things on the camera are set up correctly, checking "Scale for A/R" and "Overlay fit" should give you correct aspect ratio, and the bitmap should be positioned correctly relative to it.
Viewfinder 1:1 controls whether each UYVYYY is used to generate 2 pixels (unchecked) or 4 pixels (checked). If "Scale for A/R" is unchecked, which one looks more correct depends on your camera and it's current display mode.
Overlay 1:1 controls whether the bitmap image uses every other pixel (unchecked) or every pixel (checked). If "Overlay fit" is unchecked, which one looks more correct depends on your camera.
-
chdkptp is currently meant to run against lua 5.1
Right, I compiled lua 5.1 from source, then IM, then CD and then IUP, all against 5.1. Now, when running make on your chdkptp project, I get those errors.
-
HI,
I'v tested new Snapshot r215 with -r1703 compiled.
All is OK with SX130IS ( OK=mean no crashes -all works )
Viefinder and UI Overlay always checked.
-Viewfinder 1:1 checked - results in extension of Viewfinder window x2 (twice) in horizontal only.
-Overlay 1:1 checked - extend only grid lines twice in horizontal position.From 2 vertical lines remain only 1.Not Viefinder window.
-Overlay Fit checked - No reaction
-Scale for A/R checked - extend Viewfinder window 10 mm bottom side down.
With shoot button I'v made 2 short 20 seconds video clips recorded on SD card.
All is very stable and waiting only to be corrected Overlay colors for SX130IS.
ffdshow info: see attached picture.
-
A590
Incorrect color overlay in version 215, the rest works great.
-
chdkptp is currently meant to run against lua 5.1
Right, I compiled lua 5.1 from source, then IM, then CD and then IUP, all against 5.1. Now, when running make on your chdkptp project, I get those errors.
If they are actually from lua 5.2 (which appears likely, I don't see any references to them in 5.1), then you've done something wrong building CD, because the 5.1 library shouldn't have any references to 5.2 functions. This might be caused if it found the lua 5.2 headers while building for 5.1, or something like that.
Incorrect color overlay in version 215, the rest works great.
The following might help me correct it:
1) a "quick dump" with palette displayed in CHDK (misc, draw palette)
2) a picture (taken with another camera, cell phone etc ok) of the actual camera screen with the palette displayed.
-Viewfinder 1:1 checked - results in extension of Viewfinder window x2 (twice) in horizontal only.
That's what it does. On cameras with a 480 line viewport (like the g12) the stretched version will be approximately correct.
-Overlay 1:1 checked - extend only grid lines twice in horizontal position.From 2 vertical lines remain only 1.Not Viefinder window.
Don't understand. If you aren't using fit, it will make the overlay 2x wider. This should either be 2x too wide for the screen (assuming you don't have viewport 1:1 checked), or correct, depending on your camera.
-Overlay Fit checked - No reaction
??? This should always make the overlay exactly fit in the view window. If it's already correct (depends on the 1:1 settings) then you will see no change.
-Scale for A/R checked - extend Viewfinder window 10 mm bottom side down.
The question is, did it look correct ? You can test it like this
- connect to the camera, switch to rec, enable ui overlay
- check both "Overlay fit" and "Scale for A/R"
- make sure you have some identifiable UI on the screen (like the AF frame rectangle when you have AF frame set to center)
- disconnect. The image will now be frozen on the screen
- aim the camera at the screen. If everything is correct, the UI on the screen will almost perfectly line up with the ui on the camera.
With shoot button I'v made 2 short 20 seconds video clips recorded on SD card.
All is very stable and waiting only to be corrected Overlay colors for SX130IS.
ffdshow info: see attached picture.
Don't understand how this relates to chdkptp.
-
@reyalp
The question is, did it look correct ?
Yes, all look correct.All is correct and with other checkboxes.
GL.
-
In reyalp-ptp-live changeset 1706, I've ported over as much as I could from ewavrs old chdkcam patch. (found at http://ewavr.nm.ru/chdk/for_test/ (http://ewavr.nm.ru/chdk/for_test/) )
This adds palette and bitmap buffer functions for
a480, a590 100e (101b was already done), a60, a650, a710, a720, ixus700_sd500 (101 a only), sx1 (201a only), sx10 (101a and 102b only), sx200is
Note that the palettes types are likely wrong, but I can fix this if owners of the cameras send live view "quick dumps" and pictures of the camera display.
Copy paste errors are also likely.
I've also copied over the viewport size functions, but left them #if 0'd out, since some additional work is needed to handle this properly.
@reyalp
The question is, did it look correct ?
Yes, all look correct.All is correct and with other checkboxes.
Thanks :)
-
The following might help me correct it:
1) a "quick dump" with palette displayed in CHDK (misc, draw palette)
2) a picture (taken with another camera, cell phone etc ok) of the actual camera screen with the palette displayed.
Done
http://www.mediafire.com/?mkp4f9xjnrm91jx (http://www.mediafire.com/?mkp4f9xjnrm91jx)
-
Done
http://www.mediafire.com/?mkp4f9xjnrm91jx (http://www.mediafire.com/?mkp4f9xjnrm91jx)
Thanks.
That looks "correct" to me. It's not perfect by any means, but it's using the right palette type and the colors are approximately correct. This is pretty much the same as what I have on a540.
One issue I've noticed (same on a540) is the left most column is grayscale on the camera display. This must be a special case in the Canon firmware.
The saturation and brightness of the other colors is off a bit as well. (edit: and a few colors are quite far off, e.g. the purple at 11,3 is blue on the camera)
I do have a note to go back and look more closely at the stuff rudi posted in http://chdk.setepontos.com/index.php?topic=2361.msg80993#msg80993 (http://chdk.setepontos.com/index.php?topic=2361.msg80993#msg80993) at some point.
-
- The overlay colours are very strange: the grey gradients become rainbow coloured.
This is expected until the palette functions are implemented.
I implemented the palette and bitmap buffer functions for ixus100 in reyalp-ptp-live changeset 1710.
Untested, but looks quite similar to d10, so it might be OK.
-
Uploaded snapshot r219. This adds support for the type 3 palette, used by d10, g12 and other more recent cameras.
-
Hi,
I'v made test with -r219_-r1711 reyalp's last releases.
In expanded "view" when some sheckboxes are checked, it's a bit otside of my monitor.
But let the snapshots speak.
Fine job Mr.Wizard !
-
That looks "correct" to me. It's not perfect by any means, but it's using the right palette type and the colors are approximately correct....
It does not matter, it was a minimal problem which is missing in r219.
The only problem which I see now is that what can not open the Camera folder, if the recorded video.
-
Hi again,
Short Quick dump... forgotten in previous post - sorry
-
In expanded "view" when some sheckboxes are checked, it's a bit otside of my monitor.
Get a bigger monitor ;)
Seriously though, I'll try to add an option to scale the live view area to fit at some point.
It does not matter, it was a minimal problem which is missing in r219.
OK. I did fix a bug with the last color in the palette not getting set right.
The only problem which I see now is that what can not open the Camera folder, if the recorded video.
Can you explain more ?
-
The only problem which I see now is that what can not open the Camera folder, if the recorded video.
Can you explain more ?
When I record an AVI file (set the mode dial to Movie), I can not open the folder called "Camera" in the Files menu.
I must restart the GUI and camera, and then the "Camera" folder opens normally and can download AVI from 100CANON to PC.
-
When I record an AVI file (set the mode dial to Movie), I can not open the folder called "Camera" in the Files menu.
I must restart the GUI and camera, and then the "Camera" folder opens normally and can download AVI from 100CANON to PC.
There may be some messages in the console window which would help understand what is failing when you try to open the camera folder.
-
There may be some messages in the console window which would help understand what is failing when you try to open the camera folder.
branchopen_cb 0populate branch 0 A/
EDIT :The icon changes to an open, but is not showing any content.
-
Trying to build this myself, now have Ubuntu 10.04 and everything compiles and runs, but the live view doesn't work. I've enabled all the libs, installed, linked and checked the paths. When connecting however, I get the following stack trace:
/home/joel/chdkptp/trunk/lua/chdku.lua:950: attempt to call method 'get_handler' (a nil value)
stack traceback:
/home/joel/chdkptp/trunk/lua/chdku.lua:950: in function 'live_init_streaming'
/home/joel/chdkptp/trunk/lua/gui_live.lua:577: in function 'on_connect_change'
/home/joel/chdkptp/trunk/lua/gui.lua:111: in function 'update_connection_status'
/home/joel/chdkptp/trunk/lua/gui.lua:128: in function </home/joel/chdkptp/trunk/lua/gui.lua:114>
(tail call): ?
[C]: in function 'MainLoop'
/home/joel/chdkptp/trunk/lua/gui.lua:492: in function </home/joel/chdkptp/trunk/lua/gui.lua:478>
(tail call): ?
/home/joel/chdkptp/trunk/lua/main.lua:172: in main chunk
[C]: in function 'require'
[string "require('main')"]:1: in main chunk
Where do I look? All functions except for live view work however.
-
Trying to build this myself, now have Ubuntu 10.04 and everything compiles and runs, but the live view doesn't work. I've enabled all the libs, installed, linked and checked the paths. When connecting however, I get the following stack trace:
...
Where do I look? All functions except for live view work however.
You need to set LIVEVIEW_SUPPORT=1 in config.mk
The fact that this resulted in a runtime error is a bug, which I've worked around in r226
-
Ok, thanks, that was the trick, now have it working under Linux (after also copying live_view.h from your CHDK branch)
-
Ok, thanks, that was the trick, now have it working under Linux (after also copying live_view.h from your CHDK branch)
So do you just need to copy that file to the main trunk build ? Or do you need to use the reyalp-ptp-live branch built for your cam/fw to use live_view ?
-
Ok, thanks, that was the trick, now have it working under Linux (after also copying live_view.h from your CHDK branch)
So do you just need to copy that file to the main trunk build ? Or do you need to use the reyalp-ptp-live branch built for your cam/fw to use live_view ?
You need to use the reyalp-ptp-live branch, and the live_view.h included in chdkptp must come from that branch.
-
You need to use the reyalp-ptp-live branch, and the live_view.h included in chdkptp must come from that branch.
Thanks - wondered about that after reading the previous post. Any plans to add to the dev trunk ?
-
Note that the palettes types are likely wrong, but I can fix this if owners of the cameras send live view "quick dumps" and pictures of the camera display.
@reyalp : Got live-view working tonight under Fedora 16. Very nice!
A few rough patches to be expected I guess. The CHDK menus seem to overlay each other. If the previous menu is bigger than the new menu, you can still see it in the background. Pretty much what happens during the early stage of a port when vid_bitmap_refresh() is not working.
Here's the two image files for the G10 : http://www.box.com/s/6100778e4164ad695df7 (http://www.box.com/s/6100778e4164ad695df7)
If you can find a few minutes to "fix" the colors, I can use this to update the new USB remote wiki pages - the current images are pretty lame.
Thanks again.
-
Any plans to add to the dev trunk ?
Yes, holding off on that until after I've got the protocol changes sorted out.
I can use this to update the new USB remote wiki pages - the current images are pretty lame.
At some point I plan to link in libjpeg or IM so you can save camera screenshots directly to an image file. Not today though...
-
At some point I plan to link in libjpeg or IM so you can save camera screenshots directly to an image file. Not today though...
Nice feature. Screen capture from what we have now is a huge step above taking pictures of the cam LCD with my cellphone but that would be even nicer.
-
New snapshot build r230. Not much end-user visible stuff. Changed the linux build to not use a really old hack related to the USB API, which should make it work on newer distros. Thanks to waterwingz for helping to sort this out. Users over very old distros (2005 ?) might want to look at http://trac.assembla.com/chdkptp/changeset/222 (http://trac.assembla.com/chdkptp/changeset/222) if they trouble.
-
New snapshot build r230. Not much end-user visible stuff.
Check out the new "screenshots" on the USB remote wiki page. Thanks.
If I get a bit of time, I was going to look at how the CLI code accepts keyboard data under Linux. A command buffer that allows you to scroll back through previous commands, edit and re-use them would be nice. It works that way with the CLI under Windows so I assume its a question of what OS function is called ?
-
New snapshot build r230. Not much end-user visible stuff.
Check out the new "screenshots" on the USB remote wiki page. Thanks.
If I get a bit of time, I was going to look at how the CLI code accepts keyboard data under Linux. A command buffer that allows you to scroll back through previous commands, edit and re-use them would be nice. It works that way with the CLI under Windows so I assume its a question of what OS function is called ?
Currently, it just using standard lua file IO, using io.lines(). I'm not sure what magic makes command history work under windows in this case.
The correct way to do this would probably be to use something like GNU readline. The standard lua CLI interpreter might provide some hints. (grep lua_readline in the lua source)
This is on my TODO list ( http://www.assembla.com/spaces/chdkptp/tickets/57 (http://www.assembla.com/spaces/chdkptp/tickets/57) ), but not a high priority since I do most of my development under windows.
edit:
if you want to implement this, I'd suggest making "sys.readline" in the C code, and then adjusting the CLI module to use it. It needs to work normally if the input is not a tty (redirect from file or pipe)
-
With changeset 1755 (http://prepare) live view works fine for the SX220. The SX230 can also be tested.
Btw, I have reported, that edge overlay works not correctly for the SX220. That's not true. Only the filter function makes some problems.
msl
-
I've attached a modified gui.lua.
Added buttons for jogdial, video and shoot half.
msl
-
Something like that I made for my purposes.
-
With new branch 1755 and -r230 no change in colors on SX130IS.
Still same like old builds - both overlay colors and native Cam simbols
and text colors not true.
-
With new branch 1755 and -r230 no change in colors on SX130IS.
No changes have been made to sx130 yet. It still needs the palette functions.
both overlay colors and native Cam simbols and text colors not true.
I don't understand the distinction. There is only one overlay.
@msl and @blackhole
Thanks for those. The control interface definitely needs some improvement.
I'm not really sure what to do with half press. Ideally, you should be able to use it like the camera shutter button, so you click something to halfpress, then something to either cancel of full shoot. This would require a message script, since keyboard resets when the script ends. I'm also not sure what gui widgets to use to implement that either.
-
both overlay colors and native Cam simbols and text colors not true.
--------------------------------------------------------------------
reyalp ...I don't understand the distinction. There is only one overlay.
Should be written as:
The overlay colors and native Cam....
Very sorry... Continue to learn English ???
-
The windows binary I posted is completely standalone, IUP and lua are statically linked into chdkptp.exe. Assuming you have libusb, you can just unzip and run.
Well, when I did that and tried to connect via the gui it said "incompatible API".
My real question is, does mode switching work on the S95 ?
It should be the standard function.
It does not work in my code (it does with other cameras).
I tried this alternative client to see if it works here.
-
The windows binary I posted is completely standalone, IUP and lua are statically linked into chdkptp.exe. Assuming you have libusb, you can just unzip and run.
Well, when I did that and tried to connect via the gui it said "incompatible API".
The message only refers to live view. If you do want to use live view, then you need to use a CHDK build from my branch.
As an aside, if you are implementing PTP support in SDM (I guess you have it in an unreleased version ?) it would be good to come up with identify CHDK vs SDM, unless you make it 100% compatible with a particular version of the CHDK protocol. I'd suggest adding a third parameter to PTP_CHDK_Version that identifies the implementation.
My real question is, does mode switching work on the S95 ?
It should be the standard function.
Whether this works or not has nothing to do with the client.
@Pier
I'm sorry, I still don't understand what you are trying to say. Anyway, the colors will be wrong until someone adds the palette functions. I hope to add them to the sig finder at some point, so I'm not spending a lot of looking for individual cameras at the moment.
-
if you are implementing PTP support in SDM (I guess you have it in an unreleased version ?)
I don't know.
I cannot help feeling I would be inundated with questions and problems.
Whether this works or not has nothing to do with the client.
No, except i am using your client to try to send the command to the official CHDK version to see if switch_mode_ptp works.
If it does, it is a problem with my code that uses the standard function.
-
I'm not really sure what to do with half press. Ideally, you should be able to use it like the camera shutter button, so you click something to halfpress, then something to either cancel of full shoot.
A button for half pressed shutter is useful for a check (fokus ok?, Tv, Av). You don't need to take a photo.
I think static buttons for capture modes is not the best idea. We can get a camera-dependent mode list with a little script request.
function getcammode()
modemap=require("GEN/modelist")
capmode=require("capmode")
local mode_list="" -- string
--local mode_list={} -- table
for i=1, #modemap do
if capmode.valid(modemap[i]) then mode_list=mode_list..modemap[i].."|" end -- string variant
--if capmode.valid(modemap[i]) then table.insert(mode_list, modemap[i]) end --table variant
end
return mode_list
end
With a dropdown box you can select the capture mode.
capmode=require('capmode') capmode.set(mode_list[n]) --table variant
I also think, we need more camera data (get_buildinfo(), get_vbatt(), get_free_disk_space() ect.)
msl
-
A button for half pressed shutter is useful for a check (fokus ok?, Tv, Av). You don't need to take a photo.
Yes, this is true, but being able to half press-> shoot would also be good.
I think static buttons for capture modes is not the best idea. We can get a camera-dependent mode list with a little script request.
function getcammode()
modemap=require("GEN/modelist")
capmode=require("capmode")
local mode_list="" -- string
--local mode_list={} -- table
for i=1, #modemap do
if capmode.valid(modemap[i]) then mode_list=mode_list..modemap[i].."|" end -- string variant
--if capmode.valid(modemap[i]) then table.insert(mode_list, modemap[i]) end --table variant
end
return mode_list
end
With a dropdown box you can select the capture mode.
capmode=require('capmode') capmode.set(mode_list[n]) --table variant
I also think, we need more camera data (get_buildinfo(), get_vbatt(), get_free_disk_space() ect.)
msl
Agreed. It has been my plan to collect buildinfo, mode list etc. in gui.update_connection_status.
Vbatt, free space etc would need to be polled. I'm not yet sure how to handle this. The timer probably needs to move out of live gui or the regular gui needs another one.
No, except i am using your client to try to send the command to the official CHDK version to see if switch_mode_ptp works.
If it does, it is a problem with my code that uses the standard function.
It should connect and work (or not) regardless of whether the live view protocol is compatible.
-
It should connect and work (or not) regardless of whether the live view protocol is compatible.
No, it tries to initialise live streaming even though all the LiveView boxes are unchecked and I am displaying the console window.
Compiling your branch is going to be messy, starting with lots of errors due to redefinition of integer types in
flt.h that are already defined in my \gcc\include\stdint.h.
-
No, it tries to initialise live streaming even though all the LiveView boxes are unchecked and I am displaying the console window.
If it fails to initialize the live view, it still connects. The message just tells you live view is not supported. The other functions should still work. This works on my cameras with the r230 chdkptp build and the release branch autobuild.
Compiling your branch is going to be messy, starting with lots of errors due to redefinition of integer types in
flt.h that are already defined in my \gcc\include\stdint.h.
That probably applies to the trunk as well.
-
I am almost reluctant to ask this, but as I have never played with CHDK or Lua I am having some difficulty trying to switch between record and playback when in console mode.
What is the command ?
-
I am almost reluctant to ask this, but as I have never played with CHDK or Lua I am having some difficulty trying to switch between record and playback when in console mode.
What is the command ?
rec
=switch_mode_usb(1)
play
=switch_mode_usb(0)
-
OK, it does switch to Record and Play from the gui.
I now how to find-out why the same commands do not work for the S95 with my code but do for other cameras.
Too bad I will not see 360x240 LiveView (as compared with 320x240).
EDIT
I had tried the above commands but without "=".
-
= means "run lua code on camera and wait for it to finish"
In r232 and r233 I've added the gui from msl, and a dropdown for capture mode.
The dropdown tries to match the cameras current mode when you connect or switch to rec, but it could easily get out of sync. The whole camera control gui and associated scripting is going to need a re-work at some point.
-
In r232 and r233 I've added the gui from msl, and a dropdown for capture mode.
Thanks for that. Works fine.
msl
-
OK, it does switch to Record and Play from the gui.
I now how to find-out why the same commands do not work for the S95 with my code but do for other cameras.
what happen with S95 ?
Do the camera crash after
switch_mode_usb(1)
after the lens is move out ?.Ixus 1000 call for this is test and is correct.
Are there other cameras with this problem known, or is IXus 1000 the only ?
ASSERT!! KerQueue.c Line 86
Occured Time 2012:03:27 12:32:14
Task ID: 16711713
Task name: CtrlSrv
SP: 0x00389958
StackDump:
0x00000000
0xFF83AF44
0x00000056
0x00000001
0x001E4050
0x00000000
0x0000F6EA
0x00000000
0x00000000
0x19980218
0x19980218
0xFF83AD84
0x0000438C
0x00000001
0x0000201D
0xFF83B670
0x0000438C
0xFF8AABA8
0x00000000
0x0000410C
0x00000001
0xFF8A5B58
0x00003DAC
0x00000001
0x0000201D
0xFF89F93C
0x00003DAC
0xFF89EB04
0x001F3168
0x0000391C
0x0000201D
0xFF899B08
0x001F3168
0x00000001
0x0000391C
0x0000201D
0x0000F6EA
0xFF89A014
0x0003D54C
0x00003904
0x19980218
0x19980218
0x19980218
0x19980218
0x19980218
0xFF8994D4
0x0003D54C
0x00372B10
0x19980218
0xFF816B74
0x19980218
0x19980218
0x00002008
ShootConDump:
0f 0f 0f 0f 0f 0f 0f 0f 0f 0f
CameraConDump:
07 0a 02 0d 09 0f 0f 0f 0f 0f
00060540: UI:Reduce ScreenUnLock
00060540: UI:ScreenLock
00060540: UI:Reduce ScreenUnLock
00060540: UI:ScreenLock
00060540: UI:Reduce ScreenUnLock
00060540: UI:ScreenLock
00060540: UI:Reduce ScreenUnLock
00060540: UI:ScreenLock
00060540: UI:ScreenUnLock
00060540: UI:ScreenLock
00060540: UI:Reduce ScreenUnLock
00060550: UI:ScreenLock
00060550: UI:Reduce ScreenUnLock
00060550: UI:ScreenLock
00060550: UI:Reduce ScreenUnLock
00060550: UI:ScreenLock
00060550: UI:Reduce ScreenUnLock
00060550: UI:ScreenLock
00060550: UI:Reduce ScreenUnLock
00060550: UI:ScreenLock
00060550: UI:Reduce ScreenUnLock
00060550: UI:ScreenLock
00060550: UI:Reduce ScreenUnLock
00060550: SS:InitPTM
00060550: SS: 004b->8004
00060550: SS: Asp 0000->0000
00060560: UI:ScreenLock
00060560: UI:ScreenUnLock
00060620: UI:AC:TstEVF:Ok
00060620: SS:ToRec
00060620: SS:Lens1stP
00060620: SS: Evf=1
00060620: M:FIRST_S
00060660: M:ZM_RST_S
00060710: M:IS_RST_S
00060710: SS:InitPTM
00060710: SS: 004b->8004
00060710: SS: Asp 0000->0000
00060710: SS:ImgSys
00060710: UI:LogicalEvent:0x5004:adr:0,Para:0
00060710: UI:DisplayPhysicalScreenCBR
00060710: UI:DisplayPhysicalScreenCBR
00060710: UI:DisplayPhysicalScreenCBR
00060710: UI:AC:ShwCaptI
00060710: UI:DSIC:53,0
00060710: UI:ScreenLock
00060710: UI:DSIC:49,1
00060720: UI:Display_CaptInfo
00060740: UI:DSIC:c4,0
00060770: UI:AC:DispSht
00060770: UI:DSIC:8c,0
00060860: M:IS_RST_E
00060860: M:IR_RST_S
00060900: M:IR_RST_E
00061410: M:ZS_RST_E
00061410: M:ZM_RST
00061410: M:ZS_RST_S
00061410: M:ZS_RST_S
00061790: M:ZS_RST_E
00061970: M:ZM_RST_E
00062070: M:ZM_RST_F
00062070: M:ZS_RST_S
00062080: M:ZS_RST_E
00062080: M:ZS_RST_S
00062080: M:FC_RST_S
00062150: M:ZM_MVP_E
00062170: M:FC_RST_E
00062170: M:ZM_MVP_S
00062170: M:FC_STB_S
00062170: M:ZM_MVP_S
00062210: M:ZS_RST_E
00062210: M:ZS_RST_S
00062270: M:ZS_RST_E
00062450: M:FC_STB_E
00062500: UI:ScreenUnLock
00062530: UI:DisplayPhysicalScreenCBR
00062680: M:ZM_MVP_E
00062680: M:FIRST_E
00063210: UI:ShootSeqToUI:0x202e:adr:0x373ee8,Para:3620584
00063210: UI:ShootSeqToUI:0x201d:adr:0,Para:0
00063210: UI:DispSwCon_TurnOnBackLight
00063210: UI:DispSwCon_MuteOffPhysicalScreen
00063210: UI:AC:SUpShowI
00063210: UI:AC:EnryRecBt
00063210: UI:StartRecMode
00063220: UI:DispSwCon_MuteOffPhysicalScreen
00063220: UI:LogicalEvent:0x3110:adr:0,Para:0
00063220: UI:DispSwCon_TurnOnDisplayDevice
00063220: UI:UI_StrobeCon_Start
00063230: UI:LogicalEvent:0x301c:adr:0,Para:0
-
[quote author=Bernd R link=topic=6231.msg83439#msg83439 date=1332844997]
what happen with S95 ?
It works OK !
At the start of spytask() (before entering the endless loop), I was getting the image-resolution property-case.
However, it was carelessly positioned before init_file_modules_task() had reported 'spytask_can_start'.
David
-
Thanks for that Reyalp. I've already read that page about Darwin (after I'd spent several hours trying (and failing) to get a simple libusb program to turn off the bright white led on my Seagate FreeAgent external drive!).
I've also used the OSX IOKit framework to write a simple app to transfer photos. That worked, but it requires extensive delving into the Objective-C libraries to do anything like PTP and so far I've resisted making the effort to get to grips with that. I guess I'll either have to bite the bullet or live with Windows.
I don't know if this has been solved, I haven't finished reading the thread, but I know that you can make a "fake" kernel extension stub to override this behavior... I had done this before for some other devices, and I also know that the libomron (http://qdot.github.com/libomron/ (http://qdot.github.com/libomron/)) project did a similar thing. Look in the platform directory in the source tree.
Hope this helps, I'd like to see this available on OSX. I may even give it a look when I actually can finish the projects I'm in the middle of. LoL
-
Hi, I want to use chdkptp to take a photo with two connected cameras at the same time. Is that possible?
If I run two commands in immediate sequence then only one of them is triggered. Example:
C:\chdkptp -n -c"A480" -e"luar shoot()"
C:\chdkptp -n -c"A495" -e"luar shoot()"
The problem is, I suspect, that the second process is aborted because it detects that chdkptp is still running because the first photo takes almost two seconds to complete.
I tried making a copy of the chdkptp folder so that two different processes are started. But that didn't help.
Any suggestions on how to solve this? If I add a two second delay then the first photo has time to complete. But as I said I want shots at the same time, or at least no more than half a second apart.
-
Reyalp can answer that but for now see this :-
http://trac.assembla.com/chdkptp/browser/trunk/lua/multicam.lua (http://trac.assembla.com/chdkptp/browser/trunk/lua/multicam.lua)
-
Thanks. Works if I run all the commands in that file one by one. This may be a silly question but, how do I run the multicam.lua i.e. is there a single command line argument that does all the steps listed in the usage instruction in multicam.lua?
edit: never mind, got it.
chdkptp -n -e"!mc=require('multicam')" -e"!mc:connect()" -e"!mc:start()" -e"!return mc:cmdwait('rec')" -e"!return mc:cmdwait('preshoot')" -e"!return mc:cmdwait('shoot')" -e"!return mc:cmdwait('play')" -e"!mc:cmd('exit')"
-
I don't use CHDK or Lua, so what happens when you run your command ?
-
The combined command I pasted does these things on two (or more I guess) connected CHDK-cameras: activates photo mode, autofocuses the camera, takes a photo and then shows the photo on the camera display. Nice! :)
But I'd also like to download photos from the cameras in parallell. I see no command for that in multicam.lua . Does anyone know another way to do that?
-
The combined command I pasted does these things on two (or more I guess) connected CHDK-cameras: activates photo mode, autofocuses the camera, takes a photo and then shows the photo on the camera display. Nice! :)
Please be aware that multicam is quite unfinished at this point. Of course you are welcome to use it, but some hacking might be required to get all the functionality you want.
But I'd also like to download photos from the cameras in parallell. I see no command for that in multicam.lua . Does anyone know another way to do that?
Not implemented yet in multicam. It should be pretty straightforward, just iterate over the cameras like the other multicam functions and call one of the download functions. This is on my list of things to do.
If you use con:mdownload(), you will need to exit and restart the camera side multicam script,eg.
mc:cmd('exit')
-- download stuff here...
mc:start()
If you use the low level con:download(), you could leave the script running, but it doesn't support pattern matching, multiple files, or preserving timestamps.
Rather than passing loads of -e commands, you would write your own lua file, and then do something like
chdkptp -e"!dofile('myfile.lua')"
Or add your own function to multicam, mc:testshots may be a useful example.
I haven't tested, but I suspect the reason multiple independent processes don't work is because
1) Connect by model name or serial number requires making a connection to obtain the info
2) Obtaining a connection requires kicking off anything else that already has a connection
If you connect by product id, (-p=<pid>) it might work. Bus/device should also work, but beware they do not correspond to the physical interface the camera is connected on. The numbers are assigned by libusb and can change across camera resets, reconnects etc. even if the physical connection is never unplugged or moved.
-
If you connect by product id, (-p=<pid>) it might work.
Confirmed working, thank you!
-
I have another issue. On cameras manufactured prior to 2011 you have to use two partitions to be able to use a large SD card. But then the chdkptp command "mdl" (download multiple files) throws a memory error when trying to downloading a large enough number of files. I could download up to around 80 photos without problems. (photo size ~1.7 megabyte.) Above that I get this error message:
ERROR: :231: not enough memory
rlib msg_batcher:18
I tested the same commands on a newer camera and could download 235 files from it without problem (I didn't test above 235).
Is that a know bug? Any known fix?
I can download more than 80 photos from the same camera using ptpCamGui.exe . That's why I suspect the problem is specific to chdkptp or at least the mdl command.
-
I have another issue. On cameras manufactured prior to 2011 you have to use two partitions to be able to use a large SD card. But then the chdkptp command "mdl" (download multiple files) throws a memory error when trying to downloading a large enough number of files. I could download up to around 80 photos without problems. (photo size ~1.7 megabyte.) Above that I get this error message:
ERROR: :231: not enough memory
rlib msg_batcher:18I tested the same commands on a newer camera and could download 235 files from it without problem (I didn't test above 235).
Thanks for the report.
This has nothing to do with multiple partitions, or the size of the photos. It means the lua script on the camera is running out of heap, which is related to the amount of free memory on the camera and the number of photos. There is a bug for this http://www.assembla.com/spaces/chdkptp/tickets/50 (http://www.assembla.com/spaces/chdkptp/tickets/50)
Unfortunately, architectural issues in the CHDK script system make this difficult to handle correctly.
You may be able to work around this by adjusting the batch size. In lua/rlibs.lua try changing line 654
batchsize=20,
to something smaller. I'd try 10 to start with. This will make the downloads slower.
-
Thanks. I did some testing (average photo size 1.7 Mb ).
batchsize 10:
80 photos = downloads ok
160 = also ok
320 = memory error
batchsize 5:
320 = memory error
batchsize 2:
320 = some other error (I think it only said "mdl failed" or something similar)
batchsize 4:
320 = ok
I notice no big difference in download speed between the default 20 and 4. Are there any other drawbacks to having a lower batchsize value? If it affects (slows down) other commands then I could use a special copy of chdkptp with lower batchsize only for downloading.
-
I'm not sure whether this is a question for this thread or for the SX40HS porting thread.
I connected my new SX40HS to my dockstar device, as I had previously done for my A590IS. I'm using chdkptp compiled as of February 19. I am able to take shots with "lua shoot()", but zooming with "lua set_zoom(3)" had no effect. No zoom setting appeared to have any effect.
Do I have the right zoom command, or is this likely to be an issue with the chdk firmware on the camera (firmware from March 31)?
-
Thanks. I did some testing (average photo size 1.7 Mb ).
Again, the size of the photos is irrelevant. The actual transmission is done in chunks whose size is based on free RAM. Where you are running out is the code that builds the list of files and returns it to the PC.
Unfortunately, the current CHDK code for dealing with directories must list the entire directory, rather than reading each file name in turn and processing it, so the number of files will always have an impact.
Memory must be quite low on this camera to be running into this problem, can you post the output of
!return con:execwait('return get_meminfo()')
You can use CHDKshell to build a copy of CHDK that has some optional features turned off to get more free memory. Using the (unstable) trunk version should also give you quite a bit more free memory.
If you are running out of memory with a batchsize of 5, you are probably quite close to the limit and risk failing in other situations too. Or something else is going wrong...
I notice no big difference in download speed between the default 20 and 4. Are there any other drawbacks to having a lower batchsize value? If it affects (slows down) other commands then I could use a special copy of chdkptp with lower batchsize only for downloading.
No, there should be no other impact. I've optimized the chdkptp message wait functions since I implemented batching so maybe it isn't so important now. Anyway, the change I gave you only affects the multi-file operations (mdownload and mdelete).
-
I connected my new SX40HS to my dockstar device, as I had previously done for my A590IS. I'm using chdkptp compiled as of February 19. I am able to take shots with "lua shoot()", but zooming with "lua set_zoom(3)" had no effect. No zoom setting appeared to have any effect.
Do I have the right zoom command, or is this likely to be an issue with the chdk firmware on the camera (firmware from March 31)?
Very unlikely this is a chdkptp issue. If the function works on one camera, it should generally work on the others.
As an alternative, you can use a script that clicks or holds zoom_in and zoom_out. Unfortunately, in my experience the zoom position propcase doesn't update until your release the key, so you can't use the obvious approach of pressing the key, sleeping until the desired position is reached, and releasing. For a camera with lots of zoom steps like the sx40, clicking the key over and over will be very slow.
-
Again, the size of the photos is irrelevant. The actual transmission is done in chunks whose size is based on free RAM. Where you are running out is the code that builds the list of files and returns it to the PC.
Unfortunately, the current CHDK code for dealing with directories must list the entire directory, rather than reading each file name in turn and processing it, so the number of files will always have an impact.
So, is it the listing itself that causes the memory error rather than the transfer of files? (Sorry if I'm asking obvious questions, still have much to learn about how CHDK works)
This command
!return con:execwait('return get_meminfo()')
gives this output - I'm not sure if it is bad or really bad or something else :D
chdk_start=1216832,
name="system",
chdk_size=273536,
free_block_max_size=180128,
chdk_malloc=true,It is a PowerShot A490 camera.
You can use CHDKshell to build a copy of CHDK that has some optional features turned off to get more free memory. Using the (unstable) trunk version should also give you quite a bit more free memory.
Thanks, I'll look into both suggestions.
-
So, is it the listing itself that causes the memory error rather than the transfer of files?
Yes, listing the files and running the code to figure out what to download. There are various quirks in the implementation that amplify this problem.
free_block_max_size=180128,
It is a PowerShot A490 camera.
That means you have about 180kb free. That might sound like it should be plenty to list a few hundred files, but the Canon system can use more of that depending what it is doing, and the script is inefficient for various reasons. 180k is definitely on the low side. http://chdk.wikia.com/wiki/CHDK/Camera_RAM_memory_usage (http://chdk.wikia.com/wiki/CHDK/Camera_RAM_memory_usage) has some information
-
If someone is interested here is a version for the A530 100a, tested and works well.
I have a version for A1100 100c, but I do not have a camera, I do not know if it works, if someone wants to test let me know.
-
A follow up on the memory issue. I did another test with a borrowed camera that had free_block_max_size=328k . It began downloading ~300 photos but aborted after saving ~160 photos. I didn't catch any error message. Could it also be due to low memory? Or are there any other known issues with the mdl command in chdkptp? Again, ptpCamGui.exe could downloaded all the images so I think it is an issue with chdkptp.
-
Again, ptpCamGui.exe could downloaded all the images so I think it is an issue with chdkptp.
Not really. It's a PTP/Lua/memory issue.
ptpCamGui uses a different method. The number of possible images will be collected in a text list and sent to the GUI. The GUI sends for every image a single Lua download command. This method is very slow but safe.
chdkptp works fast and directly. With the GUI of chdkptp we have a nice file browser. The amount of data to be processed can be critical. This is at first a camera issue.
msl
-
A follow up on the memory issue. I did another test with a borrowed camera that had free_block_max_size=328k . It began downloading ~300 photos but aborted after saving ~160 photos. I didn't catch any error message.
Without knowing what failed, it's impossible to say. A memory issue seems likely, but of course there could be other bugs too.
I haven't done a lot of testing with large numbers of files.
I have some ideas for improving the memory situation, I'll try to look into it when I get some time. If someone else wants to play with it here are some of the issues:
1) The listing process gathers information about the files (path, stat information) and collects them into an array. When the array reaches batch_size, the whole thing is serialized and turned into a message. You could monitor free memory (with get_meminfo), and force a batch to be sent earlier if it was low.
2) The message is queued in the PTP code until the PC side fetches it. The script will keep running and adding to the queue until it fills up (16 items) so a lot of memory can be used by stuff waiting in the queue. It would make more sense to send fewer, larger messages, but the message API doesn't make this easy to do. Some testing would be required to see if the queue actually fills up under normal usage. If so, it might make sense to force a sleep at some point (or make it a batcher option). Or improve the message API somehow.
3) Although lua has automatic garbage collection, it's still possible to run out of memory due to uncollected garbage, because the lua memory system doesn't know how much system memory is available. You can use collectgarbage to query memory usage or force collection. You can use get_meminfo to find out how much system memory is available.
4) The serialize function currently generates a LOT of garbage. In lua, each string is a unique value. So if you build a string piecewise by something like
while cond do
foo = foo.."bar"
end
Every intermediate version becomes a lua string, which immediately becomes unreferenced, but might not be collected right away. Re-writing serialize to put all the parts in an array and join them once at the end would probably be a lot more memory friendly.
5) os.listdir lists all the files in a directory into a table, so anything that uses it inevitably uses more memory as the number of files goes up. Implementing a proper directory iterator function (like in lfs.dir() on the PC side) on the camera would solve this.
6) While improving efficiency would be good, it would be better to detect low memory and avoid failing.
-
New snapshot build r248 uploaded. This is mostly under the hood live protocol changes. You will need to use the latest chdk code from my branch to use live view.
Unless something jumps out has horribly broken in the protocol, I'll probably be moving it over to the trunk fairly soon.
-
Looks good on the A590, except impossibility to stop recording video, the camera does not respond to anything but the GUI reports: ERROR: the script is alredy running
-
Thanks for your work on the live view stuff.
I have made few quick tests. A720 works fine. With the SX220 we have some problems.
1.
Compiler error message because of a double definition;
http://trac.assembla.com/chdk/browser/branches/reyalp-ptp-live/platform/sx220hs/sub/101a/stubs_entry.S#L52 (http://trac.assembla.com/chdk/browser/branches/reyalp-ptp-live/platform/sx220hs/sub/101a/stubs_entry.S#L52)
http://trac.assembla.com/chdk/browser/branches/reyalp-ptp-live/platform/sx220hs/sub/101a/stubs_min.S#L5 (http://trac.assembla.com/chdk/browser/branches/reyalp-ptp-live/platform/sx220hs/sub/101a/stubs_min.S#L5)
I have only checked the SX220 1.01a on this issue. In trunk we haven't this problem.
2.
4:3 live view works not completely - see screenshot. 16:9 works fine.
msl
-
Looks good on the A590, except impossibility to stop recording video, the camera does not respond to anything but the GUI reports: ERROR: the script is alredy running
This means that whatever you used to start recording video is still running. Probably you used the "shoot" button, which calls shoot(), which is not appropriate for starting video because it tries to wait for still image capture to complete. If you did click('shoot_full') instead, that should work.
Note the previous version might have seemed to work, but it would actually risk some nasty memory corruption since the previous shoot() wasn't ended cleanly.
This is something that needs further thought on the control side. I guess the script called for the shoot button could detect if in a video mode, and do the right thing.
@msl
Thanks for testing. I'll take a look at those a bit later.
-
4:3 live view works not completely - see screenshot. 16:9 works fine.
This may be fixed with changeset 1875
edit:
or maybe 1877...
edit:
chdkptp r249 now checks if the camera is in video mode and uses click('shoot_full') instead of shoot.
-
It is interesting that the digital zoom works well up to x8.2, then remains fixed the lower part of the picture, which increases along with increasing zoom.
Towards the enhancement of the x13 image appears in the upper left corner where it continues to increase.
edit:
chdkptp r249 now checks if the camera is in video mode and uses click('shoot_full') instead of shoot.
;)
-
Refresh for sx200is, together with EXMEM support and custom palette.
Should "print" call CHDK menu?
I have Canon print menu in playback and nothing in record modes.
Would it be possible to implement zoom slider?
-
4:3 live view works not completely - see screenshot. 16:9 works fine.
This may be fixed with changeset 1875
edit:
or maybe 1877...
Yes, in record mode is all fine.
In playback mode it work not quite correct. The first screenshot shows a 4:3 image. But it seems to display as 1:1. The second screenshot shows the same image with one step zoom in. In this case the camera switches to 16:9, but chdk ptp to 4:3.
msl
-
Refresh for sx200is, together with EXMEM support and custom palette.
Should "print" call CHDK menu?
I have Canon print menu in playback and nothing in record modes.
Would it be possible to implement zoom slider?
If you have a proper firmware dump for the SX200 can you upload to a file share and post a link here.
Phil.
-
It is interesting that the digital zoom works well up to x8.2, then remains fixed the lower part of the picture, which increases along with increasing zoom.
This is expected, the display width/height variables from the canon firmware aren't being used. see #if 0 section in platform/sub/lib.c
I'll try to fix these up later. You can look at D10 for an example. You probably don't need to implement the stitch stuff.
Refresh for sx200is, together with EXMEM support and custom palette.
Please make fixes that aren't specific to live view (exmem, palette etc) as patches to the trunk or release branch. When those are applied I can merge them into the live view. If live view stuff is mixed up with other stuff that goes into the trunk separately, it will make the final live view merge difficult.
-
This is expected, the display width/height variables from the canon firmware aren't being used. see #if 0 section in platform/sub/lib.c
I'll try to fix these up later. You can look at D10 for an example. You probably don't need to implement the stitch stuff.
Thanks, I'll do it today
-
If you have a proper firmware dump for the SX200 can you upload to a file share and post a link here.
https://skydrive.live.com/redir?resid=67C21A0ED1F7A310!161&authkey=!ACChwRvupSTR7Uo (https://skydrive.live.com/redir?resid=67C21A0ED1F7A310!161&authkey=!ACChwRvupSTR7Uo)
Please make fixes that aren't specific to live view (exmem, palette etc) as patches to the trunk or release branch. When those are applied I can merge them into the live view. If live view stuff is mixed up with other stuff that goes into the trunk separately, it will make the final live view merge difficult.
OK, I'll wait for my updates applied to trunk (they are in the cue), then repost patch.
-
In playback mode it work not quite correct. The first screenshot shows a 4:3 image. But it seems to display as 1:1. The second screenshot shows the same image with one step zoom in. In this case the camera switches to 16:9, but chdk ptp to 4:3.
Can you check if this depends on the last setting in record mode ?
For example, if you switch to record, change to 16:9 and then switch back to play, is it different ?
-
Can you check if this depends on the last setting in record mode ? For example, if you switch to record, change to 16:9 and then switch back to play, is it different ?
Yes, there are different dependencies. I have tested with a 4:3 and a 16:9 image.
record mode = 4:3 -> playback mode: 4:3 image = (1:1 picture + black area on left side = 4:3 displaying) ; 16:9 image = 4:3 displaying
record mode = 16:9 -> playback mode: 4:3 image = 4:3 displaying; 16:9 image = 16:9 displaying
Also 3:2 and 1:1 aspect ratio have generated a wrong displaying in playback mode.
3:2 generates a 3:2 displaying. 1:1 generates a 1:1 displaying. The 4:3 picture has the same black area as on screenshot on left the side.
msl
-
Yes, there are different dependencies. I have tested with a 4:3 and a 16:9 image.
Great, thanks. I've checked in a test fix for sx220hs in the reyalp-ptp-live branch.
-
sx200is_100c, revisison 1897.
Stitch mode is wrong (should be offsetted), I'll do it later.
-
I've checked in a test fix for sx220hs in the reyalp-ptp-live branch.
Thanks. Now is all fine. I think, we can do the same for the SX230. And it's time for moving to the trunk. :)
ADamb has right. The stitch mode needs a Y-offset for centered displaying. But this is more an advanced improvement.
msl
-
Thanks. Now is all fine. I think, we can do the same for the SX230. And it's time for moving to the trunk. :)
Yes, getting there.
ADamb has right. The stitch mode needs a Y-offset for centered displaying. But this is more an advanced improvement.
Yes. I don't actually want to implement stitch support etc yet on all the cameras. I think a lot of this can be generic, rather than having the same mess of ifs in every camera. As long as the protocol supports the necessary parameters (which I think it does now), we can fix up the individual cameras over time. The main point of adding stitch support was to make sure we can support other weird offset cases.
For stitch, you can't see the previous image (if anyone knows how that's displayed, let me know), and if you wanted to do pans over PTP, you could make a super-stitch mode in the client that showed you the whole screen from the previous shot instead of a tiny window.
-
It is interesting that the digital zoom works well up to x8.2, then remains fixed the lower part of the picture, which increases along with increasing zoom.
Towards the enhancement of the x13 image appears in the upper left corner where it continues to increase.
In changeset 1912, i've made a590 get the actual viewport sizes from the camera in rec mode. The stitch offset is not implemented, so it will probably appear in the upper left.
-
It works well, increased x13 and x16 live view is half size.
-
Can anyone build the firmware for a459-100f and provide me a link ? I tried getting the arm compiler setup, but ran into issues. Would be easier if you can help me get the build.
I want to try the live view dumps, and show them as a preview for a photobooth.
-
Can anyone build the firmware for a459-100f and provide me a link ?
No problem - except that there is no a459 camera. Guessing its a typo and you meant for the A495, here's the most recent build for firmware 1.00F from the reyalp branch : https://www.box.com/s/90ad0d294ee01a7a801e (https://www.box.com/s/90ad0d294ee01a7a801e)
-
While its a little early to declare victory, today I succeeded in getting chdkptp to compile natively and run on a Raspberry Pi (http://www.raspberrypi.org/) connected via USB to my G10. Or at least I got the CLI part working.
I tried both the Debian and Arch version of Linux for the Pi. The Arch distro was easier to get setup but it throws a Segment Error when connecting via USB to a camera. The Debian version took a lot more work to find all the right packages and dev libraries but it runs without crashing.
LiveView, here we come ! (or maybe not ...)
-
No problem - except that there is no a459 camera. Guessing its a typo and you meant for the A495, here's the most recent build for firmware 1.00F from the reyalp branch : https://www.box.com/s/90ad0d294ee01a7a801e (https://www.box.com/s/90ad0d294ee01a7a801e)
Thank you! I did not proof read before hitting submit. It was indeed for a495. I'll try and post my results to the thread.
-
Uploaded a build for raspberry pi to http://www.assembla.com/spaces/chdkptp/documents (http://www.assembla.com/spaces/chdkptp/documents)
This was built on the wheezy beta from here http://www.raspberrypi.org/archives/1435 (http://www.raspberrypi.org/archives/1435) - may or may not work on other distros.
Here's the steps I used to build it:
installed the following packages
liblua5.1-0-dev
libusb-dev
subversion (not required, used to check out the source but you can download it some other way)
zip (only needed for making the zipped binary snapshot package)
checked out the chdkptp source
$ svn co https://tools.assembla.com/svn/chdkptp/trunk (https://tools.assembla.com/svn/chdkptp/trunk) chdkptp
create chdk/core inside the chdkptp directory, and copy ptp.h and live_view.h from the chdk trunk into it
$ cp config-sample-linux.mk config.mk
edit config.mk, changing
CHDK_SRC_DIR=/path/to/chdk/source
to
CHDK_SRC_DIR=chdk
$ make
$ cp chdkptp-sample.sh chdkptp.sh,
edit chdkptp.sh, change CHDKPTP_DIR to /home/pi/chdkptp
The resulting build doesn't have gui, and for some reason needs to be run as root to access the cam. Seems to work though.
-
and for some reason needs to be run as root to access the cam.
I did not need to be root to use the version I build on a "squeeze" image.
-
I am trying to run chdkptp.exe on Windows 7/64-bit with my A590IS-101b.
The program runs fine but when I try to do anything
I get one of these errors:
update mode dropdown nil
error: no devices availableupdate mode dropdown nil
ERROR: not connected
I have libusb installed and ptpCamGui2.0.121 running and working without a problem.
Am I missing something?
-
error: no devices available
This is the only message that matters. chdkptp isn't seeing any cameras. I use win7 64bit as my primary development platform, so it's not an OS issue.
CHDKPTP should be able to see any device ptpcam can see. It might not see it if the camera is in use by another program.
There are two ways to install the USB driver: The "inf driver" and "filter driver". I found the filter driver very unreliable. The inf driver works great, but means non-libusb programs will generally not see the camera.
-
Am I missing something
A stupid question, did you pushed the connect button?
msl
-
Hi guys,
I re-installed libusb + a reboot (no needed but did it anyway). And that did it!
I like chdkptp's clean to the point compact UI.
Love the "Live" tab! :) Any way to use my A590IS as a webcam now?
Great job reyalp!
-
Love the "Live" tab! :) Any way to use my A590IS as a webcam now?
There are some programs that let you use any window or area of a screen as a web cam. See this post
http://chdk.setepontos.com/index.php?topic=5691.msg75779#msg75779 (http://chdk.setepontos.com/index.php?topic=5691.msg75779#msg75779)
I got SCFH-DSF at least partially working, but it just crashed skype when I tried to use it. I didn't try any other software.
If someone knows a of a free library that lets you feed a stream of images into a virtual webcam device under windows, please let me know. I guess the SCFH-DSF code could be hacked to do this.
It looks like video4linux has some loopback drivers, so doing this on linux might actually be easier.
Or you could just go out and buy a $20 webcam with much higher resolution* ;) That said, being able to feed the live view to standard streaming software could have some interesting applications.
* and much crummier optics.
-
>Or you could just go out and buy a $20 webcam with much higher resolution
Yep, they're cheap now.
I don't want to burn out my A590's CCD :)
-
A follow up on the memory issue. I did another test with a borrowed camera that had free_block_max_size=328k . It began downloading ~300 photos but aborted after saving ~160 photos. I didn't catch any error message. Could it also be due to low memory? Or are there any other known issues with the mdl command in chdkptp? Again, ptpCamGui.exe could downloaded all the images so I think it is an issue with chdkptp.
This is probably fixed in trunk 1950 / release 1951
edit:
On further reflection, this is probably not true since the memory leak only affected PC->Camera messages, which are not really used in the download process.
-
I just d/l'd chdkptp-r248-win32
to control my SD1100IS running the latest CHDK
and it gave me a message stating:
WARNING: camera live view protocol not supported by this client, live view disabled.
Is that specific to my camera,or for all cameras under the windows version of the s/w? or am I doing something wrong.? Is there a different s/w that woudl give live view and remote shutter release for multiple cameras?
thx
Here 's the error message I get:
update mode dropdown nil
error: a script is already runningupdate mode dropdown nil
WARNING: camera live view protocol not supported by this client, live view disabledERROR: a script is already running
ERROR: a script is already running
update mode dropdown nil
error: a script is already runningupdate mode dropdown nil
WARNING: camera live view protocol not supported by this client, live view disabledERROR: a script is already running
update mode dropdown nil
branchopen_cb 0populate branch 0 A/ERROR: a script is already running
ERROR: a script is already running
ERROR: a script is already running
ERROR: a script is already running
-
I just d/l'd chdkptp-r248-win32
to control my SD1100IS running the latest CHDK
and it gave me a message stating:
WARNING: camera live view protocol not supported by this client, live view disabled.
In order to use the live view extension, you need to run the unstable trunk version of chdk, from here: http://mighty-hoernsche.de/trunk/ (http://mighty-hoernsche.de/trunk/)
Is there a different s/w that woudl give live view and remote shutter release for multiple cameras?
The GUI currently only supports controlling one camera at a time. The underlying API does support multiple simultaneous connections.
There are currently no other clients that support the live view protocol.
-
where woudl I find the non-gui version
I could use that for the dual cam live view
and then use USB trigger(s) to snap photos?
-
where woudl I find the non-gui version
There is no separate non-gui version, if you start chdkptp with -c (or any command line option other than -g) it starts in command line mode. I suggest you read http://trac.assembla.com/chdkptp/browser/trunk/USAGE.TXT (http://trac.assembla.com/chdkptp/browser/trunk/USAGE.TXT)
However, as I said multiple cameras are currently only supported in the API. That means you'll need some Lua code to control them. There is a module called multicam included with chdkptp, which provides some functions for this, but it's quite experimental and unfinished.
I could use that for the dual cam live view
I don't understand how you expect to do live view without a GUI ? You can retrieve the data using the lua API, but you'd need to write code to display it. You could use the cameras hardware video out and video grabber I guess...
As an alternative, if you don't need the shots to happen at exactly the same time, you could run two instances of the gui. To do this you'll need connect in way that specifies each camera without having to establish a connection. This can be problematic if they are the same model. See the "connect" command in the above linked USAGE.TXT. The best way to do this is probably to open one instance, use the list command to get the dev/bus IDs and then connect using those. Connecting by name or serial number will not work, because you must establish a connection to get those, and that will disrupt the other instance.
-
I just d/l'd chdkptp-r248-win32
to control my SD1100IS running the latest CHDK
and it gave me a message stating:
WARNING: camera live view protocol not supported by this client, live view disabled.
In order to use the live view extension, you need to run the unstable trunk version of chdk, from here: http://mighty-hoernsche.de/trunk/ (http://mighty-hoernsche.de/trunk/)
Thanks, I d/l'd the unstable trunk version of chdk that you referenced. Now the program works (e.g. shutter release, etc). However it still gives the same error message that the live view is not supported.
thx
-
Thanks, I d/l'd the unstable trunk version of chdk that you referenced. Now the program works (e.g. shutter release, etc). However it still gives the same error message that the live view is not supported.
thx
Either you aren't using the correct version of chdkptp, or you aren't using the current trunk. You should be using the r248 build of chdkptp from http://www.assembla.com/spaces/chdkptp/documents (http://www.assembla.com/spaces/chdkptp/documents)
edit:
typo corrected, thanks Microfunguy :D
-
You should be suing the r248 build of chdkptp
Quite right !
Sue them for every penny they have got :)
-
Uploaded snapshot r272 to http://www.assembla.com/spaces/chdkptp/documents (http://www.assembla.com/spaces/chdkptp/documents)
See http://www.assembla.com/spaces/chdkptp/wiki/Changelog (http://www.assembla.com/spaces/chdkptp/wiki/Changelog) for details. This includes the file / message size upload fix related from http://chdk.setepontos.com/index.php?topic=4338.msg87348#msg87348 (http://chdk.setepontos.com/index.php?topic=4338.msg87348#msg87348) so upgrading is recommended.
-
Greetz everyone,
For the past few weeks I have been developing software to automatically find chromaticity deviations in strips of LEDs. I've written some software in Ada to read the Bayer Filter .CRW dumps, and a perl script to connect the chdkptp interface to a set of buttons and indicator lights via my computers parallel port.
The one problem I have not been able to overcome is shooting RAW over the chdkptp interface. Here is the basic setup:
Canon PowerShot A570 running CHDK release_1 SUB101a, with "save RAW" selected and all other settings default.
chdkptp -c -i: Interactive shell successfully opened.
=switch_mode_usb(1): Camera transitions to capture mode.
=shoot(): Camera takes picture, crashes, and dies seemingly right after the .CRW has been saved to disk.
The chdkptp interface is thrown an unexpected return code: 0x2fd
After dumping the ROM log I find an ASSERT at FsIoNotify.c line 292.
After turning the camera back on I can find the XXX.CRW file on disk and of the correct size.
The A570 has the smallest amount of free RAM out of any other supported cameras and at first I assumed this was a problem, but after loading CHDK into extended memory I had the same results. The most interesting part here is that if I enable DNG format and have the camera convert the RAW dump to DNG right on board the camera no longer crashes and everything goes as expected. I don't know how to explain this last observation with DNG.
I'll be publishing my libraries and source at the end of this project, any help would be greatly appreciated.
-Mike
ROM Dump:
ASSERT!! FsIoNotify.c Line 292
Occured Time 2007:01:27 00:52:32
TCB: 00151574
Task: tFsIoNotif
SP: 0x001511FC
StackDump:
0x00000000
0x37303032
0x3A31303A
0x30203732
0x32353A30
0x0032333A
0xFFE47248
0x00000005
0x00000000
0x00000000
0x001512E4
0xFFF17BE0
0x00000007
0x00151340
0xFFECA848
0x00000000
0xFFE47560
0x00000000
0x00000005
0x00000061
0x001512C4
0x00000000
0xFFE46BC4
0x001512E4
0x00144F94
0xFFE491C8
0x00151348
0x001512E4
0xFFE2F764
0x00000000
0x00000005
0xFFEFA05C
ShootConDump:
01 02 07 08 09 0f 0f 0f 0f 0f
CameraConDump:
08 0b 02 0e 0a 01 0f 0f 0f 0f
00260650: LogicalEvent:0x112c:adr:0x0,Para:0
00260650: SSAPI::GetMFBarData
00260660: DSIC:f,0
00260670: EXPLockCon_Start
00260680: DSIC:c,0
00260690: Window:EffectiveLockPhysicalScreen
00260690: Window:IneffectiveLockPhysicalScreen
00260690: LogicalEvent:0x3135:adr:0x0,Para:0
00260690: _ManagePTMProperty
00260710: DSIC:e,0
00260730: DSIC:e,0
00260750: SSAPI::CaptureModeChange
00260750: SSAPI:: EvfMode = 2
00260750: SSAPI:: CaptMode = 0x8001
00260760: SSAPI::CompleteCaptureModeChange
00260760: _DecideCaptureMode
00260760: _StartStill
00260770: SSAPI:: UsingRaw[0]
00260770: DSIC:b0,3
00260780: DSIC:b2,1
00260780: DSIC:41,6
00260820: Window:IneffectiveLockPhysicalScreen
00260820: _MuteOffStitch
00260820: TerminateDeliverToZoomController
00260830: DSIC:e,0
00260830: OPTICAL_ZOOM_MIN_POS
00260840: ST_OPTICAL_WIDE_TERM
00260840: UnpressZoomLever
00260840: DispSwCon_TurnOnDisplayDevice
00260840: LogicalEvent:0x313d:adr:0x0,Para:0
00260840: _EntryStartRecMode
00260840: CaptModeChanger_CheckRTCRrepared
00260840: DispSw: Unlock
00260840: DispSwCon_MuteOffPhysicalScreen
00260840: MuteOffPhysicalScreen
00260840: _DecideModeDial
00260850: LogiEvnt_NotPowerType:0x09a4:adr:0x0,Para:0
00260850: LogiEvnt_NotPowerType:0x09a2:adr:0x0,Para:0
00265800: PressSwOne
00265800: SSAPI:: UsingRaw[0]
00265800: ShootState:0x1
00265800: ShtCon_Activate
00265800: ShtCon_PrepareCapture
00265800: DispSw: Lock
00265800: DSIC:61,0
00265800: DSIC:e,0
00265810: DispSwCon_TurnOffDisplayDevice
00265810: DispSwCon_TurnOffBackLight
00265810: TurnOffBackLight
00265810: TurnOffDisplay
00265900: Window:EffectiveLockPhysicalScreen
00265900: Window:IneffectiveLockPhysicalScreen
00265900: LogicalEvent:0x3135:adr:0x0,Para:0
00265900: DSIC:e,0
00265910: SSAPI::PrepareCapture
00265910: ShootState:0x2
00265910: ClearEventComp
00266530: ShootSeqToUI:0x2006:adr:0x25e9b4,Para:2484660
00266530: ShtCon_SetPreCapt
00266530: DSIC:62,0
00266530: Window:EffectiveLockPhysicalScreen
00266530: DispSwCon_TurnOffDisplayDevice
00266540: DispSwCon_TurnOffBackLight
00266540: Window:IneffectiveLockPhysicalScreen
00266550: ShtCon_ResetShtMode
00266550: _EntryPrepareShoot
00266550: ShootState:0x7
00266760: PressSwTwo
00266760: SSAPI:: UsingRaw[0]
00266760: ShootState:0x8
00266760: ShootState:0x9
00266760: DSIC:14,0
00266760: _MuteOn
00266760: DSIC:42,0
00266760: DispSwCon_MuteOnPhysicalScreen
00266760: MuteOnPhysicalScreen
00266760: TurnOnDisplayForStartup
00266760: SSAPI::ShootPicture
00266780: DSIC:63,0
00266800: UnpressSwTwo
00266800: UnpressSwOne
00266810: ShootSeqToUI:0x2022:adr:0x0,Para:0
00266830: DSIC:64,0
-
After dumping the ROM log I find an ASSERT at FsIoNotify.c line 292.
This is a well known problem, put
#define CAM_STARTUP_CRASH_FILE_OPEN_FIX 1
into platform/a570/platform_camera.h
http://chdk.setepontos.com/index.php?topic=6179.0 (http://chdk.setepontos.com/index.php?topic=6179.0)
It will be fixed soon based on your report.
-
Thank you for the quick reply! I will make the edits and give it a shot. In the meantime I patched the procedure for writing DNG files to exclude the DNG header and reversing of the bytes in main.c
-Mike
-
edit July 4 2015: For the most recent instructions see README-RASPI-LIBS.TXT in the chdkptp SVN
I managed to build the gui for raspberry pi. I've uploaded a build to the files area http://www.assembla.com/spaces/chdkptp/documents (http://www.assembla.com/spaces/chdkptp/documents) which includes the gui libs along with chdkptp
This will *only* work on the raspbian distro (or possibly other hard float distros if they exist).
I only tested of remote X (~1 fps) and VNC (~3fps). These were unable to do live view at more than a few frames per second. Local display should be better. If the target framerate is too high, the program will become unresponsive, so you should set it before enabling live view.
Since there was some trial and error and I didn't restart from the beginning with each change, the notes that follow may not be complete.
I did this using the raspbian distro announced here http://www.raspberrypi.org/archives/1605, (http://www.raspberrypi.org/archives/1605,) most of it should apply to building the libs on other Debian based distros, on pi or pc.
Add the following packages (in addition to the ones required to build chdkptp without gui)
libx11-dev
libxpm-dev
libxmu-dev
libxft-dev
libgtk2.0-dev
libgl1-mesa-dev
libwebkitgtk-dev
libglu1-mesa-dev
libncurses5-dev
These are mostly from the list found at http://www.tecgraf.puc-rio.br/iup/en/building.htm (http://www.tecgraf.puc-rio.br/iup/en/building.htm) except
- I left out the motif related ones, since I don't care about motif.
- libglu1-mesa-dev was not mentioned, but is required for GL support.
- libncurses5-dev was not mentioned, but was required for something in iup.
libwebkitgtk-dev may have been a mistake, since I couldn't get the iupweb component to build and ended up commenting it out. From what I could tell, USE_PKGCONFIG=Yes giving the wrong location.
Get and extract the IM, CD and IUP sources:
wget http://sourceforge.net/projects/imtoolkit/files/3.8/Docs%20and%20Sources/im-3.8_Sources.tar.gz (http://sourceforge.net/projects/imtoolkit/files/3.8/Docs%20and%20Sources/im-3.8_Sources.tar.gz)
wget http://sourceforge.net/projects/canvasdraw/files/5.5.1/Docs%20and%20Sources/cd-5.5.1_Sources.tar.gz (http://sourceforge.net/projects/canvasdraw/files/5.5.1/Docs%20and%20Sources/cd-5.5.1_Sources.tar.gz)
wget http://sourceforge.net/projects/iup/files/3.6/Docs%20and%20Sources/iup-3.6_Sources.tar.gz (http://sourceforge.net/projects/iup/files/3.6/Docs%20and%20Sources/iup-3.6_Sources.tar.gz)
tar -xzf im-3.8_Sources.tar.gz
tar -xzf cd-5.5.1_Sources.tar.gz
tar -xzf iup-3.6_Sources.tar.gz
Note, I used the liblua5.1-0-dev package to provide lua. This caused me some problems, it might be better to build lua along with the rest of the libs. In this case, you'd probably also want to link chkdptp with the locally built instead of the debian package.
Now build the libraries in this order IM, CD, IUP
The documentation mentions that you can build individual libraries. However, for IM and CD, it's not immediately clear which are needed to support IUP, so I just tried to build everything, running make in the top level src directory.
To the distro lua package, the following needs to be set
export LUA_SUFFIX=
export LUA_INC=/usr/include/lua5.1
IM built with just
make
CD
needs to be built with
make USE_PKGCONFIG=Yes
to find the correct GTK stuff
IUP
I had multiple problems with this one.
Edit the to level makefile to remove iupweb from do_all
create the following symlink to allow the distro installed lua lib to be found
ln -s /usr/lib/arm-linux-gnueabihf/liblua5.1.a /usr/lib/liblua.a
In srcconsole/Makefile, comment out the @$(TECMAKE_CMD) USE_LUA52=Yes in the iuplua5 target
in the IUP directory
make USE_PKGCONFIG=Yes
Only building the iup libraries actually needed by chdkptp would probably be a smarter approach.
chdkptp doesn't currently use IM, but some of the CD and IUP stuff depends on it. It might be possible to build whats needed for chdkptp without building IM at all.
-
I managed to build the gui for raspberry pi. I've uploaded a build to the files area http://www.assembla.com/spaces/chdkptp/documents (http://www.assembla.com/spaces/chdkptp/documents) which includes the gui libs along with chdkptp
Well, there goes all the spare time I have available in the next week to ten days ....
-
Hi I was messing around with chdkptp code, studying and trying to figure out how everything works. So I was looking to the chdk_get_live_data() function and I was wondering in what kind of image the buf->bytes is written? I know that is not jpg :). Just want to know how to write/deal with this byte array.
Thanks
-
Hi I was messing around with chdkptp code, studying and trying to figure out how everything works. So I was looking to the chdk_get_live_data() function and I was wondering in what kind of image the buf->bytes is written? I know that is not jpg :). Just want to know how to write/deal with this byte array.
This is not a single image, it's a full frame of the live view protocol, described in http://trac.assembla.com/chdk/browser/trunk/core/live_view.h (http://trac.assembla.com/chdk/browser/trunk/core/live_view.h)
It can contain two different kinds of frame buffers (viewport and UI overlay) a palette (for the UI) plus various information required to reproduce the size and positioning of the different elements.
It's important to know that much of the meta data can change from frame to frame, you cannot assume the viewport will have a fixed size or aspect ratio. Generally you should assume that everything except the version can change at any time (although in practice a few other things don't)
The individual frame buffers are the native camera formats, which differ between the viewport and overlay (and the palette format varies between camera models). See http://chdk.wikia.com/wiki/Frame_buffers (http://chdk.wikia.com/wiki/Frame_buffers) for some information.
Example code for decoding this into RGB can be found in http://trac.assembla.com/chdkptp/browser/trunk/liveimg.c (http://trac.assembla.com/chdkptp/browser/trunk/liveimg.c) liveimg_get_viewport_pimg and liveimg_get_bitmap_pimg
Note that this is set up for the CD library, which wants a planar image (R, G, B and possibly A each in their own contiguous buffer).
Note that if you want to work on this without running a real USB connection, chdkptp has the capability to record the data stream from chdk_get_live_data() to a file. The format is simple: the dump file has a small header, then for each frame it contains the length of the following frame data, followed by the data itself. See lua/chdku.lua con_methods:live_dump_start and con_methods:live_dump_frame
-
I wasn't sure if this should go into a separate thread or not - but here goes:
I am a developer of open-source software for controlling microscopes:
www.endrov.net (http://www.endrov.net)
www.micro-manager.org (http://www.micro-manager.org)
There is some interest in being able to use consumer grade cameras instead of the very expensive regular cameras. I wonder if I should build this on chdkptp or not? Can it be used as a library from my C code, or would you agree if we make it such that it can be used both as a library, and a CLI/GUI?
Our requirements are very specific - we want to have a well-performing live view, with the ability to change camera settings now and then. All the storage and processing will be on the computer side. How optimized is the library for this currently e.g. is it possible to download one frame while capturing the next? (is this possible to implement at all otherwise?)
Sorry for the n00bish approach - I don't yet own a canon camera I can play around with
/Johan
-
Interesting project.
There is some interest in being able to use consumer grade cameras instead of the very expensive regular cameras. I wonder if I should build this on chdkptp or not? Can it be used as a library from my C code, or would you agree if we make it such that it can be used both as a library, and a CLI/GUI?
It currently isn't a library, but it has always been my intention split out the PTP code into a one. It's pretty modular already, the C code just provides a low level API and all of the cli and gui code is in Lua. The lua code is broken into modules that provide higher level functions for dealing with the camera, handling the CLI, GUI and so on.
If you only want to use the C code, you might find yourself re-implementing some of the higher level stuff that is done in Lua. However, there's no reason you couldn't build a library that used the lua code, either from external files or included in the binary.
You should be aware that the current code is in a pretty rough state, and I don't have a whole lot of time to work on it. It's functional for the things it does, but there's a lot of stuff that was just thrown together to get something working.
Our requirements are very specific - we want to have a well-performing live view,
This would depend on what you mean by "well performing". There's a few things to consider:
1) Resolution: the camera live view resolution is quite low, generally 240 or 480 lines (width depends how you count it, but you could say 720-960). You can capture and download stills at much higher resolution of course, but lower frame rate.
2) Frame rate: On a modern PC, without spending a lot of effort optimizing, 10 FPS is easy, much over 20 is unlikely. I'm not sure how fast the live view itself updates, I doubt it's over 30 in most cases.
3) Visual artifacts: Transmitting the frames isn't synchronized with viewport updates, so you can get tearing. This might be fixable, with some frame rate cost.
with the ability to change camera settings now and then.
Camera control is done by sending Lua code (or messages to an already running script) to the camera, meaning that all the exposure parameters that normal CHDK scripts can control are available. This gives you pretty complete control over shooting. Camera side scripts can also send arbitrary data to the PC side, so the PC code can get any values that are available to camera side scripts.
All the storage and processing will be on the computer side. How optimized is the library for this currently e.g. is it possible to download one frame while capturing the next? (is this possible to implement at all otherwise?)
I'm not sure exactly what you are asking.
The live view is separate from still image capture. The actual process of shooting a still will briefly disrupt the live view: on many cameras, the full frame raw buffer overlaps the viewport framebuffer, so you will see "snow" in the live view. At a minimum, the live view will not get updated with valid data while shooting is in progress.
Currently, we can't capture stills directly over USB, you'd have to let the still capture process save it on the camera card and then download it. Getting the raw data out of RAM is doable, but would only make sense if you want to work with raw, otherwise you'd be better of letting the camera save a jpeg and then download it as a file. Getting jpeg data from the camera is also probably possible, but would require some reverse engineering.
If you are talking about downloading a still while the next one is capturing, that's probably doable (assuming you are downloading files, probably not if you are getting raw from RAM) I tried running live view at 20 fps (~9 mbyte/sec) while doing some long exposures, and didn't see any problems or significant drop in throughput. I also tried shooting in continuous mode, and surprisingly that didn't seem to hurt anything or affect throughput much either.
The current code is single threaded, so long running USB operations like downloads block the rest of the application. However, having the USB stuff in a separate thread or process should be fine, and is on my TODO list.
-
I managed to build the gui for raspberry pi.
...
Add the following packages (in addition to the ones required to build chdkptp without gui)
FWIW, unlike the Arch and Debian Squeeze Raspberry pi images that needed lots of packages added, the only things I needed to do with raspian were :
>svn co http://subversion.assembla.com/svn/chdkptp chdkptp
>sudo apt-get install libusb-dev
>cd chdkptp/trunk
>cp config-sample-linux.mk config.mk
>mk
-
I managed to build the gui for raspberry pi.
I only tested of remote X (~1 fps) and VNC (~3fps). These were unable to do live view at more than a few frames per second. Local display should be better. If the target framerate is too high, the program will become unresponsive, so you should set it before enabling live view.
Got it to build and run tonight in live view mode on my raspberry pi after the usual struggles getting paths correct.
The live view screen reported a little over 13 fps (with the target FPS control left at the 10 it defaults to).
Very nice !
-
Hi I was messing around with chdkptp code, studying and trying to figure out how everything works. So I was looking to the chdk_get_live_data() function and I was wondering in what kind of image the buf->bytes is written? I know that is not jpg :). Just want to know how to write/deal with this byte array.
This is not a single image, it's a full frame of the live view protocol, described in http://trac.assembla.com/chdk/browser/trunk/core/live_view.h (http://trac.assembla.com/chdk/browser/trunk/core/live_view.h)
It can contain two different kinds of frame buffers (viewport and UI overlay) a palette (for the UI) plus various information required to reproduce the size and positioning of the different elements.
It's important to know that much of the meta data can change from frame to frame, you cannot assume the viewport will have a fixed size or aspect ratio. Generally you should assume that everything except the version can change at any time (although in practice a few other things don't)
The individual frame buffers are the native camera formats, which differ between the viewport and overlay (and the palette format varies between camera models). See http://chdk.wikia.com/wiki/Frame_buffers (http://chdk.wikia.com/wiki/Frame_buffers) for some information.
Example code for decoding this into RGB can be found in http://trac.assembla.com/chdkptp/browser/trunk/liveimg.c (http://trac.assembla.com/chdkptp/browser/trunk/liveimg.c) liveimg_get_viewport_pimg and liveimg_get_bitmap_pimg
Note that this is set up for the CD library, which wants a planar image (R, G, B and possibly A each in their own contiguous buffer).
Note that if you want to work on this without running a real USB connection, chdkptp has the capability to record the data stream from chdk_get_live_data() to a file. The format is simple: the dump file has a small header, then for each frame it contains the length of the following frame data, followed by the data itself. See lua/chdku.lua con_methods:live_dump_start and con_methods:live_dump_frame
Hi reyalp, thank you very very much for this reply, it help a lot and now I'm able to display a live preview of the viewport inside my Qt application.
I would also like to know if someone here had already mapped the properties/values to set on stuff on camera, via lua script with the set_prop(). Like to set flash always on I run set_prop(some number, some value).
Tnx again!
-
I would also like to know if someone here had already mapped the properties/values to set on stuff on camera, via lua script with the set_prop(). Like to set flash always on I run set_prop(some number, some value).
There are two places you can look:
1) The wiki http://chdk.wikia.com/wiki/PropertyCase (http://chdk.wikia.com/wiki/PropertyCase)
2) The propsetN.h files in the chdk source http://trac.assembla.com/chdk/browser/trunk/include (http://trac.assembla.com/chdk/browser/trunk/include) which in turn are available in lua via the propcase module (see http://chdk.wikia.com/wiki/Lua/Lua_Reference#get_prop (http://chdk.wikia.com/wiki/Lua/Lua_Reference#get_prop) )
-
I get segmentation fault after running ./chdkptp-sample.sh -i -c or in gui trying to press connect button:
./chdkptp-sample.sh: line 7: 497 Segmentation fault "$CHDKPTP_DIR/chdkptp" "$@"
./chdkptp-sample.sh: line 7: 678 Segmentation fault "$CHDKPTP_DIR/chdkptp" "$@"
I don't have such problems with older chdkptp version. When I do ./chdkptp-sample -i and then try to check for the version:
___> ver
host:2.3 cam:not connected
Here is my config.mk file:
IUP_SUPPORT=1
CD_SUPPORT=1
LUA_INCLUDE_DIR=/usr/include/
DEBUG=1
IUP_LIB_DIR=/home/streznik/iup
IUP_INCLUDE_DIR=/home/streznik/iup/include
CD_LIB_DIR=/home/streznik/CD
CD_INCLUDE_DIR=/home/streznik/CD/include
And here is my chdkptp-sample.sh file:
#!/bin/sh
# adjust the following to your configuration
CHDKPTP_DIR=/home/streznik/chdkptp/chdkptp/trunk
# only need if you have compiled IUP support and have NOT installed the libraries to system directories
export LD_LIBRARY_PATH=/home/streznik/iup:/home/streznik/CD
export LUA_PATH="$CHDKPTP_DIR/lua/?.lua"
"$CHDKPTP_DIR/chdkptp" "$@"
CD download file: cd-5.5.1_Linux32_lib.tar.gz
iup download file: iup-3.6_Linux32_lib.tar.gz
libusbx 1.0.12-2
OS: Arch linux.
Any ideas what might cause this? With other username on the same box with older ptpcam version I'm able to connect to a camera.
-
I don't have such problems with older chdkptp version.
If you can identify the older version which doesn't have the problem, that may be helpful.
If you can chdkptp under gdb and get a stack trace, that might also be helpful.
Some other users have reported a segfault under the raspberry pi arch distro and gentoo. From the stack trace, the segfault was somewhere deep in the usb code, and I haven't pursued it further yet. Finding out what those distros do different from debian based distros might also help.
-
If you can identify the older version which doesn't have the problem, that may be helpful.
cat ptpcam/svn/trunk/version.inc on older build says: BUILD_NUMBER := 1.1.0
But my chdkptp-sample.sh is located in ptpcam/svn/chdkptp/chdkptp and ./chdkptp-sample.sh -i -c and then ver when in interactive shell: host: 2.3 cam: 2.3
I can not find version.inc on newer build (the one I tried yesterday). Is tere a specific way to tell version of the build and if it is, can you please write it here.
If you can chdkptp under gdb and get a stack trace, that might also be helpful.
How do I start gdb with chdkptp-sample.sh if I start that script like this: ./chdkptp-sample.sh
Thanx for your great work reyalp!
-
cat ptpcam/svn/trunk/version.inc on older build says: BUILD_NUMBER := 1.1.0
But my chdkptp-sample.sh is located in ptpcam/svn/chdkptp/chdkptp and ./chdkptp-sample.sh -i -c and then ver when in interactive shell: host: 2.3 cam: 2.3
I can not find version.inc on newer build (the one I tried yesterday). Is tere a specific way to tell version of the build and if it is, can you please write it here.
What I would want to know is what SVN revisions work/don't work.
You can use svn update with the -r switch to switch to a particular revision. svnversion will tell you what revision(s) a working copy is at. If you want to test previous versions, I would suggest the ones that correspond to snapshot builds listed here http://www.assembla.com/spaces/chdkptp/wiki/Changelog (http://www.assembla.com/spaces/chdkptp/wiki/Changelog)
version.inc is a chdk thing, it has nothing to do with chdkptp. The old build setup instructions included using a copy of the CHDK source for the headers, but copies are now included in chdkptp. The ver command just tells you the protocol versions. In the most recent versions of chdkptp, ver -p will give you a full version, but this won't help you identify older version.
How do I start gdb with chdkptp-sample.sh if I start that script like this: ./chdkptp-sample.sh
You can put the gdb command in the script, with
gdb --args "$CHDKPTP_DIR/chdkptp" "$@"
Once it loads, type 'run' to start chdkptp, and after it crashes, type bt to get a stack trace.
-
Hi reyalp!
I've checked the versions of svn:
Working version cd ~/ptpcam/svn/chdkptp/chdkptp && svnversion
257M
Not working version cd ~/chdkptp/chdkptp/trunk && svnversion
272M
backtrace of crash of not working svn:
$ ./chdkptp-sample.sh -i
GNU gdb (GDB) 7.4.1
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/streznik/chdkptp/chdkptp/trunk/chdkptp...done.
(gdb) run
Starting program: /home/streznik/chdkptp/chdkptp/trunk/chdkptp -i
warning: Could not load shared library symbols for linux-gate.so.1.
Do you need "set solib-search-path" or "set sysroot"?
Traceback (most recent call last):
File "/usr/share/gdb/auto-load/usr/lib/libgobject-2.0.so.0.3200.4-gdb.py", line 9, in <module>
from gobject import register
File "/usr/share/glib-2.0/gdb/gobject.py", line 3, in <module>
import gdb.backtrace
ImportError: No module named backtrace
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/libthread_db.so.1".
___> c
Program received signal SIGSEGV, Segmentation fault.
0xb7d7d9da in usb_bulk_write () from /lib/libusb-0.1.so.4
(gdb) bt
#0 0xb7d7d9da in usb_bulk_write () from /lib/libusb-0.1.so.4
#1 0x0805023e in ptp_write_func (bytes=0x805eb80 "\020", size=16, data=
0x80b81c0) at chdkptp.c:203
#2 0x0804df65 in ptp_usb_sendreq (params=0x80970b4, req=0xbfffedd8)
at ptp.c:116
#3 0x0804e4da in ptp_transaction (params=0x80970b4, ptp=0xbfffedd8, flags=0,
sendlen=0, data=0x0) at ptp.c:325
#4 0x0804e967 in ptp_opensession (params=0x80970b4, session=1) at ptp.c:479
#5 0x080512dd in open_camera_dev (dev=0x80adf90, ptp_usb=0x80b81c0, params=
0x80970b4) at chdkptp.c:669
#6 0x080517a9 in chdk_connect (L=0x80605b0) at chdkptp.c:783
#7 0xb7f48a77 in ?? () from /lib/liblua.so.5.1
#8 0xb7f537ab in ?? () from /lib/liblua.so.5.1
#9 0xb7f48ef8 in ?? () from /lib/liblua.so.5.1
#10 0xb7f43240 in ?? () from /lib/liblua.so.5.1
#11 0xb7f48130 in ?? () from /lib/liblua.so.5.1
#12 0xb7f490cf in ?? () from /lib/liblua.so.5.1
#13 0xb7f44804 in lua_pcall () from /lib/liblua.so.5.1
#14 0xb7f56434 in ?? () from /lib/liblua.so.5.1
#15 0xb7f48a77 in ?? () from /lib/liblua.so.5.1
#16 0xb7f537ab in ?? () from /lib/liblua.so.5.1
#17 0xb7f48ef8 in ?? () from /lib/liblua.so.5.1
#18 0xb7f44757 in lua_call () from /lib/liblua.so.5.1
---Type <return> to continue, or q <return> to quit---
#19 0xb7f5f96a in ?? () from /lib/liblua.so.5.1
#20 0xb7f48a77 in ?? () from /lib/liblua.so.5.1
#21 0xb7f537ab in ?? () from /lib/liblua.so.5.1
#22 0xb7f48ef8 in ?? () from /lib/liblua.so.5.1
#23 0xb7f43240 in ?? () from /lib/liblua.so.5.1
#24 0xb7f48130 in ?? () from /lib/liblua.so.5.1
#25 0xb7f490cf in ?? () from /lib/liblua.so.5.1
#26 0xb7f44804 in lua_pcall () from /lib/liblua.so.5.1
#27 0x08053574 in exec_lua_string (L=0x80605b0, luacode=
0x8058aa9 "require('main')") at chdkptp.c:1614
#28 0x08053645 in main (argc=2, argv=0xbffff6a4) at chdkptp.c:1638
(gdb) quit
A debugging session is active.
Inferior 1 [process 17038] will be killed.
Quit anyway? (y or n) y
Hope it helps?
-
Thanks frojnd, having the SVN revisions is very helpful. The most significant change I see to the PTP code is http://trac.assembla.com/chdkptp/changeset?reponame=&new=258%40trunk&old=257%40trunk (http://trac.assembla.com/chdkptp/changeset?reponame=&new=258%40trunk&old=257%40trunk)
I'll take a closer look at this.
both of your svnversions have "M" at the end, meaning some of the code is modified. If you've modified the actual code, please let me know (you can use svn diff).
edit:
I guess the M is probably just from editing chdkptp-sample.sh (I usually copy it to chdkptp.sh)
-
frojnd:
Can you try this
after the crash in gdb, type
up
This should output a line that looks something like
#1 0x0805023e in ptp_write_func (bytes=0x805eb80 "\020", size=16, data=0x80b81c0) at chdkptp.c:203
Then type
print *ptp_usb
Also (separate from the above) try running chdkptp as root.
On arch/raspberry pi, I get a similar segfault, but only if not running as root. Note I also get this segfault on r257, so it may not be the same.
edit:
As of chdkptp changeset 273 (http://trac.assembla.com/chdkptp/changeset/273/trunk), if you are hitting the the same problem I was having on raspberry pi, it should print an error instead of crashing.
edit:
I think you mentioned that a different user worked ? If a non-root user worked, check if the account was a member of the "camera" group.
-
Summarizing yesterdays observations:
The crash I found was due to permissions not allowing access to the device. This can also happen under debian based distros (see earlier comments on raspbian distro) but it appears that in depending on the distro usb_open returns NULL (arch case, ended up causing a segfault due to poor error checking in chdkptp) or it can succeed with only the later calls failing (raspbian case). All this should apply to ptpcam as well.
In changeset 273, I improved the error checking, so chdkptp should fail gracefully with an access denied error in the arch case.
Next question, why can't we access the USB device ?
It turns out, this is complicated under Linux, and varies depending on distro, version, desktop environment, whether the user is on the local desktop etc, what other ptp related packages are installed etc. Some references:
http://gphoto.org/doc/manual/permissions-usb.html (http://gphoto.org/doc/manual/permissions-usb.html)
https://wiki.archlinux.org/index.php/Digital_Cameras (https://wiki.archlinux.org/index.php/Digital_Cameras)
Note the above refer to gphoto2, but the same will generally apply to chdkptp. If you have gphoto2 installed, then checking whether you can connect to the camera with gphoto2 should be a good test (but note that installing libgphoto2 etc may affect how the camera is handled.)
More details:
udev is generally responsible for dealing with devices like this. In some configuration, udev sets the group on freshly plugged devices (this is the case on my Ubuntu 10.04 laptop). In other cases, something else (consolekit and systemd are mentioned on the arch page) are responsible.
On my arch install was headless and didn't have any of the consolekit stuff, so I attempted to set up a udev rule on arch to set the permissions. This lead me to another oddity:
The device appears on
/dev/usbdevN.M and /dev/bus/usb/N/M
both of these are actual devices, not symlinks. When I set group/mode in a udev rule e.g.:
ATTRS{idVendor}=="04a9", ATTRS{idProduct}=="311b", GROUP="camera", MODE="660"
This is applied the /dev/usbdev* device. However, both chdkptp and gphoto appear to use the /dev/bus/usb* device, so it doesn't solve the problem. Manually chmod'ing does the /dev/bus/usb* one does allow them to work. This should be possible using RUN to execute a shell script in the udev rule. I didn't get to test this yet because for some reason my arch install refuses to boot.
My laptop (again, older ubuntu) only has the /dev/bus/usb* device, and the default udev scripts installed change the group to plugdev and set the mode. chdkptp works out of the box for a normal user in this setup.
If someone knows more about why these different devices are used, I'd like to hear about it.
somewhat old guide to udev rules
http://www.reactivated.net/writing_udev_rules.html (http://www.reactivated.net/writing_udev_rules.html)
Note most of the commands mentioned are now sub-commands of udevadm
If you decide to write your own udev rules, keep in mind that the distros may have default rules which apply to the camera. These may appear in a variety of locations: on arch they appear in /etc/udev/rules.d, /lib/udev/rules.d, and /usr/lib/udev/rules.d
Edit:
for raspbian (Debian wheezy based), adding the following as /etc/udev/rules.d/40-chdkptp.rules allows me to use chdkptp as a standard user
ATTRS{idVendor}=="04a9", ATTRS{idProduct}=="311b", SUBSYSTEMS=="usb", ACTION=="add", MODE="0660", GROUP="plugdev"
311b is the pid, so that's the only thing that should need to change for other cameras.
This appears to set the permissions on both /dev/bus/usb/... and /dev/usbdev1...
-
Reyalp, I posted earlier in the thread ( http://chdk.setepontos.com/index.php?topic=6231.150 (http://chdk.setepontos.com/index.php?topic=6231.150) ) about memory issues for the mdl command on the A490 camera. I didn't solve the problem and have since then been transferring the files manually through a SD card reader in the PC. Today I tried chdkptp-r272-win32. Same problem as before with mdl on the command line. But if I run chdkptp GUI, connect and go to "Files" tab I can download all the images. Does the gui download images in a different way compared to mdl ? Is the new command available on the command line too?
EDIT: my mistake. The memory issue is there also with the GUI. I mixed up results from two test runs.
The current code is single threaded, so long running USB operations like downloads block the rest of the application. However, having the USB stuff in a separate thread or process should be fine, and is on my TODO list.
If I understand the above then if/when that separation is added I guess my download problems can be solved another way instead - by downloading the image to a PC (and deleting it from the camera) immediately after the shot, while shooting the next image.
-
Reyalp, I posted earlier in the thread ( http://chdk.setepontos.com/index.php?topic=6231.150 (http://chdk.setepontos.com/index.php?topic=6231.150) ) about memory issues for the mdl command on the A490 camera.
What CHDK build are you using ? Some CHDK changes since that thread may help. If you can try the latest trunk autobuild http://mighty-hoernsche.de/trunk/ (http://mighty-hoernsche.de/trunk/)
What firmware version is your a490 ?
If I understand the above then if/when that separation is added I guess my download problems can be solved another way instead - by downloading the image to a PC (and deleting it from the camera) immediately after the shot, while shooting the next image.
No, this is totally unrelated. The "single threaded" comment refers to the client application, not the camera. You could probably download files while shooting with the current code (see earlier comments regarding running live view while shooting), although you'd have to jump through some hoops to do it, and I wouldn't be surprised if it caused some instability.
In any case, an "out of memory" error from lua means camera RAM. Images are saved on your SD card so deleting them isn't going to help. The camera actually does keep a small amount of in-memory information for each file on the card, but it doesn't notice when CHDK deletes a file. See http://chdk.wikia.com/wiki/CHDK/Camera_RAM_memory_usage (http://chdk.wikia.com/wiki/CHDK/Camera_RAM_memory_usage) for some information. If you are shooting, downloading / deleting lots of files, shooting again, this could actually be part of your problem. In that case, a reboot after each download might help.
-
My A490 has 100F firmware.
My last test was with the lastest stable from http://mighty-hoernsche.de/ (http://mighty-hoernsche.de/)
a490-100f-1.1.0-2079-full_BETA.zip . I'll try the trunk/nightly version now.
Update: No go. The chdkptp GUI says "error: :243: not enough memory rlib msg_batcher:18" when trying to download 150 images.
-
Update: No go. The chdkptp GUI says "error: :243: not enough memory rlib msg_batcher:18" when trying to download 150 images.
Just to confirm, that's from the 1.2 trunk ?
-
Yes, a490-100f-1.2.0-2086-full_BETA.zip
-
Yes, a490-100f-1.2.0-2086-full_BETA.zip
Thanks for confirming. In chdkptp svn r278, I've improved the memory usage for multiple downloads. Please try it and let me know if it still gets the error.
I've also added some options to the mdownload command
-batchsize lets you control the batch size. Smaller values will be slower but use less memory
-dbgmem will print out memory usage for each batch that is sent. Please use this and post the output if you still have problems.
-pretend will build the file list but won't actually download the files. This is useful for testing, since the file list is the memory intensive part, you don't have to wait for all the files to download.
In my testing it peaked at about 100kb used by lua for batchsize=20, with ~230 images on the card.
-
Thank you. But I can't find 278 here: https://www.assembla.com/spaces/chdkptp/documents (https://www.assembla.com/spaces/chdkptp/documents)
I see it here https://www.assembla.com/code/chdkptp/subversion/nodes (https://www.assembla.com/code/chdkptp/subversion/nodes) but I don't have the skills to compile.
-
Thank you. But I can't find 278 here: https://www.assembla.com/spaces/chdkptp/documents (https://www.assembla.com/spaces/chdkptp/documents)
I see it here https://www.assembla.com/code/chdkptp/subversion/nodes (https://www.assembla.com/code/chdkptp/subversion/nodes) but I don't have the skills to compile.
Sorry about that, I had confused you with one of the users who was building their own. The r278 binary is now uploaded to the files area.
-
Uploaded snapshot r291 to the files area. Main change is addition of a "shoot" command to the cli. You can specify the tv, av and sv on the command line, e.g.
shoot -tv=1/100 -av=8 -sv=80
You can also use APEX or APEX*96 values, use help shoot for details.
The windows build is built with "context plus" support. This makes aspect correct live view images look better, at the expense of slower rendering. To use this, you must put set gui_context_plus=true in a startup file.
Thanks Stick for motivating me to work on some of this.
-
Nice, and to motivate you even more , all your hard work is really appreciated.
Is this r291 also in trunk 1.2x pre BTW?
-
Is this r291 also in trunk 1.2x pre BTW?
I'm not sure what you are asking. chdkptp is compatible with any version of CHDK from 1.0 onward. The "live view" functionality is compatible with 1.1 onward.
It does not yet include the remote capture work that srsa_4c is doing.
-
Yes, a490-100f-1.2.0-2086-full_BETA.zip
Thanks for confirming. In chdkptp svn r278, I've improved the memory usage for multiple downloads. Please try it and let me know if it still gets the error.
I've also added some options to the mdownload command
I just tried chdkptp-r291-win32 with my A490 camera. I ran a test download of 490 images and mdl worked all right (the pretend command is useful btw!)
-
I run a script that loops these actions (where ____ and _ _ _ are pid strings for two attached powershot cameras):
C:\chdkptp-r291-win32\chdkptp -n -c"-p=____" -e"luar shoot()"
C:\chdkptp-r291-win32-copy\chdkptp -n -c"-p= _ _ _" -e"luar shoot()"
Wait until all chdkptp processes have closed
Wait 500 ms more
That give roughly simultaneous shots on the two cameras. However I want to if possible decrease the wait time. But if I lower the 500 ms time wait the cameras become unreliable i.e. one of them sometimes skips a shot. Is there something in chdk and/or chdkptp I can do to speed things up or is it simply a hardware limitation with the cameras?
-
I run a script that loops these actions (where ____ and _ _ _ are pid strings for two attached powershot cameras):
C:\chdkptp-r291-win32\chdkptp -n -c"-p=____" -e"luar shoot()"
C:\chdkptp-r291-win32-copy\chdkptp -n -c"-p= _ _ _" -e"luar shoot()"
Wait until all chdkptp processes have closed
Wait 500 ms more
That give roughly simultaneous shots on the two cameras. However I want to if possible decrease the wait time. But if I lower the 500 ms time wait the cameras become unreliable i.e. one of them sometimes skips a shot. Is there something in chdk and/or chdkptp I can do to speed things up or is it simply a hardware limitation with the cameras?
Starting a new chdkptp process, opening and closing the connection is pretty slow. Just running two copies of chdkptp and feeding them the "shoot" commands with a pipe should be better.
If you are willing to write some lua code, you can also control both cameras from a single chdkptp instance, see multicam.lua for an example.
There are some issues if you try to download too soon after the shoot command, see this post http://chdk.setepontos.com/index.php?topic=8613.msg90669#msg90669 (http://chdk.setepontos.com/index.php?topic=8613.msg90669#msg90669) and following for some very long winded discussion ;)
Note that we are working on support for downloading directly over PTP without saving on the camera at all:
http://chdk.setepontos.com/index.php?topic=4338.msg88931#msg88931 (http://chdk.setepontos.com/index.php?topic=4338.msg88931#msg88931)
This isn't ready for general use yet, and will require additional code for each camera to do jpeg, but should eventually give the best performance.
-
Just running two copies of chdkptp and feeding them the "shoot" commands with a pipe should be better.
Could you give a sample of what such a command would look like?
edit: To be clear I'm not trying to download images between each shoot. I still need the wait when using the commands in my post above.
-
Just running two copies of chdkptp and feeding them the "shoot" commands with a pipe should be better.
Could you give a sample of what such a command would look like?
If I understand correctly, you are starting chdkptp from some other process ? Assuming this is correct, you just need to be able to write to stdin on the chdkptp process so you can send lines like "luar shoot()"
How you do this would depend on what the parent process was developed with (C program, .net etc). I can't possibly give you an example without knowing more about it.
-
I run chdkptp from an autohotkey script ( http://www.autohotkey.com (http://www.autohotkey.com) ).
Sorry for my confused question but I have no experience with stdin/stdout (had to google what it was) but from what I can tell I can do stdout from autohotkey with this command:
http://www.autohotkey.com/docs/commands/FileAppend.htm (http://www.autohotkey.com/docs/commands/FileAppend.htm)
I don't understand how to get chdkptp to read that sent command, especially if I want to send commands to two cameras. Do I need to first load chdkptp and connect the cameras using some special command?
The reason I so far have used a script that reconnects to each camera for every command is that I couldn't find any other reliable way to get the two cameras to repeatedly shooting roughly at the same time. I set the script to wait until all chdkptp processes have closed which means that the shoot commands start at the same time for each new iteration. The A800 camera I have is a bit slower than the older A490 camera.
-
I run chdkptp from an autohotkey script ( http://www.autohotkey.com (http://www.autohotkey.com) ).
OK, that clarifies things a bit, I assumed you had actually written program in some other language to run chdkptp.
Based on http://www.autohotkey.com/docs/Tutorial.htm#Send (http://www.autohotkey.com/docs/Tutorial.htm#Send) it looks you should be able to send keystrokes to a running copy of chdkptp, something like
Send =shoot()
From http://www.autohotkey.com/docs/Tutorial.htm#Activate (http://www.autohotkey.com/docs/Tutorial.htm#Activate) you should be able to switch between windows.
So instead of starting chdkptp each time, you could
1) start two copies of chdkptp in interactive mode, with their respective connect strings but no shoot
C:\chdkptp-r291-win32\chdkptp -i -c"-p=____"
C:\chdkptp-r291-win32-copy\chdkptp -i -c"-p= _ _ _"
2) When you want to shoot, switch to each window and send "=shoot()". It looks like you should be able identify each window by it's path
---
Alternative way, using the multicam module. This uses one copy of chdkptp to control both cameras, and shots should be very close together. I've attached two cli command files. To use them, put the files in the same directory as chdkptp. The lines that start with # are comments.
Start chdkptp with
chdkptp -i -rmcinit.chdkptp
This makes chdkptp run all the commands in mcinit.chdkptp at startup.
The commands in the file
1) load the multicam module
2) connect to all cameras that are connected to your pc
3) start the multicam script all cameras
4) Initialize the time synchronization system
5) switch the cameras to shooting mode.
To shoot
source mcshoot.chdkptp
This will press half shoot, wait for the cameras to focus etc, and then send the shoot command.
when you are done, you should send
!mc:cmdwait('exit')
to end the multicam script on the cameras. If you disconnect without doing this (and don't restart the cameras), the next time you connect you'll get errors because the script is already. You will also need to use 'exit' if you want to download files with mdownload.
The whole mc module isn't really finished, but maybe you will find it useful.
-
Thanks! I tested out the multicam scripts. They work all right but the speed is about the same as in my previous autohotkey scripting method. 10 doubleshots took 59 seconds. My script method is actually a little faster but I think that's only because I have a step that locks the camera focus before starting the shooting loop. With that added to multicam the speed would be the same I suspect.
I'll test the other scripting method you mentioned later (send commands as textstring to open cmd windows). But if it ends up having roughly the same speed then do you think there is any other way to get a speed up? I've checked the CHDK settings and I've already tried tweaking shutter time and so on. But the largest time chunk for each cycle is spent on saving the image to the sdcard and perhaps getting ready for a new shot. You mentioned work in progress on downloading directly over PTP. Would that, when done, speed up looped shooting of this kind? Or have I perhaps simply hit a hardware limit and have to look for faster cameras?
edit: the cameras can handle much faster shooting manually in continuous mode (one shot takes less than two seconds) so the camera hardware can clearly work faster. But there might still be some hardware limit to how fast it can be controlled from a PC.
-
Thanks! I tested out the multicam scripts. They work all right but the speed is about the same as in my previous autohotkey scripting method. 10 doubleshots took 59 seconds. My script method is actually a little faster but I think that's only because I have a step that locks the camera focus before starting the shooting loop. With that added to multicam the speed would be the same I suspect.
Probably. Multicam is optimized for making the cameras shoot as close as possible to the same instant, not minimum cycle time. You could adjust it, but I wouldn't expect big gains.
Would that, when done, speed up looped shooting of this kind? Or have I perhaps simply hit a hardware limit and have to look for faster cameras?
Not sure, probably depends on the relative speed of USB and SD. If you are doing shoot/save/download for each shot, then it would be quicker, but it sounds like you are taking a bunch of shots and then downloading, so a good SD card could be quicker than USB.
Connecting / disconnecting does have some overhead, so it should be possible to do a little better than invoking chdkptp for each shot.
In the canon firmware, the fastest way to shoot is using the continuous mode and holding the shutter down (which you could do from script) but using different cameras I expect they will drift apart pretty quickly. Making a "synchronized continuous mode" that shoots at the rate of the slowest camera might be possible, but it would probably take some hacking and add some overhead.
-
In the canon firmware, the fastest way to shoot is using the continuous mode and holding the shutter down (which you could do from script) but using different cameras I expect they will drift apart pretty quickly. Making a "synchronized continuous mode" that shoots at the rate of the slowest camera might be possible, but it would probably take some hacking and add some overhead.
Is there presently some way to script the camera to go into continuous hardware mode but then inject some delay time between the shots? Maybe the drift can be avoided or greatly decreased by using two cameras of the same model and version and the same model of sd card.
-
Is there presently some way to script the camera to go into continuous hardware mode but then inject some delay time between the shots?
I don't think you could do this with stock chdk, but it should be theoretically possible. You can block the shooting process in the raw hook, but I'm not sure what you'd use to synchronize.
-
I was thinking that by using the same cameras and sd cards the sync drift would perhaps be small enough for two connected cameras to take perhaps 20 shot cycles (with a time delay between each) sufficiently in sync. If that saves at least 1 second per cycle compared to what I have now (6 second cycles) then I could add some sync step once every 20 cycles. Perhaps command the cameras to exit continuous mode, wait until both cameras have waited at least a second, and then enter continuous mode in sync and run the next 20 cycles. Even if the intermittent sync step would take as much as 10 seconds the new process would still save time all in all.
-
I was thinking that by using the same cameras and sd cards the sync drift would perhaps be small enough for two connected cameras to take perhaps 20 shot cycles (with a time delay between each) sufficiently in sync.
Sure, if you have two identical cameras, try it out. I don't have identical cameras, and I don't know what your sync requirements are. I would expect identical cameras and cards to behave quite well, although SD cards can be somewhat unpredictable due to underlying wear leveling, gc etc.
If that saves at least 1 second per cycle compared to what I have now (6 second cycles) then I could add some sync step once every 20 cycles.
6 second cycles seems quite excessive, are you shooting raw ? On my a540, using an old slow SD card
=shoot()
takes about 1.5 sec complete with jpeg. and DNG takes 3.5 sec. Shooting 10 DNG shots in a row with
=for i=1,10 do shoot() sleep(10) end
takes 35 sec.
All of the above is with AF and AE enabled.
Using the new remote shoot stuff, a jpeg (including download) takes 1.3 sec.
-
I tried to reproduce the problems with long/odd filenames from http://chdk.setepontos.com/index.php?topic=4338.msg91363#msg91363 (http://chdk.setepontos.com/index.php?topic=4338.msg91363#msg91363) and http://chdk.setepontos.com/index.php?topic=8600.msg90093#msg90093 (http://chdk.setepontos.com/index.php?topic=8600.msg90093#msg90093) without success.
Some file names would fail on upload, but directly creating them on the card didn't cause listing to file. If someone knows a way to make a file that causes ls to silently fail, I'd like to fix it so it at least returns an error message.
-
I can get chdkptp-r291-win32 to read/delete files from my A590IS-101b
but I can't the "Live" tab to display the live image. It seems to work only in "Play" mode.
I'm using branches_tsvstar-uitest-2215.zip.
Do I need something else to make it work?
-
I can get chdkptp-r291-win32 to read/delete files from my A590IS-101b
but I can't the "Live" tab to display the live image. It seems to work only in "Play" mode.
I'm using branches_tsvstar-uitest-2215.zip.
Do I need something else to make it work?
You shouldn't. Live view should be supported in every version from CHDK 1.1 onward. I don't know exactly what is in tsvstars branch, but it seems unlikely he would have broken this. What happens when you try to use the live tab in record mode ?
edit:
Although I doubt this is specific to tsvstars build, any time you have a problem with an unstable branch, it's a good idea to check if the latest stable autobuild from http://mighty-hoernsche.de/ (http://mighty-hoernsche.de/) has the same problem.
-
Thanks, for the reply, reyalp.
>What happens when you try to use the live tab in record mode ?
I get "error: no devices available" and sometimes the cam crashes.
In "Play" mode it works fine. I can read files and look at folders without problems.
With the latest stable autobuild it won't work, not even in "Play" mode.
I will give it a try again late tomorrow.
-
I get "error: no devices available" and sometimes the cam crashes.
In "Play" mode it works fine. I can read files and look at folders without problems.
Are you are trying to connect when the camera is already in rec mode ?
You should connect the camera in play mode and then use the GUI buttons (or =switch_mode_usb(1) in the cli) to switch to record. You should not change the physical play/rec switch while the camera is connected.
With the latest stable autobuild it won't work, not even in "Play" mode.
This is strange. More specific details might be useful.
-
I've uploaded snapshot build r311 to the files area https://www.assembla.com/spaces/chdkptp/documents (https://www.assembla.com/spaces/chdkptp/documents)
The remote capture stuff is not enabled in these binaries, since the protocol is still in flux.
The main user visible changes are
1) support palette type 4 (sx110, a495)
2) fixed a big that prevented GUI file downloads form working in some cases
3) added a -overwrite option to mdownload. See help mdl for details.
-
@reyalp,
It works fine on my desktop PC Win 7/64-bit, but not on my laptop Win 7/32-bit :(
Could it be libusb-win32? What version should I use? Any links?
-
@reyalp,
It works fine on my desktop PC Win 7/64-bit, but not on my laptop Win 7/32-bit :(
Could it be libusb-win32? What version should I use? Any links?
You should probably use the same version that works on your desktop. There aren't separate 32 and 64 bit packages. I'm currently using 1.2.4.0 on my win7 64 desktop.
libusb has "filter" and "inf" drivers. On win7, I found only the inf driver works reliably. With the filter driver, other programs / system services interfere with the libusb connection. The inf driver will prevent other software from seeing the camera at all (possibly only on some physical USB ports, this seems to vary depending on the camera)
-
Got 1.2.4.0, and used "inf" drivers, that did it! :)
chdkptp-r311-win32 is very neat.
Thanks, reyalp!
-
A495
Live view works with a495-100f-1.1.0-2228-full_BETA.zip off the regular trunk, and the UI.
Thanks a ton guys!
-
Here is a question, how do I get the live view to show the stream in a custom window. I'm trying to run the chdkptp via a script on click of a button to shoot a photo, but at the same time, trying to show the liveview using another instance of chdkptp -g.
If I connect live view after the script starts, the script fails,
If I start the script, after live view, it stalls, saying another process is now using it.
Any ideas how can I make them work in harmony ?
-
Here is a question, how do I get the live view to show the stream in a custom window.
This would require code changes.
I'm trying to run the chdkptp via a script on click of a button to shoot a photo, but at the same time, trying to show the liveview using another instance of chdkptp -g.
You can only have one PTP connection to a camera at a time, so there is no possibility of using multiple instances to connect to the same camera.
If you are using some other program (?) to trigger chdkptp to shoot, maybe you could send a windows message to the chdkptp GUI window instead ?
The chdkptp GUI is written using IUP http://www.tecgraf.puc-rio.br/iup/ (http://www.tecgraf.puc-rio.br/iup/). If you have some programming knowledge, you can modify the interface any way you want. I apologize in advance for the lack of documentation in the code...
-
Hi !
I have a Powershot S2 IS with "CHDK-DE_s2is-100f-1.1.0_rev_2228" installed.
"libusb-win32-bin-1.2.6.0" and "chdkptp-r311-win32" on the computer.
When I start chdkptp I can see the latest picture in play-mode and see the files on the camera.
But the camera doesn't react to commands.
When i press "rec" i get
error: :82: module 'capmode' not found:
no field package.preload['capmode']
I'm for sure doing something wrong or missing something, but what ?
Thanks in advance
Edit: Chdk wasn'tinstalled in a correct way...
New complete install, but now it freezes/hangs when I press "rec", without any errormessages.
On first "rec":
error: error loading module 'GEN/modelist' from file 'A/CHDK/LUALIB/GEN/modelist.LUA':
cannot fopen A/CHDK/LUALIB/GEN/modelist.LUA
On second "rec" no respons/hangs.
-
I have a Powershot S2 IS
The S1IS, S2IS, S3IS models use a different hardware design. They have an additional CPU that makes the built-in timelapse feature possible, and also enables the camera to "wake up" when USB is connected. This could be the reason that not all features of CHDK's PTP support work as expected.
What exactly happens when you hit the "rec" button in chdkptp? Is the USB connection gone? What happens with the camera? Does it crash / freeze? What does the camera do if you remove the USB cable after this?
You may need to use the official remote capture support of the camera (with software like Canon's RemoteCapture, gphoto, etc.), which chdkptp does not support.
-
On first "rec":
error: error loading module 'GEN/modelist' from file 'A/CHDK/LUALIB/GEN/modelist.LUA':
cannot fopen A/CHDK/LUALIB/GEN/modelist.LUA
The complete CHDK install package should include that file. Make sure that the CHDK folder in the install archive is completely unpacked to your SD card (with all the files and subdirectories).
-
The file is there, but what about the first "A/" ? Is "A" the camera (no A map exists).
On first "rec":
error: error loading module 'GEN/modelist' from file 'A/CHDK/LUALIB/GEN/modelist.LUA':
cannot fopen A/CHDK/LUALIB/GEN/modelist.LUA
On second "rec" no respons/hangs.
Nothing happens with the camera if I remove the usb cable. Its still responsive to whatever I want to do with it.
So this might be a dead end for me ... :(
-
The file is there, but what about the first "A/" ? Is "A" the camera (no A map exists).
The camera calls the SD card "A", "A/CHDK" is the CHDK directory on the card, etc.
cannot fopen A/CHDK/LUALIB/GEN/modelist.LUA
The camera tells you that this file is missing. Make sure you copy it to the card.So this might be a dead end for me ... :(
Don't give up yet.
-
Confused, can't see whats wrong...
-
Confused, can't see whats wrong...
Well, me neither.
Can you open that file with CHDK's file viewer? Or, what happens, if you attempt to download it with chdkptp?
-
Its strange, but I dont get those errormessages every time.
I can open the files with CHDK's viewer, but cant do anything from chdkptp.
Its like I can see what's on the camera but not communicate with it.
For most of the "buttons" in chdkptp I can see something like ****FINISHED**** flash briefly on the cameras LCD but no other response.
If I press "rec" chdkptp hangs with no response.
If I close chdkptp and give it a new try, it says a script is running for every button i press.
-
The fact that you can browse the directory tree means you are successfully communicating with the camera.
The intermittent error with capmode is very strange, I don't know what to think about that.
I don't know if mode switching while connected to USB has ever been tested on S2IS, it's possible it doesn't work.
To narrow down exactly where the problem occurs, you can call individual lua functions on the camera from the console. For example, you can try:
=return os.stat('A/CHDK/LUALIB/GEN/MODELIST.LUA')
the result should be a table if the camera is able to access the file.
You could also do
=return require'gen/modelist'
which should return a table with all the known CHDK modes, indicating the file was read OK.
You can try to switch to record mode using
=switch_mode_usb(1)
this doesn't require capmode or modelist.
Note when you plug the camera into USB, the mode switch should probably be in the 'play' position.
If I close chdkptp and give it a new try, it says a script is running for every button i press.
This indicates that some previous script never completed. If you can identify exactly which call failed to end, that might be helpful.
-
Thanks for all your efforts !
1. Restarted computer
2. Started chdkptp
3. Pressed "play"
4. Connected usb cable
5. "Connect" in chdkptp
6. Tested your codes
See result below
Seems like I can get info from the camera but not change anything from chdkptp.
-
3. Pressed "play"
I was referring to the physical play/rec switch on the camera, not the chdkptp UI. Looking at pictures of this camera online, it looks like the switch doesn't stay in play/rec position. In that case, you should power it on initially using play rather than rec.
From your screenshot, everything appears to be working correctly. Did it hang after 'switch_mode_usb(1)' ?
-
Yes, it did hang after 'switch_mode_usb(1)'.
When I connect the usb-cable to the camera, it always gets in to a "unresponsive play-mode" (it doesn't matter if I power it on using rec or play).
I can see the latest picture on the lcd but can't use any buttons on the camera.
-
Hi,
I'm trying to use the chdkptp client on Raspbian, but from the command line.
Is it possible to use chdkptp without the GUI?
When I try to run it is just gives
starting gui...
pcall failed 2
error IupOpen: could not initialize
PANIC: unprotected error in call to Lua API (attempt to index a nil value)
Which is understandable since it won't open the GUI over SSH.
-
Hi, try with chdkptp -i
CHDK PTP control utility
Usage: chdkptp [options]
Options:
-g start GUI - default if GUI available and no options given
-i start interactive cli
-c connect at startup, with optional device spec e.g. -c"-d001 -bbus-0"
-e execute cli command, multiple allowed, e.g -e"u DISKBOOT.BIN" -ereboot
-r specify startup command file, if no file given skip default startup files
-h help
-
Thanks for the reply.
That worked and it is chdkptp is working well with my Canon Ixus 220 HS (ELPH 300)
Next question..... is it possible when taking a photo via chdkptp to tell the camera to write the photo to a certain filename in a certain directory? Or will they always end up in DCIM/1xx_xxxx/IMG_xxxx.JPG style?
-
Are there any tips on how to construct a command line command with chdkptp?
I can do everything I want via separate commands but I'd like to automate it via one bash script.
It's pretty simple...
sudo sh /home/pi/chdkptp/chdkptp-sample.sh -i -c
The commands I want to run are....
lua switch_mode_usb(1)
lua set_zoom(0)
lua shoot()
lua switch_mode_usb(0)
dis
quit
I can start by running
sudo sh /home/pi/chdkptp/chdkptp-sample.sh -i -c -e"lua switch_mode_usb(1)"
but how do I add the other commands?
sudo sh /home/pi/chdkptp/chdkptp-sample.sh -i -c -e"lua switch_mode_usb(1)" -e"lua set_zoom(0)" etc etc
doesn't seem to work.
-
I can start by running
sudo sh /home/pi/chdkptp/chdkptp-sample.sh -i -c -e"lua switch_mode_usb(1)"
but how do I add the other commands?
sudo sh /home/pi/chdkptp/chdkptp-sample.sh -i -c -e"lua switch_mode_usb(1)" -e"lua set_zoom(0)" etc etc
doesn't seem to work.
"doesn't seem to work" in what way?
You can use multiple -e commands from the command line. In that case, you don't need -i, which would leave it in interactive mode after the -e commands complete. The gui only tries to start if there are no command line options at all, if there's just -e commands it runs in batch mode, which executes all the -e commands and then exits. You also don't need dis, it will automatically close any open connections when it exits.
You can also make a file of chdkptp commands and run that with the 'source' cli command or the -r commandline option. see USAGE.TXT for more details.
You may have trouble doing switch_mode_usb and set_zoom too close together. The camera needs some time to actually switch modes, and may not be ready to move the zoom for some time after switch_mode_usb() finishes. You can use sys.sleep on the chdkptp side to force a delay, e.g.
exec sys.sleep(1000)
will wait one second.
Another problem you might have is that the 'lua' command does not wait for the script to finish on the camera, so may get an error that a script is already running. Use luar to wait for the script to complete on the camera. Or you could put all your camera commands in a single lua call, like
lua switch_mode_usb(1); set_zoom(0); shoot(); switch_mode_usb(0)
If you need delay between them, you can use sleep(<milliseconds>) in camera side lua.
-
Thanks for the reply. I should've given some more detail.
The error was that there was already a script running. I guess it was an issue with not giving it enough time.
I'll try the sleep suggestion when I get chance. Thanks for the tips and advice, it's appreciated.
-
luar instead of lua works great. Thanks for that!
Next question.....
In USAGE.TXT for the command "download" (or d) it states that if a destination directory isn't stated it will download to the current directory.
I am trying to do
d DCIM
to download the DCIM folder. The error I get is
ERROR: A/DCIM is not a file
So I assume without stating a destination this is only possible for files? Not folders?
Is it also not possible to download a folder using "mdl" without stating a destination?
Am I right in thinking I can't use the matching feature of mdl with d?
-
d DCIM
to download the DCIM folder. The error I get is
ERROR: A/DCIM is not a file
the download command only operates on files, it doesn't know how do anything with directories, it just downloads a single file.
Is it also not possible to download a folder using "mdl" without stating a destination?
No, mdl accepts multiple source files or directories, so
mdl foo bar
would be ambiguous if the destination were optional. You can use . for the current directory, but any sub directories recursed into will be created as subdirectories in the destination.
Am I right in thinking I can't use the matching feature of mdl with d?
Correct. d is a bare bones interface to the chdk download API call. mdl is the bells and whistles version.
If you are up to writing some lua code, you can make your own custom download function to do whatever you want. The discussion in this thread http://chdk.setepontos.com/index.php?topic=8613.msg90496#msg90496 (http://chdk.setepontos.com/index.php?topic=8613.msg90496#msg90496) may help you get started.
-
Thanks for the advice reyalp!
I've got it mostly working as I want now. The camera does occasionally crash/turn off and I can't figure out why. It's not a huge issue because I've now attached a relay to the power button of the camera so the Raspberry Pi running chdk-ptp can turn the camera back on when it goes off. But has this been seen in the past?
It is seemingly random, I've logged the times the camera needs restarting to see if there was any trend and there isn't....
12-12-31_21-20-42 - Internet Online - No camera - No capture
12-12-31_21-45-21 - Internet Online - No camera - No capture
12-12-31_22-37-21 - Internet Online - No camera - No capture
12-12-31_23-53-21 - Internet Online - No camera - No capture
13-01-01_01-38-02 - Internet Online - No camera - No capture
13-01-01_02-59-22 - Internet Online - No camera - No capture
13-01-01_04-18-41 - Internet Online - No camera - No capture
13-01-01_04-41-21 - Internet Online - No camera - No capture
13-01-01_07-57-21 - Internet Online - No camera - No capture
13-01-01_09-12-41 - Internet Online - No camera - No capture
13-01-01_09-39-21 - Internet Online - No camera - No capture
13-01-01_10-24-41 - Internet Online - No camera - No capture
13-01-01_10-33-21 - Internet Online - No camera - No capture
13-01-01_11-08-42 - Internet Online - No camera - No capture
13-01-01_11-10-01 - Internet Online - No camera - No capture
13-01-01_12-46-01 - Internet Online - No camera - No capture
13-01-01_14-17-22 - Internet Online - No camera - No capture
13-01-01_15-02-42 - Internet Online - No camera - No capture
One more thing, is it possible to set the focus distance?
I've tried "set_prop(6, 4); set_focus(1000);" but that doesn't seem to set the focus distance.
I may not be asking this in the right place since it's probably a general CHDK/lua question, but any help would be appreciated.
-
I've got it mostly working as I want now. The camera does occasionally crash/turn off and I can't figure out why. It's not a huge issue because I've now attached a relay to the power button of the camera so the Raspberry Pi running chdk-ptp can turn the camera back on when it goes off. But has this been seen in the past?
Without knowing what you are doing, it's hard to say if it has been seen before. If you can get ROMLOG from the camera http://chdk.wikia.com/wiki/Debugging#Camera_crash_logs_.28romlog.29 (http://chdk.wikia.com/wiki/Debugging#Camera_crash_logs_.28romlog.29) that may help.
One more thing, is it possible to set the focus distance?
In theory, set_focus should do it. However, this feature frequently has problems or only works under certain Canon settings, so there may be issues specific to your camera. You should check the porting thread for your camera and post there if it isn't working.
In auto focus modes, the focus override will only be applied on half-press (after the normal AF is complete). If your camera has MF, it should be applied immediately, and in general for cameras that have MF, it is probably preferable to do it this way.
-
The command I'm running is currently
sudo sh /home/pi/chdkptp/chdkptp-sample.sh -c -e"delete DCIM" -e"exec sys.sleep(2000)" -e"luar switch_mode_usb(1); set_zoom(0); set_prop(6, 3); shoot(); switch_mode_usb(0)" -e"exec sys.sleep(2000)" -e"mdl DCIM /tmp/chdk-download" -e"exec sys.sleep(2000)" -e"delete DCIM"
This can sometimes work for hours at a time or can cause the camera to crash/turn off/disconnect after a few minutes. It is run every 40 seconds via a cronjob. Along with a resize and FTP command but they won't be causing the camera issue.
My log today showed...
13-01-03_13-12-41 - Internet Online - No camera - No capture
13-01-03_14-25-22 - Internet Online - No camera - No capture
13-01-03_16-07-21 - Internet Online - No camera - No capture
13-01-03_19-22-41 - Internet Online - No camera - No capture
13-01-04_03-12-01 - Internet Online - No camera - No capture
13-01-04_03-37-21 - Internet Online - No camera - No capture
13-01-04_04-10-01 - Internet Online - No camera - No capture
13-01-04_05-51-21 - Internet Online - No camera - No capture
13-01-04_05-54-41 - Internet Online - No camera - No capture
13-01-04_06-10-41 - Internet Online - No camera - No capture
13-01-04_06-28-41 - Internet Online - No camera - No capture
13-01-04_09-47-21 - Internet Online - No camera - No capture
13-01-04_10-30-41 - Internet Online - No camera - No capture
13-01-04_10-44-02 - Internet Online - No camera - No capture
13-01-04_11-37-21 - Internet Online - No camera - No capture
13-01-04_14-09-21 - Internet Online - No camera - No capture
13-01-04_15-00-41 - Internet Online - No camera - No capture
13-01-04_15-04-42 - Internet Online - No camera - No capture
13-01-04_15-17-21 - Internet Online - No camera - No capture
...just an example of inconsistency of the crashes. I'll try and get some sort of log tonight to see what causes the crashes. Like I said, it's not a problem now I've got the relay working to turn the camera (Canon Ixus 220 HS / ELPH300) on and off when I want via GPIO.
-
This can sometimes work for hours at a time or can cause the camera to crash/turn off/disconnect after a few minutes.
As I said before, getting a romlog from the camera may shed some light on what is making it crash.
You might want to put some delay (camera side sleep()) between the switch_mode_usb(), set_zoom() and shoot() but again if you get a romlog that may narrow things down.
Just FYI, you may find it more convenient to put the commands into a file rather than using so many -e commands. e.g you could put the following in myfile.chdkptp
delete DCIM
exec sys.sleep(2000)
luar switch_mode_usb(1); set_zoom(0); set_prop(6, 3); shoot(); switch_mode_usb(0)
exec sys.sleep(2000)
mdl DCIM /tmp/chdk-download
exec sys.sleep(2000)
delete DCIM
and then you could execute it with
sudo sh /home/pi/chdkptp/chdkptp-sample.sh -c -rmyfile.chdkptp
-
Thanks for the tip on using the config file. It'll make things much neater.
-
Hey, good work on the software. I used it as the basis for the software for a photobooth recently, and it seemed to work pretty well. I hacked up the lua code pretty deeply as I needed a custom interface and whatnot, so in the version I am running, it is mostly just using the 'library' functions.
I noted that I could crash the camera pretty reliably if I didn't wait a bit between the capture, download and delete steps, so thanks for that detail above, it was handy.
Too bad I can't just have the camera reboot on crash. I made a function that notices that the camera connection is gone, and attempts to reconnect every few seconds. Seems to work pretty well.
-
Good work as ever. I just set this up on my Raspberry pi using reyalp's recent raspian chdkptp UI from here...
https://www.assembla.com/spaces/chdkptp/documents/crhy7KfOqr4OAMacwqjQYw/download/crhy7KfOqr4OAMacwqjQYw (https://www.assembla.com/spaces/chdkptp/documents/crhy7KfOqr4OAMacwqjQYw/download/crhy7KfOqr4OAMacwqjQYw)
I am running this with my IXY25(SD770/IXUS85) f.w 1.00a using the latest developer build CHDK 1.2.0-2504 Jan 21, 2012.
I am running the UI on the laptop as follows.
ssh -X root@mr-kipling
This allows me to connect to "mr-kipling" (what else would you call a pi?) and export the X session back to the laptop.
cd /home/{actual_user}/chdk/chdkptp
I need to do this because the UI only runs as root, and I copied the code to my user folder
I then run a modified version of chdkptp-sample.sh which I have named run_chdkptp
root@mr-kipling:/home/{actual_user}/chdk/chdkptp# ./run_chdkptp
starting gui...
Gtk-Message: Failed to load module "canberra-gtk-module"
... and up pops the UI on the laptop. I can now sit in the comfort of the front room with the camera and Pi outside. (I am on holiday in India at the moment, so no risk of rain or snow to the camera). I can sit here and watch the wildlife in the garden (well I will be able to when I recharge the camera battery ::) )
So far everything looks to work (live view, shooting etc) without any hitches, but I will report back if I hit any snags.
-
No real gotchas to report, there is an issue (possibly due to the limited oomph of the pi) which causes a lot of lag after I have been using the UI for a while, if I disable Live view it settles down again.
The colours on the Canon menu don't match what is on the Live view (I can live with that), and for some bizarre reason I cant see the Print menu in the main Canon menu, pressing right and left will show the other menus, but it stays on the previous menu when it should display the print menu (this menu looks OK on the camera LCD, so the behaviour of the Live view is slightly odd). Not a show stopper as I am unlikely to ever use the print menu, but worth reporting none the less.
The bottom few lines of pixels on the Live view are corrupted in Record mode I am still trying to work out exactly why, I'll post once I have a better idea.
I get the occasional lockup requiring the battery to be removed from the camera (I haven't yet been able to reproduce this at will, so I can't give any pointers so far as debugging goes yet. I will keep you posted).
Next I am going to map an nfs mount to the pi from the laptop so I can copy the images from the UI to a folder on the laptop, to save a step.
If I get a chance tomorrow, I'll test some more.
I am most impressed with the progress so far :D Thanks to reyalp, and everyone else who has been involved.
-
The colours on the Canon menu don't match what is on the Live view (I can live with that), and for some bizarre reason I cant see the Print menu in the main Canon menu, pressing right and left will show the other menus, but it stays on the previous menu when it should display the print menu (this menu looks OK on the camera LCD, so the behaviour of the Live view is slightly odd). Not a show stopper as I am unlikely to ever use the print menu, but worth reporting none the less.
I had a similiar problem with a2300, this should solve it: http://chdk.setepontos.com/index.php?topic=8318.msg88938#msg88938 (http://chdk.setepontos.com/index.php?topic=8318.msg88938#msg88938)
-
No real gotchas to report, there is an issue (possibly due to the limited oomph of the pi) which causes a lot of lag after I have been using the UI for a while, if I disable Live view it settles down again.
I've found that on Linux if the requested frame rate exceeds the max frame rate that can actually be delivered, the UI gets very laggy. With the current code, this means you are in trouble if your system can't do at least 1fps, because the input doesn't accept lower vlaues.
If you aren't worried about the security of your connection, you might get better performance by making x directly accessible over the network rather than tunneling over ssh, since the latter requires the pi to encrypt all your X traffic.
As nafraf says, your display issues are likely due to incomplete implementation of the functions needed for live view.
-
Should it be possible to run the chdkptp client (via the command line) with multi cameras at the same time?
I've got one camera scripted to take a photo every 40 seconds and if I attach another camera it will generally connect fine but there's often libusb errors and not all commands will excute safely. I'll get some examples of the output soon.
I'm using the serial number of the cameras to connect to them with their respective scripts so there's no issues of connecting to the wrong/same camera.
If it isn't something I should be doing that's fine, just wondering if people have managed to run the client with multiple cameras?
-
Should it be possible to run the chdkptp client (via the command line) with multi cameras at the same time?
Yes. You can either control multiple cameras from a single instance of chdkptp, or (if you are careful) run multiple instances.
I'm using the serial number of the cameras to connect to them with their respective scripts so there's no issues of connecting to the wrong/same camera.
Unfortunately, this doesn't work as you'd expect. To determine the serial number, chdkptp needs to create a temporary connection. This will disrupt any other clients connected to the device who's serial is being queried. If you use one instance of chdkptp, then it can get the serial number without resetting existing connections. However, controlling multiple cameras is only supported in the lua API, not the cli. You can see the 'multicam.lua' module for an example.
IIRC seeing kernel log messages with the serial number, which suggests there might be a way to get this without a full connection (since the kernel presumably already has it). If anyone knows how to do this, I'd be happy to add support to chdkptp (if possible).
edit:
Another thing on my TODO list is to not to attempt to connect to cameras that already have an active connection, so when connecting by serial, it would only query cameras unconnected cameras. I think this should be doable, but I haven't got around to working on it yet.
-
Having a strange problem with chdkptp (revision 323) and all current CHDK versions (release-1.1, trunk and philmoz-action-stack).
Using the GUI, I connect the camera and double click 'Camera' on the Files tab.
I then select the CHDK directory and right click and select 'Upload directory contents'.
I select the CHDK directory from my build folder and click Ok.
It will then upload some of the files to the camera before locking up chdkptp (shows as 'Not responding' in Windows). Turning off the camera will bring chdkptp back to life; but not all files have been uploaded.
Tested on G1X and G12 so far - happens on both.
Phil.
-
Yes. You can either control multiple cameras from a single instance of chdkptp, or (if you are careful) run multiple instances.
What is the careful way of doing it via multiple instances? My current setup is one camera taking a photo every 40 seconds. This is a case of a script with chdkptp, ftp upload etc running as a cronjob every 40 seconds. The second camera is activated via a motion sensor. When the sensor detects motion the RPi runs a script which takes some photos from the second camera using chdkptp then ftp uploads etc.
Unfortunately, this doesn't work as you'd expect. To determine the serial number, chdkptp needs to create a temporary connection. This will disrupt any other clients connected to the device who's serial is being queried.
Would it be better to use the pid or dev number to connect? Does this prevent chdkptp having to query for a serial number?
IIRC seeing kernel log messages with the serial number, which suggests there might be a way to get this without a full connection (since the kernel presumably already has it). If anyone knows how to do this, I'd be happy to add support to chdkptp (if possible).
edit:
Another thing on my TODO list is to not to attempt to connect to cameras that already have an active connection, so when connecting by serial, it would only query cameras unconnected cameras. I think this should be doable, but I haven't got around to working on it yet.
It is good to know you're thinking of doing more with it. I really do love chdkptp, it's a dream for automated high quality photo capture. I'm definitely going to be using it more after buying a job lot of 18 "broken" Canon compact cameras off ebay, 5 worked out of the box!
-
What is the careful way of doing it via multiple instances? My current setup is one camera taking a photo every 40 seconds.
By not using command that try to connect to all the available cameras. This includes "list" since it tries to show the name an serial (I should add an option to just show bus/dev)
Would it be better to use the pid or dev number to connect? Does this prevent chdkptp having to query for a serial number?
Yes, pid, dev and bus should fine.
-
Thanks. Connecting with pid has improved things greatly.
-
I'd dearly love to get this working under OSX on a Mac, but I think may not be possible because the OSX version of libusb has problems claiming a usb device (because OSX gets exclusive control as soon as you plug a USB device in). This is certainly true for some devices (e.g. mass storage devices like disks and cards, as well as HID's) does anyone know if it's untrue for cameras?
The libusb page says
Darwin (Mac OS X) implementation has one limitation. If the OS has an interface driver that matches the characteristics of a device, it will seize the interface and the kernel driver cannot easily be detached. So libusb will not be able to use that interface. This is a particular problem with generic HID devices. For HID device, HIDAPI is recommended.
No idea if this applies to PTP devices. If so, maybe a higher level API you can use for PTP commands ? In the long term, I hope to make things modular enough that you could change the underlying communication layer to something other than libusb. You'd expect that there should be some mechanism for camera vendors to support their PTP extensions in their own apps. It looks like there are remote capture apps for Mac (e.g. for Canon cameras that can do remote capture using the Canon SDK), so you might look into how those work.
IUP also does not have native support for OSX. I don't know if it runs under X11. Native OSX support is on their TODO list.
Hello,
I was able to compile IUP.3.7 and CD.5.6 for OSX 10.7 as dylib-s. I would be happy to upload them somewhere so someone else can confirm that they work and then send them to Tecgraf.
I didn't experienced the OSX libusb limitation with my cameras (powershot sx10 and A810). But experienced one other strange behavior:
after connecting the camera to USB port, camera will retract lens and turn of screen. (this is not happening in Ubuntu) Depending on settings in "Image Capture.app" the camera will be mounted to selected app (default is iPhoto. you can turn out mounting, but it has no impact on the behavior that I'm describing). Then I'm able connect to camera with chdkptp with working console, browse and liveview. HW and chdkptp gui buttons are not working but that's porobably normal as I read in this forum. The real problem is switching to record mode with switch_mode_usb(1), which is not working and do something harm in camera. liveview and browsing is still working, but that's all. attempt to switch the camera off with HW button or command is freezing the camera.
I found one workaround for this behavior, but virtualbox is needed and it's not very practical. Create usb filter for one virtualbox host (in my case I it's ubutnu hots). Then when you connect USB cable, connect with chdkptp from virtualbox host, switch to record mode, disconect chdkptp, remove camera from virtualbox host usb devices. then the camera will now connect to OSX as before, but will not retract lens. you can browse content with iPhote OR can connect with chdkptp from OSX and the camera fill not freeze.
I wasn't able to discover what is the reason why this happens. Probably OSX send to camera command to switch to some mode from witch switch_mode_usb(1) is not working and the camera ignore this OSX command when camera already executed switch_mode_usb(1) from virtualbox host. I tried to add autostart script that call switch_mode_usb(1), but it didn't help.
in the attachment is fix for small bug that I found in lua/gui.lua
-
Hello,
I was able to compile IUP.3.7 and CD.5.6 for OSX 10.7 as dylib-s.
Nice work.
I would be happy to upload them somewhere so someone else can confirm that they work and then send them to Tecgraf.
It might be more useful to describe what is required to build it (or perhaps provide a shell script that does everything). I'd be happy to include that in the documentation somewhere. I have no idea if tecgraf is interested in hosting binaries like this, but you could post on their mailing list.
The real problem is switching to record mode with switch_mode_usb(1), which is not working and do something harm in camera. liveview and browsing is still working, but that's all. attempt to switch the camera off with HW button or command is freezing the camera.
This definitely sounds like the OS is putting the camera in some state that isn't encountered on other platforms. I know nothing about OSX USB architecture (and relatively little about other platforms), so unfortunately I can't be any help there.
switch_mode_usb is pretty hacky, it's not really surprising that it can fail like this.
If you have the capability to sniff USB, you that might provide some clues. There might also be something recorded in the camera log when OSX does it's thing, which could point to functions or variables to poke in the firmware to get out of that state. See here http://chdk.wikia.com/wiki/Debugging#Logging_camera_console_output (http://chdk.wikia.com/wiki/Debugging#Logging_camera_console_output) for information about getting camera log output.
in the attachment is fix for small bug that I found in lua/gui.lua
Thanks, added in r324. I also upped the timeout since 50 didn't seem to be enough on my d10 with the check actually working :-[
-
Using the GUI, I connect the camera and double click 'Camera' on the Files tab.
I then select the CHDK directory and right click and select 'Upload directory contents'.
I select the CHDK directory from my build folder and click Ok.
It will then upload some of the files to the camera before locking up chdkptp (shows as 'Not responding' in Windows). Turning off the camera will bring chdkptp back to life; but not all files have been uploaded.
Tested on G1X and G12 so far - happens on both.
Sorry for taking so long to respond, was buried in RL work.
It's normal for chdkptp to show "not responding" if it's busy for a while (lua script currently doesn't yield back to the gui until it's done). Of course, the upload should finish eventually. Uploading lots of small files is quite slow.
I was able to upload the CHDK directory from my SVN tree this way several times without problems.
If it is actually hanging, you can get some output in the cmd window by doing the following in the gui console
set gui_verbose=2
!util.util_stdout = io.stdout; util.util_stderr=io.stderr
Then all the normal status output will go to the cmd window, rather than the gui window, which allows you to see it as the upload is in progress. Because of the yielding issue mentioned above, output to the gui console does not appear until the entire script is finished.
-
Using the GUI, I connect the camera and double click 'Camera' on the Files tab.
I then select the CHDK directory and right click and select 'Upload directory contents'.
I select the CHDK directory from my build folder and click Ok.
It will then upload some of the files to the camera before locking up chdkptp (shows as 'Not responding' in Windows). Turning off the camera will bring chdkptp back to life; but not all files have been uploaded.
Tested on G1X and G12 so far - happens on both.
Sorry for taking so long to respond, was buried in RL work.
It's normal for chdkptp to show "not responding" if it's busy for a while (lua script currently doesn't yield back to the gui until it's done). Of course, the upload should finish eventually. Uploading lots of small files is quite slow.
I was able to upload the CHDK directory from my SVN tree this way several times without problems.
If it is actually hanging, you can get some output in the cmd window by doing the following in the gui console
set gui_verbose=2
!util.util_stdout = io.stdout; util.util_stderr=io.stderr
Then all the normal status output will go to the cmd window, rather than the gui window, which allows you to see it as the upload is in progress. Because of the yielding issue mentioned above, output to the gui console does not appear until the entire script is finished.
Thanks.
It is working - the chdkptp window was showing '(Not responding)' in the title bar as you said.
On my system the file names transferred appear in the gui console as they are transferred for the first dozen or so, then what appears to be blank lines are displayed with the window scrolling up and the scroll bar button getting smaller and smaller (indicating more content).
When it's finished the gui console refreshes with all the file names.
Phil.
-
Hi, I have installed chdkptp in windows 7 x64
But when I connect the camera and try to connect I get this error:
http://ubuntuone.com/3uQDZsU7zOfdcDiXIzUAYW (http://ubuntuone.com/3uQDZsU7zOfdcDiXIzUAYW)
Any help?
Thanks
-
But when I connect the camera and try to connect I get this error:
http://ubuntuone.com/3uQDZsU7zOfdcDiXIzUAYW (http://ubuntuone.com/3uQDZsU7zOfdcDiXIzUAYW)
You can get that error when CHDK is not running.
-
On April 1, 2012, in conjunction with headless linux use of chdkptp, I reported a problem (not chdkptp-related) with the use of zoom with an SX40HS. I had successfully used chdkptp with an A590is, as documented here:
http://chdk.wikia.com/wiki/Chdkptp_in_headless_linux_Dockstar_-_remote_control (http://chdk.wikia.com/wiki/Chdkptp_in_headless_linux_Dockstar_-_remote_control)
I just got back to the issue, and installed the latest chdk for the SX40HS on the SD card. I went back to the dockstar and connected to the SX40HS, with no change in chdkptp. Zoom now works, up to "lua set_zoom(250)" (although I haven't figured out how to focus at that zoom level--at a distance of only about a foot). At "lua set_zoom(80)" it auto-focuses and takes good photos. Sometimes the best thing to do is wait.
-
I'm having a strange problem with my s1is.
File upload to the camera uses a protocol where the first chunk starts with
[4 bytes] filename length
[n bytes] filename
[...] file data, first chunk
The start of the file data is passed to fwrite(). This works for every other camera, but not for this one. I get semi-random data corruption when the address passed to fwrite() is odd. I have tried doing several things, but the only one which helped was to change the PTP client (chdkptp) to pad the filename with NULs for 32bit-alignment.
I'm wondering whether this is something that's good practice anyway, since neither ARMv5 nor the (possibly involved) DMA controller is able to do efficient work on unaligned addresses. I know of course that the firmware routines can deal with this situation (except on my camera).
-
I'm wondering whether this is something that's good practice anyway, since neither ARMv5 nor the (possibly involved) DMA controller is able to do efficient work on unaligned addresses. I know of course that the firmware routines can deal with this situation (except on my camera).
On most cameras, fwrite should be OK, because each FILE * has an uncached (and presumably aligned if required) buffer that is used for the actual write(). As far as I know, it would always go through this buffer.
-
On most cameras, fwrite should be OK, because each FILE * has an uncached (and presumably aligned if required) buffer that is used for the actual write(). As far as I know, it would always go through this buffer.
All other cameras should be ok, I've tried it on the Ixus30.
BTW, fwrite() is FWrite_Fut() on most cameras, except
ixus30, 40: fwrite(), there's no _Fut API.
s1is: fwrite() has horrible performance (~30kB/s, I have no idea how it could be that bad), so I've replaced all f* functions with wrapped open(), write() etc. The corruption is there, no matter fwrite() or write()...
-
On most cameras, fwrite should be OK, because each FILE * has an uncached (and presumably aligned if required) buffer that is used for the actual write(). As far as I know, it would always go through this buffer.
All other cameras should be ok, I've tried it on the Ixus30.
BTW, fwrite() is FWrite_Fut() on most cameras, except
ixus30, 40: fwrite(), there's no _Fut API.
s1is: fwrite() has horrible performance (~30kB/s, I have no idea how it could be that bad), so I've replaced all f* functions with wrapped open(), write() etc. The corruption is there, no matter fwrite() or write()...
I don't think null padding and aligning the name should hurt anything.
This reminds me of this problem: http://chdk.setepontos.com/index.php?topic=6730.msg76760#msg76760 (http://chdk.setepontos.com/index.php?topic=6730.msg76760#msg76760) ... in fact, my original workaround was to pad the filename data.
-
Live view on older cameras like the ixus60:
It seems the live view would not work properly on older cameras. Tests with an ixus 60 shows that only the bitmap overlay works conditionally. I think it is missing a few things in the source code.
A screenshot of a overlay example shows an artefact of an older displaying after a 'draw_clear()' command (red marked).
It would be very nice if there is a possibility, make live view available for these older cameras.
msl
-
It seems the live view would not work properly on older cameras. Tests with an ixus 60
To me on the A530 all work without a problem, it is a camera from the same era as the Ixus 60 , but I used an older version chdkptp client when I tried.
http://chdk.setepontos.com/index.php?topic=6231.msg83668#msg83668 (http://chdk.setepontos.com/index.php?topic=6231.msg83668#msg83668)
-
It seems the live view would not work properly on older cameras.
This is true for those models where nobody implemented the additional functions needed for live view. There are exceptions (the list below may not be complete and is VxWoks only):
a540 with probably the most complete support code,
a410-420-430-450-460
ixus65
platform/model/sub/{revision]/lib.c and/or platform/{model}/lib.c needs to be changed, the attached diff (for ixus60) shows which functions need to be implemented. The above ports usually give a hint where to find specific memory addresses in the firmware.
This kind of work doesn't require assembly skills, all what's needed is to locate the addresses in the reference disassembly (http://chdk.wikia.com/wiki/GPL:disassemble.pl), and find the equivalent places in the other disassembly. The routines usually do not differ substantially, they can be compared visually.
A screenshot of a overlay example shows an artefact of an older displaying after a 'draw_clear()' command (red marked).
If this is only happening when using ptp live view, the attached patch should help (I can't test it, need feedback).
Also note that from r2614 on, the use of memPartInfoGet has been enabled for every VxWorks model, which should speed up ptp transfers considerably. http://chdk.setepontos.com/index.php?topic=650.msg97434#msg97434 (http://chdk.setepontos.com/index.php?topic=650.msg97434#msg97434)
-
The start of the file data is passed to fwrite(). This works for every other camera, but not for this one. I get semi-random data corruption when the address passed to fwrite() is odd. I have tried doing several things, but the only one which helped was to change the PTP client (chdkptp) to pad the filename with NULs for 32bit-alignment.
A further question on this: Have you verified that it happens with regular fwrites outside of PTP? If so, I expect you could run into a lot of other problems too. If not, maybe there's something more subtle going on. If it does happen everywhere, it might be worth making a buffered version, although perhaps this would be as slow as canons fwrite...
-
A further question on this: Have you verified that it happens with regular fwrites outside of PTP?
Tried write(), acts the same. The issue is not ptp related. Guess they had forgotten to test this possibility. Even though the firmware doesn't do unaligned writes, they could have tested it with a script. If so, I expect you could run into a lot of other problems too.
I haven't noticed corrupted files elsewhere (tests, dng, config), so this seems to be the only place that triggers it. As of now. If it does happen everywhere, it might be worth making a buffered version, although perhaps this would be as slow as canons fwrite...
I've been thinking about using some BSD code (stdio routines), but currently I'm only using small parts of those (with the caching parts removed).
-
platform/model/sub/{revision]/lib.c and/or platform/{model}/lib.c needs to be changed, the attached diff (for ixus60) shows which functions need to be implemented. The above ports usually give a hint where to find specific memory addresses in the firmware.
Thanks for your work.
With this patch live view works fine for the ixus60.
msl
-
With this patch live view works fine for the ixus60.
Thanks, committed.
-
Tried CHDKPTP r311 with a SX40HS (sx40hs-100f-1.2.0-2640).
It connects, I can sometimes get the live view, but only a static frame.
Can't trigger any buttons with CHDKPTP, but can view the camera filesystem and download files.
Are there any config files I could tweak or should I just wait for the camera to be fully supported?
-
Tried CHDKPTP r311 with a SX40HS (sx40hs-100f-1.2.0-2640).
It connects, I can sometimes get the live view, but only a static frame.
Can't trigger any buttons with CHDKPTP, but can view the camera filesystem and download files.
You need to switch the camera to rec mode (use chdkptp's "rec" button), the remote camera buttons will only start to work after you do that.
Remote live view can misbehave when a stopped movie is displayed on the camera LCD.
-
Patch attached for the new palette transparency values found in the SX50HS.
http://chdk.setepontos.com/index.php?topic=8306.msg98194#msg98194 (http://chdk.setepontos.com/index.php?topic=8306.msg98194#msg98194)
Phil.
-
Patch attached for the new palette transparency values found in the SX50HS.
http://chdk.setepontos.com/index.php?topic=8306.msg98194#msg98194 (http://chdk.setepontos.com/index.php?topic=8306.msg98194#msg98194)
Thanks, added in chdkptp changeset 330 (http://trac.assembla.com/chdkptp/changeset/330/trunk)
-
For the record:
When trying to compile chdkptp-r311-Linux-x86_32 (nothing pre-compiled available) on debian testing, I got this:
chdkptp.c:40:17: fatal error: usb.h: No such file or directory
libusb-1.0-0-dev was available, however, this seems to be necessary as well:
libusb-dev (it contains usb.h).
-
Hi reyalp, I'm reviving a topic from earlier in the thread. I asked about ways to speed up the shoot cycles. The context is that I use the two cameras for book scanning. The ideal would be shoot cycles just under 2 seconds because that is roughly how long it takes to turn each page in the setup. By changing some camera settings (disabling preview, etc) I'm down to 3,5 seconds cycles. I use chdkptp on the command line from another script. (I've also tried sending the commands in interactive mode and through the GUI but didn't get noticeably faster cycles that way.) The script first sets up zoom and lock focus and then trigger shots on both cameras with this
chdkptp -c "-p=[cameraid]" -e"luar shoot()"then wait 3000 miliseconds, redo the shoot command, wait, and so on. If I decrease the wait time then one commands often fails and only one camera is triggered. I don't download the photos during the shoot cycles.
I can manually cycle shoot the cameras quicker, even in noncontinuous mode. Holding the button down gives 10 shots in 17 seconds.
On my a540, using an old slow SD card =shoot() takes about 1.5 sec complete with jpeg. and DNG takes 3.5 sec. Shooting 10 DNG shots in a row with
=for i=1,10 do shoot() sleep(10) end
takes 35 sec. ... Using the new remote shoot stuff, a jpeg (including download) takes 1.3 sec.
You 10 cycle DNG speed is similar to what I currently get for capturing JPG with two cameras simultaneously. Can you tell me more about the new remote shoot features? Can you shoot a number of cycles at around 2 seconds using that?
Both my cameras have DIGIC III. Do you know if DIGIC IV compact canon cameras in general would cycle faster? Or does that depend more on the individual camera?
-
The script first sets up zoom and lock focus and then trigger shots on both cameras with this
chdkptp -c "-p=[cameraid]" -e"luar shoot()"then wait 3000 miliseconds, redo the shoot command, wait, and so on. If I decrease the wait time then one commands often fails and only one camera is triggered. I don't download the photos during the shoot cycles.
You can get an idea of the time required for each step using the
set cli_time=true
On my D10
___> c
time 0.0130
connected: Canon PowerShot D10, max packet size 512
con> rec
time 0.2720
con 1> shoot
time 4.0832
This shot was ISO 800, flash fired, scene was bad for AF
con 2> shoot
time 1.6731
con 3> =shoot()
time 1.8661
Above changed to ISO 80, disabled flash, better scene. =shoot() might wait a little more compared to cli shoot, but could just be normal variation.
con 1> shoot
time 2.6462
con 2> shoot
time 2.6111
con 3> shoot
time 1.8601
Some more shots, same settings as above, variation due to scene.
con 4> dis
time 0.2040
Note there is some overhead for connecting/disconnecting.
You 10 cycle DNG speed is similar to what I currently get for capturing JPG with two cameras simultaneously.
Try the time commands and see how long each shot takes.
Can you tell me more about the new remote shoot features? Can you shoot a number of cycles at around 2 seconds using that?
See the discussion in the PTP thread. This is still under development, allows you to save jpeg and / or DNG directly over USB without going to the SD card. The code is in http://trac.assembla.com/chdk/browser/branches/ptp-remote-capture-test2 (http://trac.assembla.com/chdk/browser/branches/ptp-remote-capture-test2)
To use it, you also need to build chdkptp yourself with the ptp headers from that branch.
Both my cameras have DIGIC III. Do you know if DIGIC IV compact canon cameras in general would cycle faster? Or does that depend more on the individual camera?
A540 is Digic II, but only 6MP, D10 is Digic 4, 12 MP.
Speed should depend on
* camera hardware (processor, RAM speed etc)
* image size
* SD card
* shooting settings
* scene.
I don't know how your cameras will compare, but canon published specs should give you a relative measure. E.g. if official specs for a Digic 4 camera are 2x faster than your camera, it would probably be faster, even if you don't get the shot rate given in the specs.
-
Thanks, very helpful! Through
set cli_time=trueI see that my cameras have 3.2 seconds and 2.6 seconds respectively in average shoot time. So that is where the big time sink is.
if official specs for a Digic 4 camera are 2x faster than your camera, it would probably be faster, even if you don't get the shot rate given in the specs.
When I take shots directly on the camera (using the physical button) the cycles are faster. So the chdkptp/camera communication takes some time. I take it there is no difference in speed in chdkptp itself when connecting to DIGIC 4 rather than 3 cameras then?
-
So the chdkptp/camera communication takes some time.
Unless you are using a USB 1 interface, the actual communication time should be negligible. For example
con 4> =return 1
time 0.0590
5:return:1
You can check how long shoot takes on the camera with something like
con 6> =t0=get_tick_count();shoot();return get_tick_count()-t0
time 2.1501
7:return:2020
Here you can see the shot took 2.02 seconds, while the time for the full PTP round trip was 2.1501
What cameras are you using?
-
The slow camera is a powershot A800 and it gives times like these with focus locked through set_aflock
con 2> =t0=get_tick_count();shoot();return get_tick_count()-t0
time 2.4251
3:return:2170
On average 250ms spent on the communication. With USB2. I tested both through a usb hub connection and directly to the computer. I'll try to borrow a never camera with DIGIC 4 and compare speeds.
-
The slow camera is a powershot A800 and it gives times like these with focus locked through set_aflock
Have you checked whether there is actually a difference with / without aflock?
You can measure how much time is spent in pre-shoot vs shoot:
con 4> =t0=get_tick_count();press('shoot_half');repeat sleep(10) until get_shooting();t1=get_tick_count();click('shoot_full');repeat sleep(10) until not get_shooting(); t2=get_tick_count();return t1-t0,t2-t1
time 2.9792
5:return:700
5:return:1840
This is from my a540, pre-shoot took 700 ms, shoot took 1840, total time was 2979 (= ~400ms of overhead)
con 2> =t0=get_tick_count();shoot();return get_tick_count()-t0
time 2.4251
3:return:2170
On average 250ms spent on the communication. With USB2. I tested both through a usb hub connection and directly to the computer.
Given my results with digic II above, this may be normal. I'm a bit surprised by this, I knew chdkptp is not optimised to minimize USB transactions but that seems a bit excessive. A single =shoot() involves several round trips over usb and sends a non-trivial amount of support code. This could be streamlined a bit if you are willing to sacrifice some of the safety and convenience code.
What OS is the PC running?
I'll try to borrow a never camera with DIGIC 4 and compare speeds.
Can you try
con 12> !con:exec('return 1',{nodefaultlib=true,clobber=true,flushmsgs=false})
time 0.0750
con 13> getm
time 0.0220
13:return:1on both cameras. Above is from a540, below is d10
con 2> !con:exec('return 1',{nodefaultlib=true,clobber=true,flushmsgs=false})
time 0.0260
con 3> getm
time 0.0060
3:return:1
-
Some representative measurements:
con> =t0=get_tick_count();press('shoot_half');repeat sleep(10) until get_shooting();t1=get_tick_count();click('shoot_full');repeat sleep(10) until not get_sho oting(); t2=get_tick_count();return t1-t0,t2-t1A800:
time 3.9282
2:return:1030
2:return:2780 A800 with luar set_aflock(1):
time 3.1782
4:return:260
4:return:2750A800 with and without set_aflock(1):
con 3> !con:exec('return 1',{nodefaultlib=true,clobber=true,flushmsgs=false})
time 0.0310
con 4> getm
time 0.0080
4:return:1I'm testing this on a Windows 7 computer.
-
Thanks. Some observations:
1) actual shooting time is ~3 seconds (including pre-shoot with aflock), so you won't go much below this no matter what. If you want to shoot significantly faster, you'll either need to find faster cameras settings, or use a faster camera.
2) USB speed (the return 1 test) may be a bit slower than digic 4, but significantly faster than digic II. This is what we would expect for Digic III, and upgrading to a faster camera isn't going to make a huge difference.
3) USB overhead for a shot is ~100-200ms. You could reduce this a bit with customized shoot code, but it's probably not worth it.
Regarding #1
* Base ISO (100) may be faster than higher settings, since there may be less time spent on noise reduction.
* If the camera does lens distortion correction at certain zoom levels, it may be faster if you use one that doesn't.
* If you don't need full resolution, the "low light" or "blur reduction" scene modes should be substantially faster. You can use CHDK to override the ISO back to a low value.
* Other reduced resolution modes might be faster, but on some cameras they are slower than full res.
* If you are using a slow card, a fast one might help. A supposedly fast, name brand card could be counterfeit.
* edit: experimenting with other shooting settings might be productive too, the above are just off the top of my head.
-
I do want full res. I was at ISO100. I tested other values (using "shoot -sv=80") but didn't see a substantial decrease in total speed.
But changing compression from "fine" to "normal" did bring total time down from ~3.100 to ~2.700. I have to check more how that affects image quality but so far it looks worth it.
How well lit the target is also affects the total time a lot. With bright enough light I get ~1.700 which is fast enough for me.
I'll test the combination of better lighting and normal compression some more before I get any new cameras. Thank you again, your feedback is very helpful!
-
I do want full res. I was at ISO100. I tested other values (using "shoot -sv=80") but didn't see a substantial decrease in total speed.
Yes, I would expect high values (400, 800 or more) to potentially be slower. According to the Canon specs, I think 100 is as low as your camera goes. -sv works in "real" ISO which is not equal to the ISO value the Canon firmware displays.
But changing compression from "fine" to "normal" did bring total time down from ~3.100 to ~2.700.
That's good to know.
With bright enough light I get ~1.700 which is fast enough for me.
What sort of exposure times are you getting? It would be good to know if the change just due to less actual exposure time (e.g going from 1 sec to 0.5 sec), or something else in the shooting process. AF can be slow in low light, but one would expect AF lock to prevent that from being a factor.
-
I've uploaded a snapshot build of r330 to the files area https://www.assembla.com/spaces/chdkptp/documents (https://www.assembla.com/spaces/chdkptp/documents)
The main change is sx50 palette support.
-
I finally got around to testing this some more just now.
The exposure times I get with the a800 in actual use is 1/100 or 1/80 sec (read from the jpeg exif data).
I have now tested out a powershot a2300 (DIGIC4; 16 Mpix) camera and running
=t0=get_tick_count();press('shoot_half');repeat sleep(10) until get_shooting();t1=get_tick_count();click('shoot_full');repeat sleep(10) until not get_sho oting(); t2=get_tick_count();return t1-t0,t2-t1gives much better results
time 2.1031
return 210
return 1670The camera was set to iso 100 I had run set_aflock(1) earlier.
The good result was had without tweaking the lighting but is already good enough for me - I was aiming at 2 second cycles. So I guess this might be one of those cases where shifting to newer hardware will prove the easiest solution.
-
I have some problems compiling latest chdkptp.
Here are steps to reproduce the problem:
First I svn chdkptp
svn co http://subversion.assembla.com/svn/chdkptp/
Then I red README.TXT where it says I should download prebuilt IUP and CD
Downloading cd-5.6.1_Linux26g4_lib.tar.gz
wget -c http://downloads.sourceforge.net/project/canvasdraw/5.6.1/Linux%20Libraries/cd-5.6.1_Linux26g4_lib.tar.gz?r=http%3A%2F%2Fsourceforge.net%2Fprojects%2Fcanvasdraw%2Ffiles%2F5.6.1%2FLinux%2520Libraries%2F&ts=1368615412&use_mirror=surfnet
Same goes for IUP iup-3.8_Linux32_lib.tar.gz
wget -c http://downloads.sourceforge.net/project/iup/3.8/Linux%20Libraries/iup-3.8_Linux26g4_lib.tar.gz?r=http%3A%2F%2Fsourceforge.net%2Fprojects%2Fiup%2Ffiles%2F3.8%2FLinux%2520Libraries%2F&ts=1368618505&use_mirror=garr
I've then unpacked both in separate directories:
pwd /home/streznik/foto/IUP
pwd /home/streznik/foto/CD
Afterwards I copied config-sample-linux.mk to config.mk in folder where I did sv: /home/streznik/foto/chdkptp/trunk
Here is config.mk
IUP_SUPPORT=0
CD_SUPPORT=0
LUA_INCLUDE_DIR=/usr/include/
DEBUG=1
IUP_LIB_DIR=/home/streznik/foto/IUP
IUP_INCLUDE_DIR=/home/streznik/foto/IUP/include/
CD_LIB_DIR=/home/streznik/foto/CD
CD_INCLUDE_DIR=/home/streznik/foto/CD/include
For better reading I left out lines starting with #
After editing config.ml I ran make in /home/streznik/foto/chdkptp/trunk
make[1]: Entering directory `/home/streznik/foto/chdkptp/trunk/lfs'
gcc -MMD -DCHDKPTP_OSTYPE=\"Linux\" -Wall -g -I/usr/include/ -c -o lfs.o lfs.c
lfs.c:779:30: error: array type has incomplete element type
static const struct luaL_reg fslib[] = {
^
lfs.c: In function ‘luaopen_lfs’:
lfs.c:798:2: warning: implicit declaration of function ‘luaL_register’ [-Wimplicit-function-declaration]
luaL_register (L, "lfs", fslib);
^
lfs.c: At top level:
lfs.c:779:30: warning: ‘fslib’ defined but not used [-Wunused-variable]
static const struct luaL_reg fslib[] = {
^
make[1]: *** [lfs.o] Error 1
make[1]: Leaving directory `/home/streznik/foto/chdkptp/trunk/lfs'
make: *** [all-recursive] Error 1
I'm running archlinux on 32 bit system.
lua versions:
lua 5.2.2-1
lua51 5.1.5-3
Both installed from official repos.
Any help would be much appriciated since I'd like to run latest version of chdkptp for my ixus 220hs aka elph 300hs.
-
As it turns out thanx to c10ud @freenode I was having wrong includes for lua. Those are correct ones for me:
LUA_INCLUDE_DIR=/usr/include/lua5.1
LUA_LIB=lua5.1
Thank you c10ud again :)
-
So I'm using ixus 220 hs aka elph 300hs and when I use chdkptp gui after a few shots it freezes a little and Live area where output text is I get this:
tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0recording to chdk_3229_20130515_161120.lvdump
grabbing frame 1
grabbing frame 2
grabbing frame 3
grabbing frame 4
grabbing frame 5
2448536 bytes recorded to chdk_3229_20130515_161124.lvdump
recording to chdk_3229_20130515_161124.lvdump
tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0live timer update error
/home/streznik/foto/chdkptp/trunk/lua/chdku.lua:1165: write failed
stack traceback:
[C]: in function 'fwrite'
/home/streznik/foto/chdkptp/trunk/lua/chdku.lua:1165: in function 'live_dump_frame'
/home/streznik/foto/chdkptp/trunk/lua/gui_live.lua:342: in function 'record_dump'
/home/streznik/foto/chdkptp/trunk/lua/gui_live.lua:400: in function </home/streznik/foto/chdkptp/trunk/lua/gui_live.lua:383>
[C]: in function 'xpcall'
/home/streznik/foto/chdkptp/trunk/lua/gui_live.lua:424: in function </home/streznik/foto/chdkptp/trunk/lua/gui_live.lua:422>
(tail call): ?
[C]: in function 'MainLoop'
/home/streznik/foto/chdkptp/trunk/lua/gui.lua:677: in function </home/streznik/foto/chdkptp/trunk/lua/gui.lua:663>
(tail call): ?
/home/streznik/foto/chdkptp/trunk/lua/main.lua:227: in main chunk
[C]: in function 'require'
[string "require('main')"]:1: in main chunklive timer update error
/home/streznik/foto/chdkptp/trunk/lua/chdku.lua:1165: write failed
stack traceback:
[C]: in function 'fwrite'
/home/streznik/foto/chdkptp/trunk/lua/chdku.lua:1165: in function 'live_dump_frame'
/home/streznik/foto/chdkptp/trunk/lua/gui_live.lua:342: in function 'record_dump'
/home/streznik/foto/chdkptp/trunk/lua/gui_live.lua:400: in function </home/streznik/foto/chdkptp/trunk/lua/gui_live.lua:383>
[C]: in function 'xpcall'
/home/streznik/foto/chdkptp/trunk/lua/gui_live.lua:424: in function </home/streznik/foto/chdkptp/trunk/lua/gui_live.lua:422>
(tail call): ?
[C]: in function 'MainLoop'
/home/streznik/foto/chdkptp/trunk/lua/gui.lua:677: in function </home/streznik/foto/chdkptp/trunk/lua/gui.lua:663>
(tail call): ?
/home/streznik/foto/chdkptp/trunk/lua/main.lua:227: in main chunk
[C]: in function 'require'
[string "require('main')"]:1: in main chunklive timer update error
/home/streznik/foto/chdkptp/trunk/lua/chdku.lua:1165: write failed
stack traceback:
[C]: in function 'fwrite'
/home/streznik/foto/chdkptp/trunk/lua/chdku.lua:1165: in function 'live_dump_frame'
/home/streznik/foto/chdkptp/trunk/lua/gui_live.lua:342: in function 'record_dump'
/home/streznik/foto/chdkptp/trunk/lua/gui_live.lua:400: in function </home/streznik/foto/chdkptp/trunk/lua/gui_live.lua:383>
[C]: in function 'xpcall'
/home/streznik/foto/chdkptp/trunk/lua/gui_live.lua:424: in function </home/streznik/foto/chdkptp/trunk/lua/gui_live.lua:422>
(tail call): ?
[C]: in function 'MainLoop'
/home/streznik/foto/chdkptp/trunk/lua/gui.lua:677: in function </home/streznik/foto/chdkptp/trunk/lua/gui.lua:663>
(tail call): ?
/home/streznik/foto/chdkptp/trunk/lua/main.lua:227: in main chunk
[C]: in function 'require'
[string "require('main')"]:1: in main chunklive timer update error
/home/streznik/foto/chdkptp/trunk/lua/chdku.lua:1165: write failed
stack traceback:
[C]: in function 'fwrite'
/home/streznik/foto/chdkptp/trunk/lua/chdku.lua:1165: in function 'live_dump_frame'
/home/streznik/foto/chdkptp/trunk/lua/gui_live.lua:342: in function 'record_dump'
/home/streznik/foto/chdkptp/trunk/lua/gui_live.lua:400: in function </home/streznik/foto/chdkptp/trunk/lua/gui_live.lua:383>
[C]: in function 'xpcall'
/home/streznik/foto/chdkptp/trunk/lua/gui_live.lua:424: in function </home/streznik/foto/chdkptp/trunk/lua/gui_live.lua:422>
(tail call): ?
[C]: in function 'MainLoop'
/home/streznik/foto/chdkptp/trunk/lua/gui.lua:677: in function </home/streznik/foto/chdkptp/trunk/lua/gui.lua:663>
It goes like that until lI manage to shutdown camera.
I've also found when enabling Viewfinder in livegui colors are somehow unreadable. Is this normal? (see attachment)
Also how do I access alt menu? For ixus 220hs when I'm in chdk I have to press short video button and then menu. But in chdkptp when I press video it immediatelly starts to capture a video. Can I remap alt menu button somehow? How do I fix this?
Glad I'm using latest chdkptp :) Thank you reyalp!
-
I've also found when enabling Viewfinder in livegui colors are somehow unreadable. Is this normal? (see attachment)
It is a bug: vid_get_palette_type(), vid_get_palette_size(), vid_get_bitmap_active_palette() are missing in ixus220 port. It is specific to ixus220 port, so I posted a patch to ixus220 porting thread (http://chdk.setepontos.com/index.php?topic=6341.msg100562#msg100562).
-
Also how do I access alt menu? For ixus 220hs when I'm in chdk I have to press short video button and then menu. But in chdkptp when I press video it immediatelly starts to capture a video. Can I remap alt menu button somehow? How do I fix this?
Unfortunately, there is currently no way to manipulate the alt menu through Lua (and hence, over PTP). This would be a very useful feature, but the current script architecture does not allow sending keys to the CHDK UI, they just go to the Canon OS. You can set many settings using set_config_value http://chdk.wikia.com/wiki/Script_commands#set_config_value (http://chdk.wikia.com/wiki/Script_commands#set_config_value)
Regarding your other errors, it's very hard to understand without some idea of what you were actually doing. The only actual error I see is
"/home/streznik/foto/chdkptp/trunk/lua/chdku.lua:1165: write failed"
From that looks like you were trying to make a live view dump and the file write failed. This seems like it would most likely be due to something outside chdkptp (permissions or something like that?) but you don't say anything about trying to make a live dump?
The live view dump is probably only useful for debug.
I'm not clear how you would be getting the "tried to set invalid mode 0" spam, this should only happen you change the mode dropdown menu.
-
It is a bug: vid_get_palette_type(), vid_get_palette_size(), vid_get_bitmap_active_palette() are missing in ixus220 port. It is specific to ixus220 port, so I posted a patch to ixus220 porting thread (http://chdk.setepontos.com/index.php?topic=6341.msg100562#msg100562).
Thank you natraf, I've tested it: http://chdk.setepontos.com/index.php?topic=6341.msg100594#msg100594 (http://chdk.setepontos.com/index.php?topic=6341.msg100594#msg100594)
reyalp: whenever I switch from rec to play mode but not from play to rec mode I get this:
tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0tried to set invalid mode 0
Note: this is for each switch.
Unfortunately, there is currently no way to manipulate the alt menu through Lua (and hence, over PTP). This would be a very useful feature, but the current script architecture does not allow sending keys to the CHDK UI, they just go to the Canon OS. You can set many settings using set_config_value http://chdk.wikia.com/wiki/Script_commands#set_config_value (http://chdk.wikia.com/wiki/Script_commands#set_config_value)
Thank you reyalp, yes it would be great to have alt menu. Will digg into this at least for enabling/disabling dng option.
-
reyalp: whenever I switch from rec to play mode but not from play to rec mode I get this:
OK, I see this on linux too, looks like a difference in behavior either due to IUP version or the underlying gui toolkits. It looks like emptying the dropdown is calling gui.mode_dropdown:valuechanged_cb for each item that was in the list. I'll look into this more later, but these messages are probably harmless.
-
Hi reyalp,
I've compiled for 64bit version of linux and sometimes (can't reproduce when) I experience following behaviour. I turn usb cable into camera and into computer. On computer is usb 3.0
Then I power up camera and I see only for a second or less last taken photo and then display immediately goes to sleep (only green light is on) display turns off. And if I don't turn camera off before I start chdkptp and connects I have to cold reboot it (take the battery out)
bash chdkptp-sample.sh -c -i
connected: Canon IXUS 220 HS, max packet size 512
con> set cli_verbose=1
con> set cli_time=true
time 0.0000
con> rec
time 0.1029
con 1> shoot
time 0.0386
con 2> shoot -raw=1
time 0.0344
con 3> q
time 0.0000
bye
I do all this and I can't shoot, camera won't actually go to rec mode.
I'm not sure if this is only on 64 bit computer but I experienced twice in a day today.
P.S. It also happens on usb 2.0 and other usb ports. After connecting to device I can execute stuff for a period of time but then it becomes unresponsible I can't even reboot device from cli.
-
I do all this and I can't shoot, camera won't actually go to rec mode.
I'm not sure if this is only on 64 bit computer but I experienced twice in a day today.
P.S. It also happens on usb 2.0 and other usb ports. After connecting to device I can execute stuff for a period of time but then it becomes unresponsible I can't even reboot device from cli.
Waterwingz also reported something like this. My strong suspicion is that there is something automatically accessing the camera and changing it's state when you connect it (for example, something that tries to automount the camera or transfer photos). This is not specific to 64 bit, but might be be related to newer kernels or distros. I have seen similar effects on windows when using the "filter" libusb driver rather than the "inf" driver.
If you look at the kernel log, that may give some hints. You might also find something in the udev rules, mentioned in this post http://chdk.setepontos.com/index.php?topic=6231.msg89252#msg89252 (http://chdk.setepontos.com/index.php?topic=6231.msg89252#msg89252)
-
Waterwingz also reported something like this. My strong suspicion is that there is something automatically accessing the camera and changing it's state when you connect it (for example, something that tries to automount the camera or transfer photos). This is not specific to 64 bit, but might be be related to newer kernels or distros. I have seen similar effects on windows when using the "filter" libusb driver rather than the "inf" driver.
While I'm not saying you are wrong, but I've been reliably downloading scripts and CHDK updates to my various cameras using chdkptp with no issues since I reported that. Seems like that says I am gettting "control" of the USB port?
And I can connect with liveview and watch as I navigate CHDK menus with the cam's buttons ( that's where I got the screenshots I recently posted in another thread ).
But if I click the "rec" button its all over. I basically need to pull the battery to get the camera back.
Sorry .. that just does not seem like a phantom photo application in the background (on my very stripped linux box) somehow grabbing the USB port / camera / camera interface.
-
Waterwingz also reported something like this. My strong suspicion is that there is something automatically accessing the camera and changing it's state when you connect it (for example, something that tries to automount the camera or transfer photos). This is not specific to 64 bit, but might be be related to newer kernels or distros. I have seen similar effects on windows when using the "filter" libusb driver rather than the "inf" driver.
While I'm not saying you are wrong, but I've been reliably downloading scripts and CHDK updates to my various cameras using chdkptp with no issues since I reported that. Seems like that says I am gettting "control" of the USB port?
And I can connect with liveview and watch as I navigate CHDK menus with the cam's buttons ( that's where I got the screenshots I recently posted in another thread ).
But if I click the "rec" button its all over. I basically need to pull the battery to get the camera back.
Sorry .. that just does not seem like a phantom photo application in the background (on my very stripped linux box) somehow grabbing the USB port / camera / camera interface.
Do you get this on all cameras or just the memory limited A1200?
The PTP code grabs a lot of memory when in use so that could be a problem on the A1200.
Phil.
-
While I'm not saying you are wrong, but I've been reliably downloading scripts and CHDK updates to my various cameras using chdkptp with no issues since I reported that. Seems like that says I am gettting "control" of the USB port?
I'm not saying you don't have "control" of the USB port now. I'm saying that something changed the state of the camera before you got control. But if you have a better theory, feel free to post it.
-
Do you get this on all cameras or just the memory limited A1200?
It started happening when he upgraded his linux distro, and doesn't happen under windows.
-
I'm not saying you don't have "control" of the USB port now. I'm saying that something changed the state of the camera before you got control.
So something slipped in and changed the state of the camera's PTP state so that everything but going to "rec" mode works? If I go do a ps -A and kill everything but core stuff ( that will be fun to figure out ) should I be able to get past that? Is it a user level app or something that's hooked at the kernel level?
But if you have a better theory, feel free to post it.
Touchy. Hey - I'm just trying to compile the facts I can.
-
Do you get this on all cameras or just the memory limited A1200?
The PTP code grabs a lot of memory when in use so that could be a problem on the A1200.
It on my G10 - which has tons of free memory.
I'm not even sure the palette stuff and any other PTP hooks are done for the other three cameras.
It started happening when he upgraded his linux distro, and doesn't happen under windows.
Well, more correctly, I had not used anything but file download for a long time and during that interval I did an update to Fedora18. I had not done an svn update in a long while - it wasn't broken and I thus had no need to fix it - or even think about it. The upgrade required updating the IUP code to a current release and I did an svn up at the same time. Its not clear that things worked immediately prior to the upgrade and stopped working immediately after the upgrade.
-
So something slipped in and changed the state of the camera's PTP state so that everything but going to "rec" mode works? If I go do a ps -A and kill everything but core stuff ( that will be fun to figure out ) should I be able to get past that? Is it a user level app or something that's hooked at the kernel level?
As I tried to explain several times, most modern linuxes have stuff that runs as soon as you plug something into USB. This includes kernel and userspace components. The userspace components are likely to be invoked only when the actual plugin event happens, so randomly killing daemons would not necessarily prevent it.
This is something that could be investigated and proven or disproven by someone who has one of the affected systems.
Its not clear that things worked immediately prior to the upgrade and stopped working immediately after the upgrade.
I am 100% (ok, 99.999%) certain this has nothing to do with IUP. This can easily be verified by building without IUP support. (IUP_SUPPORT=0 in config.mk)
Given that it still works on windows and still works on my linux systems, this strongly suggests something specific to your particular linux configuration.
If this is triggered by a change in CHDK or chdkptp, then reverting to an old version (from about the time we implemented live view for the G10) should be a good way to check that. But I see no mechanism for changes in either to cause the observed behavior, while I have seen similar behavior triggered by meddling OSes.
edit: live view was merged in trunk 1921, the corresponding chdkptp revision is 253
-
As I tried to explain several times, most modern linuxes have stuff that runs as soon as you plug something into USB. This includes kernel and userspace components. The userspace components are likely to be invoked only when the actual plugin event happens, so randomly killing daemons would not necessarily prevent it.
I got it the first time. I was just struggling with something that runs and only stops the camera from accepting a command to go from playback to shooting mode.
So I just went back and tried some more things. I can look at files (second tab) and download them. I can use live view to watch what happens when I press camera buttons. But it turns out that I can't use any of the GUI camera buttons on the chdkptp app to do anything (like Left or Right to scroll through saved images in playback while not in <ALT> mode).
And then all of a sudden, the CHDKPTP camera buttons started working. Go to shoot mode ... shoot .. go to playback mode ... scroll through pictures .. Wasn't doing anything that I can recall to make that start happening - just clicking buttons while I wrote the description above.
Closed chdkptp, restarted the camera, run chdkptp again. No button response now.
I get it that is something to do with my Fedora18 64 bit install. But that does not help me much. So I'll just leave it for now - its not something I personally need.
-
I get it that is something to do with my Fedora18 64 bit install. But that does not help me much. So I'll just leave it from now - its not something I personally need.
Since this seems to affect other users, I'd like to understand it and find workarounds, but that's pretty hard without an affected system.
FWIW, I found that my D10, listing PTP objects using normal PTP protocol will make the screen go black. This can be done in with ptpcam using
ptpcam -L
or in gphoto with
$ gphoto2 --shell
> ls
store_00010001/
> ls store_00010001
DCIM/ PS.FI2
After doing this, chdkptp can connect, but the screen stays black and rec doesn't work.
edit:
the same happens if I access the "camera" that is automounted in the file manager.
But it turns out that I can't use any of the GUI camera buttons on the chdkptp app to do anything (like Left or Right to scroll through saved images in playback while not in <ALT> mode).
This is normal. To unlock the keyboard, you have to either switch to rec mode (if you could ;)) or post the magic levent
.post_levent_to_ui(4484)
-
Hi reyalp & waterwingz
I've red through your last posts and I think I have the effected machine as waterwingz. I'll also test on 32 bit as I think this computer wasn't effected because I was remotely accessing it... I too can download or upload files if I'm not pressing rec button. Yesterday I found out or got an idea that indeed automount could have something to do with usb blocking stuff. I use pcmanfm and if it's not opened automount for usb devices won't work. I'll take a closer look about automounting and kernel logs later today or tomorrow. Have some other work to do first.
-
Since this seems to affect other users, I'd like to understand it and find workarounds, but that's pretty hard without an affected system.
I run a somewhat hacked version of Fedora18 that uses xmonad under gnome as its desktop manager. USB automount does not work without a separate daemon - the details of how I got that working escape me at the moment.
So I guess this weekend I can try just running a straight "startx" after setting things to just boot to the command line. I think I can also run xmonad without gnome or maybe even another display manager ( IceWM ?).
Is there some additional information that could be dumped to the log window when one of the GUI buttons is pressed (and noting happens ...) ?
If I get a minute, I'll see if I can track down something that logs USB port activity more closely too.
-
So I guess this weekend I can try just running a straight "startx" after setting things to just boot to the command line. I think I can also run xmonad without gnome or maybe even another display manager ( IceWM ?).
Note this is not necessarily GUI related. udev rules run whether you are running X or not.
Is there some additional information that could be dumped to the log window when one of the GUI buttons is pressed (and noting happens ...) ?
Not really. Switching to rec mode is not special, it's just a lua function like any other. The fact that everything but switching to rec mode works as expected really means this is some internal camera state difference, not a client problem or a communication problem. As I explained in my previous post, ignoring keys like set, arrows etc is a separate, known issue (also due to camera state, not due to CHDK doing anything differently).
If you send
=switch_mode_usb(1)
to the camera, and there is no error but the camera doesn't switch, it clearly means this function is not behaving as it normally does. This is the firmware doing something different, not the client or CHDK doing something different. The USB connection is fine, the command was sent successfully, nothing in the client can tell the difference between this and any other function. As far as the client was concerned, everything worked fine, so there's really nothing to log.
If I get a minute, I'll see if I can track down something that logs USB port activity more closely too.
The kernel log (usually something like /var/kern.log and dmesg output) may have something.
A question, when you are connecting for the first time with chdkptp, do you get something like
open_camera_dev: ptp_opensession failed 0x2ff
open_camera_dev:usb_ptp_device_reset(): Device or resource busy
usb_ptp_get_device_status(): Device or resource busy
connected: Canon PowerShot D10, max packet size 512
If so, this means that something else had the camera open at the time. If not, that doesn't mean nothing touched it, but whatever it is probably doesn't have it open.
@frojnd
What distros / versions are you using, and what desktop?
-
Note this is not necessarily GUI related. udev rules run whether you are running X or not.
It came to me mid-day that I needed to remove the GUI from the equation. I discovered that running from a terminal window under Gnome, using =switch_mode_usb(1) or rec gets no reaction from the camera and no error messages on the command line.
So I changed my system default run level to 3 and rebooted into a base level console only mode. At that point chdkptp works fine - I can switch back and forth between playback and shooting modes and take pictures with the shoot command.
I'll see if I can get a simple X terminal mode only from the level 3 runlevel and try that.
Update : I do in fact get the error you asked about when running in a terminal window under gnome :
open_camera_dev: ptp_opensession failed 0x2ff
open_camera_dev:usb_ptp_device_reset(): Input/output error
usb_ptp_get_device_status(): Input/output error
connected: Canon PowerShot G10, max packet size 512
-
On my ubuntu system, I get something like this in dmesg output when I plug a camera in
[1027349.801292] usb 1-2: new high speed USB device using ehci_hcd and address 16
[1027349.953166] usb 1-2: configuration #1 chosen from 1 choice
Using this you can find the device associated with it. On my system, this comes out to /dev/bus/usb/001/016
We can see what has it open:
$ fuser /dev/bus/usb/001/016
/dev/bus/usb/001/016: 26824
$ ps -A | grep 26824
26824 ? 00:00:00 gvfsd-gphoto2
When I run chdkptp (producing the error messages in my earlier post), I get the following in dmesg
[1027736.312695] usb 1-2: usbfs: interface 0 claimed by usbfs while 'chdkptp' sets config #1
[1027736.312776] usb 1-2: usbfs: process 26990 (chdkptp) did not claim interface 0 before use
[1027736.312847] usb 1-2: usbfs: process 26990 (chdkptp) did not claim interface 0 before use
[1027736.312933] usb 1-2: usbfs: process 26990 (chdkptp) did not claim interface 0 before use
[1027736.430053] usb 1-2: reset high speed USB device using ehci_hcd and address 16
This is chdkptp stealing it from gvfsd-gphoto2.
Note that this "stealing" probably isn't the problem. Rather the problem is that whatever grabs the camera first is doing something that changes the camera state, like listing PTP objects.
-
From a cold boot, once dmesg has settled down, I plug in my G10 and get this :
[ 76.973571] usb 2-5: new high-speed USB device number 2 using ehci-pci
[ 77.090927] usb 2-5: New USB device found, idVendor=04a9, idProduct=318f
[ 77.090940] usb 2-5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 77.090948] usb 2-5: Product: Canon Digital Camera
[ 77.090954] usb 2-5: Manufacturer: Canon Inc.
[ 77.090959] usb 2-5: SerialNumber: xxxxxxxxxxxxxxxxxxxxxxxxxx
[ 122.265610] usb 2-5: reset high-speed USB device number 2 using ehci-pci
[ 174.526315] usb 2-5: reset high-speed USB device number 2 using ehci-pci
[ 317.464282] usb 2-5: reset high-speed USB device number 2 using ehci-pciThe last three lines are me going in & out of chdkptp.
[a@acer ~]$ fuser /dev/bus/usb/002/002
/dev/bus/usb/002/002: 1618
[a@acer ~]$ ps -A | grep 1618
1618 pts/1 00:00:00 chdkptp
[a@acer ~]$ Using fuser shows chdkptp attaching, but there is nothing else there when I'm not in chdkptp. Perhaps gvfsd-gphoto2 exits right away?
Note that this "stealing" probably isn't the problem. Rather the problem is that whatever grabs the camera first is doing something that changes the camera state, like listing PTP objects.
So is there a "reset state" command that can be sent over ptp to the camera?
Just going into chdkptp in interactive mode, connecting and sending "rec" locks the camera up needing a battery reset. Its not crashed - my "Led blinker" task in the G10 is still running and blinking the power LED.
Also, at one point much earlier today I did see a dmesg message about gvfs-gphoto2-vo and "did not claim interface 0 before use" but I have not been able to reproduce it.
Update : using ps -A | grep gphoto I was able to find the pid for gvfs-gphoto2-vo and do a kill -s 15 1245. It seems to stay "killed" and now when I plug in my G10 I can use all of the chdkptp commands.
-
Using fuser shows chdkptp attaching, but there is nothing else there when I'm not in chdkptp. Perhaps gvfsd-gphoto2 exits right away?
The fact that you get the reset messages on the first connection suggests that something has it in use.
It's possible that the USB device appears at multiple paths (not via symlinks). You could look at
ls -l /proc/<pid of gvfs-gphoto2-vo>/fd to see what it has open.
So is there a "reset state" command that can be sent over ptp to the camera?
Your mission, should you choose to accept it...
I tried some combinations of post_levent_to_ui("DisconnectUSBCable");post_levent_to_ui("ConnectUSBCable") but the results were not good... camera hanging and needing power unplugged to restart. I haven't tried the post_levent_for_npt variants.
Alternately, you should be able to configure the gvfs-gphoto2 system somewhere to not automatically mount/scan the camera.
Anyway, this is all good information, at least we have a good idea why it's happening. Thanks for investigating.
-
Alternately, you should be able to configure the gvfs-gphoto2 system somewhere to not automatically mount/scan the camera.
http://www.freeklijten.nl/home/2011/06/04/Mounting-a-Canon-EOS-550d-on-Ubuntu-using-gphoto2#wl-comment-672 (http://www.freeklijten.nl/home/2011/06/04/Mounting-a-Canon-EOS-550d-on-Ubuntu-using-gphoto2#wl-comment-672)
Following the above posting, I renamed the following files (the last one is different than what's in the post):
/usr/share/dbus-1/services/org.gtk.Private.GPhoto2VolumeMonitor.service
/usr/share/gvfs/mounts/gphoto2.mount
/usr/share/gvfs/remote-volume-monitors/gphoto2.monitor
/usr/libexec/gvfs-gphoto2-volume-monitor
On reboot, the gvfs_gphoto_volume_monitor no longer runs and chdkptp works correctly.
But I'm not sure what else I've lost as a result.
-
On reboot, the gvfs_gphoto_volume_monitor no longer runs and chdkptp works correctly.
But I'm not sure what else I've lost as a result.
Probably file manager type browsing of PTP devices.
I would expect there there's a place where you can filter which devices are affected. (edit: i.e., one of those things you renamed is a shell script or something that decides which devices it wants to handle, or there is a conf file referenced by one that does the same)
edit:
fuse discussion moved to the ptp thread http://chdk.setepontos.com/index.php?topic=4338.msg100727#msg100727 (http://chdk.setepontos.com/index.php?topic=4338.msg100727#msg100727)
-
What distros / versions are you using, and what desktop?
Archlinux on both computers with xmonad WM or lxde DE.
-
I have played a little bit around the GUI. It's my first try to design some icons for IUP.Lua. All icons were converted with the program iupview.
All icons are in one extra file (gui_icon.lua). Some changes in gui.lua were necessary.
- old images from scratchpad deleted
- image tags for icons inserted
- function cam_btn() for icons changed
- slightly reformatted button area
- window dimension changed (height 560 instead 460 because different height of the tabs)
- small corrections
- added function for shoot+download with selection of a destination (user request from German forum)
msl
-
I have played a little bit around the GUI. It's my first try to design some icons for IUP.Lua. All icons were converted with the program iupview.
Nice work. My only comment on the buttons is I'm not sure the half shoot and shoot are very clear. If they had a tooltip, that could solve it.
- added function for shoot+download with selection of a destination (user request from German forum)
I don't know if you saw, but yesterday I added some download options to the the 'shoot' cli command http://trac.assembla.com/chdkptp/changeset/347/trunk (http://trac.assembla.com/chdkptp/changeset/347/trunk) Not finished yet, still need to allow specifying the destination directory and name(s). It's a little complicated because there might be more than one file.
For the gui, I'd like to have a "shoot options" somewhere, which would have controls like
raw [dropdown <none>,dng,chdk]
download [] jpeg [] raw
delete [] jpeg [] raw
[folder button] [c:\selected\path...]
tv [....] av [...] sv [...]
This could go in a non-modal popup window maybe. Most of the actual work could be done with the shoot cli command.
-
My only comment on the buttons is I'm not sure the half shoot and shoot are very clear.
You're right. But I had no better idea: a green rectangle (focus ready) for 'half shoot' & a stylized shutter for 'shoot'. A tooltip is a good idea.
I don't know if you saw, but yesterday I added some download options to the the 'shoot' cli command
Yes, I saw it. But the 'shoot&download' function was already finished. Your suggestion is good.
Maybe we need an additional tab for user defined functions. I have read about a HDR GUI function in any post, don't remember where. Also a kind of .ini file would be interesting.
msl
-
Also a kind of .ini file would be interesting.
Yes, some way to save settings would be good. This is on my todo list... but as you can see my progress is slow. My original intention for the "prefs" is that they could be saved and loaded.
If you want to load customization at startup, you can use the "rc file" functionality.
.chdkptprc is run when you start the cli, .chdkptpguirc is used for the gui. On windows, _ is used instead of a . because windows explorer doesn't let you name files .foo
You can run any chdkptp commands there, so you could load your own lua addons with
!require'mymodule'
in your startup file
For additions to the gui, this might be tricky because the rc file is run before the main gui is fully created. Possibly the gui startup should have a hook of some kind to call user functions.
-
Hi reyalp,
I think a few posts are missing...
I was trying to put my camera into record mode with LUA script but I had no luck. It works if I run script from camera but if I try to run it with chdkptp nothing happens and it's stuck. If I try anything afterwards I get: ERROR: a script is already running. The only thing I'm left with is to press on power button on camera to shut it down and start it again.
if (get_mode()==false) then
sleep(1000)
set_record(1)
while (get_mode()==false) do
sleep(100)
end
sleep(1000)
end
shoot()
This code works if I run it directly on a camera, but in chdkptp it won't. Any ideas how to put camera into record mode when running script on chdkptp?
-
Hi reyalp,
I think a few posts are missing...
It does look that way :blink:
I was trying to put my camera into record mode with LUA script but I had no luck.
You need to use switch_mode_usb() rather than set_record (this is a historical artifact, different calls are needed when the camera is connected via ptp, but really chdk should detect do the right thing). You can look at the source of the rec and play cli commands for examples:
http://trac.assembla.com/chdkptp/browser/trunk/lua/cli.lua#L1402 (http://trac.assembla.com/chdkptp/browser/trunk/lua/cli.lua#L1402)
The code inside the call to con:execwait is what is sent to the camera.
If you are going to do something immediately after switching, you should wait until the switch completes, as in the code you posted. It's a good idea to not call switch_mode_usb() if you are already in the desired mode.
http://chdk.wikia.com/wiki/Lua/PTP_Scripting (http://chdk.wikia.com/wiki/Lua/PTP_Scripting) describes a lot of the ptp specific issues.
-
Thank you reyalp :)
Time to rewrite a few lines :) Much appreciated!
-
I'm currently have an inconsistent problem with downloading photos from my camera using chdkptp and the mdl command.
My setup is basically this a Raspberry Pi + Canon Ixus 110 IS (SD960IS) + stepper motor.
The motor turns the camera and a photo is taken at each position (usually at least 13), then all the photos should be downloaded then sent to another system to do the panorama stitching.
Sometimes all the photos download absolutely fine off the camera but other times there's some errors after around about 10 photos. I get this...
unexpected return code 0x2ff
ERROR: download failed
unexpected return code 0x2ff
ERROR: ptp error
ERROR: Could not close session!
Sometimes it seems to stall at about 10 photos but then manages to carry on and complete the download without error.
I've tried adding the -batchsize=n option in case that made a difference (using either 1 or 10 for n) but it doesn't seem to make any difference. What does "batchsize" refer to anyway? What is one batch?
I've never had any SD card issues with my Raspberry Pi even though it is only a Class 2 2GB card, but could the card speed be an issue here?
Currently using CHDK version 2904 and chdkptp r330.
-
unexpected return code 0x2ff
ERROR: download failed
This is just a generic error that means the connection is gone or not working, so it doesn't really tell us much. Is the camera crashed when this happens?
If the camera is crashed, try to get a romlog: http://chdk.wikia.com/wiki/Debugging#Camera_crash_logs_.28romlog.29 (http://chdk.wikia.com/wiki/Debugging#Camera_crash_logs_.28romlog.29)
If it isn't crashed, try to describe what state the camera is in: can you reconnect chdkptp, can you interact with it using the physical buttons etc.
Is the shoot and download automated by some process? Having the download too close to the shoot can cause crashes. This will produce a distinct romlog.
I've tried adding the -batchsize=n option in case that made a difference (using either 1 or 10 for n) but it doesn't seem to make any difference. What does "batchsize" refer to anyway? What is one batch?
batchsize controls how the directory listing information is sent. This is used to limit the amount of memory used on the camera. It should not be an issue if there are only a few files on the card. -dbgmem should print some memory info, but it appears to be broken in the current svn.
edit:
I fixed the dbgmem option in changeset 377.
-
When the error occurs I am able to reconnect with chdkptp right away and issue commands.
The camera doesn't crash and still responds to button presses that are available whilst plugged in via USB, Menu, Power.
I already have a 2 second delay in to allow any commands to finish, as well as that I've tried closing the connection after taking the photos then opening a new session to download them. This doesn't improve things.
For the time being I could add a few lines to my script to check how many photos have been downloaded and if it's not the right amount to try again until I get them all.
-
When the error occurs I am able to reconnect with chdkptp right away and issue commands.
OK, that doesn't sound like any of the problems I had in mind.
This could happen if some other program grabbed the USB connection. You could try looking in the kernal log (dmesg output) to see of something particular happens at the times you lose connection.
It could also be the USB connection being flaky I guess. Do you have any other USB devices plugged into the pi? Are you using a powered hub? The camera itself should be fine on USB, but other devices that expect to get a significant amount of power can cause problems if you aren't using a powered hub.
I already have a 2 second delay in to allow any commands to finish, as well as that I've tried closing the connection after taking the photos then opening a new session to download them. This doesn't improve things.
Yeah, if the camera doesn't crash, it's not the timing thing.
For the time being I could add a few lines to my script to check how many photos have been downloaded and if it's not the right amount to try again until I get them all.
You could also use chdkptp side lua or modify the mdownload cli command to reconnect if there is an error.
When you get the error, do you get an incomplete file?
-
OK, that doesn't sound like any of the problems I had in mind.
This could happen if some other program grabbed the USB connection. You could try looking in the kernal log (dmesg output) to see of something particular happens at the times you lose connection.
It could also be the USB connection being flaky I guess. Do you have any other USB devices plugged into the pi? Are you using a powered hub? The camera itself should be fine on USB, but other devices that expect to get a significant amount of power can cause problems if you aren't using a powered hub.
Thanks for the replies.
As it happens I've changed the USB hub since I last posted and I think the issue has gone. I've tried to replicate the issue with the new USB hub but all downloads seem to have been successful and without error so it looks like it could well be a Pi USB problem with the other hub (which wouldn't really be a surprise considering the known Pi USB issues).
If the issue occurs again I'll get whatever logs I can, but it's looking like an RPi USB issue rather than chdkptp problem.
-
If you build your own chdkptp, it's very important that Lua be linked to exactly the same C runtime library as chdkptp itself. The lbuf file routines expect to be able to fread and fwrite on a FILE * opened by lua io.open()
This condition probably won't be met if you use a pre-compiled Lua dll on windows. I think it's probably OK with a shared lua in typical linux environments, but I could be wrong. If in doubt, build your own Lua with the same compiler you build chdkptp with.
You can use
!require'tests':runall()
to test some aspects of your chdkptp build. It should crash or fail if the runtimes aren't compatible.
-
I've uploaded snapshot build r384 to the chdkptp files area:
https://www.assembla.com/spaces/chdkptp/documents (https://www.assembla.com/spaces/chdkptp/documents)
This includes remote capture support for the current trunk. This is available using the 'rs' command. Use
help rs
for details.
There are still some loose ends:
1) Exposure controls are not integrated in the rs command. rs should probably be integrated into the regular shoot command, or at least given equivalent options.
2) If you use rs without any options on a camera that does not have filewrite support, you will get an error "'unsupported format" because it defaults to jpeg, but jpeg is not supported. -raw or -dng should still work. In this case, the jpeg will be saved on the camera.
3) DNG does not currently create a thumbnail or patch badpixels
4) rs (and shoot) don't wait for the flash to be ready, so shooting is likely to fail if flash is enabled
The new protocol commands can also be accessed directly in lua using the chdk_connection api (documented in chdkptp.c). There are also helpers in chdku (documented in chdku.lua) to make it more convenient.
edit:
corrected above, the "shoot" cli command already used shoot()
-
I switched the chdkptp 'rs' command to use shoot instead of a get_shooting() loop. This should avoid the timeouts when the flash isn't ready.
This only applies to single shot mode, continuous still uses a get_shooting() loop.
I haven't made an updated build yet, these are lua only changes, so you can just grab cli.lua and rlibs.lua from svn.
-
Hi reyalp. I'm testing chdkptp-r384-win32 on a A2300 camera using the latest trunk version of CHDK (a2300-100f-1.2.0-2954-full_ALPHA.zip ). I can't get remoteshoot (rs) past "usb capture not supported". I've tried rs , rs -raw , rs C:\test -raw and so on but always get the same error message (see previous sentence). Any ideas on what could be amiss here?
-
Hi reyalp. I'm testing chdkptp-r384-win32 on a A2300 camera using the latest trunk version of CHDK (a2300-100f-1.2.0-2954-full_ALPHA.zip ). I can't get remoteshoot (rs) past "usb capture not supported". I've tried rs , rs -raw , rs C:\test -raw and so on but always get the same error message (see previous sentence). Any ideas on what could be amiss here?
Are you sure you have the right diskboot and modules on your camera?
"usb capture not supported" should only appear if the lua module doesn't have the "init_usb_capture" function.
What is the output of
vers -p
in chdkptp?
-
I get "unknown command 'vers' ".
If I run "version" in interactive command line mode I get: "host:2.5 cam:2.4"
-
Use 'ver' instead of 'vers'. See also: http://trac.assembla.com/chdkptp/browser/trunk/USAGE.TXT#L187 (http://trac.assembla.com/chdkptp/browser/trunk/USAGE.TXT#L187)
msl
-
I get "unknown command 'vers' ".
Oops, sorry about, it should have be 'ver' but 'version' is the same.
If I run "version" in interactive command line mode I get: "host:2.5 cam:2.4"
Your camera is not actually running a version that supports remote capture. If you are using a multi-partition card, you might not have updated the right partition.
You can use =return get_buildinfo() to see what build you are actually running.
-
Thanks. I had failed to overwrite some of the older files on the SD card. Working now.
I did some speed tests. When I run
rs C:\ -dng the shot takes ~2.2 seconds. The camera doesn't support remoteshoot to jpg. using -raw and -dnghr takes about the same time as -dng.
When I do a regular shoot using =t0=get_tick_count();press('shoot_half');repeat sleep(10) until get_shooting();t1=get_tick_count();click('shoot_full');repeat sleep(10) until not get_shooting(); t2=get_tick_count();return t1-t0,t2-t1 the shot takes ~1.9 seconds (I got it down to that by setting jpeg quality override in the CHDK menu to "normal")
Is it to be expected that the remoteshoot will take longer time? Or do you see any ways to make it as fast as or even faster than the regular shoot?
-
Thanks. I had failed to overwrite some of the older files on the SD card. Working now.
I did some speed tests. When I run
rs C:\ -dng the shot takes ~2.2 seconds. The camera doesn't support remoteshoot to jpg. using -raw and -dnghr takes about the same time as -dng.
When I do a regular shoot using =t0=get_tick_count();press('shoot_half');repeat sleep(10) until get_shooting();t1=get_tick_count();click('shoot_full');repeat sleep(10) until not get_shooting(); t2=get_tick_count();return t1-t0,t2-t1 the shot takes ~1.9 seconds (I got it down to that by setting jpeg quality override in the CHDK menu to "normal")
Is it to be expected that the remoteshoot will take longer time? Or do you see any ways to make it as fast as or even faster than the regular shoot?
Are you saving DNG on the card in the no-remote shoot case?
A more apples to apples comparison would be
shoot -dng -dl
which shoots a dng, saves it to the card, and then downloads. Remote shoot should be substantially faster than this.
On my D10, remoteshoot with DNG download is somewhat faster than saving to a slow card. However, D10 has filewrite support, so it is also skipping writing the jpeg to the card. I haven't measured how much that affects the timing.
The times will depend on your camera, card, and host system. If you don't need the image immediately, shooting and saving to the card may give you the faster shot rate.
Also note that "repeat sleep(10) until not get_shooting()" doesn't actually wait until jpeg is completely finished.
-
Are you saving DNG on the card in the no-remote shoot case?
No I saved JPG to the card in the no-remote case. I get that that makes it an apples/oranges comparison in a way. But I only used DNG for the remote shoot case because my camera didn't support JPG there. So what I'm trying to compare in terms of speed is
1. my current usage which is a JPG shoot to the SD card and
2. the fastest remote shoot case with output that can be postprocessed into a JPG of about the same quality as in 1
Also note that "repeat sleep(10) until not get_shooting()" doesn't actually wait until jpeg is completely finished.
Ok. What I really wish to time is the entire cycle. I.e. how many miliseconds until a user can successfully trigger a new chdkptp command line argument for another shoot.
-
But I only used DNG for the remote shoot case because my camera didn't support JPG there.
OK, definitely shouldn't expect anything with raw/DNG to be faster than jpeg. The size of the raw data will likely swamp everything else.
I haven't really tried to measure it, but I wouldn't expect remote shoot with jpeg (on cameras with filewerite implemented) to be much different than saving to SD card. The saving / transfer time is a relatively a smaller part of the whole process.
If you want to get each image as it is shot, remote capture will speed that up, because otherwise you would be saving and then transferring.
If you need this, someone may be willing to implement filewrite support for you on this camera.
-
If you need this [remote shoot JPG], someone may be willing to implement filewrite support for you on this camera.
Ok, good to know that there is a possibility. I first assumed it was a hardware limitation with the A2300. I'll add a quote from you from another thread with more details in case someone else reads this thread also looking for remote shoot JPG for their camera.
Raw/dng capture should work on all cameras, but the jpeg will be saved to the card. To support jpeg and and suppressing jpeg writes, filewritetask needs to be implemented. Patches adding filewrite support for more cameras are welcome. Requests for filewrite support on specific cameras are also welcome.
Is there a list of cameras that already work with remote shoot JPG?
-
Is there a list of cameras that already work with remote shoot JPG?
There is not an official list, but it is possible to get it using grep in source code directory.
grep CAM_HAS_FILEWRITETASK_HOOK platform/*/platform_camera.h | awk '{print $1}' | awk 'BEGIN{FS="/"}; {print $2}' > remotecapture_support.txt
CHDK for 2300 100f with remote capture support: http://chdk.setepontos.com/index.php?topic=8318.msg102877#msg102877 (http://chdk.setepontos.com/index.php?topic=8318.msg102877#msg102877)
-
Thanks for the list nafraf.
The latest trunk release for A2300 100f already works with remote shoot in chdk ptp. What is the difference in the file you link to?
-
Thanks for the list nafraf.
The latest trunk release for A2300 100f already works with remote shoot in chdk ptp. What is the difference in the file you link to?
remote shoot JPG ( rs -jpg )
-
nafraf: I tried it and it works fine. This is great! "rs" now outputs JPG files to the harddrive.
I timed it. "rs C:\ -jpg" takes on average 2.1 seconds on my a2300.
For comparison:
"rs C:\ -dng" ~2.3 seconds
"shoot" (saves to SD card) ~1.8 seconds
I also have the powershot A490 camera so I might as well throw out a request for filewrite for that too while I'm at it :)
edit: nafraf has added filewrite for the A490 camera; see this thread http://chdk.setepontos.com/index.php?topic=5051.220 (http://chdk.setepontos.com/index.php?topic=5051.220)
-
Do you get this on all cameras or just the memory limited A1200?
It started happening when he upgraded his linux distro, and doesn't happen under windows.
Hi
Just installed chdk (1.1.0-2968) on a Canon G7 (1.00i) and using R384-win32 on XP
I am having the same issues. The camera will not go into rec mode with the usb cable connected. Everything else either from the camera or via the command line appears to be working OK.
This is all new to me so if you provide specific details I can supply further info.
-
Just installed chdk (1.1.0-2968) on a Canon G7 (1.00i) and using R384-win32 on XP
The issue waterwingz was having had to do with other software accessing the camera on connect, putting it in a state that makes mode switching not work.
This can happen on windows, especially if you are using the "filter" driver. I would highly recommend using the INF driver if you aren't already. Note that this will normally disable regular PTP access to the camera. You can remove the driver if you want to restore the original behavior.
Does the camera screen go black when you plug it in? This is usually an indication that some other program tried to access it.
Also to be clear, the camera should be in PLAY mode when you plug it in, and when you want to switch mode, you should use the "rec" command in chdkptp. If you try to switch using the physical controls on the camera, it probably won't work.
I don't recall anyone reporting using the G7 with PTP before, so another possibility is that mode switching over PTP just doesn't work on this camera.
AFAIK the G7 does support Canon's remote capture API, so you may be able to accomplish whatever you are trying to do with other software.
-
I would highly recommend using the INF driver if you aren't already.
Using the INF driver with the camera listed in device manager
Does the camera screen go black when you plug it in?
No. Continues to show the last image taken.
Also to be clear, the camera should be in PLAY mode when you plug it in, and when you want to switch mode, you should use the "rec" command in chdkptp. If you try to switch using the physical controls on the camera, it probably won't work.
If you power the camera into rec mode it reverts to play mode as soon as the USB is connected. Once connected you cannot access rec mode by any means (direct camera, script or command line).
I don't recall anyone reporting using the G7 with PTP before, so another possibility is that mode switching over PTP just doesn't work on this camera.
So far that appears to be the case.
AFAIK the G7 does support Canon's remote capture API
The G7 works with software from the company with the windy name :-)
Canon's decision to remove remote capture on its later model P&S cameras is what led me to CHDK & PTP in the first place. My aim is to use a basic late model camera (like the A4000) and a RaspberryPi to upload an image every 15 min or so to a web server. I am only using the G7 to experiment before committing to a purchase. Any advice on any other suitable late model cameras would be appreciated.
Thanks
-
If you power the camera into rec mode it reverts to play mode as soon as the USB is connected. Once connected you cannot access rec mode by any means (direct camera, script or command line).
Right, I'm suggesting that you try just powering on the camera in play before you connect. The mode switching is hack, and can be sensitive to the previous states the camera was in so it could be worth a try.
However, I would guess that this camera probably needs some additional magic for mode switching to work at all. IIRC we have also seen this with a580 and some very early vxworks cams.
Implementing the equivalent of "switch_mode_usb" used for DryOS cams would probably be the next thing to try, if the corresponding functions exist. Someone may be able to make a test build if you are interested.
Canon's decision to remove remote capture on its later model P&S cameras is what led me to CHDK & PTP in the first place. My aim is to use a basic late model camera (like the A4000) and a RaspberryPi to upload an image every 15 min or so to a web server. I am only using the G7 to experiment before committing to a purchase. Any advice on any other suitable late model cameras would be appreciated.
Some other users have done or are working on similar things, see http://antthomas.co.uk/webcam/guide.php (http://antthomas.co.uk/webcam/guide.php) (scroll down to second camera) and http://antthomas.co.uk/motion/ (http://antthomas.co.uk/motion/)
I know another user from IRC who is working on a similar project using a4000. If you want to find cameras that are known to work, skimming through this thread and the PTP thread is one way to start.
-
However, I would guess that this camera probably needs some additional magic for mode switching to work at all. IIRC we have also seen this with a580 and some very early vxworks cams.
Implementing the equivalent of "switch_mode_usb" used for DryOS cams would probably be the next thing to try, if the corresponding functions exist. Someone may be able to make a test build if you are interested.
Have decided not to waste any more time on the G7. I will source another camera and continue from there.
Thanks for all your help and I will report back with progress.
-
I've uploaded a chdkptp snapshot build 426 to the files area https://www.assembla.com/spaces/chdkptp/documents# (https://www.assembla.com/spaces/chdkptp/documents#)
Remote capture now has all the exposure options available in regular "shoot". Errors in remote continuous mode are now handled more gracefully. Starting video recording from the GUI should also work better.
Remote capture dng now includes a (ugly, not color corrected) thumbnail. You can also optionally patch badpixels in the capture DNG file with the the rs -badpix option.
Additionally, there is preliminary support for manipulating CHDK DNG files outside of the remote shoot process. This allows you to patch bad pixels on your DNG 1.3 files, extract the raw data and thumbnail in various formats, and display various information about the file. See the dng* commands in cli help for details. This is in early stages, but the idea is that you will be able to download DNGs and prepare them for your favorite raw software in one go. You can also use Lua code to analyze or modify the contents of DNG images. The code can also be used on plain frame buffer dump raw files, but this isn't exposed in the CLI yet.
Some random examples
___> dngload test12.dng
loaded test12.dng
___> dnginfo
test12.dng:
4104x3048x12, GBRG, DNG 1.3.0.0 / 1.1.0.0, CHDK ver. 1.3.0, Canon PowerShot D10
# save raw data as a 16 bit pgm test12.pgm
___> dngdump -raw -rfmt=16pgm
# build a histogram in lua
___> !d=dngcli.selected; histo={}; for y=0,d.img:height()-1 do for x=0,d.img:width()-1 do v=d.img:get_pixel(x,y) if not
histo[v] then histo[v]=1 else histo[v]=histo[v]+1 end end end
___> !c=0 for i=0,126 do if histo[i] then c=c+histo[i] end end printf("%d pixels below blacklevel\n",c)
168985 pixels below blacklevel
edit:
I also split the IUP and CD libraries into a standalone download for the raspberry pi builds. You must download both chdkptp-r426-Linux-raspbian-gui.zip and chdkptp-raspbian-libs-20130826.zip
Additionally, the raspbian build contains a cli-only executable which does not require the libraries. For future snapshots, you should not need to re-download the library package.
-
Since I don't want to mix up programs in the ptpcamgui topic I will reply here.
While a script like ultimate.lua is running on the camera, most PTP controls won't work, because they also need to execute script and only one script can run at a time. You can download files while a script is running, although in chdkptp you have to use the -nolua option.
The -nolua option is nice, but then you have to know the exact file name. Not too convenient for downloading lots of photos of which the filename is unknown. Too bad the mdl option can't work with -nolua, but I suppose you have to run lua on the camera when you run a mdl command.
Rebooting through gui
Another thing I wanted to discuss is the reboot functions in CHDK PTP. Somehow, my Canon IXUS240HS doesn't reboot properly when issuing the command. I'm not sure if this is related to my port of CHDK or whether it's a PTP problem.
Shutdown works fine!
When I press "reboot", the camera power just goes (without retracting the lens) and I need to reinstall the battery to get it back to life again.
ptpcamgui also has troubles with rebooting, but not it's not the same...
-
Since I don't want to mix up programs in the ptpcamgui topic I will reply here.
Thanks :)
The -nolua option is nice, but then you have to know the exact file name. Not too convenient for downloading lots of photos of which the filename is unknown. Too bad the mdl option can't work with -nolua, but I suppose you have to run lua on the camera when you run a mdl command.
Exactly, you need lua to find the files on the card.
For this kind of application, you'd be much better off writing a script that is PTP aware, or just controlling everything from chdkptp either using an external program or a chdkptp side lua script. CHDK scripts an read and send "messages". So for example, you could have an intervalometer that exit when it receives a "quit" message. Then you could download under chkdptp control and restart the intervalometer.
You can send messages from chdkptp with the putm command. See http://chdk.wikia.com/wiki/Lua/PTP_Scripting (http://chdk.wikia.com/wiki/Lua/PTP_Scripting) for these functions.
You've posted a lot of question about various specifics, but if you gave an overall description of what you are trying to do, we might be able to offer better advice.
Another thing I wanted to discuss is the reboot functions in CHDK PTP. Somehow, my Canon IXUS240HS doesn't reboot properly when issuing the command. I'm not sure if this is related to my port of CHDK or whether it's a PTP problem.
It's unlikely to be a PTP problem, so you should report it in the porting thread.
When I press "reboot", the camera power just goes (without retracting the lens) and I need to reinstall the battery to get it back to life again.
It's not a good idea to call reboot in record mode or when the lens is extended. You can either set the retract delay short enough to so it can automatically retract, or possibly use an eventproc to tell it to retract: http://chdk.setepontos.com/index.php?topic=9287.msg95743#msg95743 (http://chdk.setepontos.com/index.php?topic=9287.msg95743#msg95743)
-
ptpcamgui also has troubles with rebooting, but not it's not the same..
It's not a good idea to call reboot in record mode or when the lens is extended. You can either set the retract delay short enough to so it can automatically retract, or possibly use an eventproc to tell it to retract: http://chdk.setepontos.com/index.php?topic=9287.msg95743#msg95743 (http://chdk.setepontos.com/index.php?topic=9287.msg95743#msg95743)
Btw., not ptpCamGui has troubles with a reboot. It's more a camera issue. ptpCamGui checks the camera mode. Is the camera in a record mode, first will be switched to playback mode before a reboot occurs.
msl
-
Here is a patch for gui icons based on reply#359 (http://chdk.setepontos.com/index.php?topic=6231.msg101263#msg101263).
- old images from scratchpad deleted
- new lua library for icons added
- window icon & on/off in gui added
- window dimension changed (height 560 instead 460 because different height of the tabs, prevents windows jumping.)
All other icon are only available in the library, because there was some trouble with the linux version.
msl
-
Could anybody tell me how I go about making a chdkptp command file on windows?
-
Could anybody tell me how I go about making a chdkptp command file on windows?
Write the commands you would use in chdkptp into a plain ASCII text file, using your favorite text editor.
To run the file, use
source filename
in the cli.
If you want to run it from the command line, you can use
chdkptp -rfilename
note there is no space space between the -r and the filename
This will just run a sequence of commands, as if you had typed them into the console. There are no variables or control structures. If you need to do something more complicated, you can write it in lua, and execute it using the normal lua require or dofile functions from the exec command. The CLI has fairly extensive help, which is also listed in USAGE.TXT
-
If you want to run it from the command line, you can use
chdkptp -rfilename
Thanks very much. I was looking for that option (rfilename) so I can make a .bat script.
-
Here is a patch for gui icons based on reply#359 (http://chdk.setepontos.com/index.php?topic=6231.msg101263#msg101263).
Added in rev.429 (http://trac.assembla.com/chdkptp/changeset/429/trunk).
msl
-
Added in rev.429 (http://trac.assembla.com/chdkptp/changeset/429/trunk).
Thanks :)
-
In changeset 431 (http://trac.assembla.com/chdkptp/changeset/431/trunk) I added a screenshot button which saves the current live view image as a ppm.
-
The screenshot button is very nice, Thanks for that.
In revision 434 (http://trac.assembla.com/chdkptp/changeset/434/trunk) I've created an additional tab for user functions. As example therefore there are some remote capture functions.
Perhaps it would be useful, in addition to the CD libraries the IM libraries to integrate. So we have more possibilities for image functions, e.g. picture preview for the GUI.
msl
-
In revision 434 (http://trac.assembla.com/chdkptp/changeset/434/trunk) I've created an additional tab for user functions. As example therefore there are some remote capture functions.
Nice.
Perhaps it would be useful, in addition to the CD libraries the IM libraries to integrate. So we have more possibilities for image functions, e.g. picture preview for the GUI.
Yes, this is something I have had in mind for a while, just haven't gotten around to it yet.
-
I've uploaded snapshot r438 to the files area: https://www.assembla.com/spaces/chdkptp/documents (https://www.assembla.com/spaces/chdkptp/documents)
The main purpose of this update is to fix the file timestamp bug pointed out by Stick in http://chdk.setepontos.com/index.php?topic=8801.msg105264#msg105264 (http://chdk.setepontos.com/index.php?topic=8801.msg105264#msg105264)
I have also added preliminary support for drag and drop upload. This is only tested on windows, and doesn't prompt to confirm the location or overwrite. Using this you can select files and/or directories on your pc and drop them in a directory of the tree view to upload.
Going the other way (from the file tree to your PC) is not supported.
-
I have SX200 and live view is always frozen at the first picture shown. I cannot erect the lens and no buttons are working an the GUI. But can set to show the UI overlay.
Have Win 7 and CHDK 1.2 3123, ptpCamGui2.0.136 is working on my PC.
What can be done to use live view? thanks
-
I have SX200 and live view is always frozen at the first picture shown. I cannot erect the lens and no buttons are working an the GUI. But can set to show the UI overlay.
So if you press the "rec" button, nothing at all happens? Any messages in the console?
Is the physical screen on the camera on?
Have you tried
=switch_mode_usb(1)
in the console?
Can you switch to record mode in ptpCamGui?
Note, it's normal that most keys do not respond when you are connected and not in rec mode, the Canon firmware ignores key presses when it thinks PTP is connected. You can usually use
=post_levent_to_ui(4484)
to unlock them.
edit:
This camera supposedly worked at some point in the past http://chdk.setepontos.com/index.php?topic=650.msg88814#msg88814 (http://chdk.setepontos.com/index.php?topic=650.msg88814#msg88814)
-
I had to push the REC button on the GUI, and everything goes OK. THANKS! :)
-
Hello,
Can somebody help me with an error message I am getting when starting chdkptp with a A2200 1d
ERROR: error loading module 'propcase' from file 'A/CHDK/LUALIB/propcase.lua':
cannot fopen A/CHDK/LUALIB/propcase.lua
On the SD , the file PROPCASE.LUA exists
CHDK version is CHDK_DE_a2200-100d-1.3.0-full_ALPHA_rev_3122.
chdkptp version is chdkptp-r438-win32
I am able to connect and use most functions except "JPG remote shoot"
Thanks
-
Hello,
Can somebody help me with an error message I am getting when starting chdkptp with a A2200 1d
ERROR: error loading module 'propcase' from file 'A/CHDK/LUALIB/propcase.lua':
cannot fopen A/CHDK/LUALIB/propcase.lua
The error is pretty straightforward, it's telling you it couldn't open the file. Make sure that file exists on the right location on the card.
If you are really sure it's in the right location, try to open it with the CHDK file viewer, or download it with the download command. If those fail, maybe there is something wrong with the filesystem or the card.
You could get this kind of error if CHDK was not installed correctly on a card multiple partitions, but a2200 does not support or need multiple partitions.
-
Hello,
Can somebody help me with an error message I am getting when starting chdkptp with a A2200 1d
ERROR: error loading module 'propcase' from file 'A/CHDK/LUALIB/propcase.lua':
cannot fopen A/CHDK/LUALIB/propcase.lua
The error is pretty straightforward, it's telling you it couldn't open the file. Make sure that file exists on the right location on the card.
the file EXISTS WITH A NAME IN UPPERCASE but I was not able to change the case
If you are really sure it's in the right location, try to open it with the CHDK file viewer, or download it with the download command. If those fail, maybe there is something wrong with the filesystem or the card.
the download succeeds and the file contents looks OK
Thanks for your answer , the error looks weird !!
-
the file EXISTS WITH A NAME IN UPPERCASE but I was not able to change the case
The case shouldn't matter.
the download succeeds and the file contents looks OK
This is very strange, download uses fopen just like require would. If the camera has very little free memory, that might cause fopen to fail.
You can use "show memory info" in the misc menu, or
return =get_meminfo()
in chdkptp to see how much memory is available.
What happens if you do something like
=return require'propcase'.TV
in chdkptp?
Now that I think about it, if the file was in the wrong place it would give you a different error, telling you the module was not found, rather than saying fopen failed.
-
[This is very strange, download uses fopen just like require would. If the camera has very little free memory, that might cause fopen to fail.
You can use "show memory info" in the misc menu, or
return =get_meminfo()
in chdkptp to see how much memory is available.
> =return get_meminfo()
3:return:table:{start_address=1625304,chdk_start=2866812,free_size=74712,chdk_size=144388,allocated_size=1387824,free_block_count=14,allocated_count=1422,name="system",end_address=3087840,chdk_malloc=true,free_block_max_size=72656,allocated_peak=1436656,total_size=1462536,}
What happens if you do something like
[color=green]=return require'propcase'.TV
2:return:266
[/color]
Sorry for the late reply
-
So, this camera has very little free memory:
free_size=74712
free_block_max_size=72656
Opening a file with fopen takes 32k, so it wouldn't take much to go over the limit. The camera uses different amounts of memory depending what you are doing. It usually uses a bit more in record mode. Even if the propcase error doesn't cause you big problems, you are likely to run into other problems if you use it much.
=return require'propcase'.TV
2:return:266
This is the same that caused the error you reported before, but it worked this time.
This shows that there's no problem with the files or CHDK install. Running out of memory is the most likely explanation.
We can try a build that loads CHDK in a different memory pool. This may cause other problems. There's some commented code for this in the port, but I'm not sure if it's copy and paste from another camera. I'll try to post a test build later, if no one else does it first.
-
So, this camera has very little free memory:
free_size=74712
free_block_max_size=72656
It usually uses a bit more in record mode.
=return get_meminfo()
4:return:table:{start_address=1625304,chdk_start=2866812,free_size=71952,chdk_size=144388,allocated_size=1390584,free_block_count=11,allocated_count=1441,name="system",end_address=3087840,chdk_malloc=true,free_block_max_size=69888,allocated_peak=1431168,total_size=1462536,}
Even if the propcase error doesn't cause you big problems, you are likely to run into other problems if you use it much.
Does the error (ERROR: unsupported format ) I get when trying to use the "JPG Remote Shoot" option , comes from lack of memory :?
=return require'propcase'.TV
2:return:266
This is the same that caused the error you reported before, but it worked this time.
You mean that the value of the propcase is correct
This shows that there's no problem with the files or CHDK install. Running out of memory is the most likely explanation.
We can try a build that loads CHDK in a different memory pool.
This may cause other problems.
There's some commented code for this in the port, but I'm not sure if it's copy and paste from another camera. I'll try to post a test build later, if no one else does it first.
Thanks
-
Does the error (ERROR: unsupported format ) I get when trying to use the "JPG Remote Shoot" option , comes from lack of memory :?
No, this is because the jpeg remote capture (filewritetask hook) is not currently implemented on your camera. This feature requires extra code on each supported camera.
You mean that the value of the propcase is correct
It just shows that require'propcase' was able to load the file.
-
Does the error (ERROR: unsupported format ) I get when trying to use the "JPG Remote Shoot" option , comes from lack of memory :?
No, this is because the jpeg remote capture (filewritetask hook) is not currently implemented on your camera. This feature requires extra code on each supported camera.
Extra code will not help with the free memory
Thanks
-
DNG / tiff discussion moved here: http://chdk.setepontos.com/index.php?topic=10739.0 (http://chdk.setepontos.com/index.php?topic=10739.0)
(maybe I should have put it in the raw section?)
-
Further to the problem of the error message "error loading module 'propcase' from file 'A/CHDK/LUALIB/propcase.lua' ":
the following log shows that it appears only when clicking the REC/PLAY button on the interface but not when typing the commands
Related or not ,
when I "connect" by typing
in the Live window , the viewfinder is blank ( no stream )
but
when I "connect" by clicking
in the Live window , the view finder appears (stream )
Not sure about the differences in code or timing between "typing" and "clicking"
As I intend to use it by "typing" commands , what should I type to display the viewfinder ?
logs from the console comments in red
cold start with no battery and no card inserted
insert card insert battery
power on camera
> connect
connected: Canon PowerShot A2200, max packet size 512> rec
> rs -dng
wait time 2.9640
> rs -dng
wait time 2.9640
> rs -dng
wait time 2.9796
> rs -dng
wait time 2.9796
> rs -dng
wait time 3.0108
> rs -dng
wait time 2.9640
clicking PLAY
ERROR: error loading module 'propcase' from file 'A/CHDK/LUALIB/propcase.lua':
cannot fopen A/CHDK/LUALIB/propcase.lua
clicking REC
ERROR: error loading module 'propcase' from file 'A/CHDK/LUALIB/propcase.lua':
cannot fopen A/CHDK/LUALIB/propcase.lua
> rs -dng
wait time 2.9952 > rec
ERROR: already in rec
> play
> rec
-
Not sure about the differences in code or timing between "typing" and "clicking"
Unfortunately, the gui code isn't aware of changes made from the CLI. This is something I need to fix
As I intend to use it by "typing" commands , what should I type to display the viewfinder ?
you can use
!update_connection_status()
after connecting
ERROR: error loading module 'propcase' from file 'A/CHDK/LUALIB/propcase.lua':
cannot fopen A/CHDK/LUALIB/propcase.lua
As I explained before, this error is almost certainly due to running out of memory. I understand nafraf was going to work with you to get this port using exmem? If this still happens with his build, please report how much memory is available when this happens.
-
In chdkptp r453, PTP/IP support should be mostly working. You must define PTPIP_SUPPORT=1 in config.mk to enable it. I haven't tested this on linux at all yet, since I don't know how to do the right UPnP voodoo to get a connection set up.
File upload/download, script, and live view all seem to work. The camera side caveats in http://chdk.setepontos.com/index.php?topic=10724.msg105734#msg105734 (http://chdk.setepontos.com/index.php?topic=10724.msg105734#msg105734) still apply, so it's still not terribly useful yet. For example, live view will only let you see the network connection screen ;) Performance on my 802.11g network is not as good as usb (unsurprisingly), live view only gets about 3 fps.
This involved some major re-writing that affected both USB and IP, so it's possible that USB has been broken. I'd appreciate any bug reports.
I will try to put up a new snapshot build soon.
edit:
(https://lh4.googleusercontent.com/-uXx4oRgfq5k/UlHoNS7JZFI/AAAAAAAABVg/4gwVuEK1wvU/s640/chdkptp-ptpip.jpg) (https://picasaweb.google.com/115940260949628685898/CHDK?authuser=0&feat=embedwebsite)
-
As I intend to use it by "typing" commands , what should I type to display the viewfinder ?
you can use
!update_connection_status()
after connecting
not sure where is the problem as I was testing a new version of chdk
> connect
connected: Canon PowerShot A2200, max packet size 512> !update_connection_status()
ERROR: call failed:[string "update_connection_status()"]:1: attempt to call global 'update_connection_status' (a nil value)
stack traceback:
[string "update_connection_status()"]:1: in main chunk
[C]: in function 'xpcall'
...uments\doc tech\CANON\chdkptp-r438-win32\lua\cli.lua:456: in function <...uments\doc tech\CANON\chdkptp-r438-win32\lua\cli.lua:453>
(tail call): ?
(tail call): ?
[C]: in function 'xpcall'
...uments\doc tech\CANON\chdkptp-r438-win32\lua\cli.lua:239: in function 'execute'
...uments\doc tech\CANON\chdkptp-r438-win32\lua\gui.lua:608: in function <...uments\doc tech\CANON\chdkptp-r438-win32\lua\gui.lua:605>
(tail call): ?
[C]: in function 'MainLoop'
...uments\doc tech\CANON\chdkptp-r438-win32\lua\gui.lua:630: in function <...uments\doc tech\CANON\chdkptp-r438-win32\lua\gui.lua:616>
(tail call): ?
...ments\doc tech\CANON\chdkptp-r438-win32\lua\main.lua:231: in main chunk
[C]: in function 'require'
[string "require('main')"]:1: in main chunk
-
not sure where is the problem as I was testing a new version of chdk
Ooops, my fault. The correct call would be
!gui.update_connection_status()
I changed the code (in svn r456) so this isn't needed, so in the next release the gui will automatically update when you use cli connect.
-
@reyalp, it seems that gui_user.lua has problems with directory names containing spaces, this patch add quotes to destination dir. It was tested by poussin.
-
this patch add quotes to destination dir. It was tested by poussin.
Thanks for that. The patch was added in changeset 457.
msl
-
I added a command called dnglistpixels to generate various kinds of badpixel lists.
It can be used to generate chdk badpixel / badpixel.txt (not badpixel.bin) and files for rawtherapee and dcraw.
To generate a badpixel.txt file of hot pixels for CHDK, you would do something like
Shoot a DNG dark frame
dngload <file>
dnglistpixels -min=2048 -out=badpixel.txt
where min is the minimum value you want to consider "hot"
For rawtherepee, you would use something like
dnglistpixels -min=2048 -fmt=dcraw -coords=rel -out="Canon PowerShot D10.badpixels"
with your camera model and put the file in your rawtherapee dark frame directory.
For dcraw, use
dnglistpixels -min=2048 -fmt=dcraw -coords=rel -out="badpixels"
For raw therapee and dcraw, you could also use this to patch dng 1.3 badpixels. For this use -max=0 (or some other < blacklevel value) instead of min. To combine both hot and dead pixels, you could make two files and concatenate them.
-
I uploaded snapshot build r461 to the files area https://www.assembla.com/spaces/chdkptp/documents (https://www.assembla.com/spaces/chdkptp/documents)
These binaries have PTP/IP enabled in case anyone wants to play with it. Note that this is completely untested on linux, and probably not useful without additional camera side reverse engineering.
Since the connection code was heavily re-worked to support PTP/IP, it's possible that I've broken something that affects regular USB connections.
-
Since the connection code was heavily re-worked to support PTP/IP, it's possible that I've broken something that affects regular USB connections.
Hi All,
Test results for build r461.
Seems to work "Better" than previous version in "REC":-
see attached ...... Ixus 125 125-101a_Rec_+_125-100d_Rec
Also see this post for more "Syntax Error" details:-
http://chdk.setepontos.com/index.php?topic=8085.msg106401#msg106401 (http://chdk.setepontos.com/index.php?topic=8085.msg106401#msg106401)
http://chdk.setepontos.com/index.php?action=dlattach;topic=8085.0;attach=9164 (http://chdk.setepontos.com/index.php?action=dlattach;topic=8085.0;attach=9164)
In "Play" there is a problem with 1 to 1 Aspect ratio, may be due to Ixus 115/125 cameras :-
see attached Ixus 125 ....... 125-101a_Play_&_Aspect 1-1
Edit #1; see here http://chdk.setepontos.com/index.php?topic=8085.msg106723#msg106723 (http://chdk.setepontos.com/index.php?topic=8085.msg106723#msg106723)
Note that I have also up-graded to Win-Blue_RTM which also Seems to work "Better" than previous, preview, version.
H-H
-
Seems to work "Better" than previous version in "REC":-
see attached ...... Ixus 125 125-101a_Rec_+_125-100d_Rec
Also see this post for more "Syntax Error" details:-
http://chdk.setepontos.com/index.php?topic=8085.msg106401#msg106401 (http://chdk.setepontos.com/index.php?topic=8085.msg106401#msg106401)
http://chdk.setepontos.com/index.php?action=dlattach;topic=8085.0;attach=9164 (http://chdk.setepontos.com/index.php?action=dlattach;topic=8085.0;attach=9164)
I'm sorry, I don't understand what the problem is. If you can explain what you did, what you expected to happen, and what actually happened, that might be more useful than screenshots.
I don't understand the point of the usb device stuff in the screen shots. Either libusb is set up correctly or not, it doesn't matter to me what hubs you have or what the devices are called in windows...
You can get "error syntax" if the lua module on the camera isn't able to load.
In "Play" there is a problem with 1 to 1 Aspect ratio, may be due to Ixus 115/125 cameras :-
see attached Ixus 125 ....... 125-101a_Play_&_Aspect 1-1
I don't really understand this either.
Is the fisheye a real fisheye lens, or the cameras "fisheye effect"? If it's the fisheye effect, I've seen something like this on elph130 as well, the canon firmware does something special in this mode and the live view is not correct. It would need to be fixed on the CHDK side on the camera. If it's a physical lens, then it doesn't matter, the live data is either wrong or right but the fisheye is irrelevant.
If the live display is not correct, a "quick dump" from the the debug tab may help me understand the problem.
I don't understand what the problem is with "play"?
-
Microsoft have made using unsigned drivers even harder in Windows 8.1 x64.
Although you can still jump through hoops to install the libusb-win32 drivers, they don't survive a reboot of the system.
I found the program linked here (http://zadig.akeo.ie/ (http://zadig.akeo.ie/)) will fix the problem by creating and installing self-signed libusb drivers for x64 Windows 8.1.
Phil.
-
Just for all, some info; Successfully ran chdkptp on Ubuntu 12.04 64bit. I've compiled from source. Used CLI as well interactive and via a script. Tested with IXUS 200 IS camera v1.01c. Remoteshoot worked well with RAW n DNG. Sadly not for JPG. but shoot -dl worked for JPG. Will use that until I get around remoteshoot jpg for this camera.
Only hickup is the speed per picture. It is likely not the transfer speed, but something else. In the past remote shoot without using PTP was quit a little faster 2.2sec per shot, now ~6sec per shot. Will look an sourcecode of CHDK and CHDKPTP now to see if it is somehow possible to add remoteshoot with JPG on this camera. I'll hope that will speed up the pics per second issue. Would like to get to <4sec per picture a full resolution.
So, Big thanks to all nifty coders working on CHDK and everyone else that made it possible.
-
Just for all, some info; Successfully ran chdkptp on Ubuntu 12.04 64bit. I've compiled from source. Used CLI as well interactive and via a script. Tested with IXUS 200 IS camera v1.01c. Remoteshoot worked well with RAW n DNG. Sadly not for JPG. but shoot -dl worked for JPG. Will use that until I get around remoteshoot jpg for this camera.
jpeg remote shoot requires camera side support (filewrite task). It should be possible to implement on any camera, but it's quite a bit of code.
Only hickup is the speed per picture. It is likely not the transfer speed, but something else. In the past remote shoot without using PTP was quit a little faster 2.2sec per shot, now ~6sec per shot.
Can you clarify what what setup you were using in the past that gave the faster speed? If you were doing this with a previous version of chdkptp with the same camera, please give the specific versions and commands used.
Camera settings can also have a significant impact on shooting speed (though 2.2 - 6 would be excessive for camera settings alone, unless you are taking a multi-second exposure). If you are transferring raw/DNG, that obviously adds a very significant amount of actual transfer time compared to jpeg.
Will look an sourcecode of CHDK and CHDKPTP now to see if it is somehow possible to add remoteshoot with JPG on this camera. I'll hope that will speed up the pics per second issue. Would like to get to <4sec per picture a full resolution.
As above, you just need to implement filewrite task. You can use a camera with the same dryos version that already has support as an example, and use code-gen for the asm code.
-
I'm sorry, I don't understand what the problem is. If you can explain what you did, what you expected to happen, and what actually happened, that might be more useful than screenshots.
In "Play" there is a problem with 1 to 1 Aspect ratio, may be due to Ixus 115/125 cameras :-
see attached Ixus 125 ....... 125-101a_Play_&_Aspect 1-1
The FishEye is an attached Lense and not the "FishEye effect"
A Edit #1; see here http://chdk.setepontos.com/index.php?topic=8085.msg106723#msg106723 (http://chdk.setepontos.com/index.php?topic=8085.msg106723#msg106723)
-
Based on tpont's post http://chdk.setepontos.com/index.php?topic=6231.msg90959#msg90959 (http://chdk.setepontos.com/index.php?topic=6231.msg90959#msg90959), I decided to use AutoHotKey [http://www.autohotkey.com/ (http://www.autohotkey.com/)] to start some CLI testing with my SX150IS. The PC is Win 7, 64 bit.
My CHDK was built using CHDK-Shell:
***Build Info***, CHDK Ver: CHDK 1.3.0-3187, Revision: 0, Date: Oct 28 2013, Time: 11:21:49, Camera: sx150is, FW Vers: 100a, Compiler: GCC 4.4.0
For chdkptp, I used [the easy way out]:
chdkptp-r438-win32 from here https://www.assembla.com/spaces/chdkptp/documents (https://www.assembla.com/spaces/chdkptp/documents)
Here's the first AutoHotKey script I used:
;***a semicolon denotes comment in AutoHotKey
IfWinExist C:\CHDK\chdkptp\chdkptp-r438-win32\chdkptp.exe
{
WinActivate
}
else
{
Run C:\CHDK\chdkptp\chdkptp-r438-win32\chdkptp.exe -i
WinWait C:\CHDK\chdkptp\chdkptp-r438-win32\chdkptp.exe
WinActivate
}
Send connect{Enter}
Send rec{Enter}
; notes:
;(i)camera changes to record & goes black after exactly 1 minute and camera shuts down after exactly 3 mins
;(ii) if , between 1 and 3 mins [i.e camera not shutdown], "Send shoot(){Enter}" --> then picture is taken.
So,
with usb already connected between PC and camera, I power-on camera which starts in playback. I then run the script and the
- camera changes to record. The LCD then goes black after exactly 1 minute and subsequently shuts down after exactly 3 mins
- if , between 1 and 3 mins [i.e camera not shutdown], "Send shoot(){Enter}" --> then picture is taken
Am I doing something silly ? [hope so] or is this a similar problem to that reported by ant_thomas, described here:
http://chdk.setepontos.com/index.php?topic=6231.msg95142#msg95142 (http://chdk.setepontos.com/index.php?topic=6231.msg95142#msg95142)
Please find romlog attached.
Further:
Based on this post http://chdk.setepontos.com/index.php?topic=6231.msg90966#msg90966 (http://chdk.setepontos.com/index.php?topic=6231.msg90966#msg90966) I created the following AutoHotKey script to test the chdkptp "-r" option:
;***semicolon denotes comment in AutoHotKey
IfWinExist C:\CHDK\chdkptp\chdkptp-r438-win32\chdkptp.exe
{
WinActivate
}
else
{
; Run C:\CHDK\chdkptp\chdkptp-r438-win32\chdkptp.exe -i -rmcinit.chdkptp
; WinWait C:\CHDK\chdkptp\chdkptp-r438-win32\chdkptp.exe
; WinActivate
;***had to include the complete Win7 64bit path name for the '-r' option to work:-
Run C:\CHDK\chdkptp\chdkptp-r438-win32\chdkptp.exe -i -rC:\CHDK\chdkptp\chdkptp-r438-win32\mcinit.chdkptp
WinWait C:\CHDK\chdkptp\chdkptp-r438-win32\chdkptp.exe
WinActivate
}
;Send source mcshoot.chdkptp{Enter}
;***again, had to include the complete Win7 64bit path name for this to work:-
Send source C:\CHDK\chdkptp\chdkptp-r438-win32\mcshoot.chdkptp{Enter}
Send {!}mc:cmdwait('exit'){Enter}
;------------------------------------------------------------------------------------------------------------
;------------------------------------------------------------------------------------------------------------
;File content of mcinit.chdkptp:-
;# load the multicam module
;!mc=require('multicam')
;# connect to all cameras
;!mc:connect()
;# initialize script on the cameras
;!mc:start()
;# initialize timing
;!mc:init_sync()
;# switch cameras to rec mode
;!mc:cmdwait('rec')
;------------------------------------------------------------------------------------------------------------
;------------------------------------------------------------------------------------------------------------
;File content of mcshoot.chdkptp:-
;# half press the shutter to focus
;!mc:cmdwait('preshoot')
;# shoot, 100ms after cmd issued
;!mc:cmdwait('shoot',{syncat=100})
;------------------------------------------------------------------------------------------------------------
;------------------------------------------------------------------------------------------------------------
;***Build Info***
;CHDK Ver: CHDK 1.3.0-3187
;Revision: 0
;Date: Oct 28 2013
;Time: 11:21:49
;Camera: sx150is
;FW Vers: 100a
;Compiler: GCC 4.4.0
This works.
I was surprised that I had to use the full Win7 path name in the code -
should I have been [surprised] ?
is there an entry in "some" config file that the path name can be written to ?
[I have briefly reviewed USAGE.TXT for an answer. Under Windows [for me] - the answer isn't patently obvious :(]
Any comment appreciated.
PS: both "mcinit.chdkptp" & "mcshoot.chdkptp" were copied to the same directory as chdkptp.exe
PPS: working from front to back, I still haven't got past [this] thread page 28 - so if there's later answers, apologies !
-
Based on tpont's post http://chdk.setepontos.com/index.php?topic=6231.msg90959#msg90959 (http://chdk.setepontos.com/index.php?topic=6231.msg90959#msg90959), I decided to use AutoHotKey [http://www.autohotkey.com/ (http://www.autohotkey.com/)] to start some CLI testing with my SX150IS. The PC is Win 7, 64 bit.
First of all, I would suggest you get things working using chdkptp directly, rather than involving autohotkey. Not saying that is directly related to your current problem, but adding more layers only going to cause more confusion.
;(i)camera changes to record & goes black after exactly 1 minute and camera shuts down after exactly 3 mins
Have you set "disable LCD off" in the CHDK settings? If not, it will behave something like you describe. This shouldn't trigger a romlog however, it will just turn the display off, and then if a key isn't pressed for a while, turn the camera off.
To check this, you should verify that the timestamp on the romlog matches the time the problem actually occurred. romlogs are stored indefinitely, so you get whatever old one. The one you posted appears to be from Nov 1.
-
First of all, I would suggest you get things working using chdkptp directly, rather than involving autohotkey. Not saying that is directly related to your current problem, but adding more layers only going to cause more confusion.
Understood - I had done it manually as well but found it easier copying the autohotkey code into the post. Yes, sprinkling's of "sleep, '??'" are required with it.
Have you set "disable LCD off" in the CHDK settings? If not, it will behave something like you describe. This shouldn't trigger a romlog however, it will just turn the display off, and then if a key isn't pressed for a while, turn the camera off.
No, as feared - i'm [very] embarassed :-[.
Sorry for taking your time [but at least I can still be kind to this decent little camera :)].
To check this, you should verify that the timestamp on the romlog matches the time the problem actually occurred. romlogs are stored indefinitely, so you get whatever old one. The one you posted appears to be from Nov 1.
Another lesson learnt ! [but I can't ever remember an event that would have previously triggered romlog creation :blink:].
I'm pushing it now but rather than including the complete Windows path name in the -r option is there somewhere else this can be 'stored' ?
-
I'm pushing it now but rather than including the complete Windows path name in the -r option is there somewhere else this can be 'stored' ?
As described in usage.txt, chdkptp will look for _chdkptprc at startup, and execute it if found.
Additionally, most of chdkptp is written in Lua. The code can be found in the lua directory. This is loaded at run time, so you can customize it any way you want, or write your own Lua modules to implement new functionality. To make maintenance easier, I would suggest putting your own code in a separate file whenever possible. You can load the file either by putting a require in one of the standard lua files, or by executing a require in your startup file, as you did with multicam. You could also make a copy of multicam.lua and customize it to do whatever you want.
-
Thanks [as usual].
-
Does someone have a 32-bit Linux binary of chdkptp available? My attempts to compile it have been unsuccessful.
Thanks,
Steve
-
Does someone have a 32-bit Linux binary of chdkptp available? My attempts to compile it have been unsuccessful.
If you post the problem you are having compiling, we can probably help.
If someone is going to make a binary for you, it would be helpful to know the distro and whether you need GUI support.
-
Bug reported by VladimirSlavik, tested on a530. Same behavior with sx240 chdk trunk version. chdkptp 465
con 5> rs -jpg -cont=5
wait time 0.0059
con 8> play
ERROR: :82: attempt to compare nil with number
user code: 3
Patch in attachment seems to solve it. During play command, variable i was not initialized.
-
Bug reported by VladimirSlavik, tested on a530. Same behavior with sx240 chdk trunk version. chdkptp 465
Added in changeset 466. Thanks :)
-
I'm [a bit] confused...nothing new there !
From chdkptp useage.txt [http://trac.assembla.com/chdkptp/browser/trunk/USAGE.TXT (http://trac.assembla.com/chdkptp/browser/trunk/USAGE.TXT)]
"connect (c) [-b=<bus>] [-d=<dev>] [-p=<pid>] [-s=<serial>] [model] | -h=host [-p=port]: - connect to device
If no options are given, connects to the first available device.
<pid> is the USB product ID, as a decimal or hexadecimal number.
All other options are treated as a Lua pattern. For alphanumerics, this is a case sensitive substring match.
If the serial or model are specified, a temporary connection will be made to each device
If <model> includes spaces, it must be quoted.
If multiple devices match, the first matching device will be connected."
So, my SX150IS serial is s=9A952438E0A647E9AC0179DDC30582D5
I use the following autohotkey script [sorry for being lazy again, but it is easy to copy/paste]
IfWinExist C:\CHDK\chdkptp\chdkptp-r438-win32\chdkptp.exe
{
WinActivate
}
else
{
Run C:\CHDK\chdkptp\chdkptp-r438-win32\chdkptp.exe -i
WinWait C:\CHDK\chdkptp\chdkptp-r438-win32\chdkptp.exe
WinActivate
}
Send connect -s=9A952438E0A647E9AC0179DDC30582D5{Enter}
which connects fine.
My Question: I'm not sure [for serial / model] what a 'temporary' connection means - should I be able to hardcode multiple serial numbers in multicam.lua and it then successfully enumerate over and connect to all cams ?
Earlier in this thread [http://chdk.setepontos.com/index.php?topic=6231.msg96441#msg96441 (http://chdk.setepontos.com/index.php?topic=6231.msg96441#msg96441)]
"I haven't tested, but I suspect the reason multiple independent processes don't work is because
1) Connect by model name or serial number requires making a connection to obtain the info
2) Obtaining a connection requires kicking off anything else that already has a connection
If you connect by product id, (-p=<pid>) it might work. Bus/device should also work, but beware they do not correspond to the physical interface the camera is connected on. The numbers are assigned by libusb and can change across camera resets, reconnects etc. even if the physical connection is never unplugged or moved."
This makes me think that I can't use the predetermined serial numbers [as i'd like] but, as I said at the start of this post - I am a bit confused.
Appreciate any comment.
Edit: link for very interesting usb article supplied me by a very helpful forum member:
http://www.usbmadesimple.co.uk/ums_4.htm (http://www.usbmadesimple.co.uk/ums_4.htm)
-
"connect (c) [-b=<bus>] [-d=<dev>] [-p=<pid>] [-s=<serial>] [model] | -h=host [-p=port]: - connect to device
If no options are given, connects to the first available device.
<pid> is the USB product ID, as a decimal or hexadecimal number.
All other options are treated as a Lua pattern. For alphanumerics, this is a case sensitive substring match.
If the serial or model are specified, a temporary connection will be made to each device
If <model> includes spaces, it must be quoted.
If multiple devices match, the first matching device will be connected."
My Question: I'm not sure [for serial / model] what a 'temporary' connection means
The "temporary" connection is just a regular connection, which chdkptp creates internally if needed. The point of all that text you quoted is that the cameras can only have a single PTP connection at a time. Since chdkptp needs to connect to get the serial number or model name, any other existing connections will be broken.
This is only an issue if you are using multiple instances of chdkptp (or other PTP clients). If you manage all your connections from a single chdkptp instance, it knows whether it already has a connection to a camera and re-use that connection instead of resetting it.
- should I be able to hardcode multiple serial numbers in multicam.lua and it then successfully enumerate over and connect to all cams ?
If you want to connect to all cams, why do you need the serial number?
If you want to connect to a list of cameras by serial number, it should be fairly straightforward to modify multicam.lua to do that. If you look at mc:connect() you will see..
--[[
connect to all available cams
TODO add matching support
]]
function mc:connect()
local devices = chdk.list_usb_devices()
Note the TODO ;)
It's not clear to me exactly what you want to do, but you could easily check a list of serial numbers or other criteria in that code and only add cameras that match to the connection list.
This makes me think that I can't use the predetermined serial numbers [as i'd like] but, as I said at the start of this post - I am a bit confused.
Well that makes two of us... I don't really understand what you are trying to do. Your test is using cli commands, but you are talking about using multicam.lua. These are two different things. The CLI only knows about one connection at a time. You can switch between cameras in the CLI using the serial number, as long as you only do it within one instance of chdkptp. You can also switch between active connections if you fiddle with the con global variable. multicam current just uses every camera that is connected. As I said above, it would be fairly easy to make it do other things.
Edit: link for very interesting usb article supplied me by a very helpful forum member:
http://www.usbmadesimple.co.uk/ums_4.htm (http://www.usbmadesimple.co.uk/ums_4.htm)
Um OK. I let libusb handle most of that stuff. It may be possible to get the serial number without establishing a full connection, but the current code doesn't.
-
As usual, thanks for the detailed reply - [i'm pretty sure] that's very clear now.
If you want to connect to all cams, why do you need the serial number?
&
It's not clear to me exactly what you want to do, but you could easily check a list of serial numbers or other criteria in that code and only add cameras that match to the connection list.
Aim:
build a 50/125 cam photogrammetry [human figurine 3d printing] rig
controlled via
- chdk / chdktptp, shutter control => usbremote
and [most likely] using
- multi-studio flash texture data capture [with one bank of multiple cameras]
- followed by "noise projected via multi-studio flash" geometry data capture [if I can find such a thing] with a second bank of multiple cameras [minimal delay between this and item 1. since, even small, movement 'screws up' the resultant 3D mesh]
Since I don't yet understand either photography or photogrammetry particularly well then I don't yet know that I do need to connect by serial number - but it seems that method provides ultimate flexibility to communicate with [and control] each camera [or group of cameras] if that should be useful.
-
Since I don't yet understand either photography or photogrammetry particularly well then I don't yet know that I do need to connect by serial number - but it seems that method provides ultimate flexibility to communicate with [and control] each camera [or group of cameras] if that should be useful.
I hope you understand that (among other things) a non-trivial amount of programming will be needed to make this work.
It would certainly be possible to modify multicam.lua or write your own code to manage connections groups of cameras defined by serial number within a single instance of chdkptp.
Just for completeness sake, it should be noted that old cameras (mostly vxworks, meaning released in 2007 or earlier) do not return a serial number. This shouldn't affect anyone buying any current cameras.
On another note, I'm not clear on how your process is supposed to work, but if you are exposing with flash it may not be necessary to have particularly good sync in the shutters. Given a sufficiently dark studio, you should be able to just ensure that all the shutters are open when the flash fires.
-
I hope you understand that (among other things) a non-trivial amount of programming will be needed to make this work.
Yes, I understand something of the challenge. Currently studying your conversation with VincentD [http://chdk.setepontos.com/index.php?topic=8120.msg86264#msg86264 (http://chdk.setepontos.com/index.php?topic=8120.msg86264#msg86264)] for some ideas.
...but if you are exposing with flash it may not be necessary to have particularly good sync in the shutters. Given a sufficiently dark studio, you should be able to just ensure that all the shutters are open when the flash fires.
True. There's a lot for me to consider.
Most importantly [maybe], I also vaguely remember reading that chdk EXIF data is not "accurate". Since that's key to the photogrammentry app i'll dig out that bookmark and go post something on the relevant thread.
Thanks again for your comments.
Edit:
for my record - here's the EXIF post http://chdk.setepontos.com/index.php?topic=8585.msg89924#msg89924 (http://chdk.setepontos.com/index.php?topic=8585.msg89924#msg89924)
Edit:
appreciate reply #449 - no new reply as content is, definitely, off topic !
-
Most importantly [maybe], I also vaguely remember reading that chdk EXIF data is not "accurate". Since that's key to the photogrammentry app i'll dig out that bookmark and go post something on the relevant thread.
This is getting somewhat off topic, but in general there's a good chance that the exif will be fine. You should of course verify that it comes out right with your particular cameras and scripts. If it doesn't and we can't fix it in the port you are using, you could easily log the exposure values actually used yourself.
The exif info in CHDK DNGs should also be accurate. If you use the remoteshoot option, chdkptp allows you to download only the dng header (including the exif) without the actual raw data. Using remoteshoot with USB remote sync could be tricky though.
-
I uploaded snapshot build r468 to the files area https://www.assembla.com/spaces/chdkptp/documents (https://www.assembla.com/spaces/chdkptp/documents)
This fixes the bug in the "play" command pointed out by nafraf and add support for the trunk changes described in http://chdk.setepontos.com/index.php?topic=4338.msg107827#msg107827 (http://chdk.setepontos.com/index.php?topic=4338.msg107827#msg107827)
-
Based on a few limitations I decided to start off down the multi-instance chdkptp route using AutoIT [http://www.autoitscript.com/site/ (http://www.autoitscript.com/site/)] as control [has a built in IDE with an easy to use GUI builder in comparison to AutoHotKey is reason, so far, for that].
Currently i'm trying to get my hands on the stdout chdkptp "list" info [to use bus/dev info with multi-instances] and having not a lot of fun with the AutoIT "StdoutRead" command. Absolutely no idea how this might scale to many dozens of cams but hope it's worth a go.
Anyway, my 1st [cam1 of 2] SX150IS has been operating as expected [based on a very limited set of expectations :-[ ] with chdk & chdkptp so, I just got the 2nd one [cam2 - ebay UK canon site refurb] out of it's box, inserted the SD card [previously extracted from cam1], powered on, ensured equivalent firmware version, ensured basic chdk operation then powered off.
Shortly after this:
- plugged usb lead [working with cam1] into cam2
- press "power on" cam2 [starts in playback]
- connect usb to PC => LCD goes black and green LED turns on => cam will not respond to any key press or mode change
Then:
- start chdkptp gui => press "Connect" and message "Error: no devices available" is displayed.
The problem challenge is constantly repeatable. Both cams in 'P' mode. Same win7 64 bit machine used - chdkptp snapshot r438 used.
Any comment [other than "write-off"] appreciated.
-
- connect usb to PC => LCD goes black and green LED turns on => cam will not respond to any key press or mode change
If you somehow have enabled the CHDK USB remote then this is the exact behavior that you will see.
-
Appreciate that waterwingz.
Unfortunately I ensured:
Remote Parameters => Enable Remote [ ] i.e unselected,
on both cams.
But that's exactly the sort of, silly, thing i'm concerned may be causing the problem.
To be honest i'm not now sure i'll be using your kbd.c hack [ http://chdk.setepontos.com/index.php?topic=8769.msg105488#msg105488 (http://chdk.setepontos.com/index.php?topic=8769.msg105488#msg105488) ] - I might wind up doing something along the lines of your other idea:
http://chdk.setepontos.com/index.php?topic=10837.msg106581#msg106581 (http://chdk.setepontos.com/index.php?topic=10837.msg106581#msg106581)
Nice to have a few options provided - but I digress.
-
- plugged usb lead [working with cam1] into cam2
- press "power on" cam2 [starts in playback]
- connect usb to PC => LCD goes black and green LED turns on => cam will not respond to any key press or mode change
You probably need to install a libusb INF driver again for this specific camera. I expect this is necessary for each camera (unless it's so old it doesn't report a serial number, in which case it's specific to the USB port instead). You definitely need to do it for each model of camera.
This will be fun with 50+ cameras, but I assume it's possible to automate...
As far as using autoit... this seems like an extra layer of complication. If you want a custom GUI, learning IUP http://www.tecgraf.puc-rio.br/iup/ (http://www.tecgraf.puc-rio.br/iup/) and doing in directly in chdkptp Lua might be a better option.
-
As far as using autoit... this seems like an extra layer of complication. If you want a custom GUI, learning IUP http://www.tecgraf.puc-rio.br/iup/ (http://www.tecgraf.puc-rio.br/iup/) and doing in directly in chdkptp Lua might be a better option.
FWIW .. both CHDK-Shell and CHDK-PT use AutoIT. Its a nice package for rolling up a GUI interface. YMMV.
-
To be honest i'm not now sure i'll be using your kbd.c hack [ http://chdk.setepontos.com/index.php?topic=8769.msg105488#msg105488 (http://chdk.setepontos.com/index.php?topic=8769.msg105488#msg105488) ] - I might wind up doing something along the lines of your other idea:http://chdk.setepontos.com/index.php?topic=10837.msg106581#msg106581 (http://chdk.setepontos.com/index.php?topic=10837.msg106581#msg106581) Nice to have a few options provided - but I digress.
Be sure to let us know what turns out to work for you?
-
FWIW .. both CHDK-Shell and CHDK-PT use AutoIT. Its a nice package for rolling up a GUI interface. YMMV.
Yes, PTPCamGui as well. I have nothing against AutoIT, I'm just saying wrapping a CLI executable adds another layer of complexity. I believe PTPCamGui uses a dll to go between the ptpcam exe and AutoIT, in part because of issues talking the ptpcam.exe input/output.
andrew.stephens project will almost certainly require writing chdkptp Lua code anyway, so biting the bullet and doing it all there might be a better option.
-
I believe PTPCamGui uses a dll to go between the ptpcam exe and AutoIT, in part because of issues talking the ptpcam.exe input/output
That's right. The dll solution makes the conversation between PC & camera a little bit slow. Here has chdkptp the better concept.
But ... autoit is an easy to use script language for non-programmer like me. You can make 'quick&dirty' a Windows GUI. IUP is more complicated. The description is very scarce. There is little information about this Lua extension.
Although chdkptp has the better concept was ptpCamGui downloaded very often (more than 4,500 downloads). Why is that? Beside many demonstration functions has this GUI two important 'one click' functions: 1. automated & adjustable picture download, 2. automated CHDK update. This is missing in chdkptp. Of course there are cli functions in chdkptp for this tasks. But a command line is more a thing for programmers and PC geeks.
I think the brilliant chdkptp concept needs some more GUI functionality for further distribution. What also would be important, is an Android interface. I know this involves a lot of work. But the future belongs to mobile devices.
msl
-
Time is short ........... AutoIT is very useful for relatively quick results.
I use it for my PTP application that creates burst sequences, HDR sequences, stereo focus stacks,stop-motion AVI's created 'on-the-fly' and much, much more.
-
reyalp at Reply #454:
thanks, when the problem arose I had briefly examined the existing .inf which included:
DeviceGUID = "{7E8D9BE6-3379-4442-88E6-E3FE200DC43E}" and, while not the serial number, had suspected it was unique to the cam [not sure it is though]. To that extent, what you say about install seems to make sense. In any case will check it out asap [whenever that is].
waterwingz at Reply #456:
i'm pretty sure i'll need some comment, along the way, to get this working [i.e you'll be the first to know ;) PS: YMMV - daughter now considers I am an urban hero (she still doesn't know what that [YMMV] is - but i do now, thanks [a little] to G)
Other:
Other reasons why, after brief AutoHotKey / AutoIt compare, I decided on AutoIT was, seemingly, better support for arrays and a COM automation bridge [http://sourceforge.net/projects/au3automation/ (http://sourceforge.net/projects/au3automation/)]. Since I [think I] might like to store / change individual camera settings in individual Excel worksheets in a workbook before shunting them off to the cams then AutoIT was it.
Like msl, i'm no programmer and I agree with microfunguy that 'time is short' - so while IUP/Lua definitely appeals to the [small remaining] purist within again, AutoIT it is [if I can get my hands on any "list" stdout with it :blink: ...otherwise...]
PS: impressive gui screenshot microfunguy !
-
Like msl, i'm no programmer
The kind of project you have been talking about is going to require programming, one way or the other. From what I have understood so far, the chances of success without a reasonable proficient programmer involved appear extremely low, regardless of whatever you might want to do with the GUI stuff. I don't want to discourage you, but it's important to have realistic expectations.
Then again, if you are "not a programmer" in the same way msl is, you might be ok ;)
-
Agreed reyalp:
when I say i'm not a program[m]er, I mean [just a personal perspective]:
I think folk who learnt sequence / loop / conditional branch [in the old days, whether Assembly Language or Fortran77]] are at a real disadvantage to those of today who learn oop concepts from the outset [the mindset is different in my opinion (and probably the actual neural connections)].
At some level [sequence / loop / conditional branch] my old granny could [maybe] have been a programmer ?
So, in old money - if I can do something once I should be able to do it 100 [or 125] times ? [with a little prompting].
In the final analysis [I think] motivation / persistence can do - quite a bit [at least I hope so]
If at all possible i'll need to leave the "wrappers", inheritance, mvc etc etc etc to you guys...i was looking at vaadin [https://vaadin.com/home (https://vaadin.com/home)] today for a short while though ;)
I can only wish I was [already] up to msl's high standards :)
-
So, installing another ".inf" got the second cam working [thanks again]
Currently just using the clipboard to grab the list info with autoit code:
$CopyScreen = "{ALTDOWN}{SPACE}{ALTUP}ES{ENTER}"
Send($CopyScreen)
$Count = 0
While $count < 4
Sleep(500)
$Count = $Count + 1
Send($CopyScreen)
WEnd
clipboard content =>
___> list
-1:Canon PowerShot SX150 IS b=bus-0 d=\\.\libusb0-0001--0x04a9-0x3234 v=0x4a9 p=0x3234 s=9A952438E0A647E9AC0179DDC30582D5
-2:Canon PowerShot SX150 IS b=bus-0 d=\\.\libusb0-0002--0x04a9-0x3234 v=0x4a9 p=0x3234 s=689D5005104943C09E988E4EA8301E22
___>
What is the dev/bus connect string [as an example] for either of these - please ?
Edit: also see this to grab the console info:
http://chdk.setepontos.com/index.php?topic=10060.msg103939#msg103939 (http://chdk.setepontos.com/index.php?topic=10060.msg103939#msg103939)
-
-1:Canon PowerShot SX150 IS b=bus-0 d=\\.\libusb0-0001--0x04a9-0x3234 v=0x4a9 p=0x3234 s=9A952438E0A647E9AC0179DDC30582D5
-2:Canon PowerShot SX150 IS b=bus-0 d=\\.\libusb0-0002--0x04a9-0x3234 v=0x4a9 p=0x3234 s=689D5005104943C09E988E4EA8301E22
What is the dev/bus connect string [as an example] for either of these - please ?
d=<dev string> b=<bus string>
Note that the connect command accepts these as a Lua pattern: http://www.lua.org/manual/5.1/manual.html#5.4.1 (http://www.lua.org/manual/5.1/manual.html#5.4.1) so if you want to use the whole string, you'd need to escape at least the - characters with %, like
connect -b=bus%-0 -d=\\.\libusb0%-0002%-%-0x04a9%-0x3234
edit: as pointed out below, bus - needs escaping too
(technically for an exact match you should also escape the . but it matches . so it's ok)
I will add an option to disable pattern matching, because allowing the use of list output directly seems worthwhile.
Also note that you can easily list devices in a different format if you want, e.g.
!t=chdk.list_usb_devices(); for i,d in ipairs(t) do printf("%s %s\n",d.bus,d.dev) end
-
nice one - thanks 8)
Edit:
works as expected [after escaping the hyphen following "bus"]:
so if you want to use the whole string, you'd need to escape at least the - characters with %, like
connect -b=bus-0 -d=\\.\libusb0%-0002%-%-0x04a9%-0x3234
(i) first instance to capture "list"
(ii) 2nd instance with "connect -b=bus%-0 -d=\\%.\libusb0%-0001%-%-0x04a9%-0x3234"
(iii) 3rd instance with "connect -b=bus%-0 -d=\\%.\libusb0%-0002%-%-0x04a9%-0x3234"
as instructed, it worked without escaping the period - I just chose to do that.
-
Hi, I have a setup where a computer calls chdkptp on the command line to do remote shoot (rs -jpg) commands. It now works reliaby with powershot A2300 and A490 after some issues earlier. But the cycle time until another remote shoot command can be reliably sent is still a bit long. Reyalp has helped me look into various speed optimization issues previously in this thread. Since some time has passed and I haven't kept track of developments here let my ask: Has there been any news on the cycle time front? Does anyone know of some new canon budget compact cameras with CHDK support that perhaps could lower the cycle time for remote shoot? Or any new developments in CHDK/chdkptp on the horizon that could lower cycle time?
-
But the cycle time until another remote shoot command can be reliably sent is still a bit long.
How long is "long"? And how long would you want it to be?
-
@tpont, It would be great if you could make 100 pictures of same object, same lightning and no focus change and post the timestamps of the file written in a CVS here. Also a description of the cam settings, type , resolutions etc. etc. We can use this as a reference for others to compare how fast their shots are.
And:
If you set you camera even without CHDK to all manual with no scene dynamics that change, like variable brightness, into continuous shoot with 100 pictures (Tape shutter?) with the fastest SD you can have you have an idea of what the camera is capable of. Then added the overhead time of transferring a e.g. 3MB file over USB from camera RAM via -rs. Faster than this it will never be. If your current settings and tryout are ~20% above this value, great!. If they are e.g.500% above, surely looking into chdkptp sourcecode and lua scripts and settings will be needed.
-
How long is "long"? And how long would you want it to be?
In a best case scenario I want a cycle time of 2 seconds for roughly parallel shots with two cameras. With roughly parallel I mean that the cameras can be up to 500 milisecs out of sync without any problem.
What I get in practice is a cycle time average a bit over 4 seconds. The test I calculated this average from included a few errors. With errors I mean when one of the cameras doesn't react to a shoot command because the camera hasn't finished its previous cycle yet. The errors appear because the cycle time of each camera appears to vary in practice so it is hard to know exactly when then next photo can be taken. To mitigate that problem I run a script that checks if two new jpg files are created in the harddrive destination folder soon after the shoot command. If only one or zero new jpg files are detected after a certain number of miliseconds a notification pops up asking for a reshoot and any jpg from the error shoot is discarded.
A manually shot sequence of photos in continous mode with a single camera (button held down) in the same conditions takes on average 1.9 seconds per shot when saving to the SD card in the camera.
-
In a best case scenario I want a cycle time of 2 seconds for roughly parallel shots with two cameras. With roughly parallel I mean that the cameras can be up to 500 milisecs out of sync without any problem.
How are you controlling the cameras?
What I get in practice is a cycle time average a bit over 4 seconds. The test I calculated this average from included a few errors. With errors I mean when one of the cameras doesn't react to a shoot command because the camera hasn't finished its previous cycle yet. The errors appear because the cycle time of each camera appears to vary in practice so it is hard to know exactly when then next photo can be taken.
This seems like a problem with your specific control setup, not a general problem with shooting rate.
A manually shot sequence of photos in continous mode with a single camera (button held down) in the same conditions takes on average 1.9 seconds per shot when saving to the SD card in the camera.
In my testing, chdkptp remoteshoot in continuous mode was roughly equivalent to continuous mode to the card.
A single shot without continuous mode should be fairly similar to a single shot on the camera. If it's not, doing some timing results might be helpful.
I haven't tested multiple cameras doing remoteshoot in different instances of chdkptp. If you are running them in parallel, it's possibly there isn't enough USB throughput to transfer from both at full speed.
-
How are you controlling the cameras?
From the command line. I use two separate instances of chdkptp, one for each camera. I first start the cameras, set the zoom and lock focus. Then I run this command when space is pressed on the keyboard.
chdkptp -c"-p=#######" -e"rs 'C:\test\somefilename' -jpg"I then have another script monitor the output folder every 50 miliseconds for matching filenames. If the files are found a test is done to see if the files are corrupted because every now and then chdkptp saves a jpg file that is only partial. I check if the last byte of the jpg is correct. If the files are ok the shoot script will accept space key input to run again. After the file has been verified as successfully written to the harddrive the cameras are usually ready for another shot. But every now and then one of the cameras still fail to shoot in that situation. That is what makes me think there is some issue with the cycle time. Basically the camera now and then seem to, after the jpg from the previous shot is successfully saved, spend time doing something that blocks a new remote shoot command from having effect.
This seems like a problem with your specific control setup, not a general problem with shooting rate.
Do you see anything specific in my description of the setup above that might be the problem?
I haven't tested multiple cameras doing remoteshoot in different instances of chdkptp. If you are running them in parallel, it's possibly there isn't enough USB throughput to transfer from both at full speed.
Ok, I will test if there is a speed difference when using two different computers, one for each camera.
-
If the files are found a test is done to see if the files are corrupted because every now and then chdkptp saves a jpg file that is only partial.
That's the first I have heard of this, and it is not expected behavior. If you can find a way to reproduce it, I'd certainly like to hear it.
But every now and then one of the cameras still fail to shoot in that situation.
What specifically happens when when it fails to shoot?
Does chdkptp connect?
Does the rs command get issued?
Is there any output after the rs command is issued?
Does anything happen on the camera display?
If you put
-e"set cli_verbose=2"
in your chdkptp command, the remoteshoot process will produce more verbose output, which may help identify where it is failing.
you can use
set cli_time=true
to show how long the actual rs command takes.
That is what makes me think there is some issue with the cycle time. Basically the camera now and then seem to, after the jpg from the previous shot is successfully saved, spend time doing something that blocks a new remote shoot command from having effect.
After the jpeg is downloaded, it should be done. It is possible for shoot to fail. It's also possible you could be encountering this issue: http://chdk.setepontos.com/index.php?topic=11035.0 (http://chdk.setepontos.com/index.php?topic=11035.0)
Try putting the cameras into alt mode before you start any shooting.
Do you see anything specific in my description of the setup above that might be the problem?
No. I will try to test with two cameras as you have described.
-
What specifically happens when when it fails to shoot?
Does chdkptp connect?
Does the rs command get issued?
Is there any output after the rs command is issued?
Does anything happen on the camera display?
I did some tests with the A2300. After a script has verified that the jpg is saved and after the text "BUSY" has disappeared from the camera gui and after the command line window has produced a prompt for new input there is still a period of time, at least a half second but sometimes longer, when a new shoot command produces this error message:
ERROR: no matching devices found
ERROR: not connected
When I deliberately wait a bit after the file is verified then the shoot goes through without error. Doing so I get on average 4 seconds per cycle in practical use with only the A2300 camera. I estimate that the speed of the A2300 in solo shooting is about the same as for the A2300 running in parallell with another camera. So I don't think the USB bandwidth is a slow down in dual camera use. But there could still be some other USB related issue when using the two cameras. The A490 is a second or so slower than the A2300.
If the files are found a test is done to see if the files are corrupted because every now and then chdkptp saves a jpg file that is only partial.
That's the first I have heard of this, and it is not expected behavior. If you can find a way to reproduce it, I'd certainly like to hear it.
It happens rarely so I haven't been able to pin down a cause yet. And I haven't seen it happen with the two latest chdkptp version since I haven't used them much yet.
-
I did some tests with the A2300. After a script has verified that the jpg is saved and after the text "BUSY" has disappeared from the camera gui and after the command line window has produced a prompt for new input there is still a period of time, at least a half second but sometimes longer, when a new shoot command produces this error message:
ERROR: no matching devices found
ERROR: not connected
OK, I expect this happens because the chdkptp code resets the camera USB on disconnect (on windows you can hear the device disconnect / reconnect sound when this happens). So after disconnecting there is a short period when the device is not available. This is something I inherited from the ptpcam code, so it's quite possible it isn't needed. It is on my list of things to look at some day.
That said if you are interested in speed, you would be much better off just starting chdkptp once and sending the remoteshoot commands to it's standard input. This will avoid the reset and connect/disconnect overhead.
Another option would be to add a retry count to the connect command. This should be fairly easy and useful in other situations, so I will probably do that.
It happens rarely so I haven't been able to pin down a cause yet. And I haven't seen it happen with the two latest chdkptp version since I haven't used them much yet.
There was a bug in versions before r440 (snapshot 461) which would cause corrupt jpegs if the camera produced too many chunks. This did happen occasionally on my elph130.
-
Thank you very much for the helpful replies.
That said if you are interested in speed, you would be much better off just starting chdkptp once and sending the remoteshoot commands to it's standard input. This will avoid the reset and connect/disconnect overhead.
I have to admit I have never gotten the hang of how standard input/output commands work on windows. I tried to read up on it now here http://stackoverflow.com/questions/15994824/faking-standard-input-on-the-windows-command-line (http://stackoverflow.com/questions/15994824/faking-standard-input-on-the-windows-command-line) but I'm still uncertain how to translate that to the chdkptp case at hand. Could you post an example?
There was a bug in versions before r440 (snapshot 461) which would cause corrupt jpegs if the camera produced too many chunks. This did happen occasionally on my elph130.
That could very well be it. I will run some more tests with the latest version (r468) and see if I can reproduce the issue now. Hopefully not.
-
I have to admit I have never gotten the hang of how standard input/output commands work on windows. I tried to read up on it now here http://stackoverflow.com/questions/15994824/faking-standard-input-on-the-windows-command-line (http://stackoverflow.com/questions/15994824/faking-standard-input-on-the-windows-command-line) but I'm still uncertain how to translate that to the chdkptp case at hand. Could you post an example?
Not without more details. I assume
From the command line. I use two separate instances of chdkptp, one for each camera. I first start the cameras, set the zoom and lock focus. Then I run this command when space is pressed on the keyboard.
chdkptp -c"-p=#######" -e"rs 'C:\test\somefilename' -jpg"
means you are running chdkptp from some other program. How you would send input would depend on the program. If I remember right, you were using autohotkey before? I don't know anything specifically about it, but it seems like you should be able to start chdkptp once and send the rs 'C:\test\somefilename' -jpg as key presses if nothing else.
-
If I remember right, you were using autohotkey before? I don't know anything specifically about it, but it seems like you should be able to start chdkptp once and send the rs 'C:\test\somefilename' -jpg as key presses if nothing else.
Yes autohotkey. I ran a test where the commands are sent as textstrings to two cmd windows where chdkptp was in interactive mode. I don't notice any difference in speed. For the A490 the whole cycle from the rs command to a fresh interactive mode prompt still takes between 4.5 and 5 seconds (10 mpx, jpg, normal quality). The a2300 and a490 are roughly equal in speed when doing a shoot command that saves to the SD through interactive mode, it takes 2.5 to 3 seconds. It is in the file download step that the A490 is slower.
Is it possible that chdkptp will some day be able to download "in the background" and shoot at the same time? Or does the camera hardware make that impossible?
-
Yes autohotkey. I ran a test where the commands are sent as textstrings to two cmd windows where chdkptp was in interactive mode. I don't notice any difference in speed.
If you do it this way, you shouldn't get the "no devices found" error, or need to add delays to avoid it. The time to launch chdkptp, connect and disconnect is also non-zero. On my windows system,
$ time chdkptp -c
connected: Canon PowerShot D10, max packet size 512
real 0m0.280s
For the A490 the whole cycle from the rs command to a fresh interactive mode prompt still takes between 4.5 and 5 seconds (10 mpx, jpg, normal quality).
If you set cli_time=true you will get the actual time the rs command takes.
With some modification to the code, you could measure how much time is spent in various steps.
The a2300 and a490 are roughly equal in speed when doing a shoot command that saves to the SD through interactive mode, it takes 2.5 to 3 seconds. It is in the file download step that the A490 is slower.
Older cameras seem to have slower USB, so this is no surprise.
Is it possible that chdkptp will some day be able to download "in the background" and shoot at the same time? Or does the camera hardware make that impossible?
I don't camera hardware makes it impossible. With the current remote shoot code, the previous download must finish before the raw hook can continue for the next shot. This means download can overlap with the pre-shoot and exposure, but not the jpeg creation for the next shot. This already happens if you shoot in continuous mode. It might be possible to do the same in non-continuous mode, but I think it would require some changes to the camera script and chdkptp lua.
-
[quote author=reyalp link=topic=6231.msg108135#msg108135 date=1387578175]
If you do it this way [interactive mode], you shouldn't get the "no devices found" error, or need to add delays to avoid it. The time to launch chdkptp, connect and disconnect is also non-zero.
Ok. I will keep using the interactive mode script.
Older cameras seem to have slower USB, so this is no surprise.
Yes, this is likely the biggest factor. I'll look around for a replacement to the A490 camera. Do you, or anyone else reading, know if some newer models like the powershot A2500 (in CHDK alpha I read) has the filewrite feature, meaning it is possible that they in the future may support remote shoot?
Is it possible that chdkptp will some day be able to download "in the background" and shoot at the same time? Or does the camera hardware make that impossible?
I don't camera hardware makes it impossible. With the current remote shoot code, the previous download must finish before the raw hook can continue for the next shot. This means download can overlap with the pre-shoot and exposure, but not the jpeg creation for the next shot. This already happens if you shoot in continuous mode. It might be possible to do the same in non-continuous mode, but I think it would require some changes to the camera script and chdkptp lua.
Ok. In continous remote shooting ( rs -cont=20 ) the A490 cycle is around 1.8 seconds per shoot which is very good.
-
Yes, this is likely the biggest factor. I'll look around for a replacement to the A490 camera. Do you, or anyone else reading, know if some newer models like the powershot A2500 (in CHDK alpha I read) has the filewrite feature, meaning it is possible that they in the future may support remote shoot?
See the FWT column in this table http://chdk.wikia.com/wiki/CameraFeatureTable (http://chdk.wikia.com/wiki/CameraFeatureTable)
However, if you get a camera that isn't supported, there is a fair chance someone will be willing to add support.
Ok. In continous remote shooting ( rs -cont=20 ) the A490 cycle is around 1.8 seconds per shoot which is very good.
If you can accept fixed focus and exposure, it may be possible to create a "synchronized continuous" mode, where the camera operates in continuous mode, but waits until it gets a signal from the pc for each shot. Doing this correctly would probably require some changes in the core (like what lapser did for continuous mode timelapse) but it might be possible to get fairly close by not downloading something until you are ready for the next shot. The camera jpeg saving can overlap with shooting (up until the raw hook, where the remote shoot code forces a wait), so this might have to be done using the DNG header.
-
See the FWT column in this table http://chdk.wikia.com/wiki/CameraFeatureTable (http://chdk.wikia.com/wiki/CameraFeatureTable)
However, if you get a camera that isn't supported, there is a fair chance someone will be willing to add support.
Ok thanks.
If you can accept fixed focus and exposure, it may be possible to create a "synchronized continuous" mode, where the camera operates in continuous mode, but waits until it gets a signal from the pc for each shot. Doing this correctly would probably require some changes in the core (like what lapser did for continuous mode timelapse) but it might be possible to get fairly close by not downloading something until you are ready for the next shot. The camera jpeg saving can overlap with shooting (up until the raw hook, where the remote shoot code forces a wait), so this might have to be done using the DNG header.
That sounds very good. I already lock the focus manually in the setup steps and the lighting conditions do not change between the shoots.
-
Let me add that I'd happily beta test attempts at such a "synchronized continuous" mode if anyone takes a shot at it.
-
Let me add that I'd happily beta test attempts at such a "synchronized continuous" mode if anyone takes a shot at it.
The "shooting hooks" feature recently added to the trunk should enable this. I'll see if I can put something together.
-
I just started using chdkptp. Are there shortcut keys assigned to the buttons. So I can control the camera using keyboard?
Phuoc
-
I just started using chdkptp. Are there shortcut keys assigned to the buttons. So I can control the camera using keyboard?
Not currently, but it's a good suggestion.
-
Not currently, but it's a good suggestion.
Thanks, it should be a simple enhancement for developers. But it would be a giant leap for users :-) because then I can use e.g. WiiMote to control my camera.
Hope to see the feature very soon, thanks.
-
This is what I see with my S100, the image is a bit distorted:
(https://lh4.googleusercontent.com/-NSnQYiWTYJ8/Us_eJLMy-TI/AAAAAAAAC6c/l_Fw0bSFjao/w722-h516-no/Screenshot-140110-223901.png)
Can I do anything with settings to get it right?
2nd question, can I flip the viewfinder left-to-right? It's easier to use a mirror image when I turn the camera to me.
-
Can I do anything with settings to get it right?
No, it needs to be fixed in the CHDK code. It looks like there are two things missing:
1) The bitmap palette for the UI colors
2) The viewfinder size and offsets. These might change depending on the aspect ration selected on the camera, so you may be able to find one that looks better.
If you can create a "quick dump" from the debug tab, that may make it easier for us to fix.
2nd question, can I flip the viewfinder left-to-right? It's easier to use a mirror image when I turn the camera to me.
Not currently. It would probably be fairly straightforward to do in code.
-
If you can create a "quick dump" from the debug tab, that may make it easier for us to fix.
Dump attached.
-
Let me add that I'd happily beta test attempts at such a "synchronized continuous" mode if anyone takes a shot at it.
The "shooting hooks" feature recently added to the trunk should enable this. I'll see if I can put something together.
I added some code to do this in chdkptp r479. There are no changes in the C code since the last release, so you can just update the lua files if you want.
This is very preliminary. It doesn't do much error checking, and has some hard coded timeouts.
To load the new code use
!require'extras/rsint'.init()
This adds a new cli command call rsint. This takes options similar to the 'rs' command, but instead of shooting right away, it makes the camera wait at the "shutter" hook and gives you a prompt.
entering s shoots, downloads and prompts again when it's done
entering l shoots and exits rshoot mode.
The is no way to quit without shooting the final shot, because at the point the hook is called, the camera is already committed to taking the shot. It would be nice to have a hook after the jpeg is done before the next shot is started, but I'm not sure this is possible given that the jpeg saving can overlap with the next shot in continuous mode.
It doesn't allow you to adjust exposure while between shots, but this could be added.
-
This is what I see with my S100, the image is a bit distorted:
I had a closer look at this, and it appears you are using a quite old build (protocol 2.4 on the camera)
It looks like all the code should be there, so can you try the latest 1.2 build from http://mighty-hoernsche.de/ (http://mighty-hoernsche.de/) ?
-
This is what I see with my S100, the image is a bit distorted:
I had a closer look at this, and it appears you are using a quite old build (protocol 2.4 on the camera)
It looks like all the code should be there, so can you try the latest 1.2 build from http://mighty-hoernsche.de/ (http://mighty-hoernsche.de/) ?
Installed s100-101a-1.2.0-3317, all display issues fixed. Thank you so much.
-
I added some code to do this in chdkptp r479. There are no changes in the C code since the last release, so you can just update the lua files if you want.
Nice, will try it out when I find some more spare time.
-
Hello
Using A2200 chdk build 1.3.0.3152 and chdkptp build r438, I wanted to store the video directly on the PC.
The way , I found is to dump frames with debug.
Although I am able to play the dump from files , I would like to be able to extract individual frames from the dump file.
Can you advise on this topic ?
Cordially
-
Using A2200 chdk build 1.3.0.3152 and chdkptp build r438, I wanted to store the video directly on the PC.
The way , I found is to dump frames with debug.
This doesn't have the same quality as actual video files recorded by the camera. Currently there is no way to record actual camera video over USB.
Although I am able to play the dump from files , I would like to be able to extract individual frames from the dump file.
I guess you want to convert frames in the dump file to some kind of image format? There is currently not a command do to this, but it is something I would like to add. Most of the pieces are there.
If you explain exactly what you want to do, I may be able to come up with something.
The "screenshot" button saves a ppm image of the current live view display. In theory you could just call this every frame somewhere in redraw_canvas, but the function written in lua and isn't optimized at all so it would be quite slow.
You could also write your own code to read the dump file. The dump is essentially the live view data stream, plus a small header, and a per frame header giving the frame size. The live view stream is described in
https://tools.assembla.com/svn/chdk/trunk/core/live_view.h
In addition to the image data for the viewport and/or bitmap, it also includes information about the dimensions, aspect ratio, and position on the camera screen. These are necessary to display a correct image, and can change at runtime.
The dump header is described in chdku.lua live_dump_start https://tools.assembla.com/svn/chdkptp/trunk/lua/chdku.lua
The functions in liveimg.c https://tools.assembla.com/svn/chdkptp/trunk/liveimg.c are used to convert the camera YUV data to planer RGB. The scaling and positioning of the RGB data is done using CD code in gui_live.lua.
-
Hello
Using A2200 chdk build 1.3.0.3152 and chdkptp build r438,
@poussin : if you have some time, we still need test results for the A2200 manual focus test.
Instructions and download links are here : Setting focus from scripts or menus : please run this script and report back (http://chdk.setepontos.com/index.php?topic=11078.msg108859#msg108859)
TIA !
-
Hi Everyone! Dont know if I'm interrupting with some off the topic question, but I'm having some issues in my camera while using ptp commands.
I want to delete all files in my camera using ptpcam.exe. What i'm doing is first executing the command ptpcam -D (which is used to delete all files in camera). then i'm using command ptpcam --chdk="reboot" to reboot camera. But in case I have more then 1 files (yes only 1) to be deleted, camera hangs and doesn't recognize any command succeeding ptpcam -D. After that, only way to get camera to normal state is remove and insert the battery again. Any guide for solution?
Regards.
-
Hello
Using A2200 chdk build 1.3.0.3152 and chdkptp build r438,
@poussin : if you have some time, we still need test results for the A2200 manual focus test.
Instructions and download links are here : Setting focus from scripts or menus : please run this script and report back (http://chdk.setepontos.com/index.php?topic=11078.msg108859#msg108859)
TIA !
Ok , I will do it by this week end
-
Using A2200 chdk build 1.3.0.3152 and chdkptp build r438, I wanted to store the video directly on the PC.
The way , I found is to dump frames with debug.
This doesn't have the same quality as actual video files recorded by the camera. Currently there is no way to record actual camera video over USB.
Although I am able to play the dump from files , I would like to be able to extract individual frames from the dump file.
I guess you want to convert frames in the dump file to some kind of image format? There is currently not a command do to this, but it is something I would like to add. Most of the pieces are there.
If you explain exactly what you want to do, I may be able to come up with something.
The "screenshot" button saves a ppm image of the current live view display. In theory you could just call this every frame somewhere in redraw_canvas, but the function written in lua and isn't optimized at all so it would be quite slow.
You could also write your own code to read the dump file. The dump is essentially the live view data stream, plus a small header, and a per frame header giving the frame size. The live view stream is described in
https://tools.assembla.com/svn/chdk/trunk/core/live_view.h
In addition to the image data for the viewport and/or bitmap, it also includes information about the dimensions, aspect ratio, and position on the camera screen. These are necessary to display a correct image, and can change at runtime.
The dump header is described in chdku.lua live_dump_start https://tools.assembla.com/svn/chdkptp/trunk/lua/chdku.lua
The functions in liveimg.c https://tools.assembla.com/svn/chdkptp/trunk/liveimg.c are used to convert the camera YUV data to planer RGB. The scaling and positioning of the RGB data is done using CD code in gui_live.lua.
Thanks for your answer and sorry for being late to answer you.
When I move the camera , I need to be able to monitor the video and record it ( on the PC to overcome the size limitations of the SD card )
When the picture is suitable , I want to record in high resolution preferably using remoteshoot ( to be sure that the image is recorded on the PC disk )
During the replay , I want to be able to pause it and examine a particular frame.
Note: a series of remote shoots takes too long.
Tia !
-
I want to delete all files in my camera using ptpcam.exe. What i'm doing is first executing the command ptpcam -D (which is used to delete all files in camera).
I will try to answer your question, but this thread is about chdkptp https://www.assembla.com/spaces/chdkptp/wiki (https://www.assembla.com/spaces/chdkptp/wiki) not ptpcam.
ptpcam -D uses standard PTP commands, not CHDK extension commands. I haven't tested this or looked at how it works, but sometimes using standard commands change the state of the camera.
You can delete files using the CHDK extension by sending calling os.remove() in lua.
In chdkptp, the rm command does this for you. You could use rm -skip_topdirs DCIM to delete all image.
But in case I have more then 1 files (yes only 1) to be deleted, camera hangs and doesn't recognize any command succeeding ptpcam -D.
Does this only happen when you try to reboot, or if you use ptpcam -D by itself?
Reboot can sometimes have problems to. I would suggest making sure the camera is in playback mode and has retracted the lens before you call it. Also, if you delete all images and reboot, the file counter may not be saved, meaning when you take more images they will have the same numbers as ones you took before.
-
When I move the camera , I need to be able to monitor the video and record it ( on the PC to overcome the size limitations of the SD card )
Be aware the live dump format is uncompressed, so it will take up a lot of space very quickly. On my d10, the viewport alone is about 250kb per frame, so at 10 fps is over 2 mb/sec.
When the picture is suitable , I want to record in high resolution preferably using remoteshoot ( to be sure that the image is recorded on the PC disk )
During the replay , I want to be able to pause it and examine a particular frame.
Note: a series of remote shoots takes too long.
I don't see an easy solution with chdkptp as it is now.
If you are a programmer, it wouldn't be too hard to make something that let you play back live dumps with the ability to pause or advance frame by frame.
It would also be possible to make the live view code spit out images in some simple format that another process could turn into video.
There are also screen recording programs like fraps that could let you capture the live view window I suppose.
-
Based on this previous link:
http://chdk.setepontos.com/index.php?topic=6231.msg107903#msg107903 (http://chdk.setepontos.com/index.php?topic=6231.msg107903#msg107903)
and for those who [like me] don't quite understand the multicam api yet, attached is some proof of concept CLI chdkptp multi-instance code enacted by autoit.
It's a sequential list of very rough code [no functions] and it's far from fast but I hope some may sometime find it useful.
I hope to try a similar single instance "swap con" http://chdk.setepontos.com/index.php?topic=8769.msg91611#msg91611 (http://chdk.setepontos.com/index.php?topic=8769.msg91611#msg91611) version, if I ever get a few hours
PS: it works for me with 1 and 2 cams - not with zero. I don't have any hubs yet but suspect it will work ::) with that complexity. It has zero error handling and you need to edit the code to accomodate your current multi-instance chdkptp install [but why would you have one :blink:].
-
If you are a programmer, it wouldn't be too hard to make something that let you play back live dumps with the ability to pause or advance frame by frame.
If you don't want to hack into program codes AviSynth may work for you which allows you to create a slideshow with a simple script, provided the live dump filename has a sequence number. If you use it in conjunction with AvsP you have a preview function in the editor which launches a media player and so you can play the image sequence like any other video. Whether it plays in real time, it depends on your CPU and image size.
Just found a link of a small introduction for the above topic. I'm sure it explains better than I did :-)
http://www.afterdawn.com/guides/archive/avsp-avisynth_made_easy.cfm (http://www.afterdawn.com/guides/archive/avsp-avisynth_made_easy.cfm)
-
If you don't want to hack into program codes AviSynth may work for you which allows you to create a slideshow with a simple script, provided the live dump filename has a sequence number.
I may be misunderstanding, but there is zero chance avisynth will understand the dump format. You might be able to write an avisynth plugin that does.
-
but there is zero chance avisynth will understand the dump format.
You are right :-)
-
I added some code to do this in chdkptp r479. There are no changes in the C code since the last release, so you can just update the lua files if you want.
I don't find r479 here https://www.assembla.com/spaces/chdkptp/documents (https://www.assembla.com/spaces/chdkptp/documents) , is it available elsewhere?
-
https://www.assembla.com/code/chdkptp/subversion/nodes/481/trunk/lua (https://www.assembla.com/code/chdkptp/subversion/nodes/481/trunk/lua)
There is a link 'Download' on the right side.
msl
-
Ok, got it. Thanks msl.
I replaced the lua subfolder in my chdkptp-r468-win32 folder with the new one from trunk.
The command
!require'extras/rsint'.init()appears to go through (no error message when running it at least). But the command rsint errors like this
ERROR: build does not support shoot hook
-
Hello
Using A2200 chdk build 1.3.0.3152 and chdkptp build r438,
@poussin : if you have some time, we still need test results for the A2200 manual focus test.
Instructions and download links are here : Setting focus from scripts or menus : please run this script and report back (http://chdk.setepontos.com/index.php?topic=11078.msg108859#msg108859)
TIA !
After I ran the test ,
I was wondering if it was possible to run the test from chkptp and how to do it.
( including the settings of the camera )
TIA !
-
After I ran the test , I was wondering if it was possible to run the test from chkptp and how to do it. ( including the settings of the camera )
I don't know if you noticed, but I replied to your post (http://chdk.setepontos.com/index.php?topic=11078.msg109524#msg109524) in the other testing thread. You missed a couple of tests and it would be good to get those results too :D
-
I replaced the lua subfolder in my chdkptp-r468-win32 folder with the new one from trunk.
The command
!require'extras/rsint'.init()appears to go through (no error message when running it at least). But the command rsint errors like this
ERROR: build does not support shoot hook
You need to use a recent CHDK 1.3 build from http://mighty-hoernsche.de/trunk/ (http://mighty-hoernsche.de/trunk/)
-
After I ran the test , I was wondering if it was possible to run the test from chkptp and how to do it. ( including the settings of the camera )
Further to my question I ran into a problem
Here is the log of the command loadfile("A/CHDK/SCRIPTS/MF_TEST.LUA")()
when I wanted to play the dump file to see the error message
> list
*1:Canon PowerShot A2200 b=bus-0 d=\\.\libusb0-0002--0x04a9-0x322a v=0x4a9 p=0x322a s=85046B2D98F043448BDDA65F6A2726ED
recording to chdk_322a_20140125_232304.lvdump
559168264 bytes recorded to chdk_322a_20140125_232304.lvdump
error getting frame: ptp error
recording to chdk_322a_20140125_232535.lvdump
113046424 bytes recorded to chdk_322a_20140125_232535.lvdump
recording to chdk_322a_20140125_232611.lvdump
> .loadfile("A/CHDK/SCRIPTS/MF_TEST.LUA")()
67567984 bytes recorded to chdk_322a_20140125_232611.lvdump
playing \chdk_322a_20140125_232611.lvdump
loading dump ver 1.0
live timer update error
\chdkptp-r438-win32\lua\chdku.lua:1374: attempt to perform arithmetic on field 'margin_left' (a nil value)
stack traceback:
\chdkptp-r438-win32\lua\chdku.lua:1374: in function 'get_screen_width'
\chdkptp-r438-win32\lua\gui_live.lua:94: in function 'update_canvas_size'
\chdkptp-r438-win32\lua\gui_live.lua:401: in function <\chdkptp-r438-win32\lua\gui_live.lua:383>
[C]: in function 'xpcall'
\chdkptp-r438-win32\lua\gui_live.lua:424: in function <...s\doc tech\CANON\chdkptp-r438-win32\lua\gui_live.lua:422>
(tail call): ?
[C]: in function 'MainLoop'
\chdkptp-r438-win32\lua\gui.lua:630: in function <\chdkptp-r438-win32\lua\gui.lua:616>
(tail call): ?
\chdkptp-r438-win32\lua\main.lua:231: in main chunk
[C]: in function 'require'
[string "require('main')"]:1: in main chunklive timer update error
note : the lvdump size is 85 Mbytes
-
I hope to try a similar single instance "swap con" http://chdk.setepontos.com/index.php?topic=8769.msg91611#msg91611 (http://chdk.setepontos.com/index.php?topic=8769.msg91611#msg91611) version
Attached is that autoit proof of concept file.
-
After I ran the test , I was wondering if it was possible to run the test from chkptp and how to do it. ( including the settings of the camera )
Further to my question I ran into a problem
Here is the log of the command loadfile("A/CHDK/SCRIPTS/MF_TEST.LUA")()
when I wanted to play the dump file to see the error message
after a PC reboot and without the camera connected , I reran chdkptp|debug |play from file chdk_322a_20140125_232304.lvdump and I was able to display the frames and to extract the error message from the frames
Attached is the error message from the run of MF_TEST.LUA from chkptp.
-
Attached is the error message from the run of MF_TEST.LUA from chkptp.
That error would have originated from the fprintf() function call in line 188 of the script. It's trying to print the various bits of informaion returned from calling get_buildinfo() and it looks like bi.platsub is being returned as "null" when you run the script from chdkptp.
-
You need to use a recent CHDK 1.3 build from http://mighty-hoernsche.de/trunk/ (http://mighty-hoernsche.de/trunk/)
Ok running it now. The A490 average cycle time when saving to PC using rsint is now down to 2.1 seconds :) . From around 5. And the rsint mode appears to be forgiving. Sending a "s" command while the previous one is still processing appears to cue the command and run it when it can. I will test drive this with two camera parallel shooting through a script that sends commands to two cmd windows in interactive mode. But this is looking super good so far.
-
Sending a "s" command while the previous one is still processing appears to cue the command and run it when it can. I will test drive this with two camera parallel shooting through a script that sends commands to two cmd windows in interactive mode. But this is looking super good so far.
Good to hear.
One note is that there is currently a hard coded timeout, if no "s" or "l" is received for 60 seconds, the script will end, probably with some errors.
Edit: Oops, above is incorrect. The actual timeout is currently 10 second, and the camera will continue shooting every 10 seconds but not downloading. I'll try to clean this up.
I'm not sure if there is a limit to how long the camera can be made to wait in the shoot hook.
-
After I ran the test , I was wondering if it was possible to run the test from chkptp and how to do it. ( including the settings of the camera )
Further to my question I ran into a problem
Here is the log of the command loadfile("A/CHDK/SCRIPTS/MF_TEST.LUA")()
For this to work, you need to set the menu parameters (a, b, c etc) before calling the script. Anyway, waterwingz script isn't designed to work in ptp, so other things might go wrong too.
It's not obvious to me why playing the dump failed.
-
Edit: Oops, above is incorrect. The actual timeout is currently 10 second, and the camera will continue shooting every 10 seconds but not downloading. I'll try to clean this up.
I'm not sure if there is a limit to how long the camera can be made to wait in the shoot hook.
Ok, that explains one thing I noticed. On the A490 when entering rsint mode the led blinks all the time. After around 10 seconds the screen shows "busy" and the text stays until "s" is pressed. The a2300 does not blink the led at first but it starts blinking after the 10 seconds.
Anyway, it works with two cameras. Tested it for around 50 photos in a row without any issues.
I figured out that I can set a custom save folder by changing the command line folder to the desired location before starting interactive mode and rsint.
-
Anyway, it works with two cameras. Tested it for around 50 photos in a row without any issues.
I figured out that I can set a custom save folder by changing the command line folder to the desired location before starting interactive mode and rsint.
Yes, most of the normal remoteshoot options should work with rsint.
In chdkptp changeset 482 (https://www.assembla.com/code/chdkptp/subversion/commit/482) I improved the timeout behavior. It now defaults to 60 seconds, and can be adjusted using the -cmdwait option to rsint. So
rsint -cmdwait=5
will time out after 5 seconds.
When it does time out, the camera script will end and rsint will exit the next time you enter something.
You must update extras/rsint.lua and chdku.lua to use this. You also need to update your CHDK build to 3342 or later.
-
I updated and it is working. I first tried setting a custom save path once in rsint mode like this
s 'C:\test\file'But that freezes chdkptp and the camera. I can press the shutter button on the camera to escape the freeze. But no file is saved to the target location.
Then I realized that the folder goes as parameter to rsint, like so
rsint C:\testThat works and saves each image with the filename format IMG_3410, IMG_3411, etcetera in the folder C:\test
-
After I ran the test , I was wondering if it was possible to run the test from chkptp and how to do it. ( including the settings of the camera )
Further to my question I ran into a problem
Here is the log of the command loadfile("A/CHDK/SCRIPTS/MF_TEST.LUA")()
For this to work, you need to set the menu parameters (a, b, c etc) before calling the script. Anyway, waterwingz script isn't designed to work in ptp, so other things might go wrong too.
It's not obvious to me why playing the dump failed.
Thanks for the answers.
Running the script in ptp was an interesting experiment to test the frame dump , display and "extract".
Since playing the dump succeeded after a PC reboot and when the camera was now longer connected , it may not be an important issue .
-
reyalp, is it possible to later on add a parameter for custom filenames for each image by passing parameters to each individual "s" command?
-
reyalp, is it possible to later on add a parameter for custom filenames for each image by passing parameters to each individual "s" command?
That's a good idea, I'll see if I can find a reasonable way of doing it.
-
I was trying to connect to a A2200 chdk build 1.3.0.3152 and chdkptp build r438
using a .bat file
"chdkptp.exe" -g -c -r="C:\Users\exavue\Desktop\reader\rs.lua"
where rs.lua is :
rec
rs
quit
The connect fails when executed with the batch file but succeed when executed from the console .
Any clue on the source of the problem.
Thanks
-
I was trying to connect to a A2200 chdk build 1.3.0.3152 and chdkptp build r438
using a .bat file
"chdkptp.exe" -g -c -r="C:\Users\exavue\Desktop\reader\rs.lua"
where rs.lua is :
rec
rs
quit
The connect fails when executed with the batch file but succeed when executed from the console .
A few things:
1) What does "connect fails" mean? What actually happens?
2) Are you sure that this fails when run as a batch file, but works from the command line? I think the above should not work at all, whether from a batch file or command line. -r is processed before the connect option, and before the GUI is fully started. Processing it before the GUI is intentional, so you can set settings that need to set before the GUI is started. Doing it before the connect may be a bug, but in the case of the GUI, the connect should happen only after the GUI is started. The -r and .chdkptprc functionality is mainly intended for settings.
You can get around this using the "source" command with -e, like
chdkptp -g -c -e="source C:\Users\exavue\Desktop\reader\rs.lua"
or simply by using multiple -e commands for each command.
edit: I guess by "bat file" you maybe meant the -r option, not a .bat file?
3) Note that quit doesn't actually quit in the gui, so it will stay open. This is a bug. You could get around this using lua code to tell IUP to quit. You could use !os.exit() but I'm not sure everything would be cleaned up normally.
edit: actually quit works in the GUI if typed in the input, but not in a command file or -e command.
4) If you just want to run a command and quit, starting the GUI probably isn't a good idea, even if it worked, it will just slow things down. Just take the -g out of your command.
5) The file you run with -r is not a lua file, it's a chdkptp command file. chdkptp doesn't care what extension you use, but calling it .lua might confuse someone, or be a sign of confusion.
6) Using rec when you are already in rec mode is an error, so if you ran this multiple times without switching back to play, it would fail after the first one. There is supposed to be a setting to ignore errors, but I haven't implemented it yet.
The CLI commands aren't meant for heavy duty scripting, you can use Lua for that.
-
Thanks for your answer .
I was trying to connect to a A2200 chdk build 1.3.0.3152 and chdkptp build r438
using a .bat file
"chdkptp.exe" -g -c -r="C:\rs.lua"
where rs.lua is :
rec
rs
quit
The connect fails when executed with the batch file but succeed when executed from the console .
1) What does "connect fails" mean? What actually happens?
I modified the bat as suggested first by removing the call to GUI second by using e instead of r :
1)----------------------------
if rssansg.bat is :
"chdkptp.exe" -c -r="rs.lua"
if rs.lua is :
list
rec
rs
quit
then
rssansg.bat execution gives :
chdkptp.exe" -c -r="C:\Users\exavue\Desktop\reader\rs.lua"
-1:Canon PowerShot A2200 b=bus-0 d=\\.\libusb0-0001--0x04a9-0x322a v=0x4a9 p=0x3
22a s=85046B2D98F043448BDDA65F6A2726ED
ERROR: not connected
WARNING: rc rs.lua failed: error on line 2
open_camera_dev: ptp_opensession failed 0x2ff
open_camera_dev:usb_ptp_device_reset(): No such file or directory
usb_ptp_get_device_status(): No such file or directory
open_camera_dev: ptp_opensession 2 failed: 0x2ff
ERROR: connection failed
2) --------------------------------------------
with rsgce.bat
chdkptp.exe" -g -c -e=" rs.lua"
starting gui...
with the error message on the GUI
connected: Canon PowerShot A2200, max packet size 512
ERROR: unknown command 'C'
UPDATE: the message originates during function cli:execute(line) at line 269 of cli.lua
OOPS : forgot "source" in the command line
try with :
chdkptp.exe" -g -e="source C:\rsconnect.lua"
where rsconnect.lua is
connect
list
rec
list
rs
quit
gives in GUI
connected: Canon PowerShot A2200, max packet size 512
*1:Canon PowerShot A2200 b=bus-0 d=\\.\libusb0-0001--0x04a9-0x322a v=0x4a9 p=0x322a s=85046B2D98F043448BDDA65F6A2726ED
*1:Canon PowerShot A2200 b=bus-0 d=\\.\libusb0-0001--0x04a9-0x322a v=0x4a9 p=0x322a s=85046B2D98F043448BDDA65F6A2726ED
ERROR: not in rec mode
ERROR: error on line 5
Note: The GUI is very useful to monitor the image ( and debug )
It seems to me there is a timing problem .
When the CHDKPTP commands are typed from the console in the GUI , it works but then they are included in the "rs.lua" , the "connect" command may not not have the time to complete before the next command tries to execute.
Update : it seems to be true also for the "rec" command in the rsconnect.lua example
-
Note: The GUI is very useful to monitor the image ( and debug )
If the quit actually worked, you'd never have a chance to see it. While a command file is being run, you probably can't interact with the GUI, and the live view wouldn't update until it's finished.
I have no idea why a batch file would behave differently from typing the commands in a command prompt.
I'll look into these issues if I get a chance, but as I said I never intended cli command files to be used for serious scripting. You would probably be better off doing this kind of stuff in Lua.
If you can explain what you are actually trying to do, I might be able to suggest better approaches, or tell you whether it is possible.
-
Note: The GUI is very useful to monitor the image ( and debug )
If you can explain what you are actually trying to do, I might be able to suggest better approaches, or tell you whether it is possible.
I want to build a series of high level commands stored as a batch file to control the camera from the PC
by example : {connect , rec , remoteshoot ,disconnect }
{connect , rec , video , download }
{connect,liveview}
then I can display the image or the video on the PC screen .
updates:
1)the problem is :
with the batch file , the command has not the time to finish its task before the next command is issued , hence the error message.
2)the PC OS is Windows 7 or higher.
3)the time necessary for a specific command to complete its task is "variable"
-
I have a very recent chdk running on my camera (I think--3349) and I'm running what I think is the latest version of chdkptp on my headless dockstar running debian.
I can connect, zoom, shoot, and download, but I'm having a problem with remoteshoot (rs)--I get "WARNING: capture_get_data error timed out".
Here is a session:
/usr/src/chdkptp/lua# /usr/src/chdkptp/chdkptp -i -c
connected: Canon PowerShot A590 IS, max packet size 512
con> rec
con 1> rs /var/www
WARNING: capture_get_data error timed out
ERROR: timed out
con 4> q
bye
I also get this if no path is provided, just "rs"
A question separate from chdkptp: If I'm running the camera always powered (no batteries) is there a way to keep it from turning itself off?
-
/usr/src/chdkptp/lua# /usr/src/chdkptp/chdkptp -i -c
connected: Canon PowerShot A590 IS, max packet size 512
con> rec
con 1> rs /var/www
WARNING: capture_get_data error timed out
ERROR: timed out
This means it timed out waiting for data to become available. Does the camera shoot? If not, there may be something on the camera that is preventing the shot from the starting, e.g. in automode the camera might refuse to shoot if it can't focus.
What version of chdkptp are you using? ver -p should tell you. If you are using chdkptp before r426, there are some bugs that can cause this behavior.
Assuming you are building it yourself (I'm guessing so for dockstar) you may want to try the latest svn.
Does "shoot" work?
A question separate from chdkptp: If I'm running the camera always powered (no batteries) is there a way to keep it from turning itself off?
Setting "disable LCD off" to always in the chdk menu should do this. You can also set this setting with set_config_value()
-
A question separate from chdkptp: If I'm running the camera always powered (no batteries) is there a way to keep it from turning itself off?
Try : set_config_value(67, 3)
-
This is the file I downloaded and unzipped to the SD to put chdk on the camera:
a590-100e-1.3.0-3349-full.zip
To get chdkptp on the dockstar I moved to the directory /usr/src and did this:
svn co http://subversion.assembla.com/svn/chdkptp/trunk (http://subversion.assembla.com/svn/chdkptp/trunk) chdkptp
I moved to the chdkptp directory and looked at config-sample-linux.mk, which seemed ok, so I copied it to config.mk
I ran make, and all appeared ok.
I looked in USAGE.TXT, but didn't do anything
I can turn the camera on in play mode and connect with
cd lua
/usr/src/chdkptp/chdkptp -i -c
(I tried setting LUA_PATH="/usr/src/chdkptp/lua/cli.lua" but still got lua errors unless I switched to /usr/src/chdkptp/lua)
I did not set LD_LIBRARY_PATH because I didn't understand what it did and couldn't find any "uip" on the dockstar.
Once connected, I can zoom, shoot, and download the image. "rs" appears to shoot, including flash, but the download fails with "WARNING: capture_get_data error timed out"
ver -p gives this
con> ver -p
chdkptp 0.4.0-alpha built Feb 6 2014 21:40:08
host:2.6 cam:2.6
-
/usr/src/chdkptp/chdkptp -i -c
(I tried setting LUA_PATH="/usr/src/chdkptp/lua/cli.lua" but still got lua errors unless I switched to /usr/src/chdkptp/lua)
LUA_PATH should be something like /usr/src/chdkptp/lua/?.lua The suggested way to do this is to use a shell script, see chdkptp-sample.sh but I don't think this is related to your problem.
I did not set LD_LIBRARY_PATH because I didn't understand what it did and couldn't find any "uip" on the dockstar.
It's IUP, but this is only required for the GUI. Since your system is headless, you don't need it.
Once connected, I can zoom, shoot, and download the image. "rs" appears to shoot, including flash, but the download fails with "WARNING: capture_get_data error timed out"
What is the review setting in the Canon menu? If it is "hold" the shot won't complete until you press the shutter again, which will cause a timeout like you are seeing.
If that isn't it, using
set cli_verbose=2
may provide a little more info on where it stops.
-
I set the lua path as follows:
LUA_PATH='/usr/src/chdkptp/lua/?.lua'
I still get lua errors running "/usr/src/chdkptp/chdkptp -i -c", but all works fine if I switch to the /usr/src/chdkptp/lua directory and run.
The review setting in the Canon menu was "2 sec". I changed it to "0".
Same error with more text after "set cli_verbose=2":
root@dock84:/usr/src/chdkptp/lua# /usr/src/chdkptp/chdkptp -i -c
connected: Canon PowerShot A590 IS, max packet size 512
con> rec
con 1> set cli_verbose=2
con 1> rs
rs_init
rs_shoot
get data 1
WARNING: capture_get_data error timed out
script wait time 0.0024
ERROR: timed out
con 4> q
bye
-
Just for all CHDKPTP enhousiasts, I've made a Wikipage (http://chdk.wikia.com/wiki/Getting_CHDKPTP_on_BeagleBone_Black_to_work) on how to get headless CHDKPTP running on a Beagle Bone Black (http://chdk.wikia.com/wiki/Getting_CHDKPTP_on_BeagleBone_Black_to_work) ARM board :haha
-
I set the lua path as follows:
LUA_PATH='/usr/src/chdkptp/lua/?.lua'
I still get lua errors running "/usr/src/chdkptp/chdkptp -i -c", but all works fine if I switch to the /usr/src/chdkptp/lua directory and run.
That's very strange. It's a really simple thing that should not be platform dependent, but I guess it probably isn't related to your other problem.
The review setting in the Canon menu was "2 sec". I changed it to "0".
2 shouldn't have caused the problem anyway, although it would probably add 2 sec delay to each shot.
Same error with more text after "set cli_verbose=2":
con 1> rs
rs_init
rs_shoot
get data 1
WARNING: capture_get_data error timed out
script wait time 0.0024
This is also very strange, I don't have any explanation.
How much time passes between the rs command, the get data 1, and the WARNING? It should take something like 30 seconds to time out. If you are using exposures are longer than about 30 sec (or 15 if dark frame is enabled) you would get timeouts.
I am pretty sure other people who have used remoteshoot successfully on a590. It's possible some camera setting is interfering, but I can't think of any other than recreview that would.
Can you try it using a different computer?
-
How much time passes between the rs command, the get data 1, and the WARNING? It should take something like 30 seconds to time out. If you are using exposures are longer than about 30 sec (or 15 if dark frame is enabled) you would get timeouts.
Any exposure longer than 18 seconds or 9 seconds plus dark frame causes a timeout problem.
On the shorter exposures everything works perfectly.
-
Hi everyone,
I've got CHDK PTP working beautifully with my camera, and now I want to automate it to take photos on a regular interval, and save them onto the computer without filling up the sd card. Unfortunately, I'm not familiar with the coding, so I'd really appreciate any help. I've spent some time looking over this forum, but I think I'm missing some of the basics, but can't figure out where to start. I'm probably doing it all wrong, but here's what I have done so far. Using the GUI, after connecting and setting up the camera in record mode, I enter in the console:
source D:\path\to\intervalometer.txt
intervalometer.txt is simply:
rs D:\path\to\downloaded\pics -dng
! sys.sleep(5000)
rm DCIM -skip_topdirs
! sys.sleep(2000)
source D:\path\to\intervalometer.txt
Problems with this are 1) eventually I get ERROR: too many nested source calls, and 2) once the script runs, there's no nice way to stop it. I guess a script that calls itself is not the best idea. I imagine an intervalometer script with remote shooting should be fairly straight forward, but I just don't know where to start. Would someone please show me how to do it properly?
Thanks
-
Any exposure longer than 18 seconds or 9 seconds plus dark frame causes a timeout problem.
Thanks for checking that. I'll add options for the various timeouts when I get a chance.
On the shorter exposures everything works perfectly.
Just for completeness, this is using a590? What OS and chdkptp version?
-
1) eventually I get ERROR: too many nested source calls,
Yes, this isn't really the way to make a loop, for that you should use Lua
I would suggest doing it something like this:
!dofile('d:/path/to/interval.lua')
where interval.lua is something like
while true do
status,err=cli:execute('rs -dng d:/path/to/downloaded/pics')
if not status then break end
sys.sleep(5000)
status, err=cli:execute('rm DCIM -skip_topdirs')
if not status then break end
sys.sleep(2000)
end
cli:print_status(status,err)
This will run until there is an error. Unfortunately, there is currently no good way to check for input inside a chdkptp script without blocking, but with the above script, turning off the camera would end it.
Note The \ are changed to / in the path, otherwise they will be treated as escape characters.
2) once the script runs, there's no nice way to stop it.
Yeah, this is the input problem mentioned above. I would like to fix this at some point, but it's a bit complicated. In the gui, you could run your script from a timer, but that's more complicated code than I can write off the top of my head right now.
I assume you are using -dng and rm because your camera doesn't yet support jpeg remoteshoot? If so, let us know which camera you have, someone may be able to implement it for you.
-
Regarding the problem of timing out using rs on the A590, the exposure is brief (fraction of a second), and the timeout takes about 10 seconds to occur.
I tried another camera on the Dockstar, an SX40HS. rs works fine, and "rs /var/www/test" puts the file, "test.jpg" in /var/www, where I can view it with a browser from my laptop.
Any further thoughts on getting this to work with the A590?
I'll try compiling chdkptp on a Ubuntu device tomorrow to see if that gets me any further (tho I really need to use the dockstar or other small headless device).
-
Regarding the problem of timing out using rs on the A590, the exposure is brief (fraction of a second), and the timeout takes about 10 seconds to occur.
Since a590 apparently works for blackhole, the most likely explanation seems like either a difference in settings (probably Canon firmware, but maybe CHDK) or a difference between the 100e and 101b ports.
I'll try compiling chdkptp on a Ubuntu device tomorrow to see if that gets me any further (tho I really need to use the dockstar or other small headless device).
Since the SX40 works, it seems quite unlikely it would be an OS specific issue. Would be good to confirm though.
edit:
I think I have found the bug
The filewrite task address was incorrect for 100e in the task hook. Try the attached test build.
-
Any exposure longer than 18 seconds or 9 seconds plus dark frame causes a timeout problem.
Thanks for checking that. I'll add options for the various timeouts when I get a chance.
On the shorter exposures everything works perfectly.
Just for completeness, this is using a590? What OS and chdkptp version?
Yes, I'm talking about the a590, I tried with Win XP and Win 7 and there is no difference.
chdkptp client version is r438 and r468, also no difference in use.
-
>I think I have found the bug ... The filewrite task address was incorrect for 100e in the task hook. Try the attached test build.
Yes--that fixed it. Thank you very much. rs works and "rs /var/www/test2" puts test2.jpg in /var/www, from which I can view it in the browser on my laptop, which is what I was looking for.
Thanks very much.
-
I'm now trying a camera with more zoom--the SX120IS.
lua_shoot() works, but rs fails with "unsupported format". Here is the sequence with "set cli_verbose=2" turned on.
/usr/src/chdkptp/chdkptp -i -c
connected: Canon PowerShot SX120 IS, max packet size 512
con> lua set_zoom(20)
con 1> lua set_zoom(10)
con 2> rs
ERROR: not in rec mode
con 3> rec
con 4> lua set_zoom(12)
con 5> rs /var/www/test3
ERROR: unsupported format
con 6> set cli_verbose=2
con 6> rs
rs_init
ERROR: unsupported format
con 7> q
bye
What is needed to get this to work?
-
Thanks so much reyalp, that works great.
I assume you are using -dng and rm because your camera doesn't yet support jpeg remoteshoot? If so, let us know which camera you have, someone may be able to implement it for you.
That's right. It would be nice if I could get the images as jpegs. I'm using some old canon powershots: SD700 IS and SD850 IS.
Thanks again!
-
Yes--that fixed it. Thank you very much.
Thanks for confirming, and sorry it took so long to get to the root of the problem. I've checked this in to the trunk and stable builds.
What is needed to get this to work?
Some additional code needs to be added for each port, same as for trig. This isn't huge job, so I or someone else here may be able to make builds if there is someone willing to test.
What Canon firmware version does your sx120is have?
Note that you should be able to get DNG files using remoteshoot with -dng on any CHDK supported camera. If jpeg support isn't implemented, the jpegs will still be saved to the card though.
That's right. It would be nice if I could get the images as jpegs. I'm using some old canon powershots: SD700 IS and SD850 IS.
Thanks again!
What is the canon firmware version of your sd700 ?
-
Yes, rs -dng worked.
:/usr/src/chdkptp/lua# /usr/src/chdkptp/chdkptp -i -c
connected: Canon PowerShot SX120 IS, max packet size 512
con> rec
con 1> rs /var/www/testdng -dng
con 4> q
bye
Firmware is GM1.00B.
I would be happy to test if someone can enable jpg downloading with rs for the SX120IS.
-
Thanks to nafraf, rs is now working on the SX120IS, using the chdk build he posted on the thread for that camera.
My next question is--how can I switch to low-res to see where I am while remotely controlling pan, tilt, and zoom, and then switch back to hi-res to shoot?
Is it shown somewhere how to stream the lcd headlessly to a browser?
-
What is the canon firmware version of your sd700 ?
sd700-101a and sd850-100c.
Thanks
-
Following nafraf's suggestion regarding resolution, I looked for set_prop information here:
http://chdk.wikia.com/wiki/UBASIC/propertyCaseUse (http://chdk.wikia.com/wiki/UBASIC/propertyCaseUse)
This text seemed relevant:
24 Image resolution: 0, 1, 2, 4, 8 for L, M1, M2, S, W (these are S3
designations: L is full resolution, M1 and M2 are progressively lower
resolutions, S is 640x480, and W is a “wide screen” format: full
resolution width, but less than full resolution height).
I tried the following session:
/usr/src/chdkptp/chdkptp -i -c
connected: Canon PowerShot SX120 IS, max packet size 512
con> rec
con 1> lua set_prop(24,4)
con 2> rs /var/www/test19
con 5> lua set_prop(24,5)
con 6> rs /var/www/test20
con 9> lua set_prop(24,0)
con 10> rs /var/www/test21
con 13> q
bye
I thought this would set higher or lower resolution on my SX120IS, but test19.jpg, test20.jpg, and test21.jpg all were 1600x1200, in accordance with the M3 setting on the camera.
Is the form of my "lua set_prop(24,4) command correct, and if so, what do I need to do to get the settings to take? (NOTE: (24,5) looks wrong--valid settings are single-bit--0,1,2,4,8.)
-
@lyzby
SX120 uses propset 3. Property 220 for Resolution chdk.wikia.com/wiki/PropertyCase
@trig
Test version for ixus800_sd700-101b/101a (filewrite task and simpler loader support) in attachment.
-
Thank you, nafraf--"lua set_prop(220,x)" works for setting the resolution on the SX120IS with chdkptp.
220,4 sets it to vga mode (640x480); 220,0 is full resolution, 10 megapixels, 3648x2736; 220,1 is 6 megapixels, 2816x2112; 220,2 is 4 megapixels, 2272x1704; 220,3 is 2 megapixels, 1600x1200; 220,5 is widescreen, 3648x2048.
Other cameras use different property sets--see: http://chdk.wikia.com/wiki/PropertyCase (http://chdk.wikia.com/wiki/PropertyCase)
/usr/src/chdkptp/chdkptp -i -c
connected: Canon PowerShot SX120 IS, max packet size 512
con> rec
con 1> lua set_zoom(25)
con 2> lua set_prop(220,4)
con 3> rs /var/www/test23
con 6> lua set_prop(220,0)
con 7> rs /var/www/test24
con 10> q
bye
-
What command line arguments should I use to set resolution and zoom, shoot with rs, disconnect, quit, and then be able to do it again?
This is what I tried (3 sequences):
root@dock84:/usr/src/chdkptp/lua# /usr/src/chdkptp/chdkptp -c -e"rec" -e"lua set_prop(220,4)" -e"lua set_zoom(10)" -e"rs /var/www/current" -e"dis" -e"q"
connected: Canon PowerShot SX120 IS, max packet size 512
ERROR: already in rec
bye
root@dock84:/usr/src/chdkptp/lua# /usr/src/chdkptp/chdkptp -c -e"rec" -e"lua set_prop(220,4)" -e"lua set_zoom(5)" -e"rs /var/www/current" -e"dis" -e"q"
connected: Canon PowerShot SX120 IS, max packet size 512
ERROR: already in rec
ERROR: a script is already running
bye
root@dock84:/usr/src/chdkptp/lua# /usr/src/chdkptp/chdkptp -c -e"rec" -e"lua set_prop(220,4)" -e"lua set_zoom(5)" -e"rs /var/www/current" -e"dis" -e"q"
connected: Canon PowerShot SX120 IS, max packet size 512
ERROR: already in rec
bye
The camera stays in rec mode (should I put "play" at the end, or can I rely on it's being in rec mode after the first time)?
When I get "ERROR: a script is already running" it doesn't shoot. If I re-enter the exact same command, that error doesn't occur and it does shoot. How do I terminate the running script?
What is the proper way of doing this without getting errors (assuming we'll really always be in "rec" mode)?
(Note that it did shoot the first and 3rd times.)
SX120IS
-
Is it shown somewhere how to stream the lcd headlessly to a browser?
There isn't currently a way to do this. You can run the GUI remotely with VNC or X, but performance is likely to be pretty poor.
It should be relatively easy for someone with the required programming skills to make something that reads the live view output and converts it to something an existing video streaming system accepts.
-
Is it shown somewhere how to stream the lcd headlessly to a browser?
There isn't currently a way to do this. You can run the GUI remotely with VNC or X, but performance is likely to be pretty poor.
It should be relatively easy for someone with the required programming skills to make something that reads the live view output and converts it to something an existing video streaming system accepts.
Where is the live view output documented?
-
Thank you, nafraf--"lua set_prop(220,x)" works for setting the resolution on the SX120IS with chdkptp.
Using the propcase module is highly recommended. Then you can refer to the propcases by name, which is not platform dependent, like
lua set_prop(require'propcase'.RESOLUTION,x)
The camera stays in rec mode (should I put "play" at the end, or can I rely on it's being in rec mode after the first time)?
It should stay in whatever mode you last put it in. Using -e commands, the error from rec should be harmless (this is not case for command files used with -r, in those an error will prevent all subsequent commands from completing.)
When I get "ERROR: a script is already running" it doesn't shoot. If I re-enter the exact same command, that error doesn't occur and it does shoot. How do I terminate the running script?
You are using lua ... which does not wait for the script to finish. Since set_zoom takes a significant amount of time, it isn't finished when you try to run the rs, so you get the "script already running" error.
To make chdkptp wait for the script, use luar instead.
You shouldn't need -e"dis" and -e"q", if you don't use -i it will automatically quit when the commands are done.
-
Where is the live view output documented?
In the source https://tools.assembla.com/svn/chdk/trunk/core/live_view.h
The chdkptp source has examples of how to decode it, in https://tools.assembla.com/svn/chdkptp/trunk/liveimg.c and https://tools.assembla.com/svn/chdkptp/trunk/lua/gui_live.lua
You could use the liveimg.c code to convert to RGB, but it currently only supports planar output (r, g and b each in their own buffer) and scaling is handled by the GUI code.
You would also have to arrange to get chdkptp to send the live view data while still accepting commands, which is not currently possible in the cli.
-
Using "luar" in the command line parameters for chdkptp fixed the problem of not shooting (with rs) because the zoom script had not finished. Thank you.
chdkptp -c -e"rec" -e"lua set_prop(220,4)" -e"luar set_zoom(20)" -e"rs /var/www/current"
Let me ask 2 questions about live view.
1. Is it possible with chdkptp to download a "snapshot" of the live view in a way similar to using "rs"?
2. If so, is it likely to be significantly faster to do that and decode it into a jpg and put it in a web server directory than it is to just take a vga shot with "rs", which does all the work for you but at a somewhat higher resolution? By "significantly faster" I mean more than a second. For reference, I would be talking about an SX120IS.
-
1. Is it possible with chdkptp to download a "snapshot" of the live view in a way similar to using "rs"?
Yes, using the dumpframes command. This saves the data in chdkptp lvdump format, which is essentially the raw live view protocol data with a minimal header.
Adding an option to output frames in a standard image format is on my list of things to do.
2. If so, is it likely to be significantly faster to do that and decode it into a jpg and put it in a web server directory than it is to just take a vga shot with "rs", which does all the work for you but at a somewhat higher resolution? By "significantly faster" I mean more than a second. For reference, I would be talking about an SX120IS.
Yes. It can do 10-20 frames per second.
-
Adding an option to output frames in a standard image format is on my list of things to do.
Sweet. I'd be happy to test on multiple platforms--A590IS, SX120IS, SX40HS. For my purposes, 320x240 might be ideal, although any jpg would be fine.
Any idea of a timeframe--weeks or months?
-
Adding an option to output frames in a standard image format is on my list of things to do.
Nice!
Is there a place where I can see the to-do list? under Tickets?
https://www.assembla.com/spaces/chdkptp/tickets (https://www.assembla.com/spaces/chdkptp/tickets)
There are also 2 features I really love to have:
1) Shortcut keys for all the buttons in the UI.
2) Mirrored preview image.
Thanks
-
Any idea of a timeframe--weeks or months?
I checked in some very preliminary code to do this in r487
This adds a -pbm option to dumpframes. This saves the viewport data as ppm (http://netpbm.sourceforge.net/doc/ppm.html) and the bitmap (ui overlay) as pam (http://netpbm.sourceforge.net/doc/pam.html). You can use -novp or -nobm to turn either one off.
The files are saved in the original resolution of the data, without any aspect ratio correction so they will appear quite distorted on most cameras.
pam is not as widely supported as other the other netpbm formats, but is the only one that supports an alpha channel. Imagmagick convert can be used to turn them into something more common.
Since the images are unscaled, you would probably want to run them through something like imagemagick or the netpbm tools anyway.
This is very preliminary, I will probably change things significantly before the the next released build.
Some things I'd like to do
- support dumping the frames from an existing lvdump file
- support piping the pbm data directly to another program
- recording frames from the gui while live view is running
- better control of the filenames
-
Is there a place where I can see the to-do list? under Tickets?
https://www.assembla.com/spaces/chdkptp/tickets (https://www.assembla.com/spaces/chdkptp/tickets)
In theory. In practice a lot of it is just in my head ;)
There are also 2 features I really love to have:
1) Shortcut keys for all the buttons in the UI.
2) Mirrored preview image.
Thanks for the reminder. Shortcut keys definitely seem like a valuable feature. Mirrored preview doesn't seem as widely useful but if there is an easy way to do it I'll try.
-
Thanks for the reminder. Shortcut keys definitely seem like a valuable feature. Mirrored preview doesn't seem as widely useful but if there is an easy way to do it I'll try.
Great! Thank you in advance.
At the moment, when I record video with my camera (for YouTube) I always have to use my microphone stand and hangs a small mirror which mirrors the LCD image of the camera. So I can look in the mirror and ensure I'm still in the frame hahaha... A mirrored preview would save all the hassle.
-
Hi nafraf,
I keep getting 404 attachment not found. Could you please post it again?
Thanks
@trig
Test version for ixus800_sd700-101b/101a (filewrite task and simpler loader support) in attachment.
-
reyalp, is it possible to later on add a parameter for custom filenames for each image by passing parameters to each individual "s" command?
In changeset 489, you can use "path" in rsint to set the output path. This works the same way as the initial destination argument to rs or rsint.
example
con> rsint
rsint> path temp
rsint> s
rc file temp/IMG_1531.jpg 1
...
rsint> path temp/foo
rsint> s
rc file temp/foo.jpg
(temp was an existing directory)
-
In changeset 489, you can use "path" in rsint to set the output path. This works the same way as the initial destination argument to rs or rsint.
Nice! I have used rsint some more and it just works. The path command will make it easier to keep track of pairs of photos from two cameras.
-
Hi
I just install chdkptp and it work great with a A1400.
Shoot, download jpg and raw, live view ok.
There are some problems left: (build chdkptp-r468-win32.zip )
- The Zoom+ and Zoom- buttons don't work, sometimes they work after Read Mode, but not always and very slowly.
- I plan to use chdkptp gui in live-view while sending commands with a custom application. (win32)
I tried to open another instance in console mode but It deconnect the first instance
Is there a solution to send commands to chdkptp in gui mode ?
For windows it could be a com server or pipe ou messages.
Keystrokes send by another application would do the trick too, as suggested by bigboss97
http://chdk.setepontos.com/index.php?topic=6231.msg108950#msg108950 (http://chdk.setepontos.com/index.php?topic=6231.msg108950#msg108950)
I have tried to modify gui_user.lua but the shorcuts don't seems to work.
I was thinking of write the command in a file, then send a keystroke to chdkptp gui with additional lua code to read the file and send the cli command.
According to http://www.tecgraf.puc-rio.br/iup/en/elem/iupbutton.html, (http://www.tecgraf.puc-rio.br/iup/en/elem/iupbutton.html,) this is supported by 3.0 and up
(mnemonic support since 3.0)
Do you use a lower version of iup or is it iup related ?
-
- The Zoom+ and Zoom- buttons don't work, sometimes they work after Read Mode, but not always and very slowly.
The zoom buttons just send click('zoom_in') or click('zoom_out')
- I plan to use chdkptp gui in live-view while sending commands with a custom application. (win32)
I tried to open another instance in console mode but It deconnect the first instance
The camera can only handle one PTP connection at a time.
Is there a solution to send commands to chdkptp in gui mode ?
There isn't currently any mechanism designed to do this. Of course, you could add your own code to read from a pipe or something. Both the GUI and the USB communication are single threaded, so you'd want something you could poll from a timer or something.
I have tried to modify gui_user.lua but the shorcuts don't seems to work.
According to http://www.tecgraf.puc-rio.br/iup/en/elem/iupbutton.html, (http://www.tecgraf.puc-rio.br/iup/en/elem/iupbutton.html,) this is supported by 3.0 and up
(mnemonic support since 3.0)
Do you use a lower version of iup or is it iup related ?
The windows build I post are currently built with IUP 3.5
Your issue might have to do with what has focus.
-
Thanks for quick response.
I can not make shortcuts buttons function.
I don't think it is focus related.
They don't work (Win32), even in the main ui (Try to change the button text 'Execute' by 'E&xecute')
I don't know why (Iup or the way it is integrated ?)
----
However I discovered that the menus shorcuts works.
So I make a single top level menu with name '&Command'
and add code to execute a command in the clipboard
This is the code modifications in gui.lua for those interested.
-- file gui.lua
-- Main Menu Definition.
menu = {}
menu.mnuMain = iup.menu
{
iup.item{title="&Command", action="execute_clipboard()"}
}
-- Additionnal function to call cli
function execute_clipboard()
local clipboard = iup:clipboard()
local cmd = ''
if clipboard.textavailable then
cmd = clipboard.text
else
iup.Message ("Warning", "Command not found in Clipboard")
return
end
add_status(cli:execute(cmd))
end
-- Modify line 504 in original gui.lua to show menu
-- menu = menu,
menu = menu.mnuMain,
I call this from my application by filling the clipboard with a command, activating chdkptp windows with AppActivate and sending Alt-C keystroke.
This code work but may be enhanced because that I have no skill in lua nor in iup :)
(Perhaps it's better to use a global variable for clipboard ?, clipboard must be distroyed ? )
I must admit that modfying the ui in lua is awesome !
-
I would like to rotate the live view (+/- 90°).
Can you tell me if it's possible to do that in gui_live.lua (probably slow) or may I have to modify liveimg.c and use CD functions (and recompile application ?)
-
I would like to rotate the live view (+/- 90°).
Can you tell me if it's possible to do that in gui_live.lua (probably slow) or may I have to modify liveimg.c and use CD functions (and recompile application ?)
See Coordinate System->Transform under http://www.tecgraf.puc-rio.br/cd/ (http://www.tecgraf.puc-rio.br/cd/)
!gui.live.icnv.dccnv:TransformRotate(10)
seems to work for me, but the origin isn't in the middle of the screen, so 90 rotates it off the screen.
Transform can likely also be used to mirror to as bigboss97 requested earlier..
edit:
Regarding key shortcuts / accelerators, you can also add your own key handlers to controls or the main dialog. See gui.lua inputtext:k_any() for an example.
edit:
If you are mucking with transforms and want to reset, use !gui.live.icnv.dccnv:Transform(nil)
To mirror, you can use
!width=gui.live.icnv.dccnv:GetSize();gui.live.icnv.dccnv:TransformScale(-1,1);gui.live.icnv.dccnv:TransformTranslate(-width,0)
-
Any hope for being able to download the LCD image as a jpg?
-
Any hope for being able to download the LCD image as a jpg?
Maybe eventually, but it's easy enough to convert netbpm netpbm formats if you want.
-
http://davis.lbl.gov/Manuals/NETPBM/doc/directory.html (http://davis.lbl.gov/Manuals/NETPBM/doc/directory.html)
-
Ok, so it's netpbm not netbmp?
What would the process be: chdkptp -c -e" ? ? ?"
What format? dng?
And then postprocess with netpbm or perhaps imagemagick?
-
Ok, so it's netpbm not netbmp?
What would the process be: chdkptp -c -e" ? ? ?"
What format? dng?
And then postprocess with netpbm or perhaps imagemagick?
See this post: http://chdk.setepontos.com/index.php?topic=6231.msg110306#msg110306 (http://chdk.setepontos.com/index.php?topic=6231.msg110306#msg110306)
I hope to clean this up a bit and put out a new build today. We'll see how far I get. the netpbm dump will probably go into a separate command from dumpframes.
-
I've uploaded snapshot 492 to the files area https://www.assembla.com/spaces/chdkptp/documents (https://www.assembla.com/spaces/chdkptp/documents)
There are two major additions. Both were discussed earlier in the thread, but to get everything in one place I'll document them here.
1) rsint (remote shoot, interactive)
This is a module in extras that allows you to remote shoot in continuous mode, while controlling the timing of the shots yourself. This requires CHDK 1.3, because it uses the shoot hook functionality. It currently can only be used in console CLI mode, not in the GUI.
To load the module use
!require'extras/rsint'.init()
This adds the rsint cli command. It takes the same options as regular rs for exposure settings and file formats.
When you use the rsint command, you get a rsint>
The prompt accepts 3 commands
s - shoots and waits for another command
l - shoots and exits rsint
path <new file path> - sets the output path. This is treated the same way as the output path option to rs. If you don't specify a path, it resets to default (i.e IMG_NNNN.JPG)
2) lvdumpimg
This command allows dumping live view frames to netpbm (http://netpbm.sourceforge.net/doc/) format images. This saves the viewport data as ppm (http://netpbm.sourceforge.net/doc/ppm.html) and the bitmap (ui overlay) as pam (http://netpbm.sourceforge.net/doc/pam.html).
The output files are in their native resolution, meaning that the aspect ration is not correct. Programs like imagemagick can be used to rescale them. The pam format is used for the UI overlay to support the alpha channel, but it is not as widely supported as ppm. You can use imagemagick or the netpbm tools to convert it to other formats.
The -vp and -bm options are used to specify whether the bitmap (ui overlay) or viewport (viewfinder image) are saved. Each can be used to specify the output path.
To allow capturing multiple frames without name conflicts, the output paths accept substitution variables in the from ${name[,arguments]}. The available variables are
${date} - the date / time the frame was transferred, formatted with os.date. If no format string is given, %Y%m%d_%H%M%S is used.
${frame} - the frame counter for this command (from 1 to the -count value). Note this resets every command invocation, so cannot be used to just continuously increment the number. The value is formatted with string.format. If no format is specified, %06d is used.
${time} - the time the frame was transferred, as a floating point unix-like timestamp with sub-second precision. The value is formatted with string.format. If no format is specified, %d is used, meaning you get a straight unix style timestamp without any sub second values.
There is currently no way to escape these patterns, so if you want a literal ${blahblah} in the name, you will have to hack the code.
The default filenames are
viewport vp_${time,%014.3f}.ppm
bitmap bm_${time,%014.3f}.pam
which gives you a unix timestamp with milliseconds. This gives you unique filenames that sort numerically.
tl;dr examples
con> lvdumpimg -count=2 -vp
vp_1394431593.054.ppm
vp_1394431593.177.ppm
con> lvdumpimg -vp=foo.ppm -bm=bar.pam
foo.ppm
bar.pam
con> lvdumpimg -vp=foo_${date,%H%M%S}_${frame,%02d}.ppm -count=3
foo_230851_01.ppm
foo_230851_02.ppm
foo_230852_03.ppm
In the future, I plan to add support for using substitution variables to other commands, like remoteshoot, downloads etc. I also plan to add an option to pipe the pbm data directly to another command.
-
In chdkptp r494, I added the ability to execute camera code from rsint. This allows you to adjust exposure parameters on the fly, without quitting rsint. This only affects rsint.lua, so you can just update that.
code is sent with the exec command, so to set the exposure you could use something like
rsint> exec set_tv96_direct(96)
Note that this does not affect the next shot, it affects the one after, because point where the camera waits is after the exposure is set up.
I will add more convenient exposure commands later.
-
The remoteshoot doesn't work with a A490 firmware 100f.
With rs -jpg, The file transfer stop at 1 004 032 byte and the camera freeze and shut off.
With rs -dng the complete file seems to be transferred but the camera say 'memory card error' after one shoot and need to be reset.
The readme say:
'- remote shoot via chdkptp (rs -jpg | -dng) fails after a variable number of shoots.'
I have tried various chdk version, 1.2, 1.3, DE
It's perhaps not related to chdkptp but I would like to know if someone succesfully used rs -jpg with this camera.
-
Posted by: reyalp
I also plan to add an option to pipe the pbm data directly to another command.
This would be very valuable !
Have you some tips on how to decode ppm and pam by program ?
-
The remoteshoot doesn't work with a A490 firmware 100f.
...
The readme say:
'- remote shoot via chdkptp (rs -jpg | -dng) fails after a variable number of shoots.'
Remote capture was tested, I guess that issue in notes.txt was solved too.
I made some tests with A495, if Image Quality = Fine, remote capture does not work. Please check if that makes difference.
Additionally, if you are willing to test a new version, I can send you a version where CHDK is loaded in ARAM.
-
I've uploaded snapshot 492 ...
1) rsint (remote shoot, interactive)
The cmdwait parameter is very useful so it may help people new to rsint if you add this from upthread to the description in post #520:
the rsint timeout behavior "defaults to 60 seconds, and can be adjusted using the -cmdwait option to rsint. So
rsint -cmdwait=5
will time out after 5 seconds."
-
The remoteshoot doesn't work with a A490 firmware 100f.
I have used rs -jpg many times with the A490 firmware 100f and currently use that camera with the command rsint. CHDK version a490-100f-1.3.0-3343-full_BETA, chdkptp version 492. Camera settings quality: fine and continuous mode.
-
Have you some tips on how to decode ppm and pam by program ?
You mean in your own code, or using another program?
If you are using your own code, you can use the netpbm library, or just refer to the specs: http://netpbm.sourceforge.net/doc/#formats (http://netpbm.sourceforge.net/doc/#formats) These formats are very simple, by design.
If you want a program to convert them, many common imaging program support ppm. For pam, you have less choices but imagemagick convert and the netpbm tools should work. Both are readily available for linux and windows.
Some examples using imagemagick
First, get some frames
chdkptp -c -e"lvdumpimg -vp=foo.ppm -bm=foo.pam"
Convert the bitmap to a png
convert foo.pam foo.png
As above, but fix aspect ratio (for a 4:3 camera)
convert foo.pam -resize 640x480! merge foo.png
The ! tells convert to not keep the original aspect ratio. Some shells you may need to use \! to prevent the shell from interpreting the !
You can also combine the viewport and bitmap to replicate how it appeared on the camera screen:
convert foo.ppm -resize 640x480! foo.pam -resize 640x480! -layers merge foo.jpg
Note on windows, convert conflicts with a system utility name. I rename copy it to imconvert.exe.
Note you can execute the above directly from chdkptp too
con> !return os.execute('imconvert.exe foo.ppm -resize 640x480! foo.pam -resize 640x480! -layers merge foo.jpg')
regarding remote capture failing, please use
set cli_verbose=2
and post the output from a failed capture.
In older versions of chdkptp (before r461) there as bug that would cause an "exceeded max_chunks" error when capturing jpegs in some cases. This did not affect dng.
@nafraf:
Can you clarify how it fails with fine quality, and whether DNG works?
-
@nafraf:
Can you clarify how it fails with fine quality, and whether DNG works?
I tested again, varying the image size.
If normal quality, jpeg and dng work for all image size.
Either L or M1 size, fine quality, rs -jpg, camera captures, LED blinks for a while and them camera beeps and reports "Memory Card Error", file is partially saved to PC (<1MB).
chdkptp reports:
WARNING: timed out waiting for shot script
ERROR: uninit a script is already running
Using M2, M3 or S size, remote capture works.
Either L or M2 size, fine quality, rs -dng, LED blinks once, and them camera beeps and reports "Memory Card Error", file is partially saved to PC (15MB).
Using M2, M3, or S size, remote capture works.
-
I tested again, varying the image size.
If normal quality, jpeg and dng work for all image size.
Either L or M1 size, fine quality, rs -jpg, camera captures, LED blinks for a while and them camera beeps and reports "Memory Card Error", file is partially saved to PC (<1MB).
Thanks. It seems like this would happen if the camera thought there were still more chunks to write. However, I'm pretty sure the MAX_CHUNKS_FOR_JPEG value is correct, there's not room in the structure for more. This would also break DNG, because the hook gets called to try to discard the jpeg.
Could filewrite get called more than once, like the r50+ cams? It clearly doesn't seem to have the seek code.
Can you post the output with cli_verbose=2 ?
-
Can you post the output with cli_verbose=2 ?
A495 100f 3378 trunk
con 4> rs -jpg /tmp
rs_init
rs_shoot
get data 1
rc file /tmp/IMG_0007.jpg 1
rc chunk get /tmp/IMG_0007.jpg 1 0
rc chunk size:1004032 offset:nil last:true
WARNING: timed out waiting for shot script
script wait time 30.3081
ERROR: uninit a script is already running
First chunk, but last=true?
-
First chunk, but last=true?
Same thing happens on the a3200 (r47), but the image has to be really detailed to trigger it. I have some logging to do...
-
I'm having trouble with the new ppm download, or rather, with converting it to something viewable.
I downloaded and compiled the latest chdkptp version, and also imagemagick.
If I run: /usr/src/chdkptp/lua# ../chdkptp -c -e"lvdumpimg -vp=/var/www/foo.ppm"
I get:
connected: Canon PowerShot SX120 IS, max packet size 512
/var/www/foo.ppm
If I then go to /var/www, and run "convert foo.ppm foo.jpg", I get the foo.jpg file, but can't view it in the webserver. If I "wget" it to my windows PC and try to open it, I get "Windows Photo Viewer can't open this picture because the file appears to be damaged, corrupted, or too large".
I also tried "convert foo.ppm -resize 640x480! foo2.jpg" and "convert foo.ppm -resize 640x480! foo2.png" without success.
The verbose option yields the following: convert -verbose foo.ppm foo.jpg
foo.ppm PPM 720x240 720x240+0+0 8-bit sRGB 518KB 0.020u 0:00.019
foo.ppm=>foo.jpg PPM 720x240 720x240+0+0 8-bit sRGB 518KB 0.040u 0:00.100
Any suggestions?
-
I made some tests with A495, if Image Quality = Fine, remote capture does not work. Please check if that makes difference.
Additionally, if you are willing to test a new version, I can send you a version where CHDK is loaded in ARAM.
Thanks a lot
At least it works in Normal quality mode.
I have the same behavior than you
Mode L - Quality Normal -> OK
connected: Canon PowerShot A490, max packet size 512
con> set cli_verbose=2
con> rs -jpg
rs_init
rs_shoot
get data 1
rc file IMG_0670.jpg 1
rc chunk get IMG_0670.jpg 1 0
rc chunk size:16384 offset:nil last:false
rc chunk get IMG_0670.jpg 1 1
rc chunk size:643584 offset:nil last:false
rc chunk get IMG_0670.jpg 1 2
rc chunk size:720957 offset:nil last:true
script wait time 2.0625
con 8>
Mode L - Quality Fine -> BUG
connected: Canon PowerShot A490, max packet size 512
con> set cli_verbose=2
con> rec
con 1> rs -jpg
rs_init
rs_shoot
get data 1
rc file IMG_0673.jpg 1
rc chunk get IMG_0673.jpg 1 0
rc chunk size:1004032 offset:nil last:true
script wait time 30.1563
con 4>
Mode L - Quality Fine - DNG -> OK but need reset at each shoot
connected: Canon PowerShot A490, max packet size 512
con> rec
con 1> set cli_verbose=2
con 1> rs -dng
rs_init
rs_shoot
get data 1
rc chunk get 4 0
rc chunk size:1320 offset:nil last:true
rc file IMG_0683.dng 2
rc chunk get IMG_0683.dng 2
rc chunk size:15467760 offset:nil last:true
dng 3720x2772x12
creating thumb: 128x96
script wait time 2.0625
con 4>
The dng is fully transfered and correctly converted by dcraw but the camera need to be reset
at each shoot (memory card error)
The jpg contains probably garbage (The jpeg header is not there)
I think it's a chdk side problem, for jpg files greater than about 1.5mo (buffer overflow ?)
As nafraf says, the last flag should not be true and the first chunk is always 1 004 032...
-
I have used rs -jpg many times with the A490 firmware 100f and currently use that camera with the command rsint. CHDK version a490-100f-1.3.0-3343-full_BETA, chdkptp version 492. Camera settings quality: fine and continuous mode.
I'll try this particular build.
Are you in higher resolution ? (L)
What are the sizes of the jpg ?
-
First chunk, but last=true?
This sounds like it could match multiple invocations of filewrite, where the first "session" only has one chunk.
You should be able to see if this happens by blinking an led in filewrite_main_hook, and shooting normally without remotecap, using the settings that cause the problem. You could also just increment a counter and display it with misc debug vals.
Regarding the failure at high quality, this may depend on the scene as well, since the amount of detail will affect the file size.
-
Any suggestions?
Not really, it would be very surprising if imagemagick didn't produce a valid jpeg. The files I converted worked in windows photo viewer. If the PPM wasn't valid, imagemagick shoould complain, but ppm is such stupidly simple format that is very unlikely. It's possible the jpeg is being corrupted in download, you should use md5 or something to verify that what you downloaded is identical to what is on the server.
You should also be able to view the ppm directly in many programs, irfanview for example.
-
Any suggestions?
Not really, it would be very surprising if imagemagick didn't produce a valid jpeg. The files I converted worked in windows photo viewer. If the PPM wasn't valid, imagemagick shoould complain, but ppm is such stupidly simple format that is very unlikely. It's possible the jpeg is being corrupted in download, you should use md5 or something to verify that what you downloaded is identical to what is on the server.
You should also be able to view the ppm directly in many programs, irfanview for example.
I copied the ppm file to my PC, installed imagemagick, and ran the conversion there. It worked, so the problem is with my dockstar installation. There are no complaints running it on the dockstar, but the file produced is 900+K instead of 42K on the PC--same for jpg or png (54K with conversion to 640x480). Bummer. I guess I need to go to the ImageMagick site and ask for solutions there.
On the PC:
imconvert -verbose foo.ppm -resize 640x480! foo4a.jpg
foo.ppm PPM 720x240 720x240+0+0 8-bit sRGB 518KB 0.000u 0:00.003
foo.ppm=>foo4a.jpg PPM 720x240=>640x480 640x480+0+0 8-bit sRGB 54.2KB 0.125u 0:00.137
-
I copied the ppm file to my PC, installed imagemagick, and ran the conversion there. It worked, so the problem is with my dockstar installation. There are no complaints running it on the dockstar, but the file produced is 900+K instead of 42K on the PC--same for jpg or png (54K with conversion to 640x480). Bummer. I guess I need to go to the ImageMagick site and ask for solutions there.
Hmm, 900+K might mean it's outputting it in the wrong format. Inspecting the file (with imagemagic "identify", the "file" command or a hex editor) might provide some clues. Perhaps you need to force the output format rather than just giving an extension. Prefixing the output path with the format should do this, like
$ convert foo.ppm jpeg:foo.derp
$ identify foo.derp
foo.derp JPEG 720x240 720x240+0+0 8-bit DirectClass 49.3KB 0.016u 0:00.000
You might also try netpbm tools instead. They should be very portable.
-
Perhaps you need to force the output format rather than just giving an extension. Prefixing the output path with the format should do this
Well. That was revealing.
convert /var/www/foo.ppm -verbose jpeg:/var/www/foo.derp
/var/www/foo.ppm=>jpeg:/var/www/foo.derp PPM 720x240 720x240+0+0 8-bit sRGB 518KB 0.050u 0:00.049
convert: no encode delegate for this image format `jpeg:/var/www/foo.derp' @ warning/constitute.c/WriteImage/1224.
convert: unable to open image `jpeg:/var/www/foo.derp': No such file or directory @ error/blob.c/OpenBlob/2643.
So, "no encode delegate for this image format". Whatever that means.
...
It apparently means that imagemagick was compiled without JPG support (as shown by "convert -list format" and also "convert -version" -- no Delegates listed). Also without PNG support. Now I'm searching for how to add those.
-
It apparently means that imagemagick was compiled without JPG support (as shown by "convert -list format" and also "convert -version--no Delegates listed). Also without PNG support. Now I'm searching for how to add those.
That sounds right. Quite why anyone would want it jpeg support is a mystery, but assuming your linux has a package system, I would guess it's just a matter of installing libjpeg or a different variant of imagemagick.
Or as mentioned earlier you could use the netpbm tools, they include pnmtojpeg http://netpbm.sourceforge.net/doc/pnmtojpeg.html (http://netpbm.sourceforge.net/doc/pnmtojpeg.html)
-
Thanks for the suggestions, reyalp. Maybe getting closer.
So I got netpbm on my dockstar with "apt-get netpbm". "pnmtojpeg -verbose foo.ppm > foo7.jpg" works, giving the stretched image you would expect with 720x240 interpreted as square pixels.
Then I tried to change the jpg to 4x3 with "pnmtojpeg -verbose -density=4x3 foo.ppm > foo7.jpg". This failed saying the "density" option was unknown.
The help page you linked to says that debian uses a (13+ year old) version, 9.25, which reports as 10.0. The "density" option was provided in 10.15. So I downloaded netpbm, did "make", which asked many questions. Knowing no better, I took the default for each. Then I ran "make install", which ran for a long time, but finally failed producing no new pmntojpg.
I have more digging to do for both imagemagick and netpbm. Why (he asks of no one in particular) is nothing ever as straightforward as one thinks it might be?
-
Conversion to GIF is supported and works.
convert /var/www/foo.ppm -verbose -resize 640x480! /var/www/foo2.gif
/var/www/foo.ppm=>/var/www/foo2.gif PPM 720x240=>640x480 640x480+0+0 8-bit Palette sRGB 241c 166KB 11.470u 0:11.480
Not altogether a happy solution, since 166KB instead of 54K, but I can proceed.
Still haven't found a way to get jpg and png to work on the dockstar.
-
For now, this 2-step process goes from 720x240 ppm to 640x480 jpg.
# convert /var/www/foo.ppm -verbose -resize 640x480! /var/www/fooz.ppm
/var/www/foo.ppm=>/var/www/fooz.ppm PPM 720x240=>640x480 640x480+0+0 8-bit sRGB 922KB 1.860u 0:02.220
# pnmtojpeg -verbose /var/www/fooz.ppm > /var/www/fooz.jpg
pnmtojpeg: Input file has format P6.
It has 480 rows of 640 columns of pixels with max sample value of 255.
pnmtojpeg: No scan script is being used
First a resize to 640x480 ppm with "convert", then to jpg with "pnmtojpg".
-
For now, this 2-step process goes from 720x240 ppm to 640x480 jpg.
Note you might want to use 720x540, to keep the horizontal resolution unchanged (though in the actual viewport, this only refers to brightness values, since it's YUV411)
Thinking about this, there is probably a way to go directly from the YUV data to jpeg, without going through RGB first.
What distro do you use on the docstar? I would really expect there is some way to get a version of imagemagick with jpeg support. Debian appears to offer a fork of imagemagick call "graphicsmagick". In the debian description I'm looking at, it explicitly says it supports jpeg. Imagemagick is also there, and claims jpeg support.
-
I'm using squeeze on the dockstar. I did "apt-get install graphicsmagick"
gm convert /var/www/foo.ppm /var/www/fooz2.jpg
Works, but with a stretched image. So far, non of the "-size" or "-resize" options I've tried have worked.
-
I'm running PTP v2.6 (camera S100). When I click on [shoot] there's always a delay until the picture is taken. I want to minimize the delay. I tried to click [shoot half] before shoot. It doesn't seem to make any difference.
My question, can I fix all the settings first and then next click will only take the picture, i.e. with minimal delay.
Maybe using the console commands? Which I've never used before :-)
Thanks in advance,
Phuoc
-
I'm running PTP v2.6 (camera S100). When I click on [shoot] there's always a delay until the picture is taken. I want to minimize the delay. I tried to click [shoot half] before shoot. It doesn't seem to make any difference.
Yes shoot_half just presses and releases. The shoot button presses half shoot, waits for everythign to be ready, and then presses full shoot.
My question, can I fix all the settings first and then next click will only take the picture, i.e. with minimal delay.
Maybe using the console commands? Which I've never used before :-)
Yes
.press('shoot_half') ; m=read_usb_msg(-1) if m == 's' then click('shoot_full') end
Will hold down the shoot_half button and wait indefinitely for a message. You can then use
putm s
to take the shot, or putm with anything else to cancel.
If you want to take multiple shots quickly, you can use the rsint command discussed earlier, but it current does not work in the gui.
Also, you asked earlier in the thread about mirroring the live view. It turns out this is possible, see http://chdk.setepontos.com/index.php?topic=6231.msg110737#msg110737 (http://chdk.setepontos.com/index.php?topic=6231.msg110737#msg110737)
-
I'm using squeeze on the dockstar. I did "apt-get install graphicsmagick"
gm convert /var/www/foo.ppm /var/www/fooz2.jpg
Works, but with a stretched image. So far, non of the "-size" or "-resize" options I've tried have worked.
The following works to resize. The "!" tells it to absolutely use the dimensions given. Omitting that means you will still have a stretched image.
chdkptp -c -e"lvdumpimg -vp=/var/www/foo10.ppm"
gm convert -verbose -geometry 768x512! /var/www/foo10.ppm /var/www/foo10g.jpg
(Regarding imagemagick, even after following the process to install "delegates" for jpg and png (not clearly documented that I could tell), I couldn't get imagemagick to report that they were available--so I'm giving up on that.)
-
(Mistakenly submitted)
-
Hello reyalp,
After days of working with chdk and chdkptp, between my A2500 and my raspberry pi, I am stuck :)
The idea of my project is to have 2 or more cameras of same model connected to a RPi and synchronised using multicam.lua. I run the commands I need from chdkptp using -r option and a txt file.
All is well so far. At the end, I would like to retrieve the last image from each camera. Getting the last image name, and downloading that image, is something I manage too. But I need to somehow script a loop through all possible devices and download the images.
So my question is: how do I select and connect to a camera using a script ? I have read all the docs I guess, and you write on your assembla page
The chdkptp CLI only supports one active connection at a time, but using the local Lua (! command) you can manipulate the con variable to switch between multiple connections.
How would one do that ? can you help ?
Thanks in advance.
-
The chdkptp CLI only supports one active connection at a time, but using the local Lua (! command) you can manipulate the con variable to switch between multiple connections.
How would one do that ? can you help ?
Thanks in advance.
Two cameras
$ chdkptp -i
___> list
-1:Canon PowerShot D10 b=bus-0 d=\\.\libusb0-0001--0x04a9-0x31bc v=0x4a9 p=0x31bc s=...
-2:Canon PowerShot A540 b=bus-0 d=\\.\libusb0-0002--0x04a9-0x311b v=0x4a9 p=0x311b s=nil
Make connections:
___> !con1=chdku.connection{dev='\\\\.\\libusb0-0001--0x04a9-0x31bc',bus='bus-0'} return con1:connect()
=true
___> !con2=chdku.connection{dev='\\\\.\\libusb0-0002--0x04a9-0x311b',bus='bus-0'} return con2:connect()
=true
The 'return' tells you if the connection succeeded. The extra \\ are for windows device names, on linux you won't need them.
___> list
+1:Canon PowerShot D10 b=bus-0 d=\\.\libusb0-0001--0x04a9-0x31bc v=0x4a9 p=0x31bc s=...
+2:Canon PowerShot A540 b=bus-0 d=\\.\libusb0-0002--0x04a9-0x311b v=0x4a9 p=0x311b s=nil
The '+' shows that the connections are connected, but not currently associated with the cli con variable.
Now to switch between them, you just do something like
___> !con=con1
con> list
*1:Canon PowerShot D10 b=bus-0 d=\\.\libusb0-0001--0x04a9-0x31bc v=0x4a9 p=0x31bc s=...
+2:Canon PowerShot A540 b=bus-0 d=\\.\libusb0-0002--0x04a9-0x311b v=0x4a9 p=0x311b s=nil
The * shows that camera 1 is now connected to the cli, so a download command will download from that camera.
You could also write the whole download process in lua, something like
___> !for i,dev in ipairs(chdk.list_usb_devices()) do local lcon=chdku.connection(dev) lcon:connect() lcon:download('A/DISKBOOT.BIN',i..'_DISKBOOT.BIN') lcon:disconnect() end
obviously substitute your own filename for diskboot.bin, and possibly add some error checking.
-
The chdkptp CLI only supports one active connection at a time ...
A simple workaround is to make a copy of the chdkptp folder and use the two chdkptp in parallel for one camera each in separate terminal windows.
-
A simple workaround is to make a copy of the chdkptp folder and use the two chdkptp in parallel for one camera each in separate terminal windows.
FWIW you don't need to copy the folder to run two instances.
Running multiple instances of chdkptp is a valid approach (edit: though not if you want synchronized shooting with multicam.lua as jhfelectric described), but you do have to be careful because the list and connect commands can cause the other instances connection to be reset. See this post and following http://chdk.setepontos.com/index.php?topic=6231.msg96441#msg96441 (http://chdk.setepontos.com/index.php?topic=6231.msg96441#msg96441)
-
FWIW you don't need to copy the folder to run two instances.
Ok, will test that. Might save 3MB of disk space. :P
-
I've uploaded snapshot build r511 to the files area.
The linux builds now include "readline" support for editing and history in the cli. If you are building yourself, you will need to update your config.mk to enabled this. See config-sample-linux.mk for examples.
There are also some improvements to remoteshoot: You can use rsint from the GUI (using CLI commands, an actual GUI for this feature would be nice), and if you are using chdk 1.3, failed connections are handled better in rs and rsint.
All the GUI builds now use CD 5.7 and IUP 3.10.1. Building with older libs should still work.
Raspberry pi users who want the GUI will need to update the library package to chdkptp-raspbian-libs-20140331.zip from the files area. This library package now includes everything you need to build chdkptp with the gui. I have also improved the documentation README-RASPI-LIBS.TXT.
chdkptp now supports Lua 5.2. This is currently experimental and optional, but will likely be mandatory in the future since it will allow significant improvement in the GUI.
-
Reyalp and others, about the multiple connections,
Thanks a lot for your reply, I managed to make it work easily with your input.
Here is (part of) the code I can run successfully:
devices, devices_error = chdk.list_usb_devices()
for device, devinfo in ipairs(devices) do
printf('camera %i:', device)
a_connection, a_connection_message = chdku.connection(devinfo)
connection_status, connection_error = a_connection:connect()
exp_count_status, last_number = a_connection:execwait([[return get_exp_count()]])
printf(' last image number is %i...', last_number)
if exp_count_status then
image_dir_status, image_dir = a_connection:execwait([[return get_image_dir()]])
if image_dir_status then
temp_file = string.format('%s/IMG_%04d.JPG', image_dir, last_number)
image_file = string.gsub(temp_file, string.format('/ETC_%04d.TMP', last_number), '')
printf('downloading %s...', image_file)
download_status = a_connection:download(image_file, 'IMAGE'..device..'.JPG')
end
end
disconnection_status = a_connection:disconnect()
printf('done\n')
end
The above will retrieve the last image from all available cameras.
You have noted that the "get_image_dir", which is supposed to return the current image directory, actually returns a temporary folder name, based on the last image's number. I could not figure out how or why, so I needed to skip out that part. Fyi, all my cameras are A2500.
-
The above will retrieve the last image from all available cameras.
Glad you got it working.
note there is some possibility that things will break if the camera increments the folder number, I'm not certain whether the image dir will refer to the current or previous folder. This is somewhat annoying to test for obviously reasons...
You have noted that the "get_image_dir", which is supposed to return the current image directory, actually returns a temporary folder name, based on the last image's number. I could not figure out how or why, so I needed to skip out that part. Fyi, all my cameras are A2500.
This sounds like a bug in the port, elph130 had a similar issue which I worked around with this hack:
http://trac.assembla.com/chdk/browser/trunk/platform/ixus140_elph130/shooting.c#L143 (http://trac.assembla.com/chdk/browser/trunk/platform/ixus140_elph130/shooting.c#L143)
If you have the ability to build your own CHDK, you can try this same thing. If not, I can make a test build for you.
-
In r516 (svn, no official build yet), I moved rsint into the standard cli, so the require'extras/rsint'.init() is no longer required and will result in an error.
edit:
r521 adds camera selection to the GUI. The dropdown to the left of the "connect" button keeps a list of available cameras. You can have multiple cameras connected and use the dropdown to switch between which one you are controlling.
This is preliminary, there are some known issues and probably some unknown ones too.
The list is just bus:device rather than camera names
The files tab collapses any time you switch cameras, to avoid showing the wrong file list. Really, the tree should have a branch for each camera.
-
The new readline support is really useful, one doesn't have to mess with the clipboard any more. I'm wondering if it would be somehow possible to not request liveview data until the previous frame has arrived? The linux GUI still jams when the requested framerate is larger than what's physically possible.
-
The new readline support is really useful, one doesn't have to mess with the clipboard any more.
Yes, I feel kinda bad for putting it off all these years :-[
I'm wondering if it would be somehow possible to not request liveview data until the previous frame has arrived? The linux GUI still jams when the requested framerate is larger than what's physically possible.
I have a workaround in mind for this, just skip frames if the last frame took longer than the target frame time.
Of course it would be better if we could do the USB download while rendering the previous frame, but that's a bigger project.
On a somewhat related note, if you build the current svn with Lua 5.2, the live view continues to update while script is running, e.g. you can do
=sleep(1000)
the UI including the live view doesn't freeze until the script finishes.
Actual PTP calls (like a file download) still freeze the UI until they complete, but CLI commands that wait for script or messages yield back to the GUI. PTP commands issued by the GUI without going through the CLI system don't currently use this, but they will
This also works with rsint, but unfortunately (at least on d10) it doesn't do what you'd want. On the camera, the last image taken is shown on screen while waiting for the next shot (the same way regular continuous shooting shows you the image), but it doesn't appear on the live view. I guess the "review" buffer is different.
-
I have a workaround in mind for this, just skip frames if the last frame took longer than the target frame time.
I have implemented this in chdkptp r527. It's controlled by a "set" pref gui_live_dropframes, which defaults to true when the OS isn't windows. Windows seems to handle this situation OK as is.
Note that you will get less than the max frame rate if your target rate is too high. The "Dropped" counter in the live stats will show you if this is happening.
I suspect that letting the main GUI loop run briefly might be sufficient, rather than skipping a whole frame update, but I'm not sure how to do that and this is a lot better than locking up the UI.
-
I have implemented this in chdkptp r527.
Tried it, it's working, thanks.
-
I've uploaded snapshot build r537 to the files area https://www.assembla.com/spaces/chdkptp/documents (https://www.assembla.com/spaces/chdkptp/documents)
All the binaries are now built with lua 5.2. They are statically linked, so you don't need to install Lua 5.2 on your system. If you have custom Lua code, it may need to be updated to be compatible, see http://www.lua.org/manual/5.2/manual.html#8 (http://www.lua.org/manual/5.2/manual.html#8) All the compile time compatibility settings are enabled, so most code will run as is.
Support for Lua 5.1 will be removed fairly near future.
The above all refers to chdkptp client side lua of course, camera side Lua remains 5.1.
Major changes
* rsint is now a standard command, and works from the GUI.
* GUI in Linux now limits frame rate to keep the UI from hanging. Live view using X over ssh from a raspberry pi on wifi is now fairly usable :haha
* The GUI now has a dropdown for camera selection. You can connect to multiple cameras and switch between them using the drop down. The UI and CLI operate on whichever camera you have selected. The dropdown keeps an up to date list of all available devices (by bus:device name only at the moment)
* The GUI now automatically updates the connection status if the camera goes away, or is connected using Lua API calls.
* The autoupdate of the camera list and connection status is controlled by gui_dev_check_interval, set it to 0 if you want to disable this behavior.
-
I've uploaded snapshot build r537 to the files area https://www.assembla.com/spaces/chdkptp/documents (https://www.assembla.com/spaces/chdkptp/documents)
Thank you for the update, I'm still hoping to see the the shortcut key and mirrored preview features soon :)
-
I've uploaded snapshot build r537 to the files area https://www.assembla.com/spaces/chdkptp/documents (https://www.assembla.com/spaces/chdkptp/documents)
Thank you for the update, I'm still hoping to see the the shortcut key and mirrored preview features soon :)
As I mentioned earlier, you can get mirrored preview using CD coordinate transform functions:
http://chdk.setepontos.com/index.php?topic=6231.msg110737#msg110737 (http://chdk.setepontos.com/index.php?topic=6231.msg110737#msg110737)
-
As I mentioned earlier, you can get mirrored preview using CD coordinate transform functions:
http://chdk.setepontos.com/index.php?topic=6231.msg110737#msg110737 (http://chdk.setepontos.com/index.php?topic=6231.msg110737#msg110737)
I did read that post. But I didn't understand. Ok, I'll have a closer look again, thanks.
-
With rsint we can set a folder for saving a series of photos
rsint C:\a which for each subsequent "s" command outputs something like C:\a\IMG_3066.jpg , C:\a\IMG_3067.jpg , C:\a\IMG_3068.jpg ...
And we can set the name of a single image:
rsint C:\a\namewhich outputs to C:\a\name.jpg for each "s" command (overwriting the previous image)
But it would be useful to set a file name pattern with a number part that increments for each subsequent photo. Something like
rsint C:\a\{d4}Rwhere {d4} sets a four digit increment and which would output
C:\a\0001R.jpg , C:\a\0002R.jpg , C:\a\0003R.jpg , ...
(I know I can use the sequence "rsint filepath1" and "l" and "rsint filepath2" and "l" and so on but that makes the whole cycle for each photo slower)
-
As I mentioned earlier, you can get mirrored preview using CD coordinate transform functions:
http://chdk.setepontos.com/index.php?topic=6231.msg110737#msg110737 (http://chdk.setepontos.com/index.php?topic=6231.msg110737#msg110737)
I did read that post. But I didn't understand. Ok, I'll have a closer look again, thanks.
Essentially, enter this in the console (all one line), after switching to the live view tab
!width=gui.live.icnv.dccnv:GetSize();gui.live.icnv.dccnv:TransformScale(-1,1);gui.live.icnv.dccnv:TransformTranslate(-width,0)
To un-mirror the display, use
!gui.live.icnv.dccnv:Transform(nil)
Unfortunately, you can't easily make this happen at startup, because _chdkptpguirc is run before the live view is initialized.
-
But it would be useful to set a file name pattern with a number part that increments for each subsequent photo. Something like
rsint C:\a\{d4}Rwhere {d4} sets a four digit increment and which would output
C:\a\0001R.jpg , C:\a\0002R.jpg , C:\a\0003R.jpg , ...
I plan to add support for the same kind of substitution patterns used in lvdumpimg, but I haven't got to it yet.
(I know I can use the sequence "rsint filepath1" and "l" and "rsint filepath2" and "l" and so on but that makes the whole cycle for each photo slower)
If you are triggering the s commands from another program, and can track the number yourself, you could just issue a path command between each shot instead of using l and calling rsint again. Like:
con 1> rsint
rsint> path file00
rsint> s
rc file file00.jpg 1
rsint> path file01
rsint> s
rc file file01.jpg 1
rsint> path file02
rsint> l
rc file file02.jpg 1
The path command takes negligible time.
(edit: remove incorrect =)
-
Nice, thank you! But I discovered that the path command must drop the equal sign: this works "path C:\test" and this doesn't "path=C:\test"
-
Nice, thank you! But I discovered that the path command must drop the equal sign: this works "path C:\test" and this doesn't "path=C:\test"
Oops you are right, my mistake. I ran that example and didn't even notice it was saving them with = in the name.
-
I noticed strange behavior with focusing in macro mode.
Focus does not work well if I press 'shoot half' button in the GUI.
If I physically press a button on the camera focusing is flawless.
I have the same behavior in the 1.2 and 1.3 versions, used cameras are A530 and A590. Older versions of CHDK works well. The last five focusing in the video are made with physical press on the shutter button.
Is there anyone an explanation for this?
https://www.youtube.com/watch?v=cgXliLbnx2E&feature=youtu.be (https://www.youtube.com/watch?v=cgXliLbnx2E&feature=youtu.be)
-
I noticed strange behavior with focusing in macro mode.
Focus does not work well if I press 'shoot half' button in the GUI.
If I physically press a button on the camera focusing is flawless.
As far as the Canon firmware is concerned, the only difference between pressing the physical button and using the GUI should be the duration of the the press. The half shoot button waits until get_shooting() becomes true, or 1 second (unless you are in movie mode, then it just uses 1 second)
I suppose it's possible that releasing shoot_half the instant that get_shooting() goes true may behave differently. You could try a hardcoded duration, like
=press'shoot_half' sleep(1000)
I very much doubt this behavior varies depending on CHDK version. All CHDK does is fiddle the bit that tells the Canon firmware the button is pushed, and that hasn't changed. Far more likely it just varies on it's own.
-
You could try a hardcoded duration, like =press'shoot_half' sleep(1000)
Yes, it seems that the problem is in the duration of the press.
=press'shoot_half' sleep(1000) doesn't work
=press'shoot_half' sleep(3000) works well
I very much doubt this behavior varies depending on CHDK version
Old tsvstar-uitest branch,1.2.0-r2198 works without problems,I don't know why. :D
-
Old tsvstar-uitest branch,1.2.0-r2198 works without problems,I don't know why. :D
Time required varies depending on conditions, nothing to do with the CHDK build. I really doubt the CHDK build actually matters, there is no plausible mechanism. As I said before CHDK isn't involved in the actual focusing process at all, it just holds the key down.
The fact that it takes 3 seconds to do it means your camera is really struggling to focus, so large variations aren't a surprise.
I'll could make the half press timeout longer, or adjustable. 1 second was just something that seemed reasonable.
If you want to adjust it, you can change 100 in the following code in gui.lua (near line 400 in the current trunk)
repeat
sleep(10)
n = n + 1
until get_shooting() == true or n > 100
release("shoot_half")
The number is 100ths of second, since the sleeps are 10ms.
-
Old tsvstar-uitest branch,1.2.0-r2198 works without problems,I don't know why. :D
Time required varies depending on conditions, nothing to do with the CHDK build. I really doubt the CHDK build actually matters, there is no plausible mechanism. As I said before CHDK isn't involved in the actual focusing process at all, it just holds the key down.
The fact that it takes 3 seconds to do it means your camera is really struggling to focus, so large variations aren't a surprise.
I'll could make the half press timeout longer, or adjustable. 1 second was just something that seemed reasonable.
If you want to adjust it, you can change 100 in the following code in gui.lua (near line 400 in the current trunk)
repeat
sleep(10)
n = n + 1
until get_shooting() == true or n > 100
release("shoot_half")
The number is 100ths of second, since the sleeps are 10ms.
I can reproduce the behaviour blackhole demonstrates in his video, on my G12 (although not 100%).
These steps will reproduce the effect:
- connect with chdkptp, change to REC mode
- set camera to Macro focus mode
- press 'shutter half press' button in chdkptp and focus on an object ~30cm away
- place an object close to the lens (<5cm)
- press 'shutter half press' button in chdkptp
The camera will try and focus on the close object. It appears to set the focus distance; but then suddenly jump back to the previous focus distance that was further away from the camera.
Have not tried old CHDK builds yet.
Phil.
-
The camera will try and focus on the close object. It appears to set the focus distance; but then suddenly jump back to the previous focus distance that was further away from the camera.
I see something similar on my D10 manually pressing the button without PTP connected at all. I don't see any evidence it happens more often with chdkptp connected.
edit:
I added setting for the halfshoot wait, gui_shoot_half_timeout. Default is no 3000.
-
The secret is in the distance of the object from the lens. If the SD is lower than the recommended values for the minimum distance in Macro mode comes to this kind of behavior. By the sounds that I hear from the camera looks like the camera in such difficult conditions, twice repeating the process of focusing. I just tried the same conditions with ptpCamGui 2.0.131 and can not reproduce this behavior, focusing carry out normal no matter what the SD is only 25mm.
@Philmoz
Old tsvstar-uitest branch,1.2.0-r2198 works without problems,I don't know why.
Can you please try the mentioned version of CHDK.
-
I just tried the same conditions with ptpCamGui 2.0.131 and can not reproduce this behavior, focusing carry out normal no matter what the SD is only 25mm.
As I've already told you several times, CHDK isn't involved in the AF process at all, it's just pressing the buttons. ptpCamGUI does exactly the same thing.
The only vaguely plausible mechanism I can think of is that the live view is hogging so much CPU it interferes with AF somehow. You should be able to test that by turning off the live view, but IMO it's far more likely the behavior is just unpredictable.
There is really no chance that the CHDK build matters. The key press code has worked the same way since the very early days of CHDK.
... but what do I know :-[
-
As I've already told you several times, CHDK isn't involved in the AF process at all, it's just pressing the buttons. ptpCamGUI does exactly the same thing.
The only vaguely plausible mechanism I can think of is that the live view is hogging so much CPU it interferes with AF somehow. You should be able to test that by turning off the live view, but IMO it's far more likely the behavior is just unpredictable.
There is really no chance that the CHDK build matters. The key press code has worked the same way since the very early days of CHDK.
... but what do I know
OK, I understand what you're saying, it was just my curiosity.
-
OK, I understand what you're saying, it was just my curiosity.
To be clear, if it is really reproducible and you are certain it isn't just the camera behaving unpredictably in situations where AF doesn't work well, then it's worth investigating. In my experience though, Canon AF can behave pretty randomly if conditions aren't ideal, and when something is random like this, it's pretty easy to convince yourself something you changed made a difference.
Things that seem plausible:
* Live view interfering in some way.
* Some difference between doing it with USB connected vs not connected (regardless of whether you use camera buttons). The USB mode switch is hacky, but it's hard to see why it would only affect macro.
* Some difference in the logic of how long the button is held down.
Less plausible:
* CHDK version making any difference, as long as you aren't doing anything with overrides at the same time.
* PTP client program. A half press is a half press, the camera doesn't know the difference (except for differences in how long the button is held).
-
I uploaded build 547 for the files area https://www.assembla.com/spaces/chdkptp/documents (https://www.assembla.com/spaces/chdkptp/documents)
The main change is that the -tv etc options rsint actually work instead of being ignored :-[
Additionally, I added options to the shoot commands (shoot, rs, rsint):
-sd: set sd override distance. The usual CHDK sd override caveats apply. In particular, if your camera needs to be in aflock or mf mode, you need to set that first using =set_mf() etc.
The value for -sd is dist[unit string], so -sd=10.5in means 10.5 inches. The default unit is meters.
-svm: Sets the ISO in "market" units. Requires CHDK 1.3
-
To be clear, if it is really reproducible and you are certain it isn't just the camera behaving unpredictably in situations where AF doesn't work well, then it's worth investigating. In my experience though, Canon AF can behave pretty randomly if conditions aren't ideal, and when something is random like this, it's pretty easy to convince yourself something you changed made a difference.
I do not know what to say, the same behavior can be repeated countless times, I was rehearsing and different lighting conditions, more contrastive object, I turned off live view, nothing changes. Does not include any overrides, pure P mode, the only requirement is that the subject is somewhat closer than the minimum SD values for Macro mode. I tried it with two different cameras, A590 and A530, the problem is the same, both cameras also focus normally using chdkptp if used mentioned build. If one of the users has this camera and want to try the same, I can send him a mentioned build.
* Some difference in the logic of how long the button is held down.
This seems most likely, but I do not know, you're more familiar with these problems.
-
Old tsvstar-uitest branch,1.2.0-r2198 works without problems,I don't know why. :D
Time required varies depending on conditions, nothing to do with the CHDK build. I really doubt the CHDK build actually matters, there is no plausible mechanism. As I said before CHDK isn't involved in the actual focusing process at all, it just holds the key down.
At the risk of "trying to shed light where there is no darkness", I'd point out that tsvstar did a lot of funky things in his builds to make the camera work the way he wanted to. I have not waded through all those changes (the ones I have looked at were enough fun decoding as it is) but I'd rate the possability that shot timing changed in his versions pretty high. Which fits reyalp's comments about variable timing.
-
At the risk of "trying to shed light where there is no darkness", I'd point out that tsvstar did a lot of funky things in his builds to make the camera work the way he wanted to.
Well, like I've been saying, there really isn't much to be different. As I've said a bunch of times, CHDK really isn't doing much in this process. It's just fiddling with the physw_status bit for the half press button, which
to the canon firmware should be indistinguishable from the physical button.
My comment on timing was mostly about differences between chdkptp, ptpcamgui and pressing the button manually. As mentioned earlier chdkptp, waits for the the get_shooting, and then releases the button immediately. I don't know what ptpcamgui does.
It's very difficult to see how the CHDK build would make a consistent difference in timing, although I guess it might have changed by 1 kbd_task cycle somewhere along the line. That seems like a real stretch to explain what's going on though.
I would be extremely surprised if CHDK build was actually the relevant factor. From my understanding of CHDK it seems basically impossible.
@blackhole:
Have you tried the latest chdkptp version? This changes the half shoot delay to 3 seconds.
Another thing you could try is putting some delay after get_shooting goes true.
-
Just now I tried chdkptp r547 and everything works well. The camera is focusing well at a distance of 25 mm. Thank you for your efforts.
-
A note for anyone building their own chdkptp from SVN
I started a long overdue re-work of how errors are handled, with destabilizing changes starting at r550. I try to keep the trunk reasonably usable, but there are likely to be bugs.
Additionally, while this is in progress error output and Lua APIs are likely to be incompatible from version to version, so anyone parsing chdkptp output or running custom Lua code may want to stick to an earlier version for a while.
Once complete, this should be a significant improve. In particular
* The C code won't randomly spit error messages out to stderr
* Error messages will be more descriptive
* Specific PTP errors will be available to Lua code, so it can distinguish between things like a connection failure and cameras that don't support the CHDK extension.
* The APIs will be simpler overall, avoid the need for long chains of returning status, message up the call stack.
-
Hello,
I've made a simple patch to rename some functions in chdkptp, so that lua can import them as libraries (eg require('chdkptp'))
This is pretty much a blind patch, as I do not have devices to test it with, but it should hopefully work
made against chdkptp r571.
EDIT:
The patch is missing libusb initialization.
Edit chdkptp.c function luaopen_chdkptp, insert "usb_init();" as the first command, remove "usb_init()" from main() to get it working.
-
reyalp, can you post a working example for connecting over command line with the -d (device) syntax. I can't get it to work. The device string has several backslashes in its path which I've tried to escape but I still get errors.
-
Hello,
I've made a simple patch to rename some functions in chdkptp, so that lua can import them as libraries (eg require('chdkptp'))
This is pretty much a blind patch, as I do not have devices to test it with, but it should hopefully work
made against chdkptp r571.
Thanks for doing this, it should be quite useful. It may be a little while before I get to it because I'm in the middle of some major re-organization right now.
-
reyalp, can you post a working example for connecting over command line with the -d (device) syntax. I can't get it to work. The device string has several backslashes in its path which I've tried to escape but I still get errors.
The other thing to watch out for is that - is also a special character in Lua patterns, so you should escape it with %-
In r557, I added a -nopat option which disables pattern matching completely. However, as noted earlier the chdkptp trunk is undergoing some destabilizing reorganization at the moment. You might be able to apply the diffs from just that change to the last snapshot.
-
In r557, I added a -nopat option which disables pattern matching completely.
Great.
The other thing to watch out for is that - is also a special character in Lua patterns, so you should escape it with %-
edit: after posting I discovered the right syntax: If for example the list command shows this
-d=\\.\libusb0-0001--0x1111-0x1111we connecti the camera like this
chdkptp.exe -c"-d=libusb0%-0001" -i
The background to my question is that I was trying to use two cameras of the exact same model at the same time. They have the same PID. My plan was to use -d to control which process connects to which camera. But after posting I realized that the enumeration in the second part of device string (0001 in the example above) will vary between 0001 and 0002 depending on which camera is first turned on while usb connected. The only stably unique identifier for each camera, it seems, is the serial number string. But trying -s for both cameras results in errors on the second connect attempt. The best workaround I've found, when controlling chdkptp over command line from external scripts, is to make sure to power on camera A before camera B, then connect camera B using -s and finally connect camera A using -p. I guess I could also first do a list command and somehow save the results, parse which camera (serial) is currently linked to which device number and then use those device numbers to connect each camera through a specific process.
-
But after posting I realized that the enumeration in the second part of device string (0001 in the example above) will vary between 0001 and 0002 depending on which camera is first turned on while usb connected.
Yes, this is correct. USB device names are picked when the device is connected (on both linux and windows).
The only stably unique identifier for each camera, it seems, is the serial number string. But trying -s for both cameras results in errors on the second connect attempt.
Correct again. Getting the serial number currently requires making a connection to the camera, which destroys any existing connection. I think it may be possible to get this without, but haven't had time to really investigate yet.
It should also be able to detect when a device is already opened by another process, so you could have a connect option that only applies to unclaimed cameras. The error code rework I am doing now is a step toward being able to do this.
The best workaround I've found, when controlling chdkptp over command line from external scripts, is to make sure to power on camera A before camera B, then connect camera B using -s and finally connect camera A using -p. I guess I could also first do a list command and somehow save the results, parse which camera (serial) is currently linked to which device number and then use those device numbers to connect each camera through a specific process.
Both of these are reasonable options.
The other alternative is to do everything in one instance of chdkptp, but depending on your particular application, this may lead to other difficulties.
-
The other alternative is to do everything in one instance of chdkptp, but depending on your particular application, this may lead to other difficulties.
That would slow down things for me I suspect. I switched to the workaround that first list available cameras and their device and serial numbers
chdkptp.exe -elist > c:\temp.txtand then parse the first line of the txt file. Then I start two processes that connect using the -d values that match each camera serial. Works regardless of which camera was powered on first.
-
I've uploaded snapshot build 592 to the files area
https://www.assembla.com/spaces/chdkptp/documents (https://www.assembla.com/spaces/chdkptp/documents)
This is a pretty substantial re-write (http://trac.assembla.com/chdkptp/changeset?new=592%40trunk&old=547%40trunk). It seems to be working OK for me, but it's quite likely that some new bugs snuck in.
Details are in the changelog https://www.assembla.com/spaces/chdkptp/wiki/Changelog (https://www.assembla.com/spaces/chdkptp/wiki/Changelog)
Key points
* incompatible API and error ouput changes
* Building with Lua 5.1 is deprecated
* Tests are substantially improved
I'm not entirely finished with the error handling changes, but whats left should be less invasive.
-
It appears google chrome on windows is blocking the chdkptp windows binary downloads a malicious.
I believe this is an error, and virustotal shows no detections (though it does get McAfee-GW-Edition Heuristic.LooksLike.Win32.Suspicious.N!86)
You can either trust me and use a different browser to download, or build from source, or not use chdkptp.
From what I can find by googling, google appears to have some kind of heuristic which is basically any unsigned executable they don't know about is malicious. ::)
-
I can reproduce that in Chrome. No problem in Firefox however. I ran the exe from chdkptp-r592-win32.zip throught the online multi antivir tool http://virusscan.jotti.org (http://virusscan.jotti.org) and it found no problem. I also put the unzipped chdkptp.exe file (windows binary) in dropbox and tried opening the direct link in Chrome. Chrome then says "chdkptp.exe is not commonly downloaded and could be dangerous" with "Dismiss" as the default button state.
-
Yeah, I compiled hello world, uploaded the .exe and chrome blocked it.
However, I found putting the chkdptp package in a 7zip file makes chrome not flag it. Good thing malware authors couldn't do anything like that ::)
-
However, I found putting the chkdptp package in a 7zip file makes chrome not flag it. Good thing malware authors couldn't do anything like that ::)
But will Windows open a 7zip on its own like its does zip files?
-
Hello,
I've made a simple patch to rename some functions in chdkptp, so that lua can import them as libraries (eg require('chdkptp'))
This is pretty much a blind patch, as I do not have devices to test it with, but it should hopefully work
made against chdkptp r571.
Thanks for doing this, it should be quite useful.
I looked at this some more. There's quite a bit more that needs to be done to really make it work, particularly on windows.
It's still something I would like to add, but it's going to be a bit more than merging the patch.
A few notes:
Since the luaopen_* functions now return an int, so they need to return a value. In general they should return 1 with table created for the module on top of the stack (in Lua 5.2, they really shouldn't set a global).
On windows, the luaopen_* and other public functions need to be exported, either using __declspec(dllexport) or a .def file.
When linking, the libraries like chdkptp lbuf and liveimg need to be linked with a shared Lua and IUP, CD etc. They should probably also be linked to the shared versions of the other chdkptp libraries (e.g. liveimg to the shared lbuf rather than lbuf.o)
I'm not sure it's worth making lbuf, liveimage etc all separate dlls. Lua can load mutliple sub-modules from a single dll/so, which might make the build configuration simpler.
edit:
I should add that building lbuf with a shared Lua is somewhat dangerous. It assumes that it can use C stdio functions on the FILE * used by the Lua IO library. If Lua and lbuf are compiled with different C libraries, this will fail. This is likely if using a pre-built Lua on windows.
-
Hi.
Previously, I was using a cli cmd window on Win32 and send to it keystrokes with post_key/send_key api.
It was very ugly because the cmd window can't be hidden and need focus to receive keystrokes.
So, I made a library which communicate with the command window witch use two pipes to send and receive data from stdin and stdout.
It works well with some programs like ImageMagick 'convert' and I get the response.
With chdkptp -i, I can send commands but I don't receive the prompt and responses.
It seems like chdkptp don't write to stdout, although it seems to be the case when looking at the source.
Same behavior if I call chdkptp.exe embedde in cmd.exe or directly.
Any ideas are welcomes !
I also plan to add an option to pipe the pbm data directly to another command.
Would be very usefull !
reyalp, thanks for the A490 fix on this other thread
http://chdk.setepontos.com/index.php?topic=4338.msg113097#msg113097 (http://chdk.setepontos.com/index.php?topic=4338.msg113097#msg113097)
-
With chdkptp -i, I can send commands but I don't receive the prompt and responses.
It seems like chdkptp don't write to stdout, although it seems to be the case when looking at the source.
It should mostly go to stdout (most errors / warnings go to stderr). It uses the Lua IO to to write to stdout, which should be very normal. Maybe it doesn't get flushed right away?
You might want to try lua setvbuf on stdout http://www.lua.org/manual/5.1/manual.html#5.7 (http://www.lua.org/manual/5.1/manual.html#5.7)
Something like io.stdout:setvuf('no') or io.stdout:setvuf('line')
If I do
chdkptp -i < foo.txt > bar.txt
with some commands in foo.txt, the output and prompts go to bar.txt as expected.
-
Hello,
I've made a simple patch to rename some functions in chdkptp, so that lua can import them as libraries (eg require('chdkptp'))
This is pretty much a blind patch, as I do not have devices to test it with, but it should hopefully work
made against chdkptp r571.
Thanks for doing this, it should be quite useful.
I looked at this some more. There's quite a bit more that needs to be done to really make it work, particularly on windows.
It's still something I would like to add, but it's going to be a bit more than merging the patch.
A few notes:
Since the luaopen_* functions now return an int, so they need to return a value. In general they should return 1 with table created for the module on top of the stack (in Lua 5.2, they really shouldn't set a global).
On windows, the luaopen_* and other public functions need to be exported, either using __declspec(dllexport) or a .def file.
When linking, the libraries like chdkptp lbuf and liveimg need to be linked with a shared Lua and IUP, CD etc. They should probably also be linked to the shared versions of the other chdkptp libraries (e.g. liveimg to the shared lbuf rather than lbuf.o)
I'm not sure it's worth making lbuf, liveimage etc all separate dlls. Lua can load mutliple sub-modules from a single dll/so, which might make the build configuration simpler.
edit:
I should add that building lbuf with a shared Lua is somewhat dangerous. It assumes that it can use C stdio functions on the FILE * used by the Lua IO library. If Lua and lbuf are compiled with different C libraries, this will fail. This is likely if using a pre-built Lua on windows.
I compiled it on windows using mingw, so that it doesn't need the __declspec to export the dll.
For the libraries, lua5.2 (the official supported version) changed how to use a C module.
http://lua-users.org/lists/lua-l/2012-09/msg00596.html (http://lua-users.org/lists/lua-l/2012-09/msg00596.html) says you can use luaL_newlib, but we have to change the code so that it doesn't register a global table (or we could always use lua_register from 5.1 to keep the table global and keep changes 5.1-compatible)
I'll create a patch to load the sub-modules from the chdkptp module.
-
I compiled it on windows using mingw, so that it doesn't need the __declspec to export the dll.
This doesn't work for me, using mingw and gcc 4.8. It compiles fine, but you can't actually load the module because the luaopen_* isn'texported. I believe there are some gcc options to export everything by default.
Also, using your patch the resulting DLLs were not actually usable even if I exported the luaopen, because Lua ended up statically linked to *each* dll.
My standard windows builds are a monolithic, static exe because this is easier to distribute and install.
For the libraries, lua5.2 (the official supported version) changed how to use a C module.
http://lua-users.org/lists/lua-l/2012-09/msg00596.html (http://lua-users.org/lists/lua-l/2012-09/msg00596.html) says you can use luaL_newlib, but we have to change the code so that it doesn't register a global table (or we could always use lua_register from 5.1 to keep the table global and keep changes 5.1-compatible)
I'll create a patch to load the sub-modules from the chdkptp module.
I plan to drop 5.1 compatibility soon, because maintain testing and takes extra time, but haven't done it yet, so it should stay 5.1 compatible for now.
I did convert the sub-modules to luaopen in changeset 594, but my feeling is that additional work is needed in the makefiles need to be reworked a bit so static and dynamic linking is controlled more explicitly.
-
chdkptp snapshot 592 has a silly bug where the "lua" aka . command will print something like
ERROR: . failed
for every command, even if it succeeded. This is fixed in r597.
edit:
I've uploaded snapshot build 599 to fix this issue. There aren't any other significant changes.
-
Hey reyalp,
is it possible to stream to stdout like "gphoto2 --capture-movie --stdout" would do? I would like to pipe it into VLC to make it available via HTTP as a mjpeg-stream like an IP camera.
-
Hey reyalp,
is it possible to stream to stdout like "gphoto2 --capture-movie --stdout" would do? I would like to pipe it into VLC to make it available via HTTP as a mjpeg-stream like an IP camera.
Not currently. The closest you could get without writing actual code is to display the live gui and use something like vlc or ffmpeg to capture the region of the screen it displays on. Of course this means you need X on the host running chdkptp and adds a lot of overhead.
You could also use lvdumpimg to dump frames into a directory have have some process pick them up.
It shouldn't be terribly hard to make lvdumpimg (or something like it) write continuously to a pipe or stdout.
-
Screen capture is not an Option for me, it adds too much overhead. Do you think you could add it to the wish list? May a beer or a box of beer or something else be helpful?
I look for a way to setup a canon camera that provides a live stream that even works after a power failure. So the camera has to switch on automatically f.e. by holding down the power button with a cable tie. The computer also boots again and starts a command line which starts the video stream. And I would like to have a better quality than a Logitech C920 webcam.
I tested gphoto2 with a borrowed Canon DSLR and it worked great but it's not within the budget.
-
You could also use lvdumpimg to dump frames into a directory have have some process pick them up.
Are you familiar with frame-serving ?
Basically, a programme such as AviSynth or VDub can sequentially send minimal AVI frames to an external application.
As far as the application is concerned, it is reading a normal AVI file, it does not know anything about the source movie, such as its size (which may be larger than the application normally supports).
I am not sure but maybe the application and frame-server share a common buffer that is setup when opening AVI files.
Maybe the frame format is simple RGB ?
Source code is available for frame servers but is rather complicated.
Of course, your application has to know how to read the assumed-buffered frame.
-
sounds like the frame rate will be much lower, cause it dumps them to the disk where they have to be picked up. Beside that the delay will be much higher. All suggested processings would add a higher delay and/or lower frame rates for the resulting stream. So it seems like the better approach would be to try adding chdk-ptp support to gphoto2.
-
As I recall there is a PTP client written in Delphi by one of the young Germans (not the nasty one who normally frequents here).
The client supported a webcam mode.
-
The client was written by 'rudi', try searching for it.
-
I guess were talking about ptpcamgui? it's for windows only, isn't it? I am looking for a Linux solution which could be runrun on a raspberry pie f.e.
-
Screen capture is not an Option for me, it adds too much overhead. Do you think you could add it to the wish list?
It's already on my wishlist, but so are a lot of other things and at the moment I don't have much time to work on any of it.
So it seems like the better approach would be to try adding chdk-ptp support to gphoto2.
Unlikely this would be easier than adding some kind of streaming support chdkptp, the CHDK live view protocol is quite unique due to the way it is hacked into the firmware. It is not related to Canon's built in live view.
I guess were talking about ptpcamgui? it's for windows only, isn't it? I am looking for a Linux solution which could be runrun on a raspberry pie f.e.
AFAIK PTPCamGui doesn't support live view at all, so I'm really not sure what Microfunguy is referring to.
-
There is definitely a build that refers to a webcam driver, I will try to find it on one of my USB drives later today.
It is CHDKCAM by EWAVR (Zosim Mikhaylov).
Here is part of the code :-
void __fastcall TMainForm::OnWebCamSwitch(bool on)
{
static bool OverlayState=true;
if (on)
{
try
{
if (!VCam) VCam = CoVCamSDK::Create();
}
catch(...)
{
Application->MessageBox("Cannot connect to driver.\rWebcam driver is not installed?","Error!",MB_OK|MB_ICONERROR);
WebcamCheckBox->Checked=false;
return;
}
if (!VCam) { WebcamCheckBox->Checked=false; return; }
if (HiResCheckBox->Checked) VCam.ChangeDefaultVideoSize(4);
else VCam.ChangeDefaultVideoSize(2);
HiResCheckBox->Enabled=false;
OverlayState=OverlayCheckBox->Checked;
OverlayCheckBox->Checked=false;
}
if (!on)
{
HiResCheckBox->Enabled=true;
OverlayCheckBox->Checked=OverlayState;
}
}
//---------------------------------------------------------------------------
void __fastcall TMainForm::WebcamCheckBoxClick(TObject *Sender)
{
OnWebCamSwitch(WebcamCheckBox->Checked);
}
//---------------------------------------------------------------------------
I do not have all of the files, never did.
It needs some research to see if anything else can be unearthed.
mod edit:
misattributed quote
-
OK, in svn rev 606, I added some code to lvdumpimg which may enable to you to stream the output.
If the vp filespec starts with !, it is treated as a command to pipe to. If the command includes spaces, it will need to be quoted.
lvdumpimg -count=50 -wait=33 -vp=!"ffmpeg -y -vcodec pgm -f image2pipe -i - -vcodec mpeg4 test.avi"
Created a valid 50 frame AVI for me on my raspberry pi. Presumably, something like the stuff on https://trac.ffmpeg.org/wiki/StreamingGuide would let you stream it instead.
Note in practice you would want to scale the output to the correct aspect ratio, and it's not clear to me how ffmpeg will handle the very unstable frame rate of the input.
I don't think you will be able to encode at very high framerates unless there is support somewhere to do it on the pi gpu.
The changes only affect the lua files, so if you are using a pre-built binary, you can just replace the lua files with the ones from svn.
edit:
Also, there is no way to control chdkptp while this is running. You can kill it with control+c but that's it.
-
Thanks, i will get a canon camera and give it a try and report my result.
Will chdkptp quit when there's an error like the camera has been switched off?
-
Thanks, i will get a canon camera and give it a try and report my result.
If you mean buy one, keep in mind this is a very rough hack. There is no guarantee it will work for your application.
I fiddled with some of the streaming options described in that link and didn't get it to work last night, but it was very late and my knowledge of ffmpeg and video streaming in general is pretty limited.
Will chdkptp quit when there's an error like the camera has been switched off?
Haven't tried it, but it should. The last frame sent to ffmpeg is likely to be invalid in this case, but I suspect it will handle it OK.
Assuming this works, it should be fairly easy to modify the lvdumpimg main loop so it checks some kind of control file.
It's also worth noting lvdumpimg takes the YUV411 viewport data and converts it to RGB to write as a ppm to ffmpeg. Sending some kind of YUV would probably be more efficient, because the final video will almost certainly be YUV. However, I don't know of an image format that would let you send YUV411 directly.
edit:
Also, currently only works for the viewport, it there is no support for piping the UI overlay. It would be complicated to get them in the same stream.
-
There is definitely a build that refers to a webcam driver, I will try to find it on one of my USB drives later today.
It is CHDKCAM by EWAVR (Zosim Mikhaylov).
Here is part of the code :-
void __fastcall TMainForm::OnWebCamSwitch(bool on)
{
static bool OverlayState=true;
if (on)
{
try
{
if (!VCam) VCam = CoVCamSDK::Create();
}
catch(...)
{
Application->MessageBox("Cannot connect to driver.\rWebcam driver is not installed?","Error!",MB_OK|MB_ICONERROR);
WebcamCheckBox->Checked=false;
return;
}
if (!VCam) { WebcamCheckBox->Checked=false; return; }
if (HiResCheckBox->Checked) VCam.ChangeDefaultVideoSize(4);
else VCam.ChangeDefaultVideoSize(2);
HiResCheckBox->Enabled=false;
OverlayState=OverlayCheckBox->Checked;
OverlayCheckBox->Checked=false;
}
if (!on)
{
HiResCheckBox->Enabled=true;
OverlayCheckBox->Checked=OverlayState;
}
}
//---------------------------------------------------------------------------
void __fastcall TMainForm::WebcamCheckBoxClick(TObject *Sender)
{
OnWebCamSwitch(WebcamCheckBox->Checked);
}
//---------------------------------------------------------------------------
I do not have all of the files, never did.
It needs some research to see if anything else can be unearthed.
[/quote]
-
I also have the driver files mentioned in this INF file :-
;
; e2ecam.INF -- This file contains installation information for e2eCam,
; A WDM capture driver that requires no hardware.
;
; Copyright (c) 2005-2008 e2eSoft - http://www.e2esoft.cn
;
;
etc
but no use to you as it is for Windows.
-
It is CHDKCAM by EWAVR (Zosim Mikhaylov).
Ah, not a German after all ;)
It does appear e2esoft offers a free sdk (with watermarked output) http://www.e2esoft.cn/vcam/vcamsdk.asp (http://www.e2esoft.cn/vcam/vcamsdk.asp)
One could presumably hack chdkptp to output to this without a huge amount of trouble.
-
One could presumably hack chdkptp to output to this without a huge amount of trouble.
See this http://www.e2esoft.cn/news/pages/vcam_external_source_howto.html (http://www.e2esoft.cn/news/pages/vcam_external_source_howto.html)
It uses a shared-memory buffer.
As I recall, there is a 'bouncing ball' example in the DirectShow SDK that uses source images as input.
The output of the FilterGraph can be displayed by any application capable of playing the same files as Windows Media Player does.
Presumably, the e2esoft application is based on a similar method.
On Linux systems it is interesting that GStreamer also provides code for a bouncing-ball source filter.
GStreamer looks like a lot of work http://gstreamer.freedesktop.org/ (http://gstreamer.freedesktop.org/)
-
Nice to have the new rsint. Compiled chdkptp from source svn 606. All OK can nicely use rs using the Linux chdkptp client. To speed up shooting the idea was to use rsint. Looked briefly at the lua source, will investigate some more to see how rsint actually works.
Using:
Canon IXUS200 IS Firmware v1.01c
CHDK ixus200_sd980-101c-1.3.0-3496-full (Nightlybuild)
chdkptp svn 606
A hint where to look to make it work would be appreciated.
My bad, first I compiled against LUA5.1 which flag still set was in my custom config.mk. Using Lua 5.1, rsint crashed. Re-compiled with Lue 5.2 and it worked :). However checking out via svn it is easily overlooked one can still have the config.mk hanging around
rsint indeed can indeed be used to speed up the shooting times, in my case from ~3.7sec to 2sec, HURRAY! feels like :xmas thx to all developers involved. this speedup is very important to me.
Now I'll have to figure out how to set exposure and other parameters...
Anyhow, more info or some console example on rsint usage welcomed.
-
My bad, first I compiled against LUA5.1 which flag still set was in my custom config.mk. Using Lua 5.1, rsint crashed. Re-compiled with Lue 5.2 and it worked :). However checking out via svn it is easily overlooked one can still have the config.mk hanging around
I wasn't aware that it was broken with Lua 5.1, but I plan to remove 5.1 support completely soon. After that it will give you a compile error.
Now I'll have to figure out how to set exposure and other parameters...
Anyhow, more info or some console example on rsint usage welcomed.
If you want to set the initial exposure, it works just like rsint.
If you want to change the exposure between shots, you currently need to send lua code to the camera using the exec command from rsint. Something like
con 1> rsint
rsint> exec set_tv96_direct(768)
rsint> s
rsint> s
...
You can send pretty much any camera side code with exec.
However it's important to know that most exposure overrides will not affect the next s command, they will affect the following one. So in the example above, the first shot would use the cameras auto exposure, and the second would be at 1/1024th.
This happens because the point where the camera waits is right before the shot is taken, after the exposure is already set. However, this isn't universal, for example the ND filter will take immediate effect. It may also vary some between cameras. On my D10, I was able to change focus and zoom in this hook, but this could be dangerous since the camera wouldn't normally expect them to be moving at this point.
In continuous mode, we don't really have a place to wait after the previous shot is finished but before the remote hook, the only other place to wait would be the raw hook, which happens before the jpeg is transferred.
The code is mostly in lua/rsint.lua
-
Streaming success-ish
On rpi
lvdumpimg -count=100 -vp=!"ffmpeg -vcodec pgm -f image2pipe -i - -vcodec mpeg2video -s 640x480 -r 24 -pix_fmt yuv420p -f rtp rtp://192.168.1.2:1234"
where 192.168.1.2 is the IP of the client you want to stream to.
On the client system, open rtp://192.168.1.2:1234 (that's the client IP again, NOT the pi IP) as a network stream in VLC or ffplay
The resulting video streams to vlc at about 3 fps over wifi with several seconds of latency. Dropping the resolution to 320x240 brings it up to 4 fps ;)
Note the codec and transport are just what I got working being fairly clueless about this stuff. From what I understand you would normally have an sdp for the rtp stream and have more flexibility on the codec etc, or would send it to a streaming server instead. The -r 24 is there because ffmpeg on the pi refuses accept lower rates with mpeg2video
Using the same settings on my core i5 windows desktop only gives ~8 fps clearly things are sub-optimal. PEBCAK see below.
edit:
According to http://www.raspberrypi.org/new-video-features/ (http://www.raspberrypi.org/new-video-features/) hardware h264 encode is available (without even paying the couple bucks for additional codecs). I'm not yet clear what software you would use to do this though.
-
Oops, I'd forgotten that lvdumpimg defaults to waiting 100ms between frame grabs, and this is added on top of the transfer and save times.
Using -wait=0 like
lvdumpimg -count=250 -wait=0 -vp=!"ffmpeg -vcodec pgm -f image2pipe -i - -vcodec mpeg2video -s 640x480 -r 24 -pix_fmt yuv420p -f rtp rtp://192.168.1.2:1234"
on my desktop gets a frame rate over 30 fps (despite the -r 24...) and brings the pi up slightly.
On the pi, writing to /dev/null with -wait=0 gets about 8 fps. Finding a way to send YUV directly to the video encoder should improve this quite a bit.
edit:
One more note. Supposedly you can use ffmpeg to feed a video4linux loopback device https://github.com/umlaeute/v4l2loopback/wiki/Ffmpeg (https://github.com/umlaeute/v4l2loopback/wiki/Ffmpeg) so theoretically you could use this method to use the live view in applications that expect a webcam etc.
Looking at hardware encoding on the pi, it appears to require YUV420 "packed planer" http://home.nouwen.name/RaspberryPi/documentation/ilcomponents/video_encode.html (http://home.nouwen.name/RaspberryPi/documentation/ilcomponents/video_encode.html) so unfortunately it couldn't be fed directly from the the camera live view.
-
Thx Reyalp for rsint hints. I'll have some time to test all of it soon.
-
In changeset 613, I changed how pipe output is handled in lvdumpimg. Instead of using ! on the filespec, -pipevp and -pipebm are used to specify that the output is to a pipe. Additionally, you can have all frames of a given type either go to a single process (by using -pipevp=oneproc), or invoke the command once per frame. The once per frame option is useful for resizing and converting netpbm to other formats.
Some examples (copied from USAGE.TXT)
Grab 10 viewport frames to files organized in date and time directories
lvdumpimg -vp=vp_${date,%Y%m%d}/${date,%H%M%S}/${frame}.ppm -count=10
Grab a single viewport frame, use imagemagick to convert to jpeg, re-size to 640x480 and naming by date and time:
lvdumpimg -vp='convert - -resize 640x480! vp_${date,%B_%d_%Y-%H_%M_%S}.jpg' -pipevp -count=1
NOTE:
On windows, convert conflicts with system file. You might need to use a full path.
Capture viewport and bitmap, and merge them into a single PNG:
lvdumpimg -pipebm -count=3 -vp=tmp.ppm -bm='convert tmp.ppm - -resize 640x480! -layers merge merged_${frame}.png'
pipe 100 frames of viewport to ffmpeg and stream over rtp
lvdumpimg -pipevp=oneproc -count=100 -vp='ffmpeg -vcodec pgm -f image2pipe -i - -vcodec mpeg2video -s 640x480 -r 24 -pix_fmt yuv420p -f rtp rtp://127.0.0.1:1234'
NOTE:
You could use VLC and open rtp://127.0.0.1:1234 to watch the stream
These probably aren't the best parameters to use
-
I've uploaded snapshot build r650 to the files area https://www.assembla.com/spaces/chdkptp/documents (https://www.assembla.com/spaces/chdkptp/documents)
Major changes
lvdumpimg pipe stuff described above
multicam improvements discussed in http://chdk.setepontos.com/index.php?topic=11667.80 (http://chdk.setepontos.com/index.php?topic=11667.80)
Three new cli commands for managing image files on the card
imls - lists files in the dcim directory
imdl - downloads and optionally deletes files. It has extensive options for selecting the download files and controlling the file paths they are downloaded to.
imrm - delete images files
All three commands use exactly the same options to select the files. There are a few examples in usage.txt. imdl and imrm both accept a pretend option so you can see what they will do.
Both imdl and mdl now default to asking what to do if a file would be overwritten. This can be overridden with the -overwrite option.
-
So the Canon A2500 arrived today after a 2 weeks round trip of the camera caused by the post office. Now i wanted to try the new lvdump feature, but because of my dye sub printer which only has a i386 driver, i tried to compile a 32bit version of chdkptp on Ubuntu 12.04.5 by adding some #includes and ended up here:
The output of make is attached, do you have any idea what's wrong? I would appreciate a pre-compiled i386 version, but even better if i could compile it on my own, so i can compile it everytime a new version has been released.
Thank you in advance!
ladiko
-
So the Canon A2500 arrived today after a 2 weeks round trip of the camera caused by the post office. Now i wanted to try the new lvdump feature, but because of my dye sub printer which only has a i386 driver, i tried to compile a 32bit version of chdkptp on Ubuntu 12.04.5 by adding some #includes and ended up here:
You should not need to add any includes. I'm not sure what the stuff in /usr/src is but if it's kernel headers you definitely don't want that. I would assume the errors listed are caused by these headers.
What happens if you when you try to build without those additional includes?
There really shouldn't be anything x64 specific in the default settings, if you don't need the GUI you should pretty much just be able to copy config-sample-linux.mk to config.mk and make.
-
copying the config-sample-linux.mk to config.mk made it works!
When i connect the camera to the computer, it is recognized by chdkptp but the lens retracts into the camera, the display switches off and the camera behaves like in the default ptp-file transfer mode. this way i can't take pictures. is there an chdk option that leads to a different behaviour?
When there's a picture on the SD card, this picture will be shown in live viewfinder mode instead of the lens picture, if there's no picture, you see a black screen.
If i stop udev and reconnect the camera, the display doesnt switch off, but the camera goes into play mode and stays there.
Seems to be related to the "Usage notes" here: http://chdk.wikia.com/wiki/PTP_Extension (http://chdk.wikia.com/wiki/PTP_Extension)
-
When i connect the camera to the computer, it is recognized by chdkptp but the lens retracts into the camera, the display switches off and the camera behaves like in the default ptp-file transfer mode. this way i can't take pictures. is there an chdk option that leads to a different behaviour?
This is due to something your OS is doing when you connect the camera, there are no CHDK options which affect this.
If i stop udev and reconnect the camera, the display doesnt switch off, but the camera goes into play mode and stays there.
The fact the screen doesn't go black suggests this stops the OS interference. Have you tried to switch back to record mode with the rec command (or GUI button)?
I would generally suggest making sure the camera is in play mode before you connect it to the PC, and then use rec to switch to record mode from chdkptp.
-
If running Linux, the camera behaviour might be related to the issue described here..
http://chdk.setepontos.com/index.php?topic=10664.20 (http://chdk.setepontos.com/index.php?topic=10664.20)
-
ok now it works, liveview and taking pictures etc. so the a2500 is supported with the current alpha of chdk 1.3. I also added some stuff to the other thread about the gvfs automount.
Is lvdumping able to output a jpg stream? Because ffmpeg / avconv has a lag of 2 or 3 seconds, while i was streaming mjpeg from Canon EOS 1100 -> gphoto2 -> vlc mjpeg-Stream -> Google Chrome with a lag of around 1 second. But VLC only unterstands JPEG / MJPEG streams as image input.
edit:
This works:
LUA_PATH=Downloads/chdkptp/lua/?.lua Downloads/chdkptp/chdkptp -c -e"lvdumpimg -count=10000 -pipevp=oneproc -vp='avconv -vcodec pgm -f image2pipe -i - -vcodec mpeg2video -s 640x480 -r 24 -v quiet -pix_fmt yuv420p -f mpegts - '" | vlc -
This doesnt:
LUA_PATH=Downloads/chdkptp/lua/?.lua Downloads/chdkptp/chdkptp -c -e"lvdumpimg -count=10000 -pipevp=oneproc -vp='avconv -vcodec pgm -f image2pipe -i - -vcodec mjpeg -s 640x480 -r 24 -v quiet -pix_fmt yuv420p -f mjpeg - '" | vlc -
Edit2:
This works and has a little less lag:
LUA_PATH=Downloads/chdkptp/lua/?.lua Downloads/chdkptp/chdkptp -c -e"lvdumpimg -count=10000 -pipevp=oneproc -vp='avconv -vcodec pgm -f image2pipe -i - -vcodec mjpeg -s 640x480 -f mpjpeg - | vlc -'"
Edit3
And a bit less lag and better quality:
LUA_PATH=Downloads/chdkptp/lua/?.lua Downloads/chdkptp/chdkptp -c -e"lvdumpimg -count=10000 -pipevp=oneproc -vp='avconv -vcodec pgm -f image2pipe -i - -qscale 1 -vcodec mjpeg -s 640x480 -f mpjpeg - | vlc - --file-caching=0'"
With JPG/MJPEG i could just do
LUA_PATH=Downloads/chdkptp/lua/?.lua Downloads/chdkpt/chdkptp -c -e"lvdumpimg -count=10000 -pipevp=oneproc -vp='vlc -'"
Note for me: Try to disable ffmpeg pre buffer / cache to minimize the lag: https://trac.ffmpeg.org/wiki/StreamingGuide
Btw.: How to create an endless / continuous stream?
-
double post, sorry.
-
Is lvdumping able to output a jpg stream?
No, it can only output netpbm at the moment.
Btw.: How to create an endless / continuous stream?
Use an arbitrarily large number for count.
-
Could you guess the frame rate? The GUI was limited to 30 and it didn't show any dropped frames. So it's 30? So if I use a timeout of 3 minutes, the frame could should be 30 x 180 = 5400 or 6000 if I want to have a little buffer!?
How hard would it be to provide mjpeg directly?
-
Could you guess the frame rate? The GUI was limited to 30 and it didn't show any dropped frames.
The way chdkptp live view works by polling, it doesn't know anything about the cameras actual frame rate. It just requests frames repeatedly, and gets whatever is currently in the camera framebuffer. If you request faster than the cameras actual frame rate, you get duplicated frames, and if you request slower, you miss some frames.
The frame rate you can produce is limited by USB transfer and processing overhead. The GUI should show "dropped" frames if the requested rate is faster than the combined transfer and rendering allow and gui_live_dropframes is set. By default, this is only set on Linux because the UI becomes unresponsive when an IUP timer repeatedly takes longer than the timer interval.
If you use -fps=N with lvdumpimg, it should request frames at the rate you specify, or less if it it isn't able to keep up.
How hard would it be to provide mjpeg directly?
I don't really know anything about mjpeg, so I don't know. At a minimum, it would require linking to a library with jpeg support, and converting the live view data into something the library accepts as input. I may do this eventually, but I'm not in a hurry to add extra dependencies and compile time optional features.
An alternative would be to write a shim program that reads netbpm (or raw live view protocol) on stdin and writes out mjpeg. The second option would have the advantage of allowing the conversion to happen in parallel with transfer.
FWIW, I believe the native Canon live view (as exposed by gphoto etc) the actual USB stream is mjpeg. However, we don't know how to set this up in the Canon firmware, and it's not clear if it would even be possible on cameras without Canon live view.
-
In practice, in its simplest form, an mjpeg is just a concatenation of jpeg files, one after the other in the same file. So almost the same way chdkptp outputs netbpm. Sometimes the single frames of mjepg are separated with a line of ascii code - usually just
...
<binary jpg data>
--7b3cc56e5f51db803f790dad720ed50a
<binary jpg data>
--7b3cc56e5f51db803f790dad720ed50a
<binary jpg data>
...
not a big deal, so i will just use ffmpeg / avconv or encodedv and see what produces the best / fastes results. I will report back when i found something more useful. You already mentioned the reason why i want to produce mjpeg: so i stay compatible with Canons native Live View streams which are mjpegs and i can use both as input for further processing and play them in webbrowsers. right now i am just doing a little testing. I look for a replacement of the Logitech HD C920 Webcam. Some years ago Sony DV Camcorders could have been used as DirectX "webcams" or as /dev/video0 on linux. Current camcorders only offer analog output or HDMI-Out but HDMI-In isnt that common on computers. Current webcams are just unsatisfying in comparison to 6 to 7 years old camcorders and i still believe there is something out there with a much better still image quality than a webcam, acceptable live view quality (for preview) and - if possible - halfway cheaper than DSLRs.
Like i said... i will report back later on.
Btw.: Thank you again for adding the continous ppm stream, it's really helpful! :)
-
Thinking about this http://chdk.setepontos.com/index.php?topic=11527.0 (http://chdk.setepontos.com/index.php?topic=11527.0) I realized that rsint could work the same way.
I've added this in chdkptp r652. By default, rsint now uses the new method, but continuous mode + shoot hooks can be selected by passing -cont
The new mode has several advantages:
* It doesn't require continuous mode. This is nice because remoteshoot in continuous mode has problems on some cams. Also some cams do not save the continuous setting between reboots.
* It doesn't require CHDK 1.3 shoot hooks.
* You can quit without taking a shot (use q at the rsint prompt)
* Exposure changes should affect the next shot, rather than the following shot.
Based on the testing in the linked thread, the max speed shouldn't be much different. The latency between issuing and s command and the shot being taken should be better in continuous mode.
-
For what its worth, changing the <ALT> key on the Ixus 100 /SD780IS from [Playback] to [Display] results in the camera crashing when I connect it to CHDK-PTP.
I updated the SD780IS Wikia entry (http://chdk.wikia.com/wiki/SD780IS) to point this out.
I'm not sure if its a bug worth fixing, but it did cause me a bit of head scratching.
Also some of the camera modes look to be incorrect in CHDK-PTP for this particular camera.
Any developer, PM me if you want more details, to save cluttering up this thread.
-
I'm not a developer, but tell me about the camera modes and I will check if it's the same with the a2500.
-
nafraf contacted me and we are working through the modes to fix this. This problem will be camera specific.
I've sent him a revised list of the modes on the Ixus 100, based on what I see in Propcase 49, and he will send me a test version of CHDK with these revised modes when he gets a chance.
If you want to confirm the modes are correct on your A2500, connect the camera and select each mode from the drop down list in the CHDK-PTP UI. The camera should change to the correct mode each time.
In the case of the Ixus 100, it was selecting some modes incorrectly and a couple were missing.
I had a similar issue while we were porting the Ixus Wireless a while back, so I had a pretty good idea what was required of us to fix it.
-
For what its worth, changing the <ALT> key on the Ixus 100 /SD780IS from [Playback] to [Display] results in the camera crashing when I connect it to CHDK-PTP.
It's very hard to see how the alt key assignment could cause this, mode switching doesn't have anything to do with the alt key. I guess maybe if the key masks were messed up...
-
I'll test again with the latest build when I get a chance, perhaps tomorrow.
-
I'll test again with the latest build when I get a chance, perhaps tomorrow.
A romlog from the crash might provide some clues.
-
I tried installing and starting chdkptp on Ubuntu 14.04 32bit this way:
#!/bin/bash
# variables
IUP_FILE=iup-3.11_Linux32_lib.tar.gz
CD_FILE=cd-5.8_Linux32_lib.tar.gz
CHDKPTP_DIR=${HOME}/chdkptp/trunk
# install iup
if [ ! -e ${HOME}/iup/${IUP_FILE} ] ; then
mkdir -p ${HOME}/iup
cd ${HOME}/iup
wget -N --trust-server-names 'http://downloads.sourceforge.net/project/iup/3.11/Linux%20Libraries/iup-3.11_Linux32_lib.tar.gz?r=http%3A%2F%2Fsourceforge.net%2Fprojects%2Fiup%2Ffiles%2F3.11%2FLinux%2520Libraries%2F&ts=1407825526&$
tar xpvzf ${IUP_FILE}
sudo bash ${HOME}/iup/install
cd ${HOME}
fi
# install cd
if [ ! -e ${HOME}/cd/${CD_FILE} ] ; then
mkdir -p ${HOME}/cd
cd ${HOME}/cd
wget -N --trust-server-names 'http://downloads.sourceforge.net/project/canvasdraw/5.8/Linux%20Libraries/cd-5.8_Linux32_lib.tar.gz?r=http%3A%2F%2Fsourceforge.net%2Fprojects%2Fcanvasdraw%2Ffiles%2F5.8%2FLinux%2520Libraries%2F&ts=1$
tar xpvzf ${CD_FILE}
sudo bash ${HOME}/cd/install
cd ${HOME}
fi
sudo aptitude install -q=2 -y liblua5.2-dev libusb-dev
if [ -e ${CHDKPTP_DIR} ] ; then
cd ${CHDKPTP_DIR}
svn update
else
svn checkout http://subversion.assembla.com/svn/chdkptp/
cd ${CHDKPTP_DIR}
fi
cp ${CHDKPTP_DIR}/config-sample-linux.mk ${CHDKPTP_DIR}/config.mk
make all
# only need if you have compiled IUP support and have NOT installed the libraries to system directories
export LD_LIBRARY_PATH=${HOME}/iup:${HOME}/cd
export LUA_PATH="${CHDKPTP_DIR}/lua/?.lua"
./chdkptp "$@"
echo -e "\n$?"
if i start the script with ${HOME}/chdkptp.sh -g i get: Updating '.':
At revision 652.
make[1]: Entering directory `/home/ladiko/chdkptp/trunk/lfs'
make[1]: Leaving directory `/home/ladiko/chdkptp/trunk/lfs'
starting gui...
gui not supported
1
-
I tried installing and starting chdkptp on Ubuntu 14.04 32bit this way:
You need to edit config.mk to enable IUP and CD support, and set the include and library paths. These are fairly well commented in in the -sample file. After you change config.mk, you should rebuild with
make clean all
In general, I would not suggest having your chdkptp script try to download and build everything.
-
ok got it. :)
The gui now works on 32 bit - great :D
What result does enabling CD_PLUS_SUPPORT=cairo have?
What happens if i enable IUP_SUPPORT, but leave CD_SUPPORT disabled?
Taking 6 pictures takes 22 seconds, doesnt matter if i use shoot or remoteshoot or if i use 16 or only 2 megapixel. is there any way to speed it up? are scripts faster? or is it possible to enable something like serial exposure?
Is it possible to set all options via chdkptp - switching the flash on and off well as switching "File Numbering" from "Auto Reset" to "Continuous" ?
-
What result does enabling CD_PLUS_SUPPORT=cairo have?
Better quality rendering of the live view, at the cost of lower frame rate. (edit: to be more specific, the resizing to correct aspect ratio in the GUI is smoother)
Note that the compile option only makes it available, to actually enable it you need to have set gui_context_plus=true in your .chdkptpguirc file
What happens if i enable IUP_SUPPORT, but leave CD_SUPPORT disabled?
Live view won't be available. Other things may also be broken, I haven't tested this combination recently.
Taking 6 pictures takes 22 seconds, doesnt matter if i use shoot or remoteshoot or if i use 16 or only 2 megapixel. is there any way to speed it up?
Maybe, depends what your requirements are. If you want to shoot a series of shots with the same exposure (or some exposure you know in advance) then yes, it should is possible. You can use the rs -cont option to do this (if your camera can handle remote shoot in continuous mode, some are buggy), or the rsint command, or write a camera side script that repeatedly clicks the shoot_full_only button.
Some camera settings also affect shooting speed, this has been discussed earlier in the thread. See http://chdk.setepontos.com/index.php?topic=6231.msg98677#msg98677 (http://chdk.setepontos.com/index.php?topic=6231.msg98677#msg98677)
In no case will it be significantly faster than the Canon continuous mode spec for that camera.
are scripts faster? or is it possible to enable something like serial exposure?
I don't know what you mean by "serial exposure".
Is it possible to set all options via chdkptp - switching the flash on and off well as switching "File Numbering" from "Auto Reset" to "Continuous" ?
You can manipulate the Canon menus using simulated key presses, either by sending click("keyname") or using the GUI buttons. Otherwise, everything available in http://chdk.wikia.com/wiki/CHDK_Scripting_Cross_Reference_Page (http://chdk.wikia.com/wiki/CHDK_Scripting_Cross_Reference_Page) is available by sending lua code.
-
I don't know what you mean by "serial exposure".
i guess it's called continuous (shooting) mode or burst mode.
Do you know how to modify the Makefile if i want to link iup, cd, lua etc. statically? At least iup and cd cause these are not available in the ubuntu repositories.
-
Do you know how to modify the Makefile if i want to link iup, cd, lua etc. statically? At least iup and cd cause these are not available in the ubuntu repositories.
The Linux binaries I provide are linked statically with Lua. This done just by building Lua as a static lib.
Not sure about IUP and CD. The windows builds (using mingw gcc) are static, so there might be some clues there.
Alternatively, you could just bundle the CD and IUP .so files with your build if you want a complete binary package. I provide a separate package of IUP and CD .so files for raspberry pi, since there are no official binaries and they are kind of a pain to build. Providing the libs separately allows people to build their own chdkptp without needing to build the libs.
-
Is the cairo-support available in the streamed life view as well as in the gui? if you say i need gui_context_plus=true in my .chdkptpguirc, it sounds like it only applies to the iup-gui, but not to the utput that is streamed via command line.
Just a note for this message regarding mjpg streaming (http://chdk.setepontos.com/index.php?topic=6231.msg115450#msg115450): if you ask google about 7b3cc56e5f51db803f790dad720ed50a (http://www.google.com/search?q=7b3cc56e5f51db803f790dad720ed50a), you will find some more information about that topic.
-
Is the cairo-support available in the streamed life view as well as in the gui? if you say i need gui_context_plus=true in my .chdkptpguirc, it sounds like it only applies to the iup-gui, but not to the utput that is streamed via command line.
It only applies to the gui, the lvdumpimg doesn't do any rescaling at all.
-
In chdkptp r653-655, I've added some improvements to the remoteshoot command
You can now shoot multiple shots without -cont. Specify the number of shots with -shots=n
To shoot multiple shots quickly using the "hold half press and click shoot full" method, using -quick. If you don't specify -quick or -cont, each shot will be taken with shoot(), doing focus and AE for each shot.
-quick and -cont allow specifying the number of shots directly,so rs -quick=10 shoots 10 shots.
You can specify an interval between shots using -int=n where n is the number of seconds between shots. Floating point numbers are accepted.
If you don't use -cont or -quick, the accuracy of the interval will be low, since it only controls the start of the shoot() call, not the the full press or shutter opening.
You must be using CHDK 1.3 to use -int with -cont.
-
Great, thanks for implementing this. This way it doesnt take up to 25 seconds to create 6 images with the A2500. I will test it tomorrow.
How does
-u=<s|a|96>
-badpix[=n]
-nd=<in|out>
-sd=<v>[units]
change the shooting (process)?
-
-u=<s|a|96>
This sets how the values of -tv etc are interpreted. The default is to use convention units, like -tv=1/100 -av=2.8 etc.
-badpix[=n]
This only affects DNG. It controls whether chdkptp interpolates over zero (or n) valued pixels. This is done in chdkptp, so it doesn't affect processing on the camera.
Background: Remote capture DNG is always in DNG 1.3 format, with bad pixels specified by opcodes. Many DNG processors do not understand the opcodes, so the bad pixels show up. This option interpolates over the bad pixels. All of this applies only to bad pixels which are set to 0 (or some similar value) by the canon firmware. Hot pixels must be handled separately.
-nd=<in|out>
Overrides the state of the cameras ND filter, if it has one. Note that camera auto exposure is not aware of any CHDK overrides, including this one. So if the camera would have used the ND filter, and you only force the ND out, the shot will be over exposed. In general, if you override one exposure setting, you should override all.
-sd=<v>[units]
Attempts to set the focus distance to v before shooting. The default unit is meters.
-
if there is no device, chdkptp exits with the following error message:
ERROR: no matching devices found
ERROR: not connected
and error code / return code 0. I would like to have different return codes for every error type. What do you think about that?
With my Canon A2500 using rs -cont=6 takes 9,6 seconds while rs -quick=6 takes about 11 seconds. Is there any difference, beside the fact that the camera has to be in continuous mode for -cont? Now it's a little later and darker, so the camera needs 16.2 vs. 14.3 seconds.
Would it make a difference regarding to the speed if -cont=n/-quick=n would be available to the "shoot" operation with and i download all pictures afterwards?
After executing -ereboot, the A2500 doesnt respond to chdkptp nor any key presses, not even switching off works, i have to remove the battery and after re-inserting the battery, the camera works again.
I always execute chdkptp -c -e"rec" -e"shoot ... or chdkptp -c -e"rec" -e"lvdumpimg ..." because the camera is set to play mode on initial startup. Is there any way to suppress the error message "ERROR: already in rec" ? I guess the best way is to test the current mode first, but that takes more time than just getting the erreor message, i guess. Is there a way to check the mode? I just find a reference to "list" which states if the camera is connected or not, but nothing about the current mode. Beside that, it's more like a warning than an error, cause the result is just what i want. I guess adding an option -quiet for play and rec would be sufficient!? While it shouldnt suppress "real" error messages!
-
if there is no device, chdkptp exits with the following error message:
ERROR: no matching devices found
ERROR: not connected
and error code / return code 0. I would like to have different return codes for every error type. What do you think about that?
Changing the return status if -c fails is a good idea. I'm not sure about making unique return codes for every error, that could be quite difficult to maintain.
With my Canon A2500 using rs -cont=6 takes 9,6 seconds while rs -quick=6 takes about 11 seconds. Is there any difference, beside the fact that the camera has to be in continuous mode for -cont?
Some cameras have problem with remote shoot in continuous mode. Other than that, there shouldn't be much difference.
Now it's a little later and darker, so the camera needs 16.2 vs. 14.3 seconds.
If you want an apples to apples comparison, you should set shutter speed and ISO (ISO affects processing time in some cases). The pictures don't need to be well exposed to benchmark.
Would it make a difference regarding to the speed if -cont=n/-quick=n would be available to the "shoot" operation with and i download all pictures afterwards?
Maybe, depending on the camera and SD card speed, and whether you are interested in the total time (including download) or just the time between shots. I do plan to add similar functionality to shoot at some point.
After executing -ereboot, the A2500 doesnt respond to chdkptp nor any key presses, not even switching off works, i have to remove the battery and after re-inserting the battery, the camera works again.
This sounds like a bug in the port, so you should bring it up in the a2500 porting thread if it's not already discussed there. Just to make sure it's not PTP related you can make a lua script with just reboot() in it.
I always execute chdkptp -c -e"rec" -e"shoot ... or chdkptp -c -e"rec" -e"lvdumpimg ..." because the camera is set to play mode on initial startup. Is there any way to suppress the error message "ERROR: already in rec" ?
You could change the code. In cli.lua (around line 2365 in the current trunk), replace
return false,'already in rec'
with
return true
This should probably be an info or warning message rather than an error, so I may change it.
Is there a way to check the mode?
!return con:execwait("return get_mode()")
But in that case, you might as well just use the code sent by the rec command with the modification above.
I just find a reference to "list" which states if the camera is connected or not, but nothing about the current mode.
Getting the mode requires running lua script on the camera, so it doesn't belong in list.
Instead of stringing together a bunch of -e commands and so on, you might be better off putting everything a lua module and running it with something like
chdkptp -e'exec require"mymodule"'
You can run cli commands from Lua code using cli:execute. Then you can check the status in code rather than displaying if you want.
-
While testing for side effects with my a3400 (dryos r50), I noticed that rs -quick gets stuck after the first shot (last console debug line is "get data 2"). I have to press the shutter by hand to complete the series. This anomaly only happens in single shot mode. Am I the only one experiencing this (using current CHDK and chdkptp trunk)?
-
While testing for side effects with my a3400 (dryos r50), I noticed that rs -quick gets stuck after the first shot (last console debug line is "get data 2"). I have to press the shutter by hand to complete the series. This anomaly only happens in single shot mode. Am I the only one experiencing this (using current CHDK and chdkptp trunk)?
Sounds like the second shot didn't start.
Do you have review enabled?
I think it should time out eventually if the shot doesn't start, probably somewhere form 10-30 seconds.
-
Do you have review enabled?
No (enabling review made no difference). Nafraf reports that his a810 is working normally. The only obvious difference between these models is that the a3400 has IS and touchscreen...
After some tries, rs -quick worked with a dark scene, got stuck with a relatively bright one :blink: . Anyway, the issue isn't related to my pending fwt patch.
-
No (enabling review made no difference). Nafraf reports that his a810 is working normally. The only obvious difference between these models is that the a3400 has IS and touchscreen...
I suspect that for some reason the full press for the second shot isn't being recognized, maybe because it comes too soon after the previous shot. Does it time out eventually?
If you use something like -int=5 does it work?
-
I suspect that for some reason the full press for the second shot isn't being recognized, maybe because it comes too soon after the previous shot. Does it time out eventually?
Yes, I get the usual timeout if I wait for it.
When the display comes back after the first shot, the AF-point zoom is no longer visible (as if the shutter was no longer (half)pressed).
If you use something like -int=5 does it work?
Yes...
-
If you use something like -int=5 does it work?
Yes...
So probably some undetermined time is needed between the release (or file counter increment) and the next press.
In rlibs.lua (around line 1299 in the current trunk) you can change
local tsleep=t_next - get_tick_count()
if tsleep > 0 then
if read_usb_msg(tsleep) == 'quit' then
break
end
end
to something like
local tsleep=t_next - get_tick_count()
if tsleep < 10 then
tsleep=10
end
if read_usb_msg(tsleep) == 'quit' then
break
end
If tsleep=10 isn't enough, you can try increasing it.
-
If tsleep=10 isn't enough, you can try increasing it.
Doesn't help (even tsleep=1000).
The issue is related to ISO: ISO100 is working normally, ISO400 gets stuck (the cam remains in ALT mode after the first shot, but the ALT indicator isn't always visible).
This is likely some camera specific stuff, and it isn't really needed since -cont is working.
-
Doesn't help (even tsleep=1000).
Hmm, if -int worked, maybe my code above wasn't correct. 5000 should be roughly the same as -int=5 (plust the actual shooting time)
The issue is related to ISO: ISO100 is working normally, ISO400 gets stuck (the cam remains in ALT mode after the first shot, but the ALT indicator isn't always visible).
This is likely some camera specific stuff, and it isn't really needed since -cont is working.
I guess this affects other uses of the "hold half press and click shoot" strategy, so it would be good to understand. I should add some better diagnostics to remoteshoot anyway.
Does the camera show the "busy" message after shooting at iso400?
I'll try with high ISO on my cameras.
-
Does the camera show the "busy" message after shooting at iso400?
Yes. Extra noise reduction, I guess.
-
Does the camera show the "busy" message after shooting at iso400?
Yes. Extra noise reduction, I guess.
That's my thought as well. I guess it might affect the timing.
-
I wasn't able to reproduce this on any of my cams.
After some tries, rs -quick worked with a dark scene, got stuck with a relatively bright one
How bright? My tests ended up with between 1/60th and 1/200th.
Settings I used
P mode
ISO 400-1600, depending on cam, set in camera UI not rs options
Drive mode: single
Remote shoot with jpeg only.
edit:
I wasn't really expecting to reproduce since my cameras are different generations, this is mainly for future reference.
-
How bright? My tests ended up with between 1/60th and 1/200th.
It wasn't a systematic test series, "bright" was simply my monitor screen...
-
edit: I updated to r650 and now have a path problem with rsint. It does save image to PC but not to the folder\filename set with path
path C:/test/filenamebut to the folder above the chdkptp.exe file
Has there been a syntax change for the path command?
-
edit: I updated to r650 and now have a path problem with rsint. It does save image to PC but not to the folder\filename set with path
path C:/test/filenamebut to the folder above the chdkptp.exe file
Has there been a syntax change for the path command?
No, I broke it :(
I checked in a workaround in revision 656
-
Regarding key shortcuts / accelerators, you can also add your own key handlers to controls or the main dialog. See gui.lua inputtext:k_any() for an example.
I added these lines and it seems to be working. Of course it only works when the cursor is set in the command field.
elseif k == iup.K_F8 then
gui.execquick('click("video")')
elseif k == iup.K_F9 then
gui.execquick([[
local rec,vid = get_mode()
if rec and not vid then
shoot()
else
if vid then
press('shoot_half')
sleep(200)
end
click('shoot_full')
end
]])
elseif k == iup.K_F11 then
gui.execquick('click("zoom_out")')
elseif k == iup.K_F12 then
gui.execquick('click("zoom_in")')
end
I'm not too sure with the code. I simply copied and pasted :-)
Thank you for your help.
-
If you are mucking with transforms and want to reset, use !gui.live.icnv.dccnv:Transform(nil)
To mirror, you can use
!width=gui.live.icnv.dccnv:GetSize();gui.live.icnv.dccnv:TransformScale(-1,1);gui.live.icnv.dccnv:TransformTranslate(-width,0)
I added the lines in two spots:
width=gui.live.icnv.dccnv:GetSize()
gui.live.icnv.dccnv:TransformScale(-1,1)
gui.live.icnv.dccnv:TransformTranslate( -width,0)
if lv and lv._frame then
*snip*
end
--width=gui.live.icnv.dccnv:GetSize()
gui.live.icnv.dccnv:TransformScale(-1,1)
gui.live.icnv.dccnv:TransformTranslate( -width,0)
I'm sure it's not the best way. Honestly, I understand the codes not much. I only tried and error :)
If I put them in one of the spots only it starts flicking.:(
-
Hi there!
First of all i want to thank you a lot for making dreams come true ;-)
Today i bought a PS 1100IS and tried chdkptp and it is kinda messed up. I already successful made a a590IS work with it. But with the 1100 i dont get from play mode into rec mode. It sounds like it went into rec mode but the display and function is like play mode. Is i press half shoot it goes into recmode but still with problems. The Screen ist mixed up as seen in the screenshoots attached. If i press half shoot the screen looks fine for a few seconds, but then goes back mixed up. I tried different usbports - no change. Everything works fine with the 590. Also functions go weird sometimes. I cant fully reproduce it, because it is so messed up. The graphics of the camera (not chdk) stay wrong, but chdk graphics look fine and the clock runs.
Tell me if i should try somehing.
Cheers
Toby
-
It now kinda works for me. Still got little problems. Sometimes i have to hit shoothalf when i changed from play into record to make it work. I encountered a new issue where i put the camera in AEL to set the tv as i like. When i hit shootfull the camera doesnt respond to every button from Hardware and Software. If i hit a button in the software (chdkptp) it tells me a script is already running.
-
Today i bought a PS 1100IS and tried chdkptp and it is kinda messed up.
As youar camera an A1100, or ixus80_sd1100 ?
What CHDK and CHDKPTP versions are you using?
What OS are you using?
From the screenshots, it looks like the functions for full live view support are not implemented so the dimensions and palette are wrong. Looking at the code, this is true for A1100. The cut off live view looks like it might be due to digital zoom. This wouldn't happen if the viewport size functions were implemented.
It sounds like it went into rec mode but the display and function is like play mode. Is i press half shoot it goes into recmode but still with problems. The Screen ist mixed up as seen in the screenshoots attached. If i press half shoot the screen looks fine for a few seconds, but then goes back mixed up. I tried different usbports - no change. Everything works fine with the 590. Also functions go weird sometimes. I cant fully reproduce it, because it is so messed up. The graphics of the camera (not chdk) stay wrong, but chdk graphics look fine and the clock runs.
I don't really understand what you are trying to describe here. The screenshots show the display functions aren't fully implemented. The camera appears to be in rec mode.
I encountered a new issue where i put the camera in AEL to set the tv as i like. When i hit shootfull the camera doesnt respond to every button from Hardware and Software. If i hit a button in the software (chdkptp) it tells me a script is already running.
How are you trying to put the camera in AEL?
-
I have a Powershot A1100 IS. CHDK is a1100-100c-1.2.0-3659-full_BETA and CHDKPTP is chdkptp-r599-win32.
I have Win XP.
Yes youre right. If i turn off digitalzoom its now ok with the view.
But still i have to press shoothalf after changing to rec mode to actually be complete in rec mode. (Hardeware goes into recmode but software seems not. There is still the playmode display.)
AEL mode is set by shoothalf and up.
-
I have a Powershot A1100 IS. CHDK is a1100-100c-1.2.0-3659-full_BETA
Upgrade to CHDK 1.3 and try again.
edit: sorry, I assumed koshy and nafraf implemented the missing routines but didn't check for proof... :-[
-
But still i have to press shoothalf after changing to rec mode to actually be complete in rec mode. (Hardeware goes into recmode but software seems not. There is still the playmode display.)
I would guess this is just the UI not updating because the live view implementation is not complete.
AEL mode is set by shoothalf and up.
Physically on the camera or using lua? If use lua, what specific command?
Upgrade to CHDK 1.3 and try again.
It looks to me like vid_get_viewport_height_proper, vid_get_bitmap_active_palette, vid_get_bitmap_active_buffer and friends are not implemented in 1.3 for this camera, so probably no need. I'll try to come up with a test build if no one beats me to it.
-
I uploaded chdkptp snapshot release 658 to the files area https://www.assembla.com/spaces/chdkptp/documents (https://www.assembla.com/spaces/chdkptp/documents)
This is a minor update:
Linux x64 binaries are now built on Ubuntu 14.04, and include CLI and GUI executables.
Fixed the rsint "path" command bug reported by tpont.
Adds the "hold half shoot and press full" quick mode and interval mode to remote shoot.
-
@toby: I've posted a test build in the a1100 development thread: http://chdk.setepontos.com/index.php?topic=4727.msg117898#msg117898 (http://chdk.setepontos.com/index.php?topic=4727.msg117898#msg117898)
please try it out and report back there.
-
I´m afraid to use any patches, and version that arent stable since my camera made some ugly noise while using chdkptp. It sounded like some gears went crazy and skipped some tooths. :blink:
-
I´m afraid to use any patches, and version that arent stable since my camera made some ugly noise while using chdkptp. It sounded like some gears went crazy and skipped some tooths. :blink:
Can you be more specific about what you were doing when it happened, and what chdk build you were using?
I've never seen or heard of anything like that before. If it's a previously unknown problem, there's no reason to think "stable" builds will be any safer than any other build.
The only times I've had scary mechanical noises from the cameras are when they crashed with the lens part way out.
edit:
koshy is testing the live view changes, so there's no need for you to.
-
Unfortunately i cant remember really what i was doing. I think just trying my script which has zoom, focus and shutter functions.
I could also be possible that some dirt has gotten into the gear, because this camera wasnt handled well. ( I bought it used, it had some dirt in it).
-
Unfortunately i cant remember really what i was doing. I think just trying my script which has zoom, focus and shutter functions.
OK, if your script was commanding things to move, this makes more sense. However, any risk would be related to what your script is doing, not chdkptp or whether the build was "unstable" or not.
-
Rev 659
I have added a library iniLib to save states. This library was provided by rudi. Thanks for that. ini files are stored in subfolder <chdkptp path>/data. If not available, this folder is created.
The user tab has a new function: Pic&Vid download. You can choose a target folder. Default is <chdkptp path>images. Pics and videos are stored in subfolders by date. As option you can download RAW/DNG files from A/RAW and GPS data files from A/DCIM/CANONMSC/GPS. A third option 'pretend' is for the test. Destination and options are stored in an ini file <chdkptp path>/data/gui_user_cfg.ini .
msl
-
I would like to add a progress bar for the image download function in the user tab. Is there a way to get informations about the progress and the total number of files from the cli functions 'imdl' and 'mdl'?
msl
-
I would like to add a progress bar for the image download function in the user tab. Is there a way to get informations about the progress and the total number of files from the cli functions 'imdl' and 'mdl'?
Not from the CLI command, but it should be possible using the underlying chdku functions, possibly with minor changes.
If you look at cli.lua imdl, it uses con:imglist to get a list of files, so you can get the total number. It includes stat values, so you could get size too.
imglist_download accepts an opt value called info_fn. This is normally used in verbose mode to display the file names, but you could provide your own. For a download, it will be called like
opts.info_fn('%s->%s\n',src,dst)
but it may also be called with other values, so you'd have to do some fiddling to get the file download.
Adding a new callback like progress_fn() would probably be better.
chdku mdownload doesn't use a separate function to make the file list, so it would need additional changes. A simple way to do it would be to add a callback to opts that gets called with files after the ff_mdownload call. Splitting it to work like imdl might be better.
You might also run into issues actually updating the GUI: If you call chdku code directly the gui will be blocked until the entire operation completes. If you use the cli:execute, it uses a coroutine that yields to the gui when chdku code sleeps. You might be able to work around this by calling your code through the exec (!) cli command. However, I don't think the current code yields while it's actually downloading the files anyway, so that might need to be done in the progress function.
This is something I would like to have, so I'd be willing to help add the necessary hooks if the above is more than you want to get into.
If you make major changes outside of the gui_user file, I'd prefer to have a patch to look at before it gets checked in.
-
In r660, I added the ability to use a file with lua, luar, and exec. So if you have a long complicated thing you don't want to type every time, you can just edit in an editor and then use
= <myfile.lua
to run it on the camera.
-
In r660, I added the ability to use a file with lua, luar, and exec.
Nice. I actually thought it already did that but that I had just not puzzled it out.
-
reyalp, how could my application have live view streamed to it from chdkptp commands? If it's lvdump, how do I use it?
I'm creating a stop motion application with onion skinning, using Visual Basic 2010.
-
reyalp, how could my application have live view streamed to it from chdkptp commands? If it's lvdump, how do I use it?
I'm creating a stop motion application with onion skinning, using Visual Basic 2010.
I'm not really clear what you are trying to do. If you want to display the live view inside your application, you will probably need to do some hacking, chdkptp is primarily designed to be a standalone client, not something embedded in other apps.
The lvdumpimg command can send a stream of netpbm images to a pipe (or sequential files), but it will only do that for a fixed count, and you can't control the camera in any other way until all the frames are saved. See discussion around http://chdk.setepontos.com/index.php?topic=6231.msg114468#msg114468 (http://chdk.setepontos.com/index.php?topic=6231.msg114468#msg114468)
It wouldn't be too hard to come up with a control mechanism that let you end the sequence from an external application. It might be OK if you just closed the pipe on the target, or you could use a control file.
The lvdump command is similar to lvdumpimg, except it saves raw protocol data to a single file. It doesn't currently support piping, but that wouldn't be too hard to add.
The GUI lets you display live view while controlling the camera, but it would probably be inconvenient to integrate with your application. You could probably modify the code to send each live view frame to some form of IPC.
Almost all of chdkptp except the low level communication and bulk data processing is done written in Lua. This includes the GUI, which uses IUP (http://www.tecgraf.puc-rio.br/iup/ (http://www.tecgraf.puc-rio.br/iup/)). It's intended to be customizable, if you can program in VB, you can probably learn Lua too.
If I was going to embed chdkptp in another application, I would probably write a new front end like the CLI or GUI, but with some IPC interface to talk to the application. Doing this in some generic way is on my TODO list, but so are a lot of other things...
-
I'm not really clear what you are trying to do. If you want to display the live view inside your application, you will probably need to do some hacking, chdkptp is primarily designed to be a standalone client, not something embedded in other apps.
I just want to use chdkptp like ffmpeg.
Thanks for the link. Not sure how to access live view piped images with VB. I tried to at least save them to my hard drive to access them that way, but the below code didn't work:
lvdumpimg -pipebm -count=3 -vp=tmp.ppm -bm='convert tmp.ppm - -resize 720x405! -layers merge C:\Users\Web\Pictures\liveview.png'
Has something changed? Until I figure out how to recieve piped images, saving them to my hard drive for retrieval also works, preferably without my camera's UI overlay.
-
Thanks for the link. Not sure how to access live view piped images with VB. I tried to at least save them to my hard drive to access them that way, but the below code didn't work:
lvdumpimg -pipebm -count=3 -vp=tmp.ppm -bm='convert tmp.ppm - -resize 640x480! -layers merge C:\Users\Web\Pictures\liveview.png'
Has something changed? Until I figure out how to recieve piped images, saving them to my hard drive for retrieval also works, preferably without my camera's UI overlay.
If you can describe how it didn't work, that would be helpful.
The most current syntax should be described in the help and USAGE.TXT.
One thing to watch out for is that there is an unrelated windows command called convert. The above command expects the imagemagick convert command. You can specify the absolute path, or copy the imagemagick convert.exe to something like imconvert.exe
Your example works for me if I make sure it gets the right convert command.
The pipe functionality expects to start the executable being piped to, it can't send directly to an already running executable. On unix you could probably send to a named pipe using regular file syntax, but windows doesn't support this. You could write a shim program that receives data from stdin and sends it to a windows named pipe, socket or whatever.
-
imagemagick?
Thought chdkptp converted netpbm images to pngs, or jpegs when I saw that command. So I also need imagemagick to convert for Windows? No wonder it didn't work.
-
Thought chdkptp converted netpbm images to pngs, or jpegs when I saw that command. So I also need imagemagick to convert for Windows? No wonder it didn't work.
chdkptp outputs ppm (http://netpbm.sourceforge.net/doc/ppm.html) and pam (http://netpbm.sourceforge.net/doc/ppm.html) for the live view and UI overlay, respectively. The command you quoted converts this to a single png, by outputting the the viewport to a file (-vp=tmp.ppm) and then piping the the bitmap data to convert (-pipebm -bm=...) which scales, merges and corrects the aspect ratio of the results.
If you want to work directly with the ppm and pam files (which are incredibly simple formats (http://netpbm.sourceforge.net/doc/#formats)) you can just use -vp=foo.ppm -bm=foo.pam, without involving imagemagick. You will have to take care of alpha blending, scaling and aspect ratio correction yourself in that case.
Note if you don't care about showing the camera OSD, you can leave the bitmap out entirely.
-
reyalp, gonna go with your shim idea, using the Magick.NET dll. I should have a working test project within' a couple of days, but not with onion skinning. That will come a little later. The only thing I need to figure out is the chdkptp commands for zooming. Gonna control it with the mouse wheel.
The code will be posted here once it's ready.
-
The only thing I need to figure out is the chdkptp commands for zooming.
There are no specific CLI commands for zooming, this is done by sending lua script with the = or . commands. Essentially any CHDK scripting function can be used this way http://chdk.wikia.com/wiki/CHDK_Scripting_Cross_Reference_Page (http://chdk.wikia.com/wiki/CHDK_Scripting_Cross_Reference_Page)
There are two ways to control zoom in CHDK script
1) The set_zoom functions: http://chdk.wikia.com/wiki/CHDK_scripting#set_zoom_.2F_set_zoom_rel_.2F_get_zoom_.2F_set_zoom_speed (http://chdk.wikia.com/wiki/CHDK_scripting#set_zoom_.2F_set_zoom_rel_.2F_get_zoom_.2F_set_zoom_speed)
These let you set a specific zoom step. However, on some cameras it may cause problems like incorrect distortion correction on jpegs, or crashes.
2) Simulated key presses using press/release, click or post_logical_event functions. These should work on every camera, but you may have trouble getting the exact zoom position you want, especially if your camera has a lot of steps. It may also be slow if you use a lot of clicks.
-
reyalp, first I want to thank you for all your help, but I think I discovered a bug with chdkptp. A command that works without problems via the command prompt window, lvdumpimg -count=1 -vp=foo.ppm -bm=foo.pam, doesn't work if the same command is sent from my app:
proc.StandardInput.WriteLine("lvdumpimg -count=1 -vp=foo.ppm -bm=foo.pam")
At first I thought the command wasn't being read because it was sent right after the "rec" command from a timer, but delaying the command with a stopwatch do until loop didn't solve the problem. I then moved the command to a button to test it from there, discovering that it doesn't work at all if it's sent from my app.
Private Sub Convert_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
proc.StartInfo.FileName = "C:\Users\Web\Desktop\chdkptp\chdkptp.exe"
proc.StartInfo.Arguments = String.Format(" -i -c ")
proc.StartInfo.UseShellExecute = False
proc.StartInfo.WindowStyle = ProcessWindowStyle.Hidden
proc.StartInfo.RedirectStandardInput = True
proc.StartInfo.RedirectStandardOutput = True
proc.StartInfo.CreateNoWindow = True
proc.Start()
proc.StandardInput.WriteLine("rec")
End Sub
Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
proc.StandardInput.WriteLine("lvdumpimg -count=1 -vp=foo.ppm -bm=foo.pam")
End SubMaking a connection to my camera, setting to record, and sending lua commands for zooming via my app to chdkptp works perfectly. Am I missing something in order to send the lvdumping command from my app, or is this a bug?
-
Making a connection to my camera, setting to record, and sending lua commands for zooming via my app to chdkptp works perfectly. Am I missing something in order to send the lvdumping command from my app, or is this a bug?
What exactly happens when it "doesn't work"? Does it just hang? Does it produce any output? Can you send more commands after you send the lvdumpimg command?
You can see in the chdkptp source for yourself that all input for CLI commands is handled the same way (see cli.lua cli:run) As far as the input handling is concerned, there is no difference between "rec" and "lvdumpimg". It just reads text terminated by a newline, using standard Lua IO (or GNU readline if you've compiled chkdptp with readline support, but that defaults to off under windows)
This doesn't mean there isn't a bug, but it probably isn't specific to lvdumpimg. I would expect it has something to do with piping from VB, but I know very little about that.
The obvious difference is that the lvdumpimg command is longer than the other ones you are sending.
One thing you could try is sending increasingly long commands and see if it stops at some point.
e.g.
proc.StandardInput.WriteLine("exec print('a')")
proc.StandardInput.WriteLine("exec print('aaaa')")
...
The prints will cause chdkptp to print on standard output if the command works.
You can also add debugging prints to various points in the chdkptp code: Does it reach cli:execute? Does it reach the lvdumpimg command?
If vb does any kind of output buffering when you use proc.StandardInput.WriteLine that would be an obvious thing to check.
edit:
Another possibility is if you aren't reading the standard output from chdkptp, it will could block once some buffer fills up. Again, I have no idea how this works specifically with VB.
-
chdkptp doesn't hang. I can still call commands successfully after the failed lvdumping.
Dim proc As New Process
Dim sr As StreamReader
Private Sub Convert_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
proc.StartInfo.FileName = "C:\Users\Web\Desktop\chdkptp\chdkptp"
proc.StartInfo.Arguments = String.Format("-i -c")
proc.StartInfo.UseShellExecute = False
proc.StartInfo.WindowStyle = ProcessWindowStyle.Hidden
proc.StartInfo.RedirectStandardInput = True
proc.StartInfo.RedirectStandardOutput = True
proc.StartInfo.CreateNoWindow = True
proc.Start()
proc.StandardInput.WriteLine("rec")
System.Threading.Thread.Sleep(3500)
proc.StandardInput.WriteLine("lua set_zoom(25)")
End Sub
Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
proc.StandardInput.WriteLine("lvdumpimg -count=1 -vp=foo.ppm -bm=foo.pam")
System.Threading.Thread.Sleep(3500)
proc.StandardInput.WriteLine("lua set_zoom(100)")
End Sub
The standard output doesn't show anything. Probably a mistake on my part.
Gonna have to wait on testing lengths of commands. My camera's battery is dead!
-
chdkptp doesn't hang. I can still call commands successfully after the failed lvdumping.
lvdumpimg should produce some kind of output, or an error message. Error messages might go to stderr rather than stdout.
For testing, you could presumably redirect chdkptp's stdout and stderr to files when you start it.
I guess ProcessWindowStyle.Hidden means the cmd window is hidden? If so, why not try starting without that, and don't redirect chdkptp stdout. Then you should be able to see what's happening in the resulting cmd window.
-
reyalp, your commands work perfectly! I was looking in the wrong place for the pam and ppm images. Forgot that it defaults to my project's bin folder. I was looking for them under my Window's profile's directory instead. Stupid me! ::)
The standard output probably only works within a function. I was calling it within a normal sub, to where I got nothing or it would crash my app. Displaying the chdkptp shell window, no commands or errors displayed. Just a blinking cursor.
The only thing now is to figure out how to create a shim app to handle piped images. For testing purposes, my current app loads ppm and pam images to the Magick.NET dll for processing after chdkptp saves them to my projects folder. It's slow, but works.
-
If this would be better placed on the wiki (and deleted here) please advise
For the record.
After using chdkptp successfully for quite a while with cameras either connected directly (win7 laptop) or via a 7 port hub I connected using a new 13 port hub today.
Thereafter, chdkptp gui displayed no connection candidates. Following the wiki usage notes here http://chdk.wikia.com/wiki/PTP_Extension (http://chdk.wikia.com/wiki/PTP_Extension) I disabled WIA by:
- go to Pearl button (Start) and click on the Search programs and files
- Type services.msc and press Enter
- locate Windows Image Acquisition (WIA) observe the current status and open to make changes.
- From General tab you can Start/Stop and change the Windows Image Acquisition (WIA)
chdkptp operation restored :)
ref http://computerstepbystep.com/windows_image_acquisition_%28wia%29_service.html (http://computerstepbystep.com/windows_image_acquisition_%28wia%29_service.html)
-
If this would be better placed on the wiki (and deleted here) please advise
For the record.
After using chdkptp successfully for quite a while with cameras either connected directly (win7 laptop) or via a 7 port hub I connected using a new 13 port hub today.
Thanks, useful note.
It's not clear to me why changing hubs would affect the need to disable WIA. Using the INF drivers on Win7 x64, I have never needed to disable WIA, the cameras associated with the INF driver appear to be ignored by standard windows software. For old (~ digic II era that don't return a serial number) cameras the INF driver appears to only affect specific physical ports.
I'm not sure anything needs to be added to the wiki unless the specifics of when WIA needs to be disabled can be clarified.
-
Hi everybody,
I've recently installed CHDK again on my A610 after a long time and came across new features like your remote control/live view program.
After installing the necessary USB driver, when I hit the "connect" button in CHDK PTP, it says: "Error: Operation not supported".
Does this mean that my A610 is incompatible with remote shooting/live view, or did I just do something wrong?
-
Hi everybody,
I've recently installed CHDK again on my A610 after a long time and came across new features like your remote control/live view program.
After installing the necessary USB driver, when I hit the "connect" button in CHDK PTP, it says: "Error: Operation not supported".
Does this mean that my A610 is incompatible with remote shooting/live view, or did I just do something wrong?
This would not be be caused by incomplete live view support.
Operation not supported sounds like CHDK isn't actually running. Did you set up autoboot and verify the CHDK splash screen shows when you turn on the camera?
It could also happen if you were trying to connect to the wrong device, but this should be unlikely if you are using windows, since only libusb devices would be available.
-
Oh you're right... I did load it manually and didn't know that this would be a problem (but it makes sense if you think about it). After making the card bootable it works like a charm on my good old A610.
Thank you very much!
-
It's a lot of time that didn't use chdk...I don't know why, but today I have re-installed it on my old Canon A550 :)
I have found your great app, but my Powershot doesn't switch in record mode.
-
I have found your great app, but my Powershot doesn't switch in record mode.
How did you try to switch, using chdkptp "rec" in the CLI or "rec" button in the GUI, or using the physical controls on the camera? Only the chdkptp commands are expected to work.
If the chdkptp commands don't work:
1) What operating system are you using?
2) Does the physical camera screen go black
On linux, it's quite common for interactions with the standard software to prevent the rec command from working. This can also happen on windows if you used the filter driver instead of the INF driver.
If it's none of these things, there may be a problem with the port.
-
Hi reyalp,
I have tried to switch using the *rec* button on the gui and typing *rec* on execute input field, but I get:
ERROR: switch failed
I tried with Linux: 3.19.2-1-ARCH #1 SMP PREEMPT Wed Mar 18 16:21:02 CET 2015 x86_64 GNU/Linux
..and also under Windows 7
with the same result :(
edit: the other stuff as *live*, files works good :)
-
I tried with Linux: 3.19.2-1-ARCH #1 SMP PREEMPT Wed Mar 18 16:21:02 CET 2015 x86_64 GNU/Linux
..and also under Windows 7
Under linux, it's quite likely that you will have problems with some other programs automatically accessing the camera on connect. There is some information in the "interactions with default software" section on https://www.assembla.com/spaces/chdkptp/wiki/Install (https://www.assembla.com/spaces/chdkptp/wiki/Install)
Again
2) Does the physical camera screen go black
This would happen when you plug in the camera. If it happens, then you almost certainly have the problem above.
In any case, this probably isn't your whole problem, because windows 7 generally doesn't have the same issue.
There is another problem some vxworks cams suffer from. Can you try the following in the chdkptp console
=set_levent_script_mode(1)
=set_levent_active(0x10a5,0)
=switch_mode_usb(1)
If this works, we can fix it in the CHDK code.
-
There is another problem some vxworks cams suffer from. Can you try the following in the chdkptp console
=set_levent_script_mode(1)
=set_levent_active(0x10a5,0)
=switch_mode_usb(1)
If this works, we can fix it in the CHDK code.
yeahh! Works like a charm!!
Great! :D
-
yeahh! Works like a charm!!
Thanks. I've checked in the fix for both 1.3 and 1.4. From autobuild 4110 and later, the 'rec' command should work.
-
thanks! I'll update my Canon.
Do you know if can we use our Canon like a webcam (with something like video4linux and your app)
-
thanks! I'll update my Canon.
One thing to check is whether you can switch back to play mode. It may crash or disconnect.
Do you know if can we use our Canon like a webcam (with something like video4linux and your app)
There currently isn't a good way to do this. I think it could be done on linux with some relatively straightforward "glue" code that writes the live view to a modified version of one of the video4linux loopback drivers, but no one has written it yet. There are also some programs (IIRC ffmpeg is one) that can capture what appears in a window and use it as a video source.
You can use the cli to pipe the live feed to streaming video, but it's pretty hacky. See the discussion around http://chdk.setepontos.com/index.php?topic=6231.msg115402#msg115402 (http://chdk.setepontos.com/index.php?topic=6231.msg115402#msg115402)
-
thanks! I'll update my Canon.
One thing to check is whether you can switch back to play mode. It may crash or disconnect.
FWIW, as mentioned on IRC yesterday in the middle of several other conversations, the A560 disconnects when switching back from shooting to playback mode.
-
Hi!
Is it possible to add in chdkptp something like "onion skin" for making stop motin movies?
I want to overlay the current live view on a previous frame.
Here's a photo :)
-
Hi!
Is it possible to add in chdkptp something like "onion skin" for making stop motin movies?
I want to overlay the current live view on a previous frame.
Here's a photo :)
Here's a quick hack that might help. Just replace the existing lua/gui_live.lua from chdkptp with the attached.
It adds a new sub-tab where the frame rate and debug tabs are called "onion"
The "grab" button makes a copy of whatever is currently displayed. The grabbed image is blended with the live display, with the amount controlled by the slider. All the way to the left shows only the live image, all the way to the right shows only the grabbed image.
Clear discards the grabbed image completely.
-
THANK YOU!!!
Wow, I can't belive :) :) :)
Now I can do almost professional stop motion moves!
Thank's a lot !!!
-
And the last one question :)
Can I do something like that?
-
Can I do something like that?
Try the attached version of gui.lua. You must replace the existing lua/gui.lua from chdkptp.
msl
-
Thanks guys! Now I'm completely happy :)
Where you take these lua?
-
Is it possible to add in chdkptp something like "onion skin" for making stop motin movies? I want to overlay the current live view on a previous frame.
For reference, I thought I'd attach a link that reyalp posted on IRC last night that explains how onion skinning is used.
http://www.stopmotionpro.com/index.php/12-animating-with-smp-eclipse-videos/55-onionskinning (http://www.stopmotionpro.com/index.php/12-animating-with-smp-eclipse-videos/55-onionskinning)
-
Thanks guys! Now I'm completely happy :)
If you want, it would be pretty easy to make the remote shoot buttons automatically "grab" before the shot.
Where you take these lua?
We wrote them.
If you complete a project using this, feel free to post about it in http://chdk.setepontos.com/index.php?board=20.0 (http://chdk.setepontos.com/index.php?board=20.0)
-
It would be perfect to make remote shoot buttons automatically "grab" before the shot :)
I've done one video using CHDK but I'll post it later cause it's not complete.
Thank you very much for helping :)
-
Updated lua files attached, just unzip in the lua directory.
There's a new checkbox "autograb". If it is checked, the previous overlay will be cleared and a new one grabbed each time you use one of the remote shoot buttons.
You can still grab or clear manually. If you do, the existing overlay is not cleared first.
-
Thank's! It works! But sometimes such a thing happens (photo).
But it is ok. You did a lot for me :)
-
Thank's! It works! But sometimes such a thing happens (photo).
I think the photo didn't get attached.
-
Sorry, I didn't atteched the photo
-
Sorry, I didn't atteched the photo
Thanks. It looks like sometimes the grab happens after the shot already started. Here's an updated version.
-
Cool! Work's great! How can you do this? I'm biologist, proggramming something unnown for me :)
-
Hi again!
I've got new problem. After windows replacement I can't do "jpg remote shoot" and "autograb" doesn't work. I instaled the same lib usb that I had before.
When I cliсk "jpg remote shoot" appears on the camera "Memory card error".
Thank's!
-
Hi again!
I've got new problem. After windows replacement I can't do "jpg remote shoot" and "autograb" doesn't work. I instaled the same lib usb that I had before.
When I cliсk "jpg remote shoot" appears on the camera "Memory card error".
Thank's!
Do other controls work?
Are you using the same version of windows as before?
Did you change the CHDK version on the camera?
Are you sure you are using the exact same chdkptp files as before?
In general, there shouldn't be any way reinstalling windows or the libusb driver would affect remote shoot without affecting other functions.
-
I used windows x64 in both cases, the same chdk, same version of chdkptp...Other controls works fine..
I think something wrong with libusb..
-
I think something wrong with libusb..
This is extremely unlikely. Remoteshoot uses libusb in exactly the same way as every other command.
Are there any error messages in the chdkptp console area?
edit:
After the error happens, are you still able to use other chdkptp commands?
-
No massage, but program starts lag and not respond
After error for some time I can't click any bottom
-
No massage, but program starts lag and not respond
After error for some time I can't click any bottom
So after you try to use 'jpeg remote shoot' the program freezes? The live view stops updating? Then after some time, it starts responding again?
You are sure there's no error message anywhere? Sometimes in the gui you need to scroll up to see the message.
You can use
set cli_verbose=2
set gui_verbose=2
before you start shooting to get more debugging output.
You can also try using the rs command directly instead of the button.
I don't really know what could cause this, and I don't have enough information to do any debugging. Obviously, something has changed, it could be Canon firmware settings, chdk settings on the camera, chdkptp code, or maybe something with the OS or drivers. You need to find out what it was. For libusb, the only difference I know is whether you use the filter driver or the INF driver. You should always use the INF driver.
The "memory card error" implies something went wrong in the camera side code. This might happen if connection failed in remote shoot, or chdkptp didn't request the data in the expected time.
-
After I try to use 'jpeg remote shoot' the program freezes and stop updating, but then I can't control camera.
It's hard to explane with my poor english :)
Ok, I'll try to do something, thank's!
-
Program shows that:
-
Program shows that:
The important one is "capture_get_data error I/O error"
That means communication failed somehow in the remote shoot process.
If you use
set cli_verbose=2
before trying to shoot, it might provide more information about exactly which step failed.
-
Now there is something new :)
-
Now there is something new :)
This shows the first request for the jpeg data fails.
I really have no idea what would cause this to stop working.
Can you shoot with 'shoot' in the console? How about 'rs' ?
-
Never mind, I'll try reinstall windows one more time :)
-
It work's again! :)
I just set on camera "reset all"
Sorry for the stupid question
-
It work's again! :)
I just set on camera "reset all"
Glad to hear you got it working again.
Could the "review" setting on the camera have been set? If the camera is waiting in review, I believe the remote capture will fail.
If you find some other setting that makes it failed, please let us know.
Sorry for the stupid question
Not a stupid question at all, just hard to help from a distance.
-
I suppose this error doesn't connect with CHDK. Something was wrong with camera settings, but I don't know what it could be. Anyway this error can be corrected by restoration to factory settings.
-
I'm having problems running chdkptp with my A3200IS.
The 1.00C is running just fine but the 1.00A fails to initialize rsint. (error: init failed)
After looking at the code, I noticed that this error is thrown by:
if not init_usb_capture(opts.fformat,opts.lstart,opts.lcount) thenBut I'm not very familiar with lua or this level of programming so I'm not sure what to do with that. :\
Has anyone experienced this as well? Any suggestions on how this can be fixed?
Additional background information:
I'm trying to use TwoCamControl or Spreads for a DIY Book Scanner. One of the cameras (C) seems to work just fine, while the other one (A) continues to give errors.
-
I'm having problems running chdkptp with my A3200IS.
The 1.00C is running just fine but the 1.00A fails to initialize rsint. (error: init failed)
After looking at the code, I noticed that this error is thrown by:
if not init_usb_capture(opts.fformat,opts.lstart,opts.lcount) then
The two ports should work the same, but camera settings may be a factor. For example:
1) You requested raw, and raw doesn't work in the current capture mode (for example "low light" or "auto" on some cameras)
2) The canon firmware is set to continuous mode, but CHDK has known problems with remote capture and continuous mode on that camera. I think this applies to to a3200
If neither of those is it, make sure you are using the same CHDK version on each camera.
-
Here's a quick hack that might help. Just replace the existing lua/gui_live.lua from chdkptp with the attached.
It adds a new sub-tab where the frame rate and debug tabs are called "onion"
The "grab" button makes a copy of whatever is currently displayed. The grabbed image is blended with the live display, with the amount controlled by the slider. All the way to the left shows only the live image, all the way to the right shows only the grabbed image.
Is this already in the latest version or do I have to do a manual patch?
Does the live view always blend with the previous grab or it's possible to specify an image?
I'm thinking of the (very popular) re-enact photos :-) In that case I want to blend the live view with an old photo.
-
Is this already in the latest version or do I have to do a manual patch?
It's a one-off hack, not included in chdkptp at the moment. I might include it at some point, but it seemed like something with very limited interest.
Does the live view always blend with the previous grab or it's possible to specify an image?
I'm thinking of the (very popular) re-enact photos :-) In that case I want to blend the live view with an old photo.
In the existing code, you cannot load an image from your PC. If the old images is on your camera as a jpeg, you could "grab" it in playback mode. As long as you turn off "autograb" you can take as many shots as you want after that.
-
Hi,
I'm trying to script liveview+remote shoot/capture (ie: shoot and somehow grab the result), but I have issues.
Regarding the message below:
I tried with Linux: 3.19.2-1-ARCH #1 SMP PREEMPT Wed Mar 18 16:21:02 CET 2015 x86_64 GNU/Linux
..and also under Windows 7
Under linux, it's quite likely that you will have problems with some other programs automatically accessing the camera on connect. There is some information in the "interactions with default software" section on https://www.assembla.com/spaces/chdkptp/wiki/Install (https://www.assembla.com/spaces/chdkptp/wiki/Install)
Again
2) Does the physical camera screen go black
This would happen when you plug in the camera. If it happens, then you almost certainly have the problem above.
In any case, this probably isn't your whole problem, because windows 7 generally doesn't have the same issue.
There is another problem some vxworks cams suffer from. Can you try the following in the chdkptp console
=set_levent_script_mode(1)
=set_levent_active(0x10a5,0)
=switch_mode_usb(1)
If this works, we can fix it in the CHDK code.
I'm having similar issues.
* The setup:
Ubuntu 14.04
Powershot SX260HS with CHDK 1.3
chdkptp version reports: chdkptp 0.5.0-alpha, host:2.6, cam:2.6
(I can give more details if necessary)
* The issue:
I'm trying to do remote shooting, but it is extremely unstable, and behaviour does not seem deterministic. I got it to work maybe 2 times on more than 50 tries.
I tried with:
chdkptp.sh -c -e'rec' -e'shoot'
chdkptp.sh -c -e'rec' -e'rs'
and also from Python, using chdkptp.py (version 0.1.2)
import chdkptp
camera = chdkptp.ChdkDevice(chdkptp.list_devices()[0])
camera.switch_mode('record')
camera.shoot()
The error messages vary, "I/O error, attempted to close a non-present device 002:017", and maybe another one.
The camera seems to crash (it disappears from USB, 'lsusb' does not show it anymore)
With python, the error messages are usually "767" (similar to these ones https://github.com/DIYBookScanner/spreads/issues/166 (https://github.com/DIYBookScanner/spreads/issues/166) or 173)
I tried the instructions above (set_levent... etc.) but when doing:
=switch_mode_usb(1)
I get:
ERROR: :80: attempt to call global 'switch_usb_mode' (a nil value)
user code: 1
I've checked the udev rules and the should be nothing interfering with the camera, however, the camera screen does turns black when I plug it.
Nevertheless, I am able to do live view and that works fine, it is just the remote capture/shooting that fails.
While there are a few examples on live view on chdkptp's USAGE.txt I have not found much information about remote shooting.
Also, according to this:
https://github.com/c10ud/CHDK/blob/master/platform/sx260hs/platform_camera.h (https://github.com/c10ud/CHDK/blob/master/platform/sx260hs/platform_camera.h)
and an earlier message on this thread, the sx260hs should support remote shooting.
Does anybody knows what am I missing? Is remote shooting unstable?
Thanks!
-
I've checked the udev rules and the should be nothing interfering with the camera, however, the camera screen does turns black when I plug it.
Disabling the gphoto2 gvfs (https://wiki.gnome.org/Projects/gvfs) volume monitor did the trick for me on opensuse (I have revoked file permissions from /usr/share/gvfs/remote-volume-monitors/gphoto2.monitor).
-
I'm trying to script liveview+remote shoot/capture (ie: shoot and somehow grab the result), but I have issues.
By "grab" do you just mean save the file, or onion skinning like KNEi?
I'm having similar issues.
I don't think your issue is very similar to the post you quoted, but there are some question in my reply that would help be sure.
Your camera is not a vxworks camera, so that stuff doesn't apply.
* The setup:
Ubuntu 14.04
Powershot SX260HS with CHDK 1.3
chdkptp version reports: chdkptp 0.5.0-alpha, host:2.6, cam:2.6
(I can give more details if necessary)
Since no svn revision is shown, I assume this is self built? If so, including the actual svn revision used might be helpful. Also whether you built with Lua 5.1 or 5.2 (ver -l will say).
I'm trying to do remote shooting, but it is extremely unstable, and behaviour does not seem deterministic. I got it to work maybe 2 times on more than 50 tries.
I tried with:
chdkptp.sh -c -e'rec' -e'shoot'
chdkptp.sh -c -e'rec' -e'rs'
I would suggest using chdkptp interactively until you get a sequence of steps that works, and then try to turn it into a command line.
My first guess would be that there needs to be some additional delay between switching to rec and shooting. You can insert a 100 millisecond delay in chdkptp with -e'exec sys.sleep(100)'. rec tries to wait for the mode switch to complete, but it wouldn't be surprising if a small additional delay was needed.
The fact that you can connect at all and sometimes can shoot probably means you are *not* suffering from the gvfs related problems.
The error messages vary, "I/O error, attempted to close a non-present device 002:017", and maybe another one.
The "attempted to close..." just means the camera went away probably due to the crash. I/O error probably means the same thing.
I tried the instructions above (set_levent... etc.) but when doing:
=switch_mode_usb(1)
I get:
ERROR: :80: attempt to call global 'switch_usb_mode' (a nil value)
user code: 1
If that error message is a direct copy/paste, it appears there was a typo, the correct function name is switch_mode_usb not switch_usb_mode.
As noted above, the vxworks stuff does not apply to your cameras, so there's no need to try the post_levent etc.
Nevertheless, I am able to do live view and that works fine, it is just the remote capture/shooting that fails.
Does it only fail when you attempt to do it directly in the command line? Or does it fail if you launch the gui, switch to rec, and then use rs?
-
I've checked the udev rules and the should be nothing interfering with the camera, however, the camera screen does turns black when I plug it.
Disabling the gphoto2 gvfs (https://wiki.gnome.org/Projects/gvfs) volume monitor did the trick for me on opensuse (I have revoked file permissions from /usr/share/gvfs/remote-volume-monitors/gphoto2.monitor).
Thanks for the tip.
Actually I had done that (ie: chmod -x the file you mention) because I am also scripting PTP with gphoto2 to control a DSLR on the same computer.
I had also used gsettings as shown here:
https://github.com/markvdb/diybookscanner/issues/12
However, since you mentioned this, I investigated more and did found that gvfs was indeed launching every time I plugged the camera.
Since all the above solutions had not disabled it, I just removed /usr/share/gvfs/remote-volume-monitors/gphoto2.monitor
After that the screen of the SX260HS stopped turning black! yay!
Now I get past the remote shooting, but the camera crashes further down. I will make a new post with more details.
Thanks a lot!
-
I'm trying to script liveview+remote shoot/capture (ie: shoot and somehow grab the result), but I have issues.
By "grab" do you just mean save the file, or onion skinning like KNEi?
I mean save the file.
I guess I could do the onion skinning with some ImageMagick commands.
I'm having similar issues.
I don't think your issue is very similar to the post you quoted, but there are some question in my reply that would help be sure.
Your camera is not a vxworks camera, so that stuff doesn't apply.
In that case I'm sorry for creating confusion.
* The setup:
Ubuntu 14.04
Powershot SX260HS with CHDK 1.3
chdkptp version reports: chdkptp 0.5.0-alpha, host:2.6, cam:2.6
(I can give more details if necessary)
Since no svn revision is shown, I assume this is self built? If so, including the actual svn revision used might be helpful. Also whether you built with Lua 5.1 or 5.2 (ver -l will say).
Yes, I built it myself.
svn info reports:
Last Changed Author: reyalp
Last Changed Rev: 668
and ver -l reports Lua 5.2
I'm trying to do remote shooting, but it is extremely unstable, and behaviour does not seem deterministic. I got it to work maybe 2 times on more than 50 tries.
I tried with:
chdkptp.sh -c -e'rec' -e'shoot'
chdkptp.sh -c -e'rec' -e'rs'
I would suggest using chdkptp interactively until you get a sequence of steps that works, and then try to turn it into a command line.
Actually my goal is to use a python wrapper (chdkptp.py https://pypi.python.org/pypi/chdkptp.py/0.1.2 ) because in that case I don't need to save the live view images to disk nor spawn a process for each frame of the live view.
The live view part seems to be working just fine by the way (with the python wrapper or with chdkptp CLI).
My first guess would be that there needs to be some additional delay between switching to rec and shooting. You can insert a 100 millisecond delay in chdkptp with -e'exec sys.sleep(100)'. rec tries to wait for the mode switch to complete, but it wouldn't be surprising if a small additional delay was needed.
Thanks, I will try that as well.
The fact that you can connect at all and sometimes can shoot probably means you are *not* suffering from the gvfs related problems.
Actually, it seems that I did. I mean, gvfs was indeed launched every time I plugged the camera, so the measures I had taken to disable it had not worked.
After more drastic measures regarding gvfs I now see that the camera screen does not turns black when plugging it to the computer and the remote shooting is more consistent now. I have another issue though. See further below.
The error messages vary, "I/O error, attempted to close a non-present device 002:017", and maybe another one.
The "attempted to close..." just means the camera went away probably due to the crash. I/O error probably means the same thing.
I tried the instructions above (set_levent... etc.) but when doing:
=switch_mode_usb(1)
I get:
ERROR: :80: attempt to call global 'switch_usb_mode' (a nil value)
user code: 1
If that error message is a direct copy/paste, it appears there was a typo, the correct function name is switch_mode_usb not switch_usb_mode.
As noted above, the vxworks stuff does not apply to your cameras, so there's no need to try the post_levent etc.
Ok, I see. Thanks for the explanations.
By the way, if when plugging each and every camera the screen should not turn black for chdkptp to work, what do you think about writing that somewhere (maybe it is, though I did not see it) as a basic debug step?
Nevertheless, I am able to do live view and that works fine, it is just the remote capture/shooting that fails.
Does it only fail when you attempt to do it directly in the command line? Or does it fail if you launch the gui, switch to rec, and then use rs?
I did not build the GUI because it required more dependencies.
As I stated a bit earlier, after getting rid of gvfs I get more consistent behaviour.
However, the camera is still crashing, when changing to 'record' mode again. The led blinks periodically and chdkptp.sh -c -i reports:
open_camera_dev_usb: ptp_opensession failed 0x2ff
Device status OK
connected: Canon Powershot SX260 HS, max packet size 512
con> rec
ERROR: a script is already running
I need to remove the battery to fix the camera crash.
The sequence is the following:
1) connect
2) enter record mode
3) grab some live view images
4) shoot
5) enter playback mode (I do this to save power)
6) sleep for a while
7) go to 2)
Currently going back to 2) fails (ie: the python call never returns)
The steps above should be very similar to what chdkptp's GUI does, right? Or am I missing some obvious step?
One more question, do you guys suggest to disable all powersaving (ie: auto turn off or whatever) on the camera before attempting any of the above? Because sometimes the live view does not work properly (ie: it's not live) and it seems it is because the camera shuts down the sensor (chdkptp connection seems alive, and a physical half press will automatically resume live view)
Thanks a lot in advance!
-
I did not build the GUI because it required more dependencies.
As I stated a bit earlier, after getting rid of gvfs I get more consistent behaviour.
However, the camera is still crashing, when changing to 'record' mode again. The led blinks periodically and chdkptp.sh -c -i reports:
open_camera_dev_usb: ptp_opensession failed 0x2ff
Device status OK
connected: Canon Powershot SX260 HS, max packet size 512
con> rec
ERROR: a script is already running
I need to remove the battery to fix the camera crash.
The sequence is the following:
1) connect
2) enter record mode
3) grab some live view images
4) shoot
5) enter playback mode (I do this to save power)
6) sleep for a while
7) go to 2)
Currently going back to 2) fails (ie: the python call never returns)
The steps above should be very similar to what chdkptp's GUI does, right? Or am I missing some obvious step?
One more question, do you guys suggest to disable all powersaving (ie: auto turn off or whatever) on the camera before attempting any of the above? Because sometimes the live view does not work properly (ie: it's not live) and it seems it is because the camera shuts down the sensor (chdkptp connection seems alive, and a physical half press will automatically resume live view)
Thanks a lot in advance!
About the steps above, here is the commandline that can be used to reproduce it. Note that it works some times, so it maybe be a timing issue (even though I'm actually using sys.sleep() between steps)
./chdkptp.sh -c -e'rec' -e"lvdumpimg -vp='convert - -resize 640x480! chdkptp_preview.jpg' -pipevp -count=1" -e'exec sys.sleep(1000)' -e'rs .' -e'exec sys.sleep(1000)' -e'play' -e'exec sys.sleep(1000)' -e'rec' -e"lvdumpimg -vp='convert - -resize 640x480! chdkptp_preview.jpg' -pipevp -count=1" -e'exec sys.sleep(1000)' -e'rs .' -e'exec sys.sleep(1000)' -e'play' -e'exec sys.sleep(1000)'
Has anybody experienced such issues?
I also tried to see how the GUI does, but I'm not versed in Lua, so any help would be highly appreciated.
-
Actually I had done that (ie: chmod -x the file you mention)
For completeness: that file is not executable, I just removed its r attribute, so that I can restore this functionality when I need it.
However, the camera is still crashing, when changing to 'record' mode again. The led blinks periodically and chdkptp.sh -c -i reports:
open_camera_dev_usb: ptp_opensession failed 0x2ff
Device status OK
connected: Canon Powershot SX260 HS, max packet size 512
con> rec
ERROR: a script is already running
I need to remove the battery to fix the camera crash.
That's a known issue unfortunately, see http://chdk.wikia.com/wiki/User:Nafraf/RemoteShootIssues (http://chdk.wikia.com/wiki/User:Nafraf/RemoteShootIssues) . (This table doesn't yet list the sx260 as problematic, but it does list the sx240 which has identical firmware).
Theory is that the firmware expects the recently shot photos to be present on the card and gets confused because those files are missing.
There might be a solution (http://chdk.setepontos.com/index.php?topic=11481.msg114716#msg114716) to this, but not for the average user.
One more question, do you guys suggest to disable all powersaving (ie: auto turn off or whatever) on the camera before attempting any of the above? Because sometimes the live view does not work properly (ie: it's not live) and it seems it is because the camera shuts down the sensor (chdkptp connection seems alive, and a physical half press will automatically resume live view)
You can try either adjusting the Canon power saving settings, or use CHDK Settings -> Disable LCD Off [Always]. Or, you can wake up the cam with a keypress before you issue rs.
-
I guess I could do the onion skinning with some ImageMagick commands.
Sorry, not suggesting you should, just wanted to make sure because "grab" was used for a specific thing in that discussion.
Actually my goal is to use a python wrapper (chdkptp.py https://pypi.python.org/pypi/chdkptp.py/0.1.2 (https://pypi.python.org/pypi/chdkptp.py/0.1.2) ) because in that case I don't need to save the live view images to disk nor spawn a process for each frame of the live view.
That's fine, but I'd still suggest you verify that you can do each step in the chdkptp CLI.
By the way, if when plugging each and every camera the screen should not turn black for chdkptp to work, what do you think about writing that somewhere (maybe it is, though I did not see it) as a basic debug step?
I'm not sure what you are asking for. If the camera screen goes black, then 99% certain, some non CHDK software on your PC is accessing the camera. You need to make it stop. How you do that is dependent on your OS. If you are using linux, it probably involves udev, but the details are distro specific and udev documentation is so lacking that there is no way I can provide specific steps to debug it. This issue is mentioned, with links to some relevant forum threads in https://www.assembla.com/spaces/chdkptp/wiki/Install (https://www.assembla.com/spaces/chdkptp/wiki/Install)
I did not build the GUI because it required more dependencies.
OK, I assumed earlier from the "live view" references that you were using the GUI, but now I understand you are using lvdumpimg or similar. What I meant was, if you enter the commands individually instead of trying to run it all with -e commands. GUI or CLI is not relevant.
open_camera_dev_usb: ptp_opensession failed 0x2ff
Device status OK
connected: Canon Powershot SX260 HS, max packet size 512
con> rec
ERROR: a script is already running
I need to remove the battery to fix the camera crash.
If it says "a script is already running" it almost certainly means a script is running, I don't see any way this error could be generated if the camera has crashed. You could use killscript to kill the script, assuming you are using a vaguely recent version of CHDK.
The earlier "opensession failed" message suggests something was already connected to the camera. It could be different CHDK client (another instance of chdkptp or the python lib) or the gvfs stuff.
1) connect
2) enter record mode
3) grab some live view images
4) shoot
5) enter playback mode (I do this to save power)
6) sleep for a while
7) go to 2)
As srsa said, switching to playback after using remoteshoot is problematic on many cameras. However, this should result in an actual crash, not the "script is already running" error you posted above.
One more question, do you guys suggest to disable all powersaving (ie: auto turn off or whatever) on the camera before attempting any of the above? Because sometimes the live view does not work properly (ie: it's not live) and it seems it is because the camera shuts down the sensor (chdkptp connection seems alive, and a physical half press will automatically resume live view)
The simplest solution would be to set "Disable LCD Off" to "always" in the CHDK settings, which will prevent the screen from turning off, and also prevent the camera from eventually shutting off.
The camera shutting down the sensor when it turns the display off is expected, since it takes a lot of power.
-
Actually I had done that (ie: chmod -x the file you mention)
For completeness: that file is not executable, I just removed its r attribute, so that I can restore this functionality when I need it.
Ok thanks.
However, the camera is still crashing, when changing to 'record' mode again. The led blinks periodically and chdkptp.sh -c -i reports:
open_camera_dev_usb: ptp_opensession failed 0x2ff
Device status OK
connected: Canon Powershot SX260 HS, max packet size 512
con> rec
ERROR: a script is already running
I need to remove the battery to fix the camera crash.
That's a known issue unfortunately, see http://chdk.wikia.com/wiki/User:Nafraf/RemoteShootIssues (http://chdk.wikia.com/wiki/User:Nafraf/RemoteShootIssues) . (This table doesn't yet list the sx260 as problematic, but it does list the sx240 which has identical firmware).
Theory is that the firmware expects the recently shot photos to be present on the card and gets confused because those files are missing.
Ok, so if instead of 'remote shoot' I used 'shoot' would it work consistently?
Alternatively, if I did not went back to 'play', would it work consistently?
Because I see two solutions then:
1) use 'shoot' so that the file is saved on the camera and retrieve it later (or use a wifi sd card to get it automatically)
2) do not go back to 'play' (which I was doing to save battery), let the camera power down by itself (like it seems to do) and just issue a "press('half_shoot')" or something to wake it up before using it again.
Do you guys think those solutions are viable?
Do you know which one would use less battery?
There might be a solution (http://chdk.setepontos.com/index.php?topic=11481.msg114716#msg114716) to this, but not for the average user.
Indeed :(
One more question, do you guys suggest to disable all powersaving (ie: auto turn off or whatever) on the camera before attempting any of the above? Because sometimes the live view does not work properly (ie: it's not live) and it seems it is because the camera shuts down the sensor (chdkptp connection seems alive, and a physical half press will automatically resume live view)
You can try either adjusting the Canon power saving settings, or use CHDK Settings -> Disable LCD Off [Always]. Or, you can wake up the cam with a keypress before you issue rs.
By "keypress" you mean and automated script-generated keypress, right?
-
By the way, if when plugging each and every camera the screen should not turn black for chdkptp to work, what do you think about writing that somewhere (maybe it is, though I did not see it) as a basic debug step?
I'm not sure what you are asking for. If the camera screen goes black, then 99% certain, some non CHDK software on your PC is accessing the camera. You need to make it stop. How you do that is dependent on your OS. If you are using linux, it probably involves udev, but the details are distro specific and udev documentation is so lacking that there is no way I can provide specific steps to debug it. This issue is mentioned, with links to some relevant forum threads in https://www.assembla.com/spaces/chdkptp/wiki/Install (https://www.assembla.com/spaces/chdkptp/wiki/Install)
Thanks. I meant mentioning the "black screen" issue on chdkptp's wiki.
As you point out the "possible interference" is mentioned, just that the actual behaviour that shows that something is interfering (ie: "black screen") is not mentioned.
In a nutshell, if the wiki said "On Linux, default camera software may connect to the camera automatically. If the camera's screen turns black when connecting to a computer, then some software is active on the computer and will interfere with chdkptp." or something like that, it would be much clearer.
OK, I assumed earlier from the "live view" references that you were using the GUI, but now I understand you are using lvdumpimg or similar. What I meant was, if you enter the commands individually instead of trying to run it all with -e commands. GUI or CLI is not relevant.
Ok.
open_camera_dev_usb: ptp_opensession failed 0x2ff
Device status OK
connected: Canon Powershot SX260 HS, max packet size 512
con> rec
ERROR: a script is already running
I need to remove the battery to fix the camera crash.
If it says "a script is already running" it almost certainly means a script is running, I don't see any way this error could be generated if the camera has crashed. You could use killscript to kill the script, assuming you are using a vaguely recent version of CHDK.
The earlier "opensession failed" message suggests something was already connected to the camera. It could be different CHDK client (another instance of chdkptp or the python lib) or the gvfs stuff.
It is another instance of chdkptp, since I use it in scripting (or with the python wrapper), when it fails I cannot use the same session that is blocked.
1) connect
2) enter record mode
3) grab some live view images
4) shoot
5) enter playback mode (I do this to save power)
6) sleep for a while
7) go to 2)
As srsa said, switching to playback after using remoteshoot is problematic on many cameras. However, this should result in an actual crash, not the "script is already running" error you posted above.
Ok, about that, I just did more tests, in case it helps.
In interactive mode if I do:
1) rec
2) shoot
3) play
4) go to 1)
I can repeat the sequence many times. The lens retracts with every call to "play".
If I do:
1) rec
2) play
3) go to 1)
I can repeat the sequence many times. The lens retracts with every call to "play".
But if I do:
1) rec
2) wait until camera power off (display turns off)
3) play
the lens retracts but the screen stays black and the led will blink periodically.
Under those conditions, I can issue a 'reboot' command and the camera will restart, the connection is lost but a 'c' command will reconnect.
If I do:
1) rec
2) rs .
3) reboot
The lens does not retract, the led does not blink (it is turned off), but the camera is totally unresponsive, I need to take out the battery to make it work again.
One more question, do you guys suggest to disable all powersaving (ie: auto turn off or whatever) on the camera before attempting any of the above? Because sometimes the live view does not work properly (ie: it's not live) and it seems it is because the camera shuts down the sensor (chdkptp connection seems alive, and a physical half press will automatically resume live view)
The simplest solution would be to set "Disable LCD Off" to "always" in the CHDK settings, which will prevent the screen from turning off, and also prevent the camera from eventually shutting off.
The camera shutting down the sensor when it turns the display off is expected, since it takes a lot of power.
So the camera will eventually shut itself off completely? Because I'm trying to maximize run time by reducing power usage. Do you guys have any suggestions?
Thanks!
-
Thanks. I meant mentioning the "black screen" issue on chdkptp's wiki.
As you point out the "possible interference" is mentioned, just that the actual behaviour that shows that something is interfering (ie: "black screen") is not mentioned.
Good point. I've adjusted the wiki.
It is another instance of chdkptp, since I use it in scripting (or with the python wrapper), when it fails I cannot use the same session that is blocked.
In that case, killscript should take care of whatever script is running, although depending why the other client hung, there may be other problems. Debugging the hang would probably be better than relying on killscript.
Note that the PTP implementation on these cameras (in the Canon firmware as well as CHDK) can only handle one session at a time.
Ok, about that, I just did more tests, in case it helps.
In interactive mode if I do:
1) rec
2) shoot
3) play
4) go to 1)
I can repeat the sequence many times. The lens retracts with every call to "play".
If I do:
1) rec
2) play
3) go to 1)
I can repeat the sequence many times. The lens retracts with every call to "play".
But if I do:
1) rec
2) wait until camera power off (display turns off)
3) play
the lens retracts but the screen stays black and the led will blink periodically.
Good debugging work. Then my suggestion is "don't do that" :P CHDK is a hack, and the PTP mode switching stuff is particularly hacky.
You could try sending a scripted key press wake the camera up before going to play. I'd suggest a small delay in between.
So the camera will eventually shut itself off completely? Because I'm trying to maximize run time by reducing power usage. Do you guys have any suggestions?
There are two or three stages in Canon power saving, which vary some depending on the model
1) Display and sensor turns off
2) Lens retracts, camera goes to play mode
3) Camera physically powers off.
There should be some settings to control them in the Canon menu, and they should be described in your camera manual. Again, these will vary some by model.
As far as saving power saving goes, this thread http://chdk.setepontos.com/index.php?topic=9049.0 (http://chdk.setepontos.com/index.php?topic=9049.0) and the older threads linked from it should give you an idea. Generally speaking, display + sensor off is pretty good, play is probably a bit better.
On some cameras, you can use a button press to trigger #1 without waiting for the delay. This may be the "disp" button (mostly on cameras with an optical viewfinder) or a "sleep" function that can be assigned in the canon firmware.
You can also use CHDK set_lcd_display() to turn off the display, but this does not turn off the sensor so will save less power than the sleep mode.
Because I see two solutions then:
1) use 'shoot' so that the file is saved on the camera and retrieve it later (or use a wifi sd card to get it automatically)
2) do not go back to 'play' (which I was doing to save battery), let the camera power down by itself (like it seems to do) and just issue a "press('half_shoot')" or something to wake it up before using it again.
Either of these should work, though note "power down" is really a sleep mode, not an actual power off.
You can use shoot -dl to shoot and download. shoot -dl -rm will shoot, download and delete, but will probably cause the same problems when you try to switch to play. You can probably delete the images after you switch to play with imrm.
-
In that case, killscript should take care of whatever script is running, although depending why the other client hung, there may be other problems. Debugging the hang would probably be better than relying on killscript.
Note that the PTP implementation on these cameras (in the Canon firmware as well as CHDK) can only handle one session at a time.
Ok, I see.
Good debugging work. Then my suggestion is "don't do that" :P CHDK is a hack, and the PTP mode switching stuff is particularly hacky.
Really? But if simulating key presses is ok, changing modes could be done that way and not need to be so hacky, right?
You could try sending a scripted key press wake the camera up before going to play. I'd suggest a small delay in between.
Thanks. Does CHDK or CHDKPTP have timing issues?
There are two or three stages in Canon power saving, which vary some depending on the model
1) Display and sensor turns off
2) Lens retracts, camera goes to play mode
3) Camera physically powers off.
There should be some settings to control them in the Canon menu, and they should be described in your camera manual. Again, these will vary some by model.
As far as saving power saving goes, this thread http://chdk.setepontos.com/index.php?topic=9049.0 (http://chdk.setepontos.com/index.php?topic=9049.0) and the older threads linked from it should give you an idea. Generally speaking, display + sensor off is pretty good, play is probably a bit better.
On some cameras, you can use a button press to trigger #1 without waiting for the delay. This may be the "disp" button (mostly on cameras with an optical viewfinder) or a "sleep" function that can be assigned in the canon firmware.
You can also use CHDK set_lcd_display() to turn off the display, but this does not turn off the sensor so will save less power than the sleep mode.
Ok, I see.
I think that letting the camera go to sleep is probably better than what I was trying to do.
I mean, when it goes to sleep it also turns off the display automatically, while if I put it in 'play', it would keep it on unless I also turn it off with the script.
Either of these should work, though note "power down" is really a sleep mode, not an actual power off.
You can use shoot -dl to shoot and download. shoot -dl -rm will shoot, download and delete, but will probably cause the same problems when you try to switch to play. You can probably delete the images after you switch to play with imrm.
Yes, I did some more tests and it seems that "shoot -dl -rm" does trigger the same crash when going back to 'play'.
However, thanks to the answers I got here I managed to do what I wanted.
I'm letting the camera go to sleep, then wake it up when necessary, keep it awake periodically (it can go to sleep even if we are making calls to live view), and so on. I gave up on going back to 'play'.
Thanks a lot!
-
Hello
I hope this is thr right way for my question.
If not, please let me know.
I use CHDK with a Timelapsscript on my G7 (the old one).
The Cam stands on a very high construction, so i can not easily get the SD-card.
With CHDK-PTP it is possible to get the pictures of the camera,
but not if the script is running.
I get an error: "a script is already running"
Is there a way to start the camera and the script
and to copy & delete files from the SD-card without touching the camera,
by using CHDK-PTP?
Greetings
Kolja
-
Really? But if simulating key presses is ok, changing modes could be done that way and not need to be so hacky, right?
When the camera is connected to USB, it ignores key presses that would switch modes. The hacks are needed to "unlock" it in USB mode.
Thanks. Does CHDK or CHDKPTP have timing issues?
Almost certainly, but that's not exactly the issue here. If you send a key press to wake up, that may trigger a bunch of actions in the camera firmware, and there's no guarantee they will all be done by the time the key press call returns. If you try to switch to play while it's still waking up, something might get confused. I don't know whether there is a problem in this specific case, just a general caution.
-
Is there a way to start the camera and the script
and to copy & delete files from the SD-card without touching the camera,
by using CHDK-PTP?
If you have wifi available you could use a wifi SD card like eye-fi or http://chdk.setepontos.com/index.php?topic=11262.0 (http://chdk.setepontos.com/index.php?topic=11262.0)
If you want to use chdkptp, you need to use a timelapse script that can cooperate with chdkptp.
There are two things you need to deal with
1) If USB isn't connected all the time, the camera may react when it is plugged/unplugged, for example by retracting the lens when you plug it in. Exactly what happens depends on the camera model.
2) Stopping and restarting the script when you want to download images. You can make the script detect the presence of USB, or check for a USB message to stop. You can restart it over PTP.
http://chdk.wikia.com/wiki/Ultimate_Intervalometer#Pause_when_USB_connected.3F (http://chdk.wikia.com/wiki/Ultimate_Intervalometer#Pause_when_USB_connected.3F)
Has an option to switch to play if USB is detected. I'm not sure if this will do exactly what you need.
-
Is there a way to start the camera and the script
and to copy & delete files from the SD-card without touching the camera,
by using CHDK-PTP?
Starting the camera is not possible.
Use the following procedure you can start and finish a script via chdkptp (This requires a permanent USB connection):
Copy the lremote script from here (https://www.assembla.com/code/rudi_space/subversion/nodes/HEAD/hostlua_npp/trunk/bin/lremote.lua) in the chdkptp dir. Start chdkptp in GUI mode and connect the camera.
Start a script with the following console command:lua require("lremote").exec("A/CHDK/SCRIPTS/test.lua", false)Stop the script with:killscriptAfter the command 'killscript' you can use the chdkptp file browser for your actions.
msl
-
I stumbled into an issue while testing fwt support on the a3400.
Both rs -cont and rs -quick tend to fail shooting the requested number of photos. The first shot always succeeds, the rest mostly does not. Shooting stops, the LCD begins showing regular live view. One can press the shutter manually to shoot the rest of the photos or just wait until the chdkptp side times out. There's no problem with the transferred pictures. It also seems that specifying a long enough interval (such as 5 seconds) lets the rs command finish correctly. All experiments were carried out with jpg only shots.
I have a feeling that the camera side script exits prematurely for some reason. I'm using up-to-date chdkptp.
Question: can somebody reproduce this on a relatively new camera (note: my a3200 is also affected)?
This issue is keeping me currently from committing the a3400 support code.
-
Question: can somebody reproduce this on a relatively new camera (note: my a3200 is also affected)?
Tested with sx170 and elph160(ixus160) sequences of 10 photos, test run without problems.
-
Both rs -cont and rs -quick tend to fail shooting the requested number of photos. The first shot always succeeds, the rest mostly does not. Shooting stops, the LCD begins showing regular live view.
FWIW, I was able to do rs cont=5 -jpeg successfully on D10, A540, IXUS140 and SX160.
I'm not completely sure, but it's possible something like what you describe might happen if the USB remote hook wasn't implemented correctly (edit: i.e. wasn't ever called in the shot). The script would be waiting for the hook to be ready, while the camera would just think it was done.
-
Thanks for the test results.
I'm not completely sure, but it's possible something like what you describe might happen if the USB remote hook wasn't implemented correctly (edit: i.e. wasn't ever called in the shot).
Thanks for the hint. The a3400 capt_seq code does mention that the nr and remote hooks are untested, and these hooks are also at a questionable (= conditionally executed) location in the a3200 code.
I think the script shooting hooks could be useful in a script for testing (http://chdk.wikia.com/wiki/Testing) hooking success under various shooting conditions...
-
Re-tested the cameras with reyalp's new script (http://chdk.setepontos.com/index.php?topic=12473.0). No failures...
... and then I realised that I had to use a card with plenty free space to run the script, because the cards I normally use in these cams are rather small.
Conclusion: rs -cont and rs -quick can stop prematurely when the JPEG size exceeds the available card space.
-
Re-tested the cameras with reyalp's new script (http://chdk.setepontos.com/index.php?topic=12473.0). No failures...
... and then I realised that I had to use a card with plenty free space to run the script, because the cards I normally use in these cams are rather small.
Conclusion: rs -cont and rs -quick can stop prematurely when the JPEG size exceeds the available card space.
You mean when 1 jpeg exceeds card space, or the camera thinks card space decreases by the jpeg size even though the image isn't actually saved?
On sx160, neither get_free_disk_space() nore the canon display of images remaining changes after shooting many shots with rs.
I'm not surprised if the shooting fails when the free space is close to the size of a single jpeg.
-
You mean when 1 jpeg exceeds card space, or the camera thinks card space decreases by the jpeg size even though the image isn't actually saved?
The former, fortunately.
-
Hi!
Is it possible to add in chdkptp something like "onion skin" for making stop motin movies?
I want to overlay the current live view on a previous frame.
Here's a photo :)
Here's a quick hack that might help. Just replace the existing lua/gui_live.lua from chdkptp with the attached.
It adds a new sub-tab where the frame rate and debug tabs are called "onion"
The "grab" button makes a copy of whatever is currently displayed. The grabbed image is blended with the live display, with the amount controlled by the slider. All the way to the left shows only the live image, all the way to the right shows only the grabbed image.
Clear discards the grabbed image completely.
Hi reyalp：
can we add a new button to run an appointed script ,like a button for
!for i,lcon in ipairs(mc.cams) do con=lcon cli:print_status(cli:execute('mdl A/DCIM /some/path -fmatch=%.JPG$')) end
so we just need click the button to get what we want
is that possible??
-
I used a A2500 for testing. Right now it takes up to 20 seconds to take 6 pictures. I know it depends on the settings, but this camera is just too slow. Processing seems to take ages. I look for a camera which can do faster continuous shots and / or "remoteshoot -quick". Which camera would you suggest?
-
I used a A2500 for testing. Right now it takes up to 20 seconds to take 6 pictures. I know it depends on the settings, but this camera is just too slow. Processing seems to take ages. I look for a camera which can do faster continuous shots and / or "remoteshoot -quick". Which camera would you suggest?
The Canon specs should give you a reasonable idea of the speed differences between cameras. Keep in mind that some cameras have problems with remoteshoot in continuous: http://chdk.wikia.com/wiki/User:Nafraf/RemoteShootIssues (http://chdk.wikia.com/wiki/User:Nafraf/RemoteShootIssues)
However, without more information about what you are doing, it's hard to say whether a faster camera will actually solve your problem. When you say "Processing seems to take ages" what specifically are you referring to?
-
Hi,
Trying this program but it's only half working. win8.1 x64, connected cam with chdk already loaded in Play mode, used Zadig, installed libusb 1.26, ran chdkptp, clicked connect, pressing buttons causes the lcd to "blink" but doesn't execute button presses. The files section works and I can upload files. The live view doesn't work. Cam has chdk 1.3, sd1200.
Wanted to use this for faster script testing. Cam buttons don't work while connected.
ptpcam gui works fine, no live view though
ps pressed REC then click Viewfinder and it works.
The INSTALL.TXT is missing in the latest download, could you write up a simple step-by-step to get it working like I just did? ie get zadig, activate chdk with load firmware,plugin camera, options show all devices, select cannon digital camera, select libusb, click install, run chdkptp, click connect, click REC, click Liveview.
-
Cam has chdk 1.3, sd1200.
It might be helpful to know what revision of CHDK 1.3.0 you have? You can get that from the Show Build Info menu item in the CHDK Miscellaneous menu.
-
4272
-
Hi,
Trying this program but it's only half working. win8.1 x64, connected cam with chdk already loaded in Play mode, used Zadig, installed libusb 1.26, ran chdkptp, clicked connect, pressing buttons causes the lcd to "blink" but doesn't execute button presses. The files section works and I can upload files. The live view doesn't work. Cam has chdk 1.3, sd1200.
It is normal for the camera to ignore key presses when in playback mode with USB connected. On many cameras you can send
=post_levent_to_ui(4484)
in the console to unlock the keys in playback mode. I believe PTPCamGui does this automatically.
When you say the live view "doesn't work", what specifically does it do?
Do you have any images on the camera? Is there a video selected in the camera playback screen?
What does the physical screen on the camera show?
ps pressed REC then click Viewfinder and it works.
Do you mean the viewfinder works, or everything works, or...?
The INSTALL.TXT is missing in the latest download, could you write up a simple step-by-step to get it working like I just did? ie get zadig, activate chdk with load firmware,plugin camera, options show all devices, select cannon digital camera, select libusb, click install, run chdkptp, click connect, click REC, click Liveview.
I can't, because I have not set it up on windows later than Win 7. If someone else can provide clear instructions, I would be happy to included them.
The contents of INSTALL.TXT are approximately https://www.assembla.com/spaces/chdkptp/wiki/Install (https://www.assembla.com/spaces/chdkptp/wiki/Install)
-
reyalp
Can you add support for Digic6 cameras that have 16 bit/pixel overlays ?
-
reyalp
Can you add support for Digic6 cameras that have 16 bit/pixel overlays ?
I don't see why not, but someone with one of the cameras will have to work on the camera side and at least provide sample data. This will likely require a live view protocol update. I suspect this is a CHDK 1.5 feature.
-
This is my sample data.
viewport: 736 * 480 * 16 bit/pixel
bitmap: 736 * 480 * 16 bit/pixel, but in camera RAM it is 8 bit.
I propose to add one more palette_type (#4 )
-
@Ant
Since you did not have to change the display routines, your cam very likely has the same kind of overlay buffers as mine.
The usable ones are:
- viewport: resolution may depend on output device (didn't check yet), there are buffers with at least 2 variants of YUV. One of them seems to be the same as the 16bpp variant found in earlier cams. Y411 (12bpp) format is not available.
- overlay: resolution depends on output device, 16bit YUV (UYVY, U and V component values are shifted by 0x80)
- overlay opacity (I called this "stencil" buffer): 8bpp, same resolution as the overlay buffer
Palette is not needed as all buffers are YUV, but a lot more data will have to be transferred for a "full experience" (2 YUV buffers + the opacity buffer). Perhaps we should consider lowering the frame rate for some of them (i.e. don't transfer the overlays every time).
-
I already did some changes in live_view.c and lib.c (screen buffer resolution and vp_size)
Stencil buffer in RAM dump is 8bpp, but in chdkptp it is 16bit. Why?
-
Stencil buffer in RAM dump is 8bpp, but in chdkptp it is 16bit. Why?
CHDKPTP can only handle 2 kinds of buffers (plus the palette which we don't need) at the moment. The display data appearing on your attached picture does not seem to include the stencil data as both buffers are obviously 16 bpp.
I'd also recommend using the newer hexplorer release (sent you a link a few days ago) since that supports the new YUV variants found in DIGIC 6 cameras.
-
I'd also recommend using the newer hexplorer release
Ok, it is not stencil data (lower frame) , but now colours are the same as on camera display
-
After replacement in live_view.c
//data->send_data(data->handle,vid_get_bitmap_active_buffer(),bm_size,0,0,0,0);
data->send_data(data->handle,vid_get_bitmap_active_stencil(),bm_size,0,0,0,0);I got:
(https://chdk.setepontos.com/proxy.php?request=http%3A%2F%2Fchdk.setepontos.com%2Findex.php%3Faction%3Ddlattach%3Btopic%3D6231.0%3Battach%3D12633%3Bimage&hash=6f68fefa2e14ce479d307281e3704370)
-
After replacement in live_view.c
Have you modified the chdkptp code at all? It will need quite significant changes to handle this.
If you can upload a sample memory dump of a viewport, overlay and stencil, along with the dimension and format, I may be able to help (but not till the end of the week, at least)
To support this properly, I think we need:
* new lv_fb_type for stencil and the new YUV format(s)
* new TFR flag for "stencil" (I suspect this is an alpha channel, not it actually stencil (https://www.opengl.org/wiki/Stencil_Test)?). If you only want the UI, you probably don't need it.
* add stencil buffer offset lv_fb_desc. I guess we could overload palette for this (new type, size is size of the buffer, fb_desc stuffed at the start) but this seems like it might be confusing. Would be OK for a quick hack testing though.
Perhaps we should consider lowering the frame rate for some of them (i.e. don't transfer the overlays every time).
Since the TFR flags are set on each lv update call, it would be pretty easy to make chdkptp only ask for the UI overlay every Nth frame.
-
If you can upload a sample memory dump of a viewport, overlay and stencil, along with the dimension and format, I may be able to help (but not till the end of the week, at least)
Did you read all my previous messages?
I just want to get correct rendering of viewport and bitmap(not stencil) data provided at http://chdk.setepontos.com/index.php?topic=6231.msg125026#msg125026 (http://chdk.setepontos.com/index.php?topic=6231.msg125026#msg125026)
as it shown here:
(https://chdk.setepontos.com/proxy.php?request=http%3A%2F%2Fchdk.setepontos.com%2Findex.php%3Faction%3Ddlattach%3Btopic%3D6231.0%3Battach%3D12631%3Bimage&hash=d4ef3880f6736c52ac4a12e9ec87870a)
(I suspect this is an alpha channel, not it actually stencil?)
This is buffer, that now used for correctly drawing CHDK GUI.
To support this properly, I think we need:
* new lv_fb_type for stencil and the new YUV format(s)
* new TFR flag for "stencil" (I suspect this is an alpha channel, not it actually stencil?). If you only want the UI, you probably don't need it.
I don't need stencil. New viewport and bitmap buffer format (UYVY 16 bit) can be detected by palette size(0 or -1) or type ( 4 )
-
(I suspect this is an alpha channel, not it actually stencil (https://www.opengl.org/wiki/Stencil_Test)?).
It is alpha channel or opacity. At the time I named this buffer, I thought the firmware was using OpenGL. As I found out later, the CPU core CHDK runs on doesn't have access to OpenGL, there is a separate CPU core (with its own firmware) for that.
I just want to get correct rendering of viewport and bitmap(not stencil) data
If this can't wait until next week, you'll have to start hacking the CHDKPTP source too.
I don't need stencil. New viewport and bitmap buffer format (UYVY 16 bit) can be detected by palette size(0 or -1) or type ( 4 )
It might be possible to skip rendering of overlay pixels if their value corresponds to the background color (0x80, 0x00, 0x80, 0x00 for two pixels on my cam). This won't be perfect as the Canon graphics have transparent parts.
-
Did you read all my previous messages?
Yes, but maybe I missed something. An lvdump is a protocol dump, but since the protocol doesn't actually support your camera and you've made unspecified changes to the camera side (?), it's not clear what it contains.
I don't need stencil. New viewport and bitmap buffer format (UYVY 16 bit) can be detected by palette size(0 or -1) or type ( 4 )
That's fine, but my goal is not just make a one-off hack for your immediate need. It's clear that full support needs the alpha channel.
edit:
To be clear, I do appreciate you bringing thus up and working on it. Good stuff :D
-
It might be possible to skip rendering of overlay pixels if their value corresponds to the background color (0x80, 0x00, 0x80, 0x00 for two pixels on my cam). This won't be perfect as the Canon graphics have transparent parts.
Hack for both sides attached. Can't guarantee it will work for ports other than mine. Alpha channel is guessed, see quote above.
-
Hack for both sides attached
Can you post windows32 binary?
-
Can you post windows32 binary?
Sorry, can't currently do that. Try following the readme (https://www.assembla.com/spaces/chdkptp/subversion/source/HEAD/trunk/README.TXT).
-
Here's windows binary (exe only, use lua files etc from previous build or svn)
-
Thank you. Now it is ok, excepting some transparency problems
-
Now it is ok, excepting some transparency problems
That was expected. Adding the "stencil" buffer to the mix is much less trivial (for the code and the protocol), so I decided not to attempt that.
@reyalp
If "stencil" is confusing, perhaps it's not too late to rename it to something that makes more sense.
-
@reyalp
If "stencil" is confusing, perhaps it's not too late to rename it to something that makes more sense.
I would prefer to avoid "stencil" since that means something quite different in most computer graphics contexts. I think alpha channel or alpha buffer would be appropriate. "opacity" or "transparency" could be OK too.
-
I would prefer to avoid "stencil" since that means something quite different in most computer graphics contexts. I think alpha channel or alpha buffer would be appropriate. "opacity" or "transparency" could be OK too.
Done in changeset 4276 (no link due to unavailable assembla web interface). I chose "opacity", because
- perhaps it's more obvious at first glimpse
- the buffer content is encoded as: 0 = fully transparent ... 255 = opaque pixel
-
FYI .. by changing LUA_SFX to 53 in include.mk, and installing the most recent IUP and CD packages, chdkptp seems to run quite well under Lua 5.3 (the default for my Fedora 23 install).
edit : I should have said that it both builds and runs quite well
-
I uploaded chdkptp snapshot release 690 to the files area https://www.assembla.com/spaces/chdkptp/documents (https://www.assembla.com/spaces/chdkptp/documents)
Details can be found in the changelog https://www.assembla.com/spaces/chdkptp/wiki/Changelog (https://www.assembla.com/spaces/chdkptp/wiki/Changelog)
As noted there, I changed the names and default locations of the startup files and user tab ini file. These are all stored in the directory specified by the environment variable CHDKPTP_HOME. On Linux, if CHDKPTP_HOME is not set, it defaults to $HOME/.chdkptp. On windows, it defaults to %HOME%/_chdkptp, or if that isn't set %USERPROFILE%/_chdkptp. *chdkptprc and *chdkptpguirc are renamed to user.chdkptp and user_gui.chdkptp respectively.
Other highlights
* chdkptp now returns an exit status of 1 if the main lua code encountered an error, or if the last cli command failed. This should make shell scripting simpler.
* Also for shell scripting, setting cli_error_exit=1 causes chdkptp to exit immediately if cli command from standard input or a -e command fails. Note that the startup connect option -c is not affected by this, but you can use -e"connect" if you want to error immediately on connection failure.
* rsint can now be controlled by an external program using the -pipe option. The code is also re-arranged to make it easier to use from script.
@waterwingz
Thanks for the note about Lua 5.3. Looking at http://www.lua.org/manual/5.3/manual.html#8 (http://www.lua.org/manual/5.3/manual.html#8) I'm not surprised it works, but I wouldn't rule out subtle issues cropping up. The latest snapshot build is still using Lua 5.2, and the same IUP and CD libraries as the previous snapshot.
-
Some nice additions...spent some of today updating (/simplifying) my r658 multicam.lua function additions to this - excellent.
Having previously briefly wondered if it could be, or is, possible to "clear" the cli of all previously displayed information (I think that may have been in connection with copying to windows clipboard) I thought now was as good a time as any to ask?.
-
Having previously briefly wondered if it could be, or is, possible to "clear" the cli of all previously displayed information
If you mean in the windows command prompt window, chdkptp doesn't have any way to do this, it just treats it as standard text output. There are presumably OS specific ways, but I see no reason to add special code to chdkptp to support this. I suppose you could do
!os.execute('cls')
You should be able to clear the GUI text output window with
!statustext.value=''
-
Ok - thanks.
Update, for the record - this works fine on Win7:
!os.execute('cls')
-
Seeming bug in r690 multicam.lua (repeated concatenated optional parameter sent):
As workaround (until fully tested), in function:
mc:cmd(cmd,opts)I changed this:
if opts.syncat then
sendcmd = string.format('%s %d',cmd,self:get_sync_tick(lcon,tstart,opts.syncat))
end
if opts.args then
sendcmd = sendcmd..' '..opts.args
endto this:
if opts.syncat and opts.args then
sendcmd = string.format('%s %d',cmd,self:get_sync_tick(lcon,tstart,opts.syncat))
sendcmd = sendcmd..' '..opts.args
end
if opts.args then
sendcmd = cmd..' '..opts.args
end
Edit: syncat only to be added...
-
Thanks. This should be fixed in r691.
-
thanks reyalp! love it, especially the live-view! do you think you can make the window larger?
i am using it with an ixus 160 ...
-
thanks reyalp! love it, especially the live-view! do you think you can make the window larger?
i am using it with an ixus 160 ...
Currently, the largest display is what you get when "viewfinder 1:1" is checked. This is essentially the native resolution of the camera live view (in luminance, color is significantly lower res). It would be possible to scale this up, but you wouldn't get more detail.
-
Issue: multicam.lua shoot_hook_sync - get_shooting does not go false in wait_timeout_write_status when raw enabled (set via CCHDK4.CFG), ok with jpg only.
Tested in Auto mode with a single camera (sx150is-100a-1.4.0-4297-full).
CLI listing ok with raw off (CCHDK4.CFG used attached as txt)
___> !mc=require('multicam')
___> !mc:connect({list='C:/CHDKPTP/listfile'})
+ 1:Canon PowerShot SX150 IS b=\\.\libusb0-0001--0x04a9-0x3234 d=bus-0 s=9A95243
8E0A647E9AC0179DDC30582D5
___> !mc:start()
___> !return mc:cmdwait('rec')
rec
=true,{
[1]={
status={
status=true,
cmd="rec",
},
done=true,
failed=false,
},
}
___> !return mc:cmdwait('set_mode',{args=1})
set_mode 1
=true,{
[1]={
status={
status=true,
cmd="set_mode",
},
done=true,
failed=false,
},
}
___> !return mc:init_sync()
1: send 5 diff 31 pred=54111 r=54120 delta=-8
1: send 3 diff 66 pred=54146 r=54150 delta=-3
1: send 8 diff 136 pred=54216 r=54220 delta=-3
1: send 3 diff 167 pred=54247 r=54250 delta=-2
1: send 3 diff 197 pred=54277 r=54280 delta=-2
1: send 3 diff 229 pred=54309 r=54310 delta=0
1: send 11 diff 254 pred=54334 r=54350 delta=-15
1: send 3 diff 299 pred=54379 r=54380 delta=0
1: send 9 diff 337 pred=54417 r=54430 delta=-12
1: send 8 diff 369 pred=54449 r=54460 delta=-10
1: ticks=10 min=-15 max=0 mean=-6.487800 sd=5.062612
1: sends=10 min=3 max=11 mean=5.600500 sd=2.939558
minimum sync delay 8
___> !return mc:cmdwait('preshoot')
preshoot
=true,{
[1]={
status={
status=true,
cmd="preshoot",
},
done=true,
failed=false,
},
}
___> !return mc:cmdwait('shoot_hook_sync',{syncat=100})
shoot_hook_sync [sync +100]
=true,{
[1]={
status={
status=true,
cmd="shoot_hook_sync",
},
done=true,
failed=false,
},
}
___>
CLI listing timeout with raw ON (increasing shoot_complete_timeout from 5000 to 7500 made no difference)
___> !mc=require('multicam')
___> !mc:connect({list='C:/CHDKPTP/listfile'})
+ 1:Canon PowerShot SX150 IS b=\\.\libusb0-0001--0x04a9-0x3234 d=bus-0 s=9A95243
8E0A647E9AC0179DDC30582D5
___> !mc:start()
___> !return mc:cmdwait('rec')
rec
=true,{
[1]={
status={
cmd="rec",
status=true,
},
done=true,
failed=false,
},
}
___> !return mc:cmdwait('set_mode',{args=1})
set_mode 1
=true,{
[1]={
status={
cmd="set_mode",
status=true,
},
done=true,
failed=false,
},
}
___> !return mc:init_sync()
1: send 3 diff 38 pred=117508 r=117510 delta=-1
1: send 4 diff 131 pred=117601 r=117610 delta=-8
1: send 3 diff 199 pred=117669 r=117670 delta=0
1: send 36 diff 237 pred=117707 r=117740 delta=-32
1: send 39 diff 301 pred=117771 r=117810 delta=-38
1: send 34 diff 435 pred=117905 r=117940 delta=-34
1: send 4 diff 536 pred=118006 r=118010 delta=-3
1: send 67 diff 572 pred=118042 r=118110 delta=-67
1: send 31 diff 669 pred=118139 r=118170 delta=-30
1: send 8 diff 739 pred=118209 r=118220 delta=-10
1: ticks=10 min=-67 max=0 mean=-23.277800 sd=20.523779
1: sends=10 min=3 max=67 mean=22.901500 sd=20.720543
minimum sync delay 43
___> !return mc:cmdwait('preshoot')
preshoot
=true,{
[1]={
status={
cmd="preshoot",
status=true,
},
done=true,
failed=false,
},
}
___> !return mc:cmdwait('shoot_hook_sync',{syncat=100})
shoot_hook_sync [sync +100]
=true,{
[1]={
status={
cmd="shoot_hook_sync",
msg="get_shooting timeout",
status=false,
},
done=true,
failed=false,
},
}
___>
Should raw setting make any difference?
Edit.
loosely related follow-up...I had originally used
savecon=con for i,lcon in ipairs(mc.cams) do con=lcon cli:print_status(cli:execute('u -nolua B.Slave_GUI/For_Slave_chdk-configs/RAW_ON_CCHDK4.CFG chdk/CCHDK4.CFG')) end con=savecon)to upload the raw ON config file after having completed the first jpg only shot but was not surprised to find the new config file setting was not used in the second shot (the raw shot).
Using this method is it known if the raw setting in the file would only take effect the next time chdk was loaded?
(wasn't sure if this could be better placed in sx150 porting thread...or somewhere)
Further info:
Base used was multicam-r692
Addition to camera script
capmode=require("capmode")
function cmds.set_mode()
--e.g. to run !return mc:cmdwait('set_mode',{args=1})
--1 -> AUTO
--2 -> P
--3 -> TV
--4 -> AV
--5 -> M
local new_mode = tonumber(mc.args)
capmode.set(new_mode)
wait_timeout_write_status(capmode.get,new_mode,100,mc.mode_sw_timeout)
end
-
Issue: multicam.lua shoot_hook_sync - get_shooting does not go false in wait_timeout_write_status when raw enabled (set via CCHDK4.CFG), ok with jpg only.
get_shooting() should go false after the raw finishes saving. This appears to work correctly on D10. If you have review on, it will probably wait for the review time too, but this shouldn't be directly affected by raw.
I would suggest trying with the timeout set to something large, like 20 seconds.
loosely related follow-up...I had originally used
savecon=con for i,lcon in ipairs(mc.cams) do con=lcon cli:print_status(cli:execute('u -nolua B.Slave_GUI/For_Slave_chdk-configs/RAW_ON_CCHDK4.CFG chdk/CCHDK4.CFG')) end con=savecon)to upload the raw ON config file after having completed the first jpg only shot but was not surprised to find the new config file setting was not used in the second shot (the raw shot).
Using this method is it known if the raw setting in the file would only take effect the next time chdk was loaded?
CHDK does not expect the cfg files to be changed externally while it's running! If you want to change the raw setting, use set_raw() or set_config_value(). You can use the 'call' command to send the Lua code in multicam, e.g. mc:cmdwait('call set_raw(true)')
If you want to upload cfg files, you should upload them and reboot the camera immediately, if any settings are change on the camera before rebooting, CHDK will probably overwrite the new CFG. Alternately, use one of the Lua scripts that saves and loads cfg values.
-
10 secs works reliably...your note reminded me to list "review off" for inclusion in canon initialisation script ::)
Thanks for various cfg options - pretty sure upload can be excluded as a contender.
-
@reyalp: a question about the -pipe option for rsint that was added in r690, https://www.assembla.com/spaces/chdkptp/subversion/commits/688 (https://www.assembla.com/spaces/chdkptp/subversion/commits/688) .
I have managed to use it to have an external process trigger the camera shoot. But is there also some way to read the message chdkptp returns on a successful shoot? After doing e.g. "rsint -pipe=C:\external.exe" the cmd window does not display anything when the camera shoots.
I have without success tried reading the StdIn of the external process. But I don't know if there is a problem with my code for reading StdIn or if chdkptp doesn't return anything there. Or perhaps I am missing something else.
-
I have managed to use it to have an external process trigger the camera shoot. But is there also some way to read the message chdkptp returns on a successful shoot?
Short answer: There isn't. Lua popen doesn't let you open a bi-directional pipe, so chdkptp can't send anything to to the control process.
If you want to read chdkptp output, you would need have your program start chdkptp from your process with chdkptp stdin and stdout connected. The main advantage of the -pipe option over this is it lets you use a very simple executable, e.g. if you want to control shooting with external hardware on something like a raspberry pi, you could have a very simple program that outputs s when it sees a particular value on a GPIO.
-
Ok, good to know.
If you want to read chdkptp output, you would need have your program start chdkptp from your process with chdkptp stdin and stdout connected.
Yes, but I haven't been able to write a program that starts, stdin/stdout connects *and* keeps two chdkptp processes throughout a session of taking many rsint shots.
-
I did not find any clue about this in the chdkptp sources:
could we get the status of the battery via chdkptp ? So that it can be displayed in the gui ?
-
I did not find any clue about this in the chdkptp sources:
could we get the status of the battery via chdkptp ? So that it can be displayed in the gui ?
You can get battery voltage using the camera side lua function get_vbatt()
However, there a few problems with displaying this in the GUI
1) Only one script can run at a time, so periodically polling the voltage from the GUI could fail, or interfere with other scripts.
2) To turn it into a status, you need to know the voltage range for the cameras particular battery type. You could use the battery low and battery high values from get_config_value to the range.
In some situations, using the live view to see the CHDK battery OSD might be an option.
-
in Full zoom: no distortions via chdkptp client, but distorted using init_usb_capture(1,0,0); and shoot();
Cam Model is IXUS 105.
This first image is taken using chdkptp client (remote shoot), exhibiting no distortion, the second has (note the bent edges).
I use a java library to take photos (relevant lines:https://github.com/acamilo/CHDK-PTP-Java/blob/master/src/main/java/chdk/ptp/java/camera/AbstractCamera.java#L389 (https://github.com/acamilo/CHDK-PTP-Java/blob/master/src/main/java/chdk/ptp/java/camera/AbstractCamera.java#L389)).
Why are the images distorted and what to do against it ?
What does your client do better ?
-
I replied in the porting thread, because this is mostly a port issue: https://chdk.setepontos.com/index.php?topic=5720.msg128870#msg128870
The difference between your tool and chdkptp is likely that the chdkptp GUI uses key clicks rather than set_zoom.
-
Hi, reyalp
I downloaded chdkptp-r690-win32.zip and found that ptpLIVEvew does not work with my camera unlike your special build(https://chdk.setepontos.com/index.php?topic=6231.msg125049#msg125049)
Where to find the latest build of chdkptp and does it support Digic 6 cameras?
Probably it can be used with your G7X port
-
Hi, reyalp
I downloaded chdkptp-r690-win32.zip and found that ptpLIVEvew does not work with my camera unlike your special build(https://chdk.setepontos.com/index.php?topic=6231.msg125049#msg125049)
Where to find the latest build of chdkptp and does it support Digic 6 cameras?
Probably it can be used with your G7X port
This code has not been integrated into CHDK or chdkptp yet. Sorry.
-
Why? It is just need to add framebuffer type for Digic 6...
-
Why? It is just need to add framebuffer type for Digic 6...
Not really. There are unresolved issues with Digic 6 display generally, and how they are resolved will impact the live view. E.g. sx280 and other ports using totally different kinds of buffers.
Also, assuming you are referring to the M3 port, I don't understand the desire to have live view on such an incomplete port. How is this useful?
edit:
This wasn't meant to be snark, if there is a real use case I would be more motivated to spend effort supporting it.
-
E.g. sx280 and other ports using totally different kinds of buffers
I suspect that not only M3 can have this kind of buffers. What about your G7X?
-
I suspect that not only M3 can have this kind of buffers. What about your G7X?
I have found both types of buffer on g7x, but have not yet found how to get the the current buffer for either. I have also identified the playback buffers, but again haven't found a way to get the current one.
I'm working on this stuff as I have time. At the moment, I don't have any particular reason to prioritize chdkptp live view over the other display related issues.
-
As far as integrating the "opacity" buffers into chdkptp, is the favored approach to do the integration on the camera, or in chdkptp? I'm assuming it would be good to maintain backwards compatibility in chdkptp but that might not be so easy. Also, I think there are two opacity buffers: does that mean we need to determine which one is live?
-
As far as integrating the "opacity" buffers into chdkptp, is the favored approach to do the integration on the camera, or in chdkptp?
Definitely in chdkptp, doing it on camera would use a large amount of memory and be very slow, unless we figure out how to control the GPU. USB transfers are much slower if you do a lot of calls with small amounts of data, using a small buffer to combine is not a viable option.
There are also the 640x480 RGBA buffers srsa identified, but at the moment they don't contain CHDK output and it's not really clear how they work.
Also, I think there are two opacity buffers: does that mean we need to determine which one is live?
The current drawing code uses active_bitmap_buffer as an index into opacity_buffer (without the &1 vid_get_active_bitmap_buffer uses :-[). This appears to work. We should probably add a vid_get_active_opacity_buffer function.
I'm assuming it would be good to maintain backwards compatibility in chdkptp but that might not be so easy.
The live view protocol works by the client polling the camera each time it wants a frame. Each request includes a bitmask of which things it wants (see core/ptp.h PTP_CHDK_GetDisplayData). My plan is to add another bit for the opacity buffer, along with another lv_fb_type value and lv_framebuffer_desc and offset in the lv_data_header. (see core/live_view.h)
Clients that are unware of the new buffer won't request it, and properly implemented clients should ignore any extra values in the lv_data_header.
Since the opacity buffer is a large amount of data, and isn't needed if you only want the UI display, it should be optional with fallback to the current method.
We also need to define what appears in the palette information.
One downside to the current protocol is that there is really no way for clients to know what to expect (i.e. whether a camera uses paletted live view or YUV+alpha). They can just request everything and decide what to draw based on the response, but this may get awkward as more things are added.
Another minor protocol change needed for g7x is adding 3:2 aspect ratio.
edit:
FWIW, I'm planning to do some work on this over the weekend.
-
Another minor protocol change needed for g7x is adding 3:2 aspect ratio.
I think, aspect ratio should be defined by UI overlay.
Please, make checkbox "Scale for A/R" unchecked by default.
Your special build (https://chdk.setepontos.com/index.php?topic=6231.msg125049#msg125049) already works fine with various aspect ratios:
-
I think, aspect ratio should be defined by UI overlay.
Please, make checkbox "Scale for A/R" unchecked by default.
Your special build (https://chdk.setepontos.com/index.php?topic=6231.msg125049#msg125049) already works fine with various aspect ratios:
No it doesn't. It's just looks about right on your camera because it has nearly square pixels.
"Scale for AR" produces incorrect results with the hack because it assumes 4:3.
There are several ratios involved:
1) The *physical* aspect ratio of the screen
2) The pixel aspect ratio. Many CHDK cameras have pixels that are very far from square.
3) The aspect ratio setting. This affects where the image appears with in the physical screen.
I understand your desire to have something that works checked in quickly, but I have to think about >100 other cameras, and maintaining the code in the future.
-
Attached are preliminary patches for full d6 protocol support, including opacity buffer. A windows client build is also attached. I will probably check this in soon, but posting it here for comments and to allow others to update their ports.
This introduces a new minor live view protocol revision (2.2) Arguably, this should be a "major" version, not backward compatible, but old clients should work fine for non-digic 6 cameras, and fail relatively gracefully for digic 6. The updated chdkptp code supports both 2.1 and 2.2.
The G7X port is fully updated. I made my best guess at the required changes for sx280. I haven't attempted to update the sx60 port since I think the svn source is quite a bit behind 62ndidiots.
Things that need attention in digic 6 ports
- The _proper functions for digic 6 should not be 2x the normal values. See g7x examples.
- palette type and size should be 0. This is the default in generic wrappers, so they do not need to be defined.
- vid_get_opacity_active_buffer must be implemented. See g7x
- vid_get_viewport_type must be implemented. Include the live_view.h for constants. Ports like the g7x only need to return LV_FB_YUV8B. The current sx280 code probably needs to return different values for play and rec.
- for playback image display vid_get_viewport_fb_d should be implemented and, dimension functions (*get_viewport_width etc) should return a non-zero value in playback mode
- for full support of different shooting aspect ratios etc, the various vid_*offset functions must be implemented. G7X has a fairly complete implementation, but specifics will vary by camera.
- I have not tested behavior with TV or HDMI out.
General chdkptp notes
- I added a checkbox to skip the d6 opacity buffer. Since all the protocol data is sent in every frame, this is available whether it makes sense for the camera or not.
- lvdump, lvdumpimg and screenshots should work. lvdumps should be compatible to the same extent real live view is.
- I made a zero image size (which can happen if the viewport sizes aren't correctly implemented) treated the same as no data returned (e.g. if viewport address is null)
- chdkptp live code now checks the live protocol version, which it did not before.
Other CHDK notes
- Pulling the live view headers into lib.c / wrappers.c is not really clean, but using the same constants makes sense.
- The opacity buffer description is sent regardless of whether the camera has one or whether opacity data was requested. It's only ~36 bytes, not significant compared to any of the frame buffers. The type is set to LV_FB_OPACITY8 regardless, because we don't have a "none" type. Possibly, it would make more sense not to send the description at all on cameras that don't support it (e.g. lv->bmo_desc_start = 0). The rational for sending the description for buffers that don't have data selected is that it allows clients to determine what kinds of buffers are present.
- The use of THUMB_FW to decide various things in live_view.c probably isn't great, we should probably have defines and/or functions for the specific characteristics. I added a function for the viewport type, since on SX280 it varies between modes.
- I did not define a wrappers.c default vid_get_opacity_active_buffer. d6 ports must implement it. Others should not.
- I defined the wrappers.c default vid_get_viewport_type for pre-d6 only, since all those cameras to date use the same format.
-
Tested on EOS M3 - fine!
But when I turn on camera with connected USB cable I get an error:
e:\Foto\EOS M3\ptpCHDK\lua\gui_live.lua:527: width > buffer_width
stack traceback:
[C]: in function 'get_viewport_pimg'
e:\Foto\EOS M3\ptpCHDK\lua\gui_live.lua:527: in function <e:\Foto\EOS M3\ptpCHDK\lua\gui_live.lua:516>
(...tail calls...)
[C]: in function 'MainLoop'
e:\Foto\EOS M3\ptpCHDK\lua\gui.lua:758: in function <e:\Foto\EOS M3\ptpCHDK\lua\gui.lua:731>
(...tail calls...)
e:\Foto\EOS M3\ptpCHDK\lua\main.lua:286: in main chunk
[C]: in function 'require'
[string "require('main')"]:1: in main chunkFor normal work I need to switch camera to Rec mode from PC.
This problem was present in previous builds too...
-
It will be a few days before I can test SX60, but I don't foresee any problems.
-
Tested on EOS M3 - fine!
But when I turn on camera with connected USB cable I get an error:
e:\Foto\EOS M3\ptpCHDK\lua\gui_live.lua:527: width > buffer_width
stack traceback:
[C]: in function 'get_viewport_pimg'
e:\Foto\EOS M3\ptpCHDK\lua\gui_live.lua:527: in function <e:\Foto\EOS M3\ptpCHDK\lua\gui_live.lua:516>
(...tail calls...)
[C]: in function 'MainLoop'
e:\Foto\EOS M3\ptpCHDK\lua\gui.lua:758: in function <e:\Foto\EOS M3\ptpCHDK\lua\gui.lua:731>
(...tail calls...)
e:\Foto\EOS M3\ptpCHDK\lua\main.lua:286: in main chunk
[C]: in function 'require'
[string "require('main')"]:1: in main chunkFor normal work I need to switch camera to Rec mode from PC.
This problem was present in previous builds too...
Your port is sending incorrect dimensions for the viewport buffer. Probably you need to have a check for playback mode.
If you enter
set gui_verbose=2
in the chdkptp console before connecting, you should see all the dimensions sent in the live view frame.
Looking at your svn, I see some direct variable references like
int vid_get_viewport_buffer_width_proper() { return (*(int*)(0x00053CBC) ); }
These variables might not be initialized in playback.
Also, fwiw platform/<cam>/lib.c should not reference variables directly, because addresses are likely to vary between firmware versions. You can define the variable in stubs_min.S or implement the function in sub/<fw>/lib.c
-
int vid_get_viewport_buffer_width_proper() { return (*(int*)(0x00053CBC) ); }
These variables might not be initialized in playback.
You was right. Now I had replaced it by camera_screen.buffer_width
Can you add button "CR2 Remote Shoot" ?
-
I've checked in the changes from the previous posts, chdk r4680, chdkptp r712. In r4681 I checked in minimal changes to sx60 to allow to compile, but I didn't attempt to fix any of the other stuff.
I'll post updated builds for all the chdkptp platforms in the next few days.
-
Test SX60HS...updated to chdk to latest svn and rebuilt, updated chdkptp to latest and rebuilt...initially some problems:
1. I cannot see live view in record mode. I get some errors, similar to what @Ant experienced.
x/chdkptp-svn/chdkptp/trunk/lua/gui_live.lua:527: width > buffer_width
stack traceback:
x/chdkptp-svn/chdkptp/trunk/lua/gui_live.lua:527: in function 'action'
x/chdkptp-svn/chdkptp/trunk/lua/gui_live.lua:450: in function <x/chdkptp-svn/chdkptp/trunk/lua/gui_live.lua:419>
[C]: in function 'xpcall'
x/chdkptp-svn/chdkptp/trunk/lua/gui_live.lua:493: in function <x/chdkptp-svn/chdkptp/trunk/lua/gui_live.lua:491>
(...tail calls...)
[C]: in function 'MainLoop'
x/chdkptp-svn/chdkptp/trunk/lua/gui.lua:758: in function <x/chdkptp-svn/chdkptp/trunk/lua/gui.lua:731>
(...tail calls...)
x/chdkptp-svn/chdkptp/trunk/lua/main.lua:280: in main chunk
[C]: in function 'require'
[string "require('main')"]:1: in main chunklive timer update error
2. Sometimes the background is not initialized to the correct YUV422 form, I mean the UI overlay is fine but the background is pinkish.
I'm researching the problem.
-
Fixed...I just need to merge my more recent lib.c with the old one edited by @reyalp. I think it's time I checked in my changes....will clean and post on the SX60HS thread.
-
I have uploaded snapshot build r723 to the chdkptp files area: https://app.assembla.com/spaces/chdkptp/documents
See the changelog for details: https://app.assembla.com/spaces/chdkptp/wiki/Changelog
Significant changes include the d6 live view stuff described up thread, as well as some changes to the the binary distribution:
* All builds are now based on Lua 5.2.4, CD 5.10 and IUP 3.19.1
* Intel Linux binaries are provided for both 32 bit (-i686) and 64 bit (x86_64)
* Intel Linux binaries are now built on Debian Jessie 8.5
* Raspberry pi builds are built on Raspbian Jessie 8.0
* All Linux builds include both CLI and GUI executable, along with the required IUP and CD .so files for the GUI builds.
* The chdkptp.sh and chdkptp_gui.sh in the Linux packages should now set required environment variables automatically, and do not need to be edited.
* The chdkptp-raspbian-libs-….zip is no longer required to run the raspberry pi GUI. It is required if you want to build the GUI yourself.
I would be interested to know what success (or otherwise) people have running the linux builds. My hope is that at least most Debian heritage distros will be able to run them, but I haven't tested. edit: Verified it runs fine on ubuntu 16.04 x64
Side note: While making these builds, I found that chdkptp in a Linux virtualbox guest VM running under windows 10 is able to access cameras with reasonable performance and little hassle. Just right click on the USB icon on the VM window and select the camera. You probably want the Virtualbox "extra" package that includes USB 2.0 support for this.
I have only used this with cameras that already had the libusb driver installed on the windows side. If it wasn't installed, I suspect windows software would probably put the camera in the "black screen/unable to switch to rec" state before you can grab it in the VM.
I did have the VM USB die once in a way that made chdkptp hang for a long time and then fail when attempting to connect. This went away after a VM reboot.
edit:
not->now, thanks waterwingz
-
* The chdkptp.sh and chdkptp_gui.sh in the Linux packages should not set required environment variables automatically, and do not need to be edited.
Is this supposed to say "should now set" ?
-
I found a little problem:
> rmem 0x00000000 0x00100000 -f=ram.bin
ERROR: Protocol error: data expected
-
I found a little problem:
> rmem 0x00000000 0x00100000 -f=ram.bin
ERROR: Protocol error: data expected
NULL pointer protection (https://app.assembla.com/spaces/chdk/subversion/source/4685/trunk/core/ptp.c#ln308). You can still crash your camera if you try accessing any of the first 32 bytes (or words?) of memory (which is protected on your camera).
-
I don't get crash typing:
> rmem 0x10 0x100000 -f=10.bin
0x00000010 1048576 10.bin
Whole RAM dumping also works from CHDK menu.
-
A low level tool like rmem probably doesn't need to protect you from things like this, but in any case the first few words generally have much you'd need to dump more than once.
It's not clear to me if the underlying send_ptp_data would handle NULL anyway, and on older cameras this is ITCM which doesn't always play nice if you try to DMA from it.
Whole RAM dumping also works from CHDK menu.
It has special code (https://app.assembla.com/spaces/chdk/subversion/source/4685/trunk/core/main.c#ln68) to read from the uncached address space instead (edit: although this should still on cameras with the first 32 bytes MPU protected). If you want to read the lowest values in physical RAM, you can do the same. On cameras where ITCM is mapped to 0, this is potentially not the same as the the ITCM contents.
-
I don't get crash typing:
> rmem 0x10 0x100000 -f=10.bin
0x00000010 1048576 10.bin
I don't see how this could work when the first 32 bytes are protected by the MPU...? Is there something wrong with the way CPUINFO decodes the MPU related data?
-
I don't see how this could work when the first 32 bytes are protected by the MPU...? Is there something wrong with the way CPUINFO decodes the MPU related data?
Hmm, looking again I think it's only write protection:
Access permission 0x5 5 [P:R- U:--]
=peek(0) works fine on g7x.
-
Hmm, looking again I think it's only write protection:
Access permission 0x5 5 [P:R- U:--]
=peek(0) works fine on g7x.
Oh. I keep forgetting that the CPU is always in privileged mode in Powershots.
-
On EOS M3 I can dump 0xBFE00000 and 0x80000000 memory, but can not dump 0xDFE00000. Why?
-
On EOS M3 I can dump 0xBFE00000 and 0x80000000 memory, but can not dump 0xDFE00000.
Which dumping method? rmem or DmpRAM? What happens when you try?
-
rmem causes crash when I try to read 0xDFE00000.
-
rmem causes crash when I try to read 0xDFE00000.
The canon firmware send_ptp_data almost certainly uses DMA, (there might be a minimums size). DMAing from MMIO address space is likely to be unpredictable
-
Is there equivalent of "call" and "set" commands used in ptpcam?
-
Is there equivalent of "call" and "set" commands used in ptpcam?
In most cases, you should be able to use call_func_ptr and poke in Lua to do the same things.
The call PTP command is available using con:call_function, but is not currently exposed in the CLI. I have not implemented set.
-
Replying to a question from mphx in PM
So i am trying to compile chdkptp in linux.Since my system has newest packages than chdkptp is "used" to work well with , i downloaded :
It would be helpful to know which distro you you are using.
1. IUP
2. CD
3. Lua52 source (system has lua5.3 but lets play it safe here with 5.2)
So i created a folder with chdkptp source , an extra subfolder in there were i put iup/cd/lua(headers and compiled lib from the lua source i downloaded)
I created and edited the config.mk file , put the correct paths for headers/libs/etc and hit the "make" command.
And i am here -> (attachment mphx-chdptp_compile-error.png)
From the little that i understand that must be the end of the compiles ...i mean if was not the error.
Error about some variable not defined although i checked lua headers and it seems to be defined at luaxlib.h just fine.
So have you ever seen this before?Any ideas?
It looks like you set the Lua path to a relative path like ./lib/lua52. The error is related to something lfs, which is in the a subdirectory where the relative path is no longer valid. Try using an absolute paths for all the library / include settings. Be sure to make clean before you rebuild, because lfs may have been built with the wrong lua includes.
I would have used the latest binary (r723 if not mistaken) that seemed to be ok with the supplied libs but has a thing with installed gtk as far as i can understand.
(attachment mphx-chdkptp_gui-error.png)
Maybe its not chdkptp's problem but system's problem.
I haven't seen this one before. Just to be sure: chdkptp fails to run when this happens? It's not unusual for linux GUI programs to spew some messages without any real problem.
Again, knowing which distro and desktop would be helpful.
-
First of all i hadnt notice this thread , thats why i sent the pm.
@reyalp
Second of all i am using Manjaro (archlinux in essence) with XFCE4.
About the compiling and the lfs situation.
------------------------------------------------------------
You were right.it was all about the relative paths to lua headers/libs.I corrected them and compile finished without errors.
And now we come to the real (as it seems) problem.
After the compile as everyone would do , i tried to run the binary.Before that i created a new subfolder.I threw all the cd/iup(+lua) libs into this subfolder.
I edited config.sh accordingly and ran the executable. NO-GO :)
Ok not entirely true. cli mode works.GUI not.
And to answer your question , when the "messages" are thrown , chdkptp (gui) doesnt not start.I am talking about the binary i was testing, before i compiled the source myself.
This one (the compiled one) , does not show any message.
Only "Segmentation fault"
EDIT : i noticed a related system message (dmesg) that maybe help anyone having more technical knowledge than me.
[27136.899370] chdkptp[14723]: segfault at 21044f ip 00007f174655493a sp 00007ffefeda4180 error 4 in libgobject-2.0.so.0.5000.2[7f1746520000+51000]
That message comes in harmony with the messages that the binary was throwing before.Something about GObject stuff.
Any ideas welcomed.
Thanks.
-
Second of all i am using Manjaro (archlinux in essence) with XFCE4.
Thanks. I have not built or tested on any arch based distros. I don't really have the time to troubleshoot every linux flavor. If changing distros is an option, the builds I provided should run out of the box on many Debian based distros. The builds are built on Debian 8 and I have verified they work on Ubuntu 16.04.
I'm a bit confused from you post what problems each build has. As far as I understand
Your self built build
* Running the gui segfaults with no other errors displayed. The dmesg segfault is also from this build?
* Running the same executable in command line mode (chdkptp -i etc) works
For this build, it might be useful to know what specific IUP and CD libraries you used.
My build (chdkptp-r723-Linux-*.zip)
* Displays the GTK errors posted earlier and does not start, but does not segfault?
For both builds, running ldd with same environment that chdkptp would run in might provide insight into which libraries each one is actually using. e.g. in chdkptp_gui.sh replace
"$CHDKPTP_DIR/$CHDKPTP_EXE" "$@"
with
ldd "$CHDKPTP_DIR/$CHDKPTP_EXE"
Doing this in the .sh file ensures it uses the same LD_LIBRARY_PATH that chdkptp is actually using.
Since your errors seem to be GTK related, comparing the GTK libraries provided with your distro to those used by the Debian or Ubuntu versions known to work might provide a clue.
-
@reyalp
To simplify things.
1.Both binaries (precompiled by you and compiled by me) are segfaulting.
2.dmesg segfault is from my compiled binary. ** but i just checked , dmesg message is the same for both binaries**
Your precompiled binary as far as i can understand uses one or two versions back of IUP and CD.
I used the latest available.Probably thats why one binary throws in some warning/errors and segfaults and the other one doesnt throws any messages and just segfaults.
So bottom line i believe that both binaries have the same problem and that must be something to do with libgobject-2.0.so.0.xxx which is part of the glib2 package. (installed version is 2.50.2-1).
I tried some older versions but it was no-go either.
I did some ldd with both binaries just to check if the various libgobject i was using were "used" by the binary.
https://www.dropbox.com/s/w590qzum8r6oy4f/ldd.zip?dl=0 (https://www.dropbox.com/s/w590qzum8r6oy4f/ldd.zip?dl=0) ** i zipped 2 files containing the result of the ldd command for both binaries**
Probably they are the same libraries used and only difference would be the iup/cd libraries (especially in versions)
I dont have a debian/ubuntu distro handy at this time to check versions and stuff , if you have feel free to check it.If you need to check versions of specific packages/libraries/whatever feel free to tell me.
EDIT : Changing distros is not big deal but i'd like to stick with arch-based distro for mostly 2 reasons.Firstly there are precompiled packages i couldnt dream to find in any other distro.There is even chdkptp available ( https://aur.archlinux.org/packages/chdkptp (https://aur.archlinux.org/packages/chdkptp)) although it doesnt build correctly :) . So prebuilt/compiled packages is a big plus here.
Secondly , arch-based distros are bleeding edge and since i have a rather difficult hardware (hybrid graphics) i want to get new updates fast in hoping some things would get implemented or fixed some day.
Just for the history :)
EDIT 2 :
IUP : iup-3.20-Lua52_Linux44_64_lib.tar.gz (+lua52 libs)
CD : cd-5.11-Lua52_Linux44_64_lib.tar.gz (+lua52 libs)
Thanks.
-
I had some difficulties in ubuntu 15.04. I made a script for both the GUI version and line mode version to set things like ld_library_path etc.
I also after every reboot, manually have to:
sudo ldconfig /usr/lib64
-
Here's ldd from the pre-compiled build running on Ubuntu 16.04. Nothing really jumps out at me comparing with yours.
The glib version on my system is 2.48.1
I did notice that yours has a bunch of wayland (https://en.wikipedia.org/wiki/Wayland_(display_server_protocol)) libraries. If gtk is trying to use wayland, using X instead might be something to try. The wiki page states
GTK+ 3 lets users select the desired GDK back-end by setting the GDK_BACKEND Unix environment variable.
I assume something like
export GDK_BACKEND=x11
before chdkptp is invoked
I wouldn't be at all surprised if IUP/CD have some X specific dependencies.
There's probably some error log for wayland (equivalent to .xsession-errors or /var/log/Xorg.N.log) which might provide more clues.
-
@reyalp
Lets take things in a order.
1.i pulled from old archives glib2 2.48.1 and linked chdkptp locally to it . no-go
2. According to this ( https://wiki.archlinux.org/index.php/wayland#GTK.2B_3 (https://wiki.archlinux.org/index.php/wayland#GTK.2B_3) ) gtk3 backend defaults to X11 and can be overriden to use wayland backend with the command you suggested.Which it didn't make any difference.So that link might be telling the truth.
3.3 out of 4 wayland libs mentioned in my files , are mentionted to your file too.So i dont think wayland is involved / affecting anything here.
4.I didn't find any logs concerning wayland.Thats logic if you think that nothing related to wayland is running.Some packages pulled some wayland libs as dependencies apparently,nothing more.
/var/log/Xorg.N.log has zero errors (thats a shock!) , .xession-errors has nothing related to chdkptp.
I've noticed something odd that might be relevant or not.
As i said i have hybrid graphics.When i need to run something on my second gpu (the good one) i use something like "optirun <application>" and sends the <application> to the second gpu , using all the libs/drivers/etc that are related to this card.
Its the well-known bumblebee project , best solution for hybrid graphics so far in linux. :(
Well i was playing around with chdkptp and i issued "optirun ./chdkptp.sh" .It just displayed "starting gui..." and exited.Zero messages at dmesg.No "segmentation fault" at prompt. Like nothing ran at all.Pretty odd.
I presume that we are missing some strange version combination of libs involved in all this.
A good thing would be to zip your source folder with all libs involved in there , send it over to me , so i can try to compile it here , with your configuration , your combination of local libs.
Can't think of anything else to test/try at this moment...
-
1.i pulled from old archives glib2 2.48.1 and linked chdkptp locally to it . no-go
Not surprising. It's quite likely that where the error occurs is not the source of the problem.
2. According to this ( https://wiki.archlinux.org/index.php/wayland#GTK.2B_3 (https://wiki.archlinux.org/index.php/wayland#GTK.2B_3) ) gtk3 backend defaults to X11 and can be overriden to use wayland backend with the command you suggested.Which it didn't make any difference.So that link might be telling the truth.
3.3 out of 4 wayland libs mentioned in my files , are mentionted to your file too.So i dont think wayland is involved / affecting anything here.
4.I didn't find any logs concerning wayland.Thats logic if you think that nothing related to wayland is running.Some packages pulled some wayland libs as dependencies apparently,nothing more.
Yeah, that makes sense. I know very little about this wayland stuff.
/var/log/Xorg.N.log has zero errors (thats a shock!) , .xession-errors has nothing related to chdkptp.
To be clear, N is the display number (typically 0). If that's what you looked at, maybe error logging is turned off somewhere?
I've noticed something odd that might be relevant or not.
As i said i have hybrid graphics.When i need to run something on my second gpu (the good one) i use something like "optirun <application>" and sends the <application> to the second gpu , using all the libs/drivers/etc that are related to this card.
Its the well-known bumblebee project , best solution for hybrid graphics so far in linux. :(
Well i was playing around with chdkptp and i issued "optirun ./chdkptp.sh" .It just displayed "starting gui..." and exited.Zero messages at dmesg.No "segmentation fault" at prompt. Like nothing ran at all.Pretty odd.
I don't really know anything about this, but it wouldn't surprise me if optirun just didn't display the error.
A good thing would be to zip your source folder with all libs involved in there , send it over to me , so i can try to compile it here , with your configuration , your combination of local libs.
I don't understand how this would help. The libs I used are listed in README-LINUX-BINARIES.TXT
You could check out r723 of the chdkptp source if you wanted, but I'm very confident that none of the changes since then are relevant to this problem.
The config.mk I used is attached, but all it really does is set the paths.
Since both my build and yours crash in similar ways, my suspicion is that the errors are between IUP/CD and the GTK etc libraries on your system. But this is just a wild guess.
-
@reyalp
After the last days , trying distros , running binaries , compiling sources.. the result is. ZERO :)
After Manjaro/XFC4 , i installed ubuntu 16.10/Unity (clean install).First thing i did was to run chdkptp.Same segfault.
Updated it to 17.04.Thought newer versions there , maybe i will get lucky.Same story there.
I fcked up ubuntu installation at some point, so i ended up to Fedora since i want to run some 3d programs that are coming in rpm packages so suits me well.
Newest fedora runs wayland.First shock there :)
export GDK_BACKEND=x11 did the trick though and after that , we are back to the same segfault.
I am starting to believe that iup/cd maybe want specific versions of specific system libraries :)
Ah forgot to mention that every try was made , by compiling iup/cd(im)/lua52 every time to be sure that they are built against current system's libraries.
Its not big ,deal i can test stuff in chdkptp at studio (windows) but i'd like to have it available at home too...
-
@mphx
You could try investigating those crashes a bit more. See posts starting here (https://chdk.setepontos.com/index.php?topic=6231.msg88970#msg88970) to get some ideas (gdb, backtrace).
-
After Manjaro/XFC4 , i installed ubuntu 16.10/Unity (clean install).First thing i did was to run chdkptp.Same segfault.
That's strange, in the past builds on older versions of ubuntu have run fine on later versions for me.
Did you try my build on this OS?
Ah forgot to mention that every try was made , by compiling iup/cd(im)/lua52 every time to be sure that they are built against current system's libraries.
Do you really mean building IUP/CD ? I really don't recommend this (I remember we had a long conversation about this in the other thread). Up to now, I've had no problems using their pre-built libraries.
As srsa_4c suggests, debugging with gdb might give some clues.
-
@reyalp
Sorry,forgot to mention , that i firstly was testing pre-built binaries of yours , before starting compiling , in every distro i was installing.The result was the same with either binaries and compiled.
I did some debugging , dont know alot of it to dig really deep..but it was all ended up to glib2/libgobject library.
I will check the link too.
-
Sorry,forgot to mention , that i firstly was testing pre-built binaries of yours , before starting compiling , in every distro i was installing.The result was the same with either binaries and compiled.
Thanks for clarifying.
I did some debugging , dont know alot of it to dig really deep..but it was all ended up to glib2/libgobject library.
If you can get stack trace, please post it.
If anyone else is using chdkptp on Linux, I'd be interested to know what distros the GUI is working (or not) on.
I'll try to investigate this further at some point, but unfortunately due to real life circumstance I have even less time for CHDK related stuff than usual.
-
@reyalp
Did some testing , not much though.Being on real physical machine or in a VM apparently doesn't affect anything.
1.Manjaro XFCE4 - NO
2.Ubuntu 16.10 Unity - NO
3.Ubuntu 17.04 Unity - NO
4.Opensuse Tumbleweed KDE (rolling branch of opensuse , quite bleeding edge) - NO
5.Fedora 25 Gnome - NO
Every case was producing the same segfault :
[ 6378.654711] chdkptp_gui[4240]: segfault at 544e4f46 ip 00007fb5fe871946 sp 00007ffe80dd0770 error 4 in libgobject-2.0.so.0.5000.0[7fb5fe83d000+52000]Every time the same file , only different version.
Here is a backtrace (from gdb) of chdkptp_gui trying to run on a ubuntu 16.10 installation.
http://pastebin.com/GVbtLTu3 (http://pastebin.com/GVbtLTu3) -Don't know if that will help at all..
-
Doubt this is helpful but I've
attached ldd chdkptp for my ubuntu studio installation, which is working fine.
I believe I ended up not building iup, and just downloading their library.
lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 15.04
Release: 15.04
Codename: vivid
-
@62ndidiot
This installation is like 2 versions back.So we are talking about old version libraries.
Can you please check the version of glib2 package?This one provides libgobject library that is mentioned in segfaults.
@reyalp
Some of the essentials libraries are getting hard to be found in newer distros.
E.g. readline6 , libusb 0.1-4 .
So put in your TODO list at some point to compile iup/cd with newer libraries.They compile just fine as i found out lately.
Because even the latest versions of cd/iup , are not compiled with the latest readline and libusb libraries.
-
Can you please check the version of glib2 package?This one provides libgobject library that is mentioned in segfaults.
pkg-config --modversion glib-2.0
2.44.1
locate libgobject
/usr/lib/i386-linux-gnu/libgobject-2.0.so.0
/usr/lib/i386-linux-gnu/libgobject-2.0.so.0.4400.1
/usr/lib/x86_64-linux-gnu/libgobject-2.0.a
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4400.1
I'm pretty sure I dynamically link to these when I run the gui version, because I need to issue ldconfig /usr/lib64, and locate libiup only returns stuff in /usr/lib64
ls -l /usr/lib64
total 13424
-rwxr-xr-x 1 root root 71154 Mar 23 2016 libcdcairo.so
-rwxr-xr-x 1 root root 30022 Mar 23 2016 libcdcontextplus.so
-rwxr-xr-x 1 root root 35087 Mar 23 2016 libcdgl.so
-rwxr-xr-x 1 root root 202772 Mar 23 2016 libcdlua51.so
-rwxr-xr-x 1 root root 258670 Mar 23 2016 libcdlua52.a
-rwxr-xr-x 1 root root 202774 Mar 23 2016 libcdlua52.so
-rwxr-xr-x 1 root root 9284 Mar 23 2016 libcdluacairo51.so
-rwxr-xr-x 1 root root 9283 Mar 23 2016 libcdluacairo52.so
-rwxr-xr-x 1 root root 8485 Mar 23 2016 libcdluacontextplus51.so
-rwxr-xr-x 1 root root 2628 Mar 23 2016 libcdluacontextplus52.a
-rwxr-xr-x 1 root root 8484 Mar 23 2016 libcdluacontextplus52.so
-rwxr-xr-x 1 root root 8571 Mar 23 2016 libcdluagl51.so
-rwxr-xr-x 1 root root 2754 Mar 23 2016 libcdluagl52.a
-rwxr-xr-x 1 root root 8531 Mar 23 2016 libcdluagl52.so
-rwxr-xr-x 1 root root 18460 Mar 23 2016 libcdluaim51.so
-rwxr-xr-x 1 root root 17274 Mar 23 2016 libcdluaim52.a
-rwxr-xr-x 1 root root 18459 Mar 23 2016 libcdluaim52.so
-rwxr-xr-x 1 root root 8577 Mar 23 2016 libcdluapdf51.so
-rwxr-xr-x 1 root root 2764 Mar 23 2016 libcdluapdf52.a
-rwxr-xr-x 1 root root 8537 Mar 23 2016 libcdluapdf52.so
-rwxr-xr-x 1 root root 43387 Mar 23 2016 libcdpdf.so
-rwxr-xr-x 1 root root 799283 Mar 23 2016 libcd.so
-rwxr-xr-x 1 root root 752182 Mar 23 2016 libcdx11.so
-rwxr-xr-x 1 root root 710646 Mar 23 2016 libfreetype.so
-rwxr-xr-x 1 root root 217922 Mar 23 2016 libftgl.so
-rwxr-xr-x 1 root root 8617 Mar 23 2016 libiupcd.so
-rwxr-xr-x 1 root root 249421 Mar 23 2016 libiupcontrols.so
-rwxr-xr-x 1 root root 18926 Mar 23 2016 libiupgl.so
-rwxr-xr-x 1 root root 536609 Mar 23 2016 libiupimglib.so
-rwxr-xr-x 1 root root 18701 Mar 23 2016 libiupim.so
-rwxr-xr-x 1 root root 168042 Mar 23 2016 libiuplua51.so
-rwxr-xr-x 1 root root 172251 Mar 23 2016 libiuplua52.so
-rwxr-xr-x 1 root root 8578 Mar 23 2016 libiupluacd51.so
-rwxr-xr-x 1 root root 8539 Mar 23 2016 libiupluacd52.so
-rwxr-xr-x 1 root root 43660 Mar 23 2016 libiupluacontrols51.so
-rwxr-xr-x 1 root root 43663 Mar 23 2016 libiupluacontrols52.so
-rwxr-xr-x 1 root root 13903 Mar 23 2016 libiupluagl51.so
-rwxr-xr-x 1 root root 13905 Mar 23 2016 libiupluagl52.so
-rwxr-xr-x 1 root root 28467 Mar 23 2016 libiupluaglcontrols52.so
-rwxr-xr-x 1 root root 13183 Mar 23 2016 libiupluaim51.so
-rwxr-xr-x 1 root root 13183 Mar 23 2016 libiupluaim52.so
-rwxr-xr-x 1 root root 8279 Mar 23 2016 libiupluaimglib51.so
-rwxr-xr-x 1 root root 8279 Mar 23 2016 libiupluaimglib52.so
-rwxr-xr-x 1 root root 13725 Mar 23 2016 libiupluamatrixex51.so
-rwxr-xr-x 1 root root 13727 Mar 23 2016 libiupluamatrixex52.so
-rwxr-xr-x 1 root root 23822 Mar 23 2016 libiuplua_mglplot51.so
-rwxr-xr-x 1 root root 23824 Mar 23 2016 libiuplua_mglplot52.so
-rwxr-xr-x 1 root root 33970 Mar 23 2016 libiuplua_plot52.so
-rwxr-xr-x 1 root root 23695 Mar 23 2016 libiuplua_pplot51.so
-rwxr-xr-x 1 root root 23699 Mar 23 2016 libiuplua_pplot52.so
-rwxr-xr-x 1 root root 13396 Mar 23 2016 libiuplua_scintilla51.so
-rwxr-xr-x 1 root root 13398 Mar 23 2016 libiuplua_scintilla52.so
-rwxr-xr-x 1 root root 12846 Mar 23 2016 libiupluatuio51.so
-rwxr-xr-x 1 root root 12848 Mar 23 2016 libiupluatuio52.so
-rwxr-xr-x 1 root root 13181 Mar 23 2016 libiupluaweb51.so
-rwxr-xr-x 1 root root 13183 Mar 23 2016 libiupluaweb52.so
-rwxr-xr-x 1 root root 127694 Mar 23 2016 libiupmatrixex.so
-rwxr-xr-x 1 root root 2233105 Mar 23 2016 libiup_mglplot.so
-rwxr-xr-x 1 root root 714563 Mar 23 2016 libiupmot.so
-rwxr-xr-x 1 root root 249138 Mar 23 2016 libiup_pplot.so
-rwxr-xr-x 1 root root 2756612 Mar 23 2016 libiup_scintilla.so
-rwxr-xr-x 1 root root 773930 Mar 23 2016 libiup.so
-rwxr-xr-x 1 root root 168829 Mar 23 2016 libiuptuio.so
-rwxr-xr-x 1 root root 20644 Mar 23 2016 libiupweb.so
-rwxr-xr-x 1 root root 1461133 Mar 23 2016 libpdflib.so
drwxr-xr-x 2 root root 4096 Jul 30 2015 sane
Some of the essentials libraries are getting hard to be found in newer distros.
E.g. readline6 , libusb 0.1-4 .
So put in your TODO list at some point to compile iup/cd with newer libraries.They compile just fine as i found out lately.
Because even the latest versions of cd/iup , are not compiled with the latest readline and libusb libraries.
Advice for me? :( I've almost bit the bullet and done an upgrade a couple of times this year. Both times I talked myself out of it, mainly because it might disrupt my CHDK efforts and gain me little or nothing in the way of functionality.
When I do upgrade, I will leave my current distro intact and bootable just in case.
-
http://pastebin.com/GVbtLTu3 (http://pastebin.com/GVbtLTu3) -Don't know if that will help at all..
Not really obvious. AFAIK iupMap is what creates/displays the actual windows and controls. So maybe there is some specific control that is doing something weird that was ignored in older version but is now a problem.
One way to debug this would be to disable everything except the basic window, and if that works, start re-enabling stuff until it crashes again. That would take some understanding of the code to do effectively though.
-
I'm pretty sure I dynamically link to these when I run the gui version, because I need to issue ldconfig /usr/lib64, and locate libiup only returns stuff in /usr/lib64
Assuming you start using the .sh file, the current pre-built packages should be self contained and not require you to install anything in the system /lib directories.
edit:
Of course, you should be able to use a similar script with your own builds as long as you point LD_LIBRARY_PATH at wherever you put the libs
-
Some of the essentials libraries are getting hard to be found in newer distros.
E.g. readline6 , libusb 0.1-4 .
So put in your TODO list at some point to compile iup/cd with newer libraries.They compile just fine as i found out lately.
Because even the latest versions of cd/iup , are not compiled with the latest readline and libusb libraries.
I don't understand. chdkptp is linked to libusb and readline, but that should have nothing to do with CD and IUP.
-
@reyalp
Ye my bad with readline.I saw it a lot during compiles and thought its iup/cd dependency.Now i am reading that its lua dependency , thats explains the whole connection to it.
Bottom line is that these versions are getting old and some -not all- , some distros just keep them for compatibility purposes only.
-
Ye my bad with readline.I saw it a lot during compiles and thought its iup/cd dependency.Now i am reading that its lua dependency , thats explains the whole connection to it.
chdkptp uses readline to provide command history in CLI mode. This is a compile time option you can turn off by setting READLINE_SUPPORT=0 in config.mk. I'm not aware that it specifically requires readline 6 rather than 7, but I haven't looked into it.
The Lua standalone interpreter can also use readline, but this shouldn't be relevant to chdkptp
libusb-0.1 is the USB API chdkptp uses to communicate with the camera. It's a legacy API, but changing to a different one would require a significant amount of work. AFAIK on linux versions it's just a compatibility wrapper over more recent APIs anyway. On windows, libusb-win32 only supports the 0.1 API, so a different library would need to be used.
There are good reasons to update the USB API, but it's not likely to be a simple project.
Bottom line is that these versions are getting old and some -not all- , some distros just keep them for compatibility purposes only.
As long as they are available and compatible, I don't see much reason to change. I'd much rather figure out why it's crashing.
edit:
OK, set up an ubuntu 16.10 VM. I understand the point about readline/libusb is that users will get load errors if the corresponding packages aren't installed. This is what you get trying to run pre-compiled binaries in linux.
I also get the segfault you described on on startup using the prebuilt build.
-
I tracked the segfault down to the mode dropdown.
Running the IUP example http://webserver2.tecgraf.puc-rio.br/iup/examples/Lua/list.lua also segfaults, unless I comment out the dropdown, so I'm guessing this is an IUP bug (though I suppose it could be triggered by some aspect of how chdkptp is built, I haven't tried running it in a non-chdkptp executable).
You can make chdkptp work by commenting out the line that adds the dropdown in gui.lua, like
iup.hbox{
-- gui.mode_dropdown,
},
Obviously, you will no longer be able to set the shooting mode with this control.
edit:
I confirmed the crash happens running their examples + precompiled binaries.
-
@reyalp
Yes , lua needs readline , chdkptp needs readline.Since lua is probably installed on the system , the only readline request comes from chdkptp.
It asks for "readline.so.6" so i believe it means readline6.Linking that lib to version 7 of the system is something i try to avoid doing.
Usually i can find version 6 in most of the distros...but the feeling is that is getting old.No biggie , just saying.
Same exactly thing applies for libusb , but i can understand that this "thing" is more difficult to change into the program...
Just keep them in mind , if you intent on working on chdkptp since there will be no point on upgrading it and it could not work because of incompatibilities..
Confirming that chdkptp works if i comment out that line.I noticed that the pull down menu were we see the connected cameras is disabled..no big deal for me..never use it.
Dont know where else has impact to be honest...
-
I think someone (who's actually experiencing the problem) should report this to the UIP (http://webserver2.tecgraf.puc-rio.br/iup/) devs. Only mentioning the malfunction of their own examples, of course.
-
I think someone (who's actually experiencing the problem) should report this to the UIP (http://webserver2.tecgraf.puc-rio.br/iup/) devs. Only mentioning the malfunction of their own examples, of course.
Yes, I'll send them a bug report.
-
The crash is reportedly fixed in IUP svn https://sourceforge.net/p/iup/mailman/message/35586943/
I haven't verified this myself yet
-
Well , i compiled all involved sources (cd,iup,im , chdkptp) using the latest versions (got latest svn trunk for iup to get the latest fix ofc) and indeed the built chdkptp works and doesn't segfaults.
But i don't consider it as a solution since the only thing they did is (as far as i can understand) disabling dropdown function in the source.
Of course for us (that using chdkptp) that dropdown function maybe doesn't affect us that much , is a progress ..but as i said before i don't know what else is affected , as
far as chdkptp is concerned.
-
But i don't consider it as a solution since the only thing they did is (as far as i can understand) disabling dropdown function in the source.
As far as I understand, the dropdown should work, but if you read Scuri's email he's quite clear it isn't a full fix.
I would expect a more complete fix in the next IUP release.
-
@reyalp
Well , dropdown..doesn't work :) Do you remember your dirty fix?GUI is behaving the same way in the two situations..that's why i said that they probably did something similar with your dirty fix in "source" level.
Ofc i understand its not a complete fix but for our case , since you had proposed that dirty fix , this fix didn't supplied something more. That's all.
-
Well , dropdown..doesn't work :) Do you remember your dirty fix?GUI is behaving the same way in the two situations..that's why i said that they probably did something similar with your dirty fix in "source" level.
Are you certain you aren't accidentally using the modified lua file?
Scuri's email says:
Fixed: crash at IupList in GTK 3.20 when DROPDOWN=Yes and EDITBOX=NO. But
in that case keyboard, focus and enter/leave window callbacks stopped
working.
To me, this seems like it should just prevent keyboard input and some other events from being recognized, rather than preventing the dropdown from displaying at all.
However, I know nothing about the internals of IUP so maybe I'm missing something.
-
@reyalp
Yes , pretty sure.Because i downloaded everything from the start.CD,IUP,IM,chdkptp and compiled them.
But your question made me worry to be honest :) So i fired up VM to check it.
Check the screenshot. https://www.dropbox.com/s/9j3nfl1zl6ps3we/chdkptp.png?dl=0 (https://www.dropbox.com/s/9j3nfl1zl6ps3we/chdkptp.png?dl=0)
Top terminal shows gui.lua and the line that should be commented out.Apparently it is not.
Bottom terminal is executing chdkptp and you can see the GUI running at the right.Believe me the dropdown areas are not clickable or anything.
How is "Keyboard , focus and enter/leave windows callbacks" affecting chdkptp gui?So i can check it out to see if it has any impact.Or the dropdown function is the only side-effect.
-
Top terminal shows gui.lua and the line that should be commented out.Apparently it is not.
Bottom terminal is executing chdkptp and you can see the GUI running at the right.Believe me the dropdown areas are not clickable or anything.
If you implemented my workaround the dropdown does not appear at all. In your screenshot, it appears to be present but empty. So this is definitely not the same.
The dropdown is normally empty until you are connected and have switched the camera to rec mode.
Whether you can interact with an empty dropdown depends on the GUI platform. You can on windows but AFAIK in some linux environments you can't.
How is "Keyboard , focus and enter/leave windows callbacks" affecting chdkptp gui?So i can check it out to see if it has any impact.Or the dropdown function is the only side-effect.
My impression is that comment only referred to dropdown type controls, but I don't have any more information than the email I linked and quoted.
-
@reyalp
Ok , maybe my understanding was wrong.Their fix ends up to the GUI you see in the screenshot.
Your fix , disappears the second one (the one that is under the rec/play buttons) at all.
I am used to windows version gui , where dropdown boxes are clickable even without anything connected.
So maybe its what you said , difference in gui platform behavior.
So , bottom line , "their fix" seems to be correct.
PS : If you want me , to zip the compiled cd/im/iup/lua packages so you can compile a new chdkptp and release a "fixed" version just let me know.Or even the compiled chdkptp itself , although i am a bit messy with the included libs/includes :)
-
Ok , maybe my understanding was wrong.Their fix ends up to the GUI you see in the screenshot.
With the fix, if you connect to a camera and switch to REC using the GUI, can you use the dropdown to change shooting mode?
PS : If you want me , to zip the compiled cd/im/iup/lua packages so you can compile a new chdkptp and release a "fixed" version just let me know.Or even the compiled chdkptp itself , although i am a bit messy with the included libs/includes
Thanks, but I think I'll wait for the next version of IUP to be released.
-
@reyalp
No idea :) I have minimum experience operating cameras+chdkptp on linux. So bare with me :)
Linux distro is on VM.I connected camera and got automounted.That fcked up things for chdkptp.So i had to configure ubuntu not to automount stuff.
Did that , camera was detected , not mounted.
In every case , chdkptp was connecting to the camera.But nothing worked.I could shutdown/reboot camera but thats all.None of the buttons on gui worked.
Camera was in a do-nothing-state even if i was disconnecting the usb cable.I had to remove battery and restart it in order to operate it.
Nothing to do with chdkptp.I checked with the precompiled chdkptp (with your fix) and it was same case.
Then i thought to check if camera is working ok in windows chdkptp.Since windows were upgraded lately something was screwed up with libusb and canon related stuff.
Reinstalled them , chdkptp and camera were working just fun.Tried to "pass" camera to VM but never got through ever again."Driver error" on the vm log.
So it has to do something about the connection of the camera in linux or vm or both.No clue what exactly.As i said 99% of the time i work with windows chdkptp.
Bottom line i cant check what you asked.
But i zipped chdkptp and the link is https://www.dropbox.com/s/03nxr38aiogxivl/chdkptp.tar.gz?dl=0 (https://www.dropbox.com/s/03nxr38aiogxivl/chdkptp.tar.gz?dl=0)
It should worked in any linux installation , all the libs are included (some libs must be present in distro though i suppose like e.g. readline6).Someone could take it and try it on some physical installation and tell us his comments.
Its the compiled chdkptp with the fix.
-
@reyalp
No idea :) I have minimum experience operating cameras+chdkptp on linux. So bare with me :)
That's fine, I'll just wait for the next release of IUP. Thanks for reporting the issue and testing as far as you have.
I have had USB stop working in virtualbox under windows. I think the rebooting the guest fixed it in my case, but I don't remember exactly.
-
I have uploaded snapshot r735 to files area https://app.assembla.com/spaces/chdkptp/documents
The main change is that all binaries are now built with IUP 3.21, which resolves the crash issue on newer linux distributions that mphx reported. I verified that the new build works on Ubuntu 16.10.
The only other significant changes is I fixed a bug which would cause the "shoot" cli command to occasionally fail on some cameras when -rm or -dl was used.
-
Hi, I have a question, could someone provide an example how to use lvdumpimg or how to decode lvdump data?
-
Hi, I have a question, could someone provide an example how to use lvdumpimg or how to decode lvdump data?
You might get a better answer if you told us a little more about what you are trying to do.
lvdumpimg is use to grab frames from the camera and save them to netpbm format files.
To get a screenshot of the current live viewport image, you could use:
lvdumpimg -vp
Or to get both the viewport and UI, you could use
lvdumpimg -vp -bm
The files are in netpbm pnm and pam formats, respectively.
All the images are saved in the native buffer sizes, so you might need to scale them with netpbm tools, imagemagic etc to get correct aspect ratios.
You can capture a stream of images using the -count option, specifying the frame rate with -wait or -fps
The posts around https://chdk.setepontos.com/index.php?topic=6231.msg114468#msg114468 have some examples of the piping options.
The lvdump format is essentially a dump of the raw PTP live view protocol, plus a very simple header. The code that writes it is in chdku.lua, see con_methods:live_dump_start and surrounding code.
lvdumpimg doesn't currently support taking an lvdump file as input instead of the camera, but this is something I would like to add.
-
I think lvdumpimg will be enough for me, but I will see if that will work. I don't need high speed, even 1fps will be enough for me so I will just dump a lvdumpimg every time I need.
-
There isn't any build on the assembla site! Could someone upload the latest windows build?
-
There isn't any build on the assembla site! Could someone upload the latest windows build?
=> https://app.assembla.com/spaces/chdkptp/documents
-
There isn't any build on the assembla site! Could someone upload the latest windows build?
=> https://app.assembla.com/spaces/chdkptp/documents
Sorry i changed the browser and now i can see the builds
-
Is it possible to shut down the lcd with a command?
-
Is it possible to shut down lcd retroillumination with a command?
If you mean the LCD altogether or its backlight, see the following script commands:
set_lcd_display (http://chdk.wikia.com/wiki/Script_commands#set_lcd_display.28.29)
set_backlight (http://chdk.wikia.com/wiki/Script_commands#set_backlight.28.29)
See the chdkptp manual documentation or its help command for details on how to run a script on camera.
-
Sorry i changed the browser and now i can see the builds
Which browser gave you problems?
-
Sorry i changed the browser and now i can see the builds
Which browser gave you problems?
Opera Beta 44.0.2510.73
-
GetMemory discussion split to https://chdk.setepontos.com/index.php?topic=4338.msg132332#msg132332
(leaving a link here because I linked the original thread in the commit message :()
-
In the SX260 porting thread,
Please check what the underlying mkdir (=MakeDirectory_Fut stub) function returns on success and failure. The lua code assumes 0 on success.
If the canon code returns something different on these cameras, the wrapper should be adjusted with a DRYOS_R... #ifdef so the chdk sees the expected return value.
You can test this on an affected camera with chdkptp, by looking up the stub address and using return call_func_ptr(address,"dirname",-1)
Note the CHDK wrapper code passes -1 as the second (unknown) param to mkdir, but it looks like for the sx260, the canon firmware passes 1 or 0.
How exactly to do this with chdkptp? Trying to debug ixus175_elph180 filewrite failure.
I could use a pointer to a script or other info source, to learn how to invoke this specific test. Thanks in advance.
edit: actually insert quoted text, clarified where quote came from.
-
How exactly to do this with chdkptp? Trying to debug ixus175_elph180 filewrite failure.
What I meant in that thread was
1) Look up the address of MakeDirectory_Fut in stubs_entry.S (or stubs_entry_2.S if defined there)
2) Use
=return call_func_ptr(... the address you got above...,"A/TESTDIR",-1)
where A/TESTDIR could be any valid path that doesn't exist. Native calls must be enabled in the CHDK menu to use call_func_ptr.
However, the above was specifically to check the return value. If the stub were wrong, regular os.mkdir in chdk Lua would crash or fail. You can use the llibtst.lua script in CHDK/SCRIPTS/TEST to test this and many other functions.
-
Speaking of debugging, how about (possibly dumbed-down) gdbserver? This (https://chdk.setepontos.com/index.php?topic=4338.msg41282#msg41282) was the latest attempt that I could find.
-
Speaking of debugging, how about (possibly dumbed-down) gdbserver? This (https://chdk.setepontos.com/index.php?topic=4338.msg41282#msg41282) was the latest attempt that I could find.
If someone wants to write it, sure... however, I suspect it would be rather difficult, and the biggest difficulties would be in implementing the debugger part rather than the communication part.
The thread you linked mentions using the DryOS console. This can be done using the physical UART or the patches in https://chdk.setepontos.com/index.php?topic=11029.30 (I'm still slowly tinkering with getting that code into the trunk)
Another thing I've considered is adding a way to watch arbitrary ranges of memory using in the chdkptp GUI. It would also be relatively easy to implement a memory browser that gives you a hex-editor style window.
-
Another thing I've considered is adding a way to watch arbitrary ranges of memory using in the chdkptp GUI.
Now that would be handy. Even more so if it can trigger on a change of one or more addresses within the range.
It would also be relatively easy to implement a memory browser that gives you a hex-editor style window.
I think we'd be happy to see that too. Hacking the DEBUG_PRINT_TO_LCD stuff at the end of core/main.c to watch memory gets old after a whie.
-
The thread you linked mentions using the DryOS console. This can be done using the physical UART or the patches in https://chdk.setepontos.com/index.php?topic=11029.30 (I'm still slowly tinkering with getting that code into the trunk)
My use case is as follows. I wrote a module that freezes the camera (not as its primary objective). If I could step into the code, that would let me pinpoint the problem. The same module happens to run smoothly on a DryOS camera, so the DryOS console wouldn't be of much use here.
-
I've got another idea (hopefully much easier to implement).
Uploading a build currently looks like this:
chdkptp/trunk/run -c -e"mup $1/SDimage/DISKBOOT.BIN A/" -e"mup $1/SDimage/PS.FI2 A/" -e"mup $1/SDimage/CHDK/MODULES -fmatch=%.flt$ CHDK/MODULES" -e"mup $1/SDimage/CHDK/DATA -fmatch=%.txt$ CHDK/DATA" -e"mup $1/SDimage/CHDK/LUALIB -fmatch=%.lua$ CHDK/LUALIB"
What if the entire zip were uploaded at once (this (https://github.com/brimworks/lua-zip) could help)?
-
My use case is as follows. I wrote a module that freezes the camera (not as its primary objective). If I could step into the code, that would let me pinpoint the problem.
Right, I'm not questioning the value of a debugger, it would be great to have. The reality is that implementing a working debugger on the cameras would be Really Hard (IMHO), and PTP communication would be a relatively minor (though non-trivial) part.
My general approach to the kind thing you describe would be to use either LEDs (just blink when a particular point is reached, move) or logging. If the camera actually crashes, messages logged with LogCameraEvent will be included in the romlog. If it doesn't crash and PTP is still working, then you can use uart redirection and ShowCameraLog (possibly with chdkptp devutil). If you want more advice debugging the specific problem with your module, please post in it's own thread.
-
I've got another idea (hopefully much easier to implement).
Uploading a build currently looks like this:
chdkptp/trunk/run -c -e"mup $1/SDimage/DISKBOOT.BIN A/" -e"mup $1/SDimage/PS.FI2 A/" -e"mup $1/SDimage/CHDK/MODULES -fmatch=%.flt$ CHDK/MODULES" -e"mup $1/SDimage/CHDK/DATA -fmatch=%.txt$ CHDK/DATA" -e"mup $1/SDimage/CHDK/LUALIB -fmatch=%.lua$ CHDK/LUALIB"
What if the entire zip were uploaded at once (this (https://github.com/brimworks/lua-zip) could help)?
I have thought about adding an "upload build' feature, but for now you can do something like
unzip <build zip> temp
chdkptp -c -e"mup temp A/"
-
I have thought about adding an "upload build' feature, but for now you can do something like
unzip <build zip> temp
chdkptp -c -e"mup temp A/"
I was thinking about a generic "upload zip" feature (e.g. no reboot is required if only modules are uploaded), but yes, that's the idea. The upload would be much faster that way.
-
Hi all.
Is it possible to modify "gui.lua" to be able to control touch-screen
models (such as IXUS 240 HS) with mouse clicking on UI Overlay screen?
-
Would some generous soul create, or point me to, a CHKD-PTP for Dummies Set up Guide?
EDIT : figured it out finally!
As a 'Dummy' with only minor unix skills, I struggled to follow the instructions for a Raspberry Pi install. Got confused between the ready built binaries and the 'roll your own' versions.
I do think the instructions might be improved a little for people like me.. adding details of how to set environment variables, connect to another computer via network to exchange files and where to place the files in the system.
Thanks for your consideration
Nigel
Byron Bay
Australia (GMT +11)
-
I just found a simple fix for the:
gphoto2 usb scan, stuffing up the switchability of the rec mode issue: uninstall gphoto
doesn't seem to affect the camera or chdkptp at all.
Please let me know if I'm losing something by doing this. The other options either didn't work or worked sporadically. ahull's suggestion of adding a kill to the gphoto daemon worked once but the next time I booted up and powered up the camera, the problem was back.
Cheers
N
PS. my camera is an IXUS160
-
gphoto2 usb scan, stuffing up the switchability of the rec mode issue: uninstall gphoto
doesn't seem to affect the camera or chdkptp at all.
Please let me know if I'm losing something by doing this. The other options either didn't work or worked sporadically.
This may stop the camera from "auto mounting" as a folder or appearing the GUI, but this would be true with any of the solutions to the rec mode problem, because the auto-mounting causes the problem.
Other methods might allow you to gphoto applications manually while still disabling the auto-mount.
I do think the instructions might be improved a little for people like me.. adding details of how to set environment variables, connect to another computer via network to exchange files and where to place the files in the system.
If you point out specific parts of the documentation that are incorrect on confusing, I'm happy to try to improve them, but IMO general pi / linux usage not specific to chdkptp is better documented elsewhere.
-
Is it possible to modify "gui.lua" to be able to control touch-screen
models (such as IXUS 240 HS) with mouse clicking on UI Overlay screen?
Oops, I meant to respond to this earlier. Better late then never I guess...
This is a good idea, and would definitely be nice on cameras with tap to focus. Unfortunately, CHDK doesn't currently have the ability to simulate touch inputs (AFAIK... philmoz or waterwingz correct me if I'm wrong). It's possible something could be done with post_logical_event_to_ui. There are various touch related levents, but I don't know how coordinates are handled if they are usable at all.
-
Unfortunately, CHDK doesn't currently have the ability to simulate touch inputs (AFAIK... philmoz or waterwingz correct me if I'm wrong).
The Powershot N code intercepts touch events differently from philmoz's implemention (mostly because the Canon code was very different and I could not copy philmoz's original work). But AFAIK the result is pretty much the same.
When active in <ALT> mode, the code interrupts the Canon firmware's touch processing software, steals the x-y position of a touch, and prevents that touch from being passed to the Canon firmware for processing.
While it might be possible to inject a "touch" into the system at the point where it's hacked out, I'm pretty sure that would not work - for a bunch of reasons. So adding the ability to create a "virtual touch" would be a new development project. Not a huge effort compared to the original stuff srsa_4c does, but work none the less.
tl;dr : you are correct - not currently available.
It's possible something could be done with post_logical_event_to_ui. There are various touch related levents, but I don't know how coordinates are handled if they are usable at all.
That would be one approach to try prior to creating a lower level touch event insertion attempt.
-
My apologies for not reading this entire thread. I have tried searching and read about half of the General discussion thread. And of course I am humbled by the depth of knowledge I see here.
I have a few SD990ISs I am running CHDK ver 1.5. (I think.) CHDKPTP ver Host 2.7 cam2.8.
I would like to be able to do a time lapse from the computer with the pictures downloading, either as they are taken or in batches at night. I can’t seem to get ultimate.lua to work from CHDKPTP. It works great on the camera if executed from the camera. I need to bea able to control these remotely without touching the camera every day, sometimes for weeks.
If I start it with “.<ultimate.lua” or =<ultimate.lua I get a:142 attempt to perform arithmetic on global ‘start_hr’ (a nil value) ***TERMINATED*** error.
I have tried grouping commands and using source to call them but as I read somewhere in one of these threads the script takes time to complete and the next command tries to execute and fails.
Is there a way to get a modified ultimate.lua to execute so I could take pictures during the day and have the pictures download at night, automated of course. I can’t seem to figure out a sleep command in a source file that will make the camera wait between remoteshoot commands.
thanks
-
If I start it with “.<ultimate.lua” or =<ultimate.lua I get a:142 attempt to perform arithmetic on global ‘start_hr’ (a nil value) ***TERMINATED*** error.
This happens because the variables set by the CHDK script menu parameters aren't defined when you run it using chdkptp.
You can get around them by defining them yourself, but in this case you can't use the < shortcut because you need additional code.
If you the script is on the camera, you can do something like
.start_hr=1 [...similar code for all the other options in the script header...] loadfile('A/CHDK/SCRIPTS/ultimate.lua')()
You could also modify ultimate.lua to check if one of the menu options is nil, and set defaults.
Note in either case the script has a lot of options and you'll need to translate them from CHDK menu syntax: http://chdk.wikia.com/wiki/CHDK_Script_Header
I know ultimate has some capability to support PTP download, but IIRC the original concept was the USB would only occasionally be plugged in to download, rather than the script being initiated over USB and constantly connected. Maybe waterwingz can elaborate.
Depending on your requirements, you might also consider using a chdkptp side script without involving ultimate at all. In that case, you could write a loop that shoots during the day and downloads everything at the end, or just downloads each shot as it's taken.
-
You could also modify ultimate.lua to check if one of the menu options is nil, and set defaults. Note in either case the script has a lot of options and you'll need to translate them from CHDK menu syntax : http://chdk.wikia.com/wiki/CHDK_Script_Header
I'll look at augmenting the code - the checking for nil idea is clever and makes for a nice side effect free upgrade to the code! Thanks for that idea.
I know ultimate has some capability to support PTP download, but IIRC the original concept was the USB would only occasionally be plugged in to download, rather than the script being initiated over USB and constantly connected. Maybe waterwingz can elaborate.
Yea - that was pretty much the idea. Start the script by pressing the shutter button and then let the script & camera do its thing unattended. Connect via USB to semi-regularly to download images. IIRC "regularly" might have been every few weeks at a really remote bird nest on an island but daily would work just as well.
Depending on your requirements, you might also consider using a chdkptp side script without involving ultimate at all. In that case, you could write a loop that shoots during the day and downloads everything at the end, or just downloads each shot as it's taken.
This is probably the best option if you have a PC that you can leave powered up 24x7. From a reliability standpoint I'd bet on a battery backed up camera running longer that any PC solution. But then, having done both, I'm a little biased.
-
Thanks for your quick and helpful response.
I suspected that they are undefined variables. I added a line: start_hr = 6 right before it is math-ed into another variable and sure enough it the error moves onto start_min, and then moves on each time I set a parameter. But I wanted to check with the experts before I go and modify the whole program. This solves the first issue. Thanks!
I will probably modify ‘ultimate’ to only shoot for a day and exit this way I can now fiddle with the next problem.
Is there a way to Sleep in either lua executed on the computer or from the CLI? I am sure you know where I am going with this. (I am assuming that I can’t ‘push’ the pictures from the camera to the computer with lua via CHDKPTP so I am attempting to ‘pull’ them with CHDKPTP.
Here is pseudo code for what I want to do:
if Time between 5am and 11pm {execute ultimateModifiedForOneDayOnly (next command waits until this is done. Is that possible?)}
if Time between 11pm and 5am {download and delete all images from camera, and then sleep until 5am}
repeat as needed
Or
if Time between 5am and 11pm
{
remoteshoot
sleep(x)
}
if Time between 11pm and 5am {sleep}
thanks much
-
I suspected that they are undefined variables.
Well, sort of. When a CHDK script running normally, they are not undefined as the header code defines them. It's part of the CHDK specification for Lua and legal syntax. The issues is how chdkptp runs scripts and how it ignores the standard CHDK first pass Lua initialization. Which leads to something that looks like undefined variables in the script code.
I added a line: start_hr = 6 right before it is math-ed into another variable and sure enough it the error moves onto start_min, and then moves on each time I set a parameter.
You understand this correctly. reyalp's suggestion was to bracket the additional code with a test to see if the first user parameter in the list shows up as undefined, and if so then manually set each one individually as you suggest here.
I will probably modify ‘ultimate’ to only shoot for a day and exit this way I can now fiddle with the next problem.
That's the really nice part about CHDK script - you can modify on the fly to your heart's content with minimal effort.
Is there a way to Sleep in either lua executed on the computer or from the CLI? I am sure you know where I am going with this. (I am assuming that I can’t ‘push’ the pictures from the camera to the computer with lua via CHDKPTP so I am attempting to ‘pull’ them with CHDKPTP.
Here is pseudo code for what I want to do:
if Time between 5am and 11pm {execute ultimateModifiedForOneDayOnly (next command waits until this is done. Is that possible?)}
if Time between 11pm and 5am {download and delete all images from camera, and then sleep until 5am}
repeat as needed
Or
if Time between 5am and 11pm
{
remoteshoot
sleep(x)
}
if Time between 11pm and 5am {sleep}
Ummm .. I'll leave this one to reyalp.
-
Yea - that was pretty much the idea. Start the script by pressing the shutter button and then let the script & camera do its thing unattended. Connect via USB to semi-regularly to download images. IIRC "regularly" might have been every few weeks at a really remote bird nest on an island but daily would work just as well.
Let's call this a "really remote bird nest on an island" with an internet connection and an ac power adapter for the camera. Therefore I can't go touch anything for weeks at a time and the SD card can't hold more than a day's worth of pix. (Actually on some of my locations I don't have an internet connection, just a big battery powering the laptop and camera. But still can't visit but every week or so)
Depending on your requirements, you might also consider using a chdkptp side script without involving ultimate at all. In that case, you could write a loop that shoots during the day and downloads everything at the end, or just downloads each shot as it's taken.
This is probably the best option if you have a PC that you can leave powered up 24x7. From a reliability standpoint I'd bet on a battery backed up camera running longer that any PC solution. But then, having done both, I'm a little biased.
This solution sounds interesting. I just need the sleep syntax. thanks
-
This solution sounds interesting. I just need the sleep syntax. thanks
In chdkptp, you can use sys.sleep() to wait for a given number of milliseconds. You can use Lua standard os.date(), os.time() and os.difftime (http://www.lua.org/manual/5.2/manual.html#6.9) to do various things with time and date.
See https://app.assembla.com/spaces/chdkptp/wiki/Scripting_Guide for some general information about scripting chdkptp.
if Time between 5am and 11pm {execute ultimateModifiedForOneDayOnly (next command waits until this is done. Is that possible?)}
if Time between 11pm and 5am {download and delete all images from camera, and then sleep until 5am}
For a once (or a few times) per a day command, you might consider just using OS scheduling (cron on *nix, windows task scheduler) to run chdkptp. If you pass commands with -e it will run them and exit when complete. So you could have a job that runs at 5 AM and does
chdkptp -c -e"lua loadfile('A/CHDK/SCRIPTS/ultimate.lua')()"
and another that runs at 11:00 PM
chdkptp -c -e"imdl -rm"
It is possible to check if a script is running on the camera, but it might be simpler to just set up the scheduling so ultimate quits before the download runs.
if Time between 5am and 11pm
{
remoteshoot
sleep(x)
}
In chdkptp lua you could do this something like
interval = 1000*60*10 -- 10 minutes in milliseconds
while true do
local hour=os.date('*t').hour
if hour >= 5 and hour <23 do
cli:execute('remoteshot')
end
sys.sleep(interval)
end
This would go in a file (say, myfile.lua) which you could run in chdkptp with
chdkptp -e"exec dofile('myfile.lua')"
caveats:
1) This is untested, off the top of my head
2) No way is provided to gracefully exit, to stop it you'd have to control+C or kill the process
A more complete example of this kind of approach can be found in https://chdk.setepontos.com/index.php?topic=13261.msg134971#msg134971
-
thanks so much. I will try these ideas.
-
Build 785 is uploaded to the files area https://app.assembla.com/spaces/chdkptp/documents
Main changes
* The linux binaries are built with symbols exported. This means you can Lua modules in .so files from chdkptp
* The lua-signal module is included with linux builds. This is not currently used by default, it's mostly there to support @manoweb's multilapse script (https://chdk.setepontos.com/index.php?topic=13261.msg134971#msg134971). There are some quirks limitations with this module, the main one being it does not work correctly if chdkptp is waiting for input with readline.
* The shoot command now allows you to specify file download names, similar to the imdl command using shoot -dl=<substitution pattern>
* remoteshoot and rsint now treat the filename as a substitution string if it contains a $ (if you really want a $ in your filename, you can use -nosubst)
* shoot, rs and rsint can number files sequentially for each shot taken using the ${shotseq} substitution. So if you use rs ${shotseq}${ext} repeatedly, you'll get 0001.jpg, 0002.jpg etc. You can set the starting number with -seq=n.
* The imdl command and multicam download_images commands can also use ${shotseq}, so you can download your images as a continuous numbered sequence independent of what the camera used.
* Multicam now has preliminary support for hardware remote triggering, using usb_pwr_sync=true in mc:shoot()
-
Awesome,
Thanks heaps Reyalp.
I'm finally testing my whole rig today to see how long the batteries will run.
Cheers
Sdack
-
Build 795 is uploaded to the files area https://app.assembla.com/spaces/chdkptp/documents
The main change is fix to be bug in the linux shell script wrappers reported by Sdack (https://chdk.setepontos.com/index.php?topic=13261.msg135673#msg135673)
There are some other minor changes, covered in the changelog https://app.assembla.com/spaces/chdkptp/wiki/Changelog
-
I am having trouble getting chdkptp to run in Ubuntu. I have it running on one of my Ubuntu 12.04 machines. But I can't seem to get it to run on any of my other Ubuntu machines. I have several and depending on the hardware they have various builds of Ubuntu running. Some 12.04 32bit some 16.04 32 and 64 bit. I was trying to stay uniform with r735 but I have downloaded r795 and I get the same results. When I click on things, including sh files, it just spins. I tried in Terminal too, no luck. In terminal it tells me the file I asked to run doesn't exist, yet an ls shows that it is there. I have checked permissions of the files. Any ideas what I am doing wrong? thanks
John
-
I was trying to stay uniform with r735 but I have downloaded r795 and I get the same results.
If you can give the specific output from starting it in a terminal, that would be helpful.
In any case, you must run either chdkptp.sh (for terminal only CLI interface) or chdkptp_gui.sh (for the GUI). Running the binary (chdkptp or chdkptp_gui) will not work.
Older versions had a bug in the .sh file, which could cause it to fail with a "not found" type error in some case.
r795 works for me on 64 bit Ubuntu 16.04 starting the .sh file from a terminal window.
Double clicking in the file manager just opens it in gvim. Going to edit->preferences->Behavior and setting "Executable Text Files" to "ask each time" allows me to run it by double clicking.
-
If you can give the specific output from starting it in a terminal, that would be helpful.
john@Betsy03-AsusK52F:~$ cd chdkptp
john@Betsy03-AsusK52F:~/chdkptp$ ls
chdkptp-r795 Scripts
john@Betsy03-AsusK52F:~/chdkptp$ cd chdkptp-r795
john@Betsy03-AsusK52F:~/chdkptp/chdkptp-r795$ ls
chdkptp COPYING README-OSX.TXT THANKS.TXT
chdkptp_gui lib README-RASPI-LIBS.TXT USAGE.TXT
chdkptp_gui.sh lua README.TXT
chdkptp.sh README-LINUX-BINARIES.TXT signal.so
john@Betsy03-AsusK52F:~/chdkptp/chdkptp-r795$ sudo ./chdkptp_gui.sh
[sudo] password for john:
/home/john/chdkptp/chdkptp-r795/chdkptp_gui: error while loading shared libraries: libusb-0.1.so.4: cannot open shared object file: No such file or directory
john@Betsy03-AsusK52F:~/chdkptp/chdkptp-r795$
-
I googled libusb-0.1.so.4 and found where it lives and it is in my system
this is where I found it: /lib/x86_64-linux-gnu/
Not sure if I am barking up the right tree.
-
john@Betsy03-AsusK52F:~/chdkptp/chdkptp-r795$ sudo ./chdkptp_gui.sh
FWIW, you should not need to run chdkptp as root, just starting as a regular user should be fine. However, running it with sudo also worked for me.
The libusb-0.1 .so is provided by the libusb-0.1 package. On my system, the .so is found correctly and is at /lib/x86_64-linux-gnu. Make sure this package is installed, if it's not you might just be seeing an old symlink or something.
can you post the output of
ldd chdkptp
and
ls -l /lib/x86_64-linux-gnu/libusb*
-
john@Betsy03-AsusK52F:~/chdkptp/chdkptp-r795$ ldd chdkptp
linux-gate.so.1 => (0xf7788000)
libusb-0.1.so.4 => /lib/i386-linux-gnu/libusb-0.1.so.4 (0xf7762000)
libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xf770d000)
libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xf7707000)
libreadline.so.6 => not found
libhistory.so.6 => not found
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf7551000)
/lib/ld-linux.so.2 (0x565dc000)
john@Betsy03-AsusK52F:~/chdkptp/chdkptp-r795$ ls -l /lib/x86_64-linux-gnu/libusb*
lrwxrwxrwx 1 root root 19 Dec 23 11:58 /lib/x86_64-linux-gnu/libusb-0.1.so.4 -> libusb-0.1.so.4.4.4
-rw-r--r-- 1 root root 30944 Jan 8 2016 /lib/x86_64-linux-gnu/libusb-0.1.so.4.4.4
lrwxrwxrwx 1 root root 19 Dec 23 11:58 /lib/x86_64-linux-gnu/libusb-1.0.so.0 -> libusb-1.0.so.0.1.0
-rw-r--r-- 1 root root 97056 Oct 23 2015 /lib/x86_64-linux-gnu/libusb-1.0.so.0.1.0
As far as sudo goes. I am a bit new to Ubuntu so if something doesn't work it gets sudo at the front. Most of the time it helps. :D
-
I noticed that when I plug the camera in the OS does not see it. All my other Ubuntu machines do. I don't think this has anything to do with chdkptp. I will reload the OS tomorrow and try again. I will let you know what happens. Thanks for trying. I really appreciate it.
John
-
I noticed that when I plug the camera in the OS does not see it. All my other Ubuntu machines do. I don't think this has anything to do with chdkptp. I will reload the OS tomorrow and try again. I will let you know what happens. Thanks for trying. I really appreciate it.
John
Note for chdkptp to be able to switch to rec mode and shoot, you very much want the OS default software to not see it. If you previously had chdkptp working on this box, that may be why. See discussion under "Interactions with default software" in the linux of https://app.assembla.com/spaces/chdkptp/wiki/Install
On the output you posted, the libusb-0.1 stuff all seems good, but I notice errors related to libreadline.
You might want to install the readline6 package or similar.
-
I reloaded and downgraded to 12.04 32bit and now when I plug the camera in, with chdkptp off, at least the OS sees the camera. I fire up CHDKptp and it sees the camera but when I go to connect chdkptp goes grey and hangs. BTW, these tests are with a SD1400, if that makes any difference. I don't think it does. I think this laptop has an issue with its USB ports.
The only machines I have gotten to work have been with 12.04 32bit. I have a stack of laptops I hope to deploy with SD1400s for time lapse projects that I have planned. Although 16.04 would be great, I don't care, if 12.04 works I will go with that. Oh, and this test is back to r735. Since that is what I have on the Windows machines I have deployed in the field already. I would prefer that all of my set ups have the same ver of chdkptp, Ubuntu and other software.
I thank you again for you thoughts and efforts.
-
I reloaded and downgraded to 12.04 32bit and now when I plug the camera in, with chdkptp off, at least the OS sees the camera.
As I mentioned before, if the OS software access the camera, this will cause problems with chdkptp.
This is unfortunately complicated, poorly documented, and distro/configuration specific. I've updated https://app.assembla.com/spaces/chdkptp/wiki/Install with the specific steps I needed to get it working on Ubuntu 16.04.
I fire up CHDKptp and it sees the camera but when I go to connect chdkptp goes grey and hangs.
I assume "goes grey and hang" means the GUI? If so, I'd suggest trying the cli, as there could be GUI problems independent of the PTP issues. It might also give more useful error output.
Sometimes system logs provide clues.
I personally prefer to pick a configuration and try to understand the problems rather than throwing every possible permutation of version at it. chdkptp works on Ubuntu 16.04 (and recent raspbian and debian), your challenge is to figure out how specifically it fails on your particular systems.
-
I agree. I only use the GUI to see if things are working before unleashing the Lua on it through the CLI. chdkptp has been solid. I never thought it was the problem. I was just hoping that you would have insight into what Ubuntu needed. Yes, going grey was in the GUI. I might just have to abandon this laptop and move on.
-
User @ftm reports successfully building chdkptp with the GUI on OSX 10.13 (High Sierra) with macports.
Build and scripts to build at https://github.com/rprr/chdkptp
They report being able to use this without default software putting the camera in the "black screen, can't switch to rec" state. I'm not clear if this was a result of some specific configuration, or is the default behavior for 10.13. They previously used USB pass-through to a virtualbox VM, which may have affected configuration. There may also be relevant options in the "Image Capture" app.
I would like to make it easier for Mac users to build/use chdkptp, so I'd appreciate any feedback anyone else has on how usable this is, if any additional configuration is required and so on.
-
While it build and runs, I have not been able to get any connection to a camera.
The MacOS PTPCamera app kicks in whenever a camera is connected and takes over the USB connection.
I can't see any options in Image Capture to stop this - you can prevent Image Capture from starting; but can't block PTPCamera.
There should be a way to do it as VMware and Virtual Box can both block the behaviour and allow the camera to connect to a VM. I just haven't found it yet.
The old tricks (in the README-OSX.TXT file) don't work anymore. You can't change the file mode on system files, and the database for PTPCamera has moved somewhere else so the gphoto script does not work.
FYI, to get this to build I had to install:
- gtk3, libusb, libusb-compat, ftgl and readline in MacPorts
- XQuartz
Phil.
-
I don't see any PTP Camera App on my Mac running 10.13.
When I start Image Capture, the camera shows up and then I can't run chdkptp. However if I quit the Image Capture, then chdkptp works.
In Image Capture, there is an option at the bottom "Connecting This Camera Opens". I have it set to "No Application".
Not sure if this helps. You may have already done this.
-
I don't see any PTP Camera App on my Mac running 10.13.
When I start Image Capture, the camera shows up and then I can't run chdkptp. However if I quit the Image Capture, then chdkptp works.
In Image Capture, there is an option at the bottom "Connecting This Camera Opens". I have it set to "No Application".
Not sure if this helps. You may have already done this.
PTPCamera is a component of Image Capture - USB PTP driver. It manages the camera connection.
You can see the process running in Activity Monitor when you connect a camera.
The option in Image Capture only defines what app should open after MacOS detects a camera has connected.
If PTPCamera is not starting when you connect a camera then there is something else going on - I'm not aware of any supported way to stop this process auto-running since El Capitan.
Phil.
-
It's odd. When I look at Activity Monitor, PTP Camera does not seem to be running on my Mac. It only shows up when I start up an app like Photos/Image Capture etc.
-
Not sure if this is relevant, but IIRC ftm mentioned having the Canon software installed an uninstalling it. ftm also used virtualbox, but I would expect that to only matter if virtualbox was actually running.
-
Not sure if this is relevant, but IIRC ftm mentioned having the Canon software installed an uninstalling it. ftm also used virtualbox, but I would expect that to only matter if virtualbox was actually running.
That is a possibility. Maybe the Canon software install disabled the Mac PTPcamera App permanently. There was also no Uninstall option. Just drag the App into the Trash.
-
Not sure if this is relevant, but IIRC ftm mentioned having the Canon software installed an uninstalling it. ftm also used virtualbox, but I would expect that to only matter if virtualbox was actually running.
That is a possibility. Maybe the Canon software install disabled the Mac PTPcamera App permanently. There was also no Uninstall option. Just drag the App into the Trash.
Something odd going on.
Tried on three different Macs, two automatically start PTPCamera whenever a camera is plugged in, the third does not.
Of the two that auto-start PTPCamera, one has Canon Utilities, the other does not. The one that doesn't start PTPCamera does not have Canon Utilities.
Phil.
-
Are all of these Macs running 10.13? I assume that no other photos related app is running? How about iCloud photos?
-
Are all of these Macs running 10.13? I assume that no other photos related app is running? How about iCloud photos?
Found the problem on my Mac's - seems like MacOS now behaves itself and does not take over devices like it used to.
On my systems, the culprit is the 'Google Backup and Synch' app (new version of Google Drive). Even though I have turned off the option to synch USB devices, the app is still opening a persistent connection to every USB device plugged in (hence the PTPCamera process).
I have sent feedback to Google; but I don't hold much hope of them ever fixing it.
Phil.
-
I'm glad this was solved.
With my script, I noticed some weirdness when running the build script versus directly running each of the build commands on the shell one by one. This was especially the case when compiling the 'cd' libraries. It wouldn't find gtk and cairo include files when running via the script and give some errors. However the build would not fail even though these errors were present. When I ran each line of the script directly on the shell, the errors went away.
I've also modified the script to use USK_PKGCONFIG=Yes.
-
I'm glad this was solved.
With my script, I noticed some weirdness when running the build script versus directly running each of the build commands on the shell one by one. This was especially the case when compiling the 'cd' libraries. It wouldn't find gtk and cairo include files when running via the script and give some errors. However the build would not fail even though these errors were present. When I ran each line of the script directly on the shell, the errors went away.
I've also modified the script to use USK_PKGCONFIG=Yes.
I didn't have any weirdness with the script.
You can reduce the number of patches to the tecgraf stuff by using GCC (with openmp) instead of the XCode compiler, and adding USE_MACOS_OPENGL=Yes and GTK_BASE=/opt/local to the script.
The iupcontrols libs aren't used so don't really need to be built.
I've attached my version of the build script and patch file if you're interested.
Phil.
-
I'm glad this was solved.
With my script, I noticed some weirdness when running the build script versus directly running each of the build commands on the shell one by one. This was especially the case when compiling the 'cd' libraries. It wouldn't find gtk and cairo include files when running via the script and give some errors. However the build would not fail even though these errors were present. When I ran each line of the script directly on the shell, the errors went away.
I've also modified the script to use USK_PKGCONFIG=Yes.
I didn't have any weirdness with the script.
You can reduce the number of patches to the tecgraf stuff by using GCC (with openmp) instead of the XCode compiler, and adding USE_MACOS_OPENGL=Yes and GTK_BASE=/opt/local to the script.
The iupcontrols libs aren't used so don't really need to be built.
I've attached my version of the build script and patch file if you're interested.
Phil.
Thanks for making these improvements. Fewer patches is always better. Which gcc are you using? Was it built from scratch?
-
Thanks for making these improvements. Fewer patches is always better. Which gcc are you using? Was it built from scratch?
Currently using GGC 8 installed with MacPorts.
Phil.
-
Currently using GGC 8 installed with MacPorts.
Phil.
That worked great. Thanks.
Edit to add: I've incorporated your suggestions into my github page.
-
Inspired by ftm's script, I decided to put together a quick script that worked for other platforms too. It uh... got a little out of hand :haha
Anyway, misc/setup-ext-libs.bash in the chdkptp source is the result.
It probably doesn't work completely on mac, but I think it should be pretty close. Feedback would be greatly appreciated.
It should work out of the box for many linux platforms (including raspberry pi) and windows with msys or msys2
It tries to do the following
* Download required source and/or binary packages
* extract sources and apply any required patches
* build
* extract or copy files required by chdkptp build a standardize directory tree
* copy runtime shared libraries to chdkptp/lib
The script has a bunch of options, which can be seen by passing -help
Most of the steps above can be skipped by passing a -no* option.
-pretend prints what it would do without doing anything
By default, files are only downloaded if they don't exist in the archive directory.
The script in a standardized directory tree, which defaults to extlibs/ under the chdkptp source directory. The default makefile settings are set to use this tree, so a customized config.mk should no longer be required in most cases.
The chdkptp makefiles now attempt to build GUI if you pass GUI=1 on the make command line. You should make clean between GUI and non-GUI builds.
The extlibs tree contains
/archive : downloaded zip + tgz files.
/src : extracted and patched sources
/built : built or extracted libraries, includes etc, and logs from builds.
On windows, only pre-compiled CD and IUP are supported.
On intel Linux, it defaults to pre-compiled but this can be overridden with -force-tec-src. Tecgraph appears to have stopped distributing 32 bit binaries for later versions of IUP, so build from source will become the default for those at some point. On Ubuntu, I found building from source avoided some GUI uglyness.
On other platforms, it attempts to build the minimum CD / IUP components. IM and some of the opengl dependencies are no longer required.
Prerequisites
* Normal development stuff, i.e. build-essential on Debian distros
* wget - You can download manually using URLs listed by pretend
* unzip (Info-ZIP compatible)
* For GUI, the CD/IUP prerequisites. On Debian based systems, something like:
g++ libfreetype6-dev libgtk-3-dev libx11-dev libxpm-dev libxmu-dev libxft-dev
On non windows platforms, chdkptp also requires libusb-dev and defaults to using libreadline-dev
* On Windows, MSYS or MYS2 is assumed
* On Mac, python is required
-
How to make DNG Remote Shoot without capturing the picture?
i.e. camera's raw buffer already contains raw data (https://chdk.setepontos.com/index.php?topic=12754.msg135922#msg135922) and I need to create DNG file on PC without saving it on SD card.
Or maybe there is a simple way to create DNG file in RAM?
At the moment I just call capt_seq_hook_raw_here() but this is not convenient for experiments because I have to select and copy DNG file manually.
-
How to make DNG Remote Shoot without capturing the picture?
Remoteshoot is pretty complicated and tightly connected to the shooting process, so you'll need to dig into both the chdkptp and camera side code. I think the actual capture_get_data stuff should be mostly but you need a new camera side script (rlibs.lua rs_shoot) to initiate it. On the CHDK side you'd need to make sure remotecap_is_ready and remotecap_get_data_chunk do the right thing.
If your shooting process calls the raw hook code this might "just work", as long as init_usb_capture is called from lua with appropriate values beforehand.
i.e. camera's raw buffer already contains raw data (https://chdk.setepontos.com/index.php?topic=12754.msg135922#msg135922) and I need to create DNG file on PC without saving it on SD card.
Or maybe there is a simple way to create DNG file in RAM?
You could use con:getmem to just read the data directly, and then reverse byte order and combine it with a pre-exisiting DNG header. Note getmem returns a lua string, which you'd need to convert to an lbuf to use the existing chdkptp DNG code. I should add an lbuf option added in r829.
The CHDK DNG header code relies on propcases which probably aren't valid if you aren't using the normal shoot process, so using a fake header may not be much of a disadvantage.
Most of the propcases should update in halfshoot, so you could potentially get reasonable data if the non-shoot exposure uses those values.
-
Inspired by ftm's script, I decided to put together a quick script that worked for other platforms too. It uh... got a little out of hand :haha
Anyway, misc/setup-ext-libs.bash in the chdkptp source is the result.
It probably doesn't work completely on mac, but I think it should be pretty close. Feedback would be greatly appreciated.
@ reyalp -- Thanks for working on this script. I have not had time to fully explore it but the build seemed to fail on my Mac. This happened when 'cd' was being built. A quick look at the log showed that the problem was when compiling cdcairoprn_unix.c. Errors such as
In file included from cairo/cdcairoprn_unix.c:15:0:
/opt/local/include/gtk-3.0/unix-print/gtk/gtkprintunixdialog.h:22:2: error: #error "Only <gtk/gtkunixprint.h> can be included directly."
#error "Only <gtk/gtkunixprint.h> can be included directly."
^~~~~
In file included from /opt/local/include/gtk-3.0/unix-print/gtk/gtkprintunixdialog.h:26:0,
from cairo/cdcairoprn_unix.c:15:
/opt/local/include/gtk-3.0/unix-print/gtk/gtkprinter.h:22:2: error: #error "Only <gtk/gtkunixprint.h> can be included directly."
#error "Only <gtk/gtkunixprint.h> can be included directly."
^~~~~
/opt/local/include/gtk-3.0/unix-print/gtk/gtkprinter.h:71:1: error: unknown type name 'GDK_AVAILABLE_IN_ALL'; did you mean 'ATK_AVAILABLE_IN_ALL'?
GDK_AVAILABLE_IN_ALL
^~~~~~~~~~~~~~~~~~~~
ATK_AVAILABLE_IN_ALL
-
I will try to play with it some more over the weekend.
Thanks for testing. Those errors look like they are somehow related to the
CPATH=/opt/local/include/gtk-3.0/unix-print
stuff. I put this as a makefile command line option instead of an environment variable, but I think that should be equivalent. Quite possible I messed something up though...
-
You could use con:getmem to just read the data directly, and then reverse byte order and combine it with a pre-exisiting DNG header.
I created dng using this code:
local hh,err=io.open("dng_header.bin","rb")
if not hh then
return false, err
end
local h = hh:read("*a")
hh:close()
local r = con:getmem(0x4464F8C8, 0x02969FE0)
local fh,err=io.open("test_raw.dng","wb")
if not fh then
return false, err
end
fh:write(h)
fh:write(r)
fh:close()
But how to reverse byte order on PC side using LUA only? (I did not found WIN32 binary for r829)
-
You could use con:getmem to just read the data directly, and then reverse byte order and combine it with a pre-exisiting DNG header.
I created dng using this code:
local hh,err=io.open("dng_header.bin","rb")
if not hh then
return false, err
end
local h = hh:read("*a")
hh:close()
local r = con:getmem(0x4464F8C8, 0x02969FE0)
local fh,err=io.open("test_raw.dng","wb")
if not fh then
return false, err
end
fh:write(h)
fh:write(r)
fh:close()
But how to reverse byte order on PC side using LUA only? (I did not found WIN32 binary for r829)
You can make an lbuf from from the string returned by getmem
local lb=lbuf.new(r)
lb:reverse_bytes()
To write the lbuf, you need to use lb:fwrite(fh)
lbuf.c is fairly well commented.
Note this will use 2x DNG memory size for each shot. If you shoot a lot, you might want to do collectgarbage('collect') occasionally. Lua collects automatically, but in some cases it can let a lot of uncollected stuff pile up.
-
Note this will use 2x DNG memory size for each shot. If you shoot a lot, you might want to do collectgarbage('collect') occasionally. Lua collects automatically, but in some cases it can let a lot of uncollected stuff pile up.
Will this prevent the creation of 2 buffers?
local lb=lbuf.new(con:getmem(0x4464F8C8, 0x02969FE0))
-
Will this prevent the creation of 2 buffers?
local lb=lbuf.new(con:getmem(0x4464F8C8, 0x02969FE0))
No, con:getmem will still create the string, it will just be eligible for garbage collection as soon as the call completes. In a local, it would be eligible when the local went out of scope.
This shouldn't be a big deal, I only mentioned it because it's possible if you took lots of shots you'd find chdkptp taking up hundreds of megs of memory when you didn't expect it.
-
In r832, I added support for remoteshoot to control shooting with a user supplied script.
With a little "glue" code to set the menu options, this allows you to use normal camera side intervalometers, bracketing scripts etc without modification, or write your own logic to control exposure etc. Discussion and example with rawopint in https://chdk.setepontos.com/index.php?topic=13386.msg136688#msg136688
A minimal script just needs to shoot the same number of shots as passed to remoteshoot with the -shots= option. Remoteshoot setup (init_usb_capture etc) is handled in the usual way prior to running the user script.
The options normally passed to camera side code are available in rs_opts. The functions from rlibs rs_shoot are also available.
A minimal example:
for i=1,rs_opts.shots do
shoot()
end
Thanks @Bluestone_7 for the discussion that prompted this.
-
Hi reyalp,
thanks a lot for your excellent job.
Yesterday I played with the remoteshoot function.
This shouldn't be a big deal, I only mentioned it because it's possible if you took lots of shots you'd find chdkptp taking up hundreds of megs of memory when you didn't expect it.
My Windows 7 PC (8gb RAM) will clear the RAM if chdkptp exceeds 900 mb of memory. It shot 1500 pictures (about 6gb) without any problem.
My RPi3 (1gb RAM) with Raspian does not clear the RAM, so it crashes. The following pictures are saved to the camera SD card (as you mentioned in https://chdk.setepontos.com/index.php?topic=13386.msg136688#msg136688 (https://chdk.setepontos.com/index.php?topic=13386.msg136688#msg136688)). Sometimes the RPi will clear the RAM once or maybe twice, but it crashes always. My best attempt was about 800 pictures.
code I used:
rs /media/pi/KINGSTON/1500fotos/${ldate}${ext} -shots=1500 -int=2Saving the pictures to the OS-microSD card or to an USB device, doesn´t change the problem.
-
My Windows 7 PC (8gb RAM) will clear the RAM if chdkptp exceeds 900 mb of memory. It shot 1500 pictures (about 6gb) without any problem.
My RPi3 (1gb RAM) with Raspian does not clear the RAM, so it crashes. The following pictures are saved to the camera SD card (as you mentioned in https://chdk.setepontos.com/index.php?topic=13386.msg136688#msg136688 (https://chdk.setepontos.com/index.php?topic=13386.msg136688#msg136688)). Sometimes the RPi will clear the RAM once or maybe twice, but it crashes always. My best attempt was about 800 pictures.
Thanks for the report. I should have a fix for this later today.
-
@Bluestone_7
I checked in a workaround for the remoteshoot memory issues in chdkptp r835. Update to the latest lua files to use it.
-
Hi reyalp,
thank you very much.
I just tried it and it works perfectly.
-
As discussed in this thread (https://chdk.setepontos.com/index.php?topic=13416.10) I was able to get CHDK PTP working on OpenSuse Leap 42 using a slight modification of the instructions for Fedora 27.
The only difference is in the line to insert below. From the install instructions for Fedora 27:
edit /etc/udev/rules.d/40-libgphoto2.rules, immediately below the line
ENV{ID_USB_INTERFACES}=="", IMPORT{program}="usb_id --export %%p"Add
ENV{ID_USB_INTERFACES}=="*:060101:*", ATTRS{idVendor}=="04a9", MODE="0664", GOTO="libgphoto2_rules_end"
For OpenSuse I inserted the same line below:
ENV{ID_USB_INTERFACES}=="", IMPORT{builtin}="usb_id"
Also as discussed I was not able to open an Assembla account, so I'm providing feedback here just in case other OpenSusers come up against the same problem.
-
As discussed in this thread (https://chdk.setepontos.com/index.php?topic=13416.10) I was able to get CHDK PTP working on OpenSuse Leap 42 using a slight modification of the instructions for Fedora 27.
Thanks for the note. I'm not sure how much distro specific detail it's worth including, but it's good to have another data point.
I moved the ixus240 related post back to the other thread: https://chdk.setepontos.com/index.php?topic=13416.10
-
Discussion about set_zoom split to https://chdk.setepontos.com/index.php?topic=13540.msg138182
Unicode related discussion quoted below to keep in this thread
2. question about special (not A-Z) characters after the path command when in rsint mode
What characters are supported after the path command? Could support be added for characters such as the german ü ?
For example if we start rsint mode and then enter the commands
path C:/1ü2/1
s
one would expect the file
C:/1ü2/1.jpg
But in my tests the image is instead saved as
C:/12/1.jpg
where the character between 1 and 2 is https://unicode-table.com/en/search/?q=%C2%81 , a character not visible in File Explorer in Windows 10
Unfortunately, chdkptp currently isn't unicode aware at all, so I'd recommend sticking to straight ANSI for now. Maybe I can fix this in the future.
Ok, I'll make users stick to A-Z 0-9 Space in paths for now.
You can allow other ASCII symbols if you want (_-+= etc), excluding any the OS disallows of course.
Spaces may be a problem in some contexts, but as long as you've tested that it works it should be fine. For most normal chdkptp commands (download, rs etc), spaces would need to be quoted, but rsint has it's own parsing.
-
Build 921 is posted on the files pages: https://app.assembla.com/spaces/chdkptp/documents
Highlights:
Windows builds should no longer have issues that caused sleep and time measurement to have only ~15ms precision in some cases. This could substantially affect multicam sync, and cause some operations to be significantly slower than they needed to be.
Linux intel and raspberry pi builds should run on modern distros. Tested on raspbian 10, Ubuntu 19.10, Fedora 31.
Building on Linux and msys2 should be much simpler than it used to be:
* Check out the source from https://subversion.assembla.com/svn/chdkptp/trunk or download it from https://app.assembla.com/spaces/chdkptp/subversion/source/HEAD/trunk using the download button
* Install any required distro-provided dependencies. Common ones are listed in the readme or the output of misc/setup-ext-libs.bash -h
* From the root of the chdkptp source, run misc/setup-ext-libs.bash
* It will download, extract, and build as needed. If it works, you can then just run make in the source tree to build chdkptp (you still need to set GUI=1 if you want the GUI)
setup-ext-libs.bash likely does not work on OSX, but I think I fixed the bug in the script @ftm encountered in https://chdk.setepontos.com/index.php?topic=6231.msg135956#msg135956
A bunch of improvements to multicam and other changes described in the changelog https://app.assembla.com/spaces/chdkptp/wiki/Changelog (where assembla's textile engine didn't eat it >:( )
-
setup-ext-libs.bash likely does not work on OSX, but I think I fixed the bug in the script @ftm encountered in https://chdk.setepontos.com/index.php?topic=6231.msg135956#msg135956 (https://chdk.setepontos.com/index.php?topic=6231.msg135956#msg135956)
Mostly works on MacOS (10.15.1) with a couple of tweaks:
- requires -nogui option (CD does not build anymore, I've given up trying to make it work)
- copy_runtime does not copy the Lua libs if -nogui is set
- the path for the Lua libs in liblist-osx.txt should be lua52/lib not lua
Phil.
-
Mostly works on MacOS (10.15.1) with a couple of tweaks:
Thanks for checking.
- requires -nogui option (CD does not build anymore, I've given up trying to make it work)
Does the version from https://chdk.setepontos.com/index.php?topic=6231.msg135842#msg135842 still build with that procedure? Those libs should still work with chdkptp.
If you don't want to mess with it, that's totally fine.
- copy_runtime does not copy the Lua libs if -nogui is set
- the path for the Lua libs in liblist-osx.txt should be lua52/lib not lua
Hmm, on the other platforms I link lua statically. There's a special case in copy_built_lua to make a dylib, if you leave that out can it just link to the .a?
-
- requires -nogui option (CD does not build anymore, I've given up trying to make it work)
Does the version from https://chdk.setepontos.com/index.php?topic=6231.msg135842#msg135842 (https://chdk.setepontos.com/index.php?topic=6231.msg135842#msg135842) still build with that procedure? Those libs should still work with chdkptp.
If you don't want to mess with it, that's totally fine.
CD hasn't built since Mojave. They don't even provide pre-built MacOS libraries anymore.
I only use the command line stuff in MacOS - if I need the gui I use a Debian VM.
- copy_runtime does not copy the Lua libs if -nogui is set
- the path for the Lua libs in liblist-osx.txt should be lua52/lib not lua
Hmm, on the other platforms I link lua statically. There's a special case in copy_built_lua to make a dylib, if you leave that out can it just link to the .a?
That works thanks. I changed copy_built_lua to create the liblua52.a link instead of the dylib files.
-
That works thanks. I changed copy_built_lua to create the liblua52.a link instead of the dylib files.
Thanks. I made it default to nogui on OSX, and changed the lua lib link to be the same as linux.
-
In chdkptp r924, I added some commands to the devutil module for working with non-CHDK PTP operations.
In particular, dptpsendobj allows uploading files to a camera without CHDK installed, which may save some round trips with the card reader while porting.
Note that some cameras crash if the upload file name does not include A/, while other crash if it does. I don't know which are which. A540 requires A/, while IIRC all my other cameras do not.
devutil can be loaded with
!require'extras/devutil'.init_cli()
which can be included in your user.chdkptp startup file.
devutil has a number of other goodies, which aren't new but may not have been described here
dromlog downloads the romlog, automatically decodes vxworks
The dprop* commands allow you to snapshot and compare propcase values
dl* allow you start and stop UART redirect logging (on cameras that support it), and download the UART and camera logs
-
Hi all, I'm just getting started with chdkptp on OSX. I've tried running
chdkptp -elist and ./chdkptp.sh -elist but I keep getting the following output:
open_camera_dev_usb: ptp_opensession failed 0x2ff
Device status OK
open_camera_dev_usb: ptp_opensession 2 failed: 0x2ff
!1: b=020 d=028 ERROR: connection failed
Is that normal? I suspect something is trying to access the USB port. Is there a fix to this? I'm on 10.13.6.
EDIT: Solved! I forgot to run sudo chmod -x "/System/Library/Image Capture/Devices/PTPCamera.app/Contents/MacOS/PTPCamera"
-
The build system with msys2 that I set up to build CHDKPTP which works fine on 874 which was then current fails on 925. The error I get is undefined reference to "clock_gettime" and to "clock_getres". Stackoverflow suggests to add -lrt to the end of the gcc call (https://stackoverflow.com/questions/2418157/c-error-undefined-reference-to-clock-gettime-and-clock-settime) to fix that on earlier versions of gcc but I did not figure out how to do just that in the makefile.
gcc --version reports 4.8.2
gcc -Wall filename.c -lrt -O2For gcc version 4.6.1, -lrt must be after filename.c otherwise you get a link error.
-
The build system with msys2 that I set up to build CHDKPTP which works fine on 874 which was then current fails on 925. The error I get is undefined reference to "clock_gettime" and to "clock_getres". Stackoverflow suggests to add -lrt to the end of the gcc call (https://stackoverflow.com/questions/2418157/c-error-undefined-reference-to-clock-gettime-and-clock-settime) to fix that on earlier versions of gcc but I did not figure out how to do just that in the makefile.
Try adding adding rt to SYS_LIBS, like
SYS_LIBS=ws2_32 kernel32 winmm rt
But the stack overflow you linked in is for linux, so this may not be the solution on windows. My environment does not have an 'rt' lib. mingw targets would generally be expected to use microsoft runtime libraries.
chdkptp won't try to use clock_* if CLOCK_MONOTONIC is not defined, so you could undefine that, I guess.
gcc --version reports 4.8.2
My msys2 gcc is 9.2.0 :blink:
-
gcc --version reports 4.8.2
My msys2 gcc is 9.2.0 :blink:
That's great because it means it works. If I recall right I had trouble with putting the extlibs folder together so that it would work on current gcc, the error I was getting which I forgot but could probably reproduce by trying again with what I have suggested that I needed to use the same version of gcc as the iup and/or lua files had been compiled with and gcc 4.8 worked so I didn't try to do more. Would you zip your extlibs folder that works with gcc 9.2 and throw it on some file host? I'd then conveniently set up a current mingw instead of a legacy one...
-
Would you zip your extlibs folder that works with gcc 9.2 and throw it on some file host? I'd then conveniently set up a current mingw instead of a legacy one...
setup-ext-libs.sh should work in an msys2 mingw shell. At the very least, -pretend should give you the download links for the CD and IUP files. It currently uses the mingw6 files.
-
So, there is an automatism I missed or neglected to look for. Good to know.
I put it together manually. I'll try the script with current mingw. I'll also try undefining what you pointed out.
-
So, there is an automatism I missed or neglected to look for. Good to know.
Setting it up manually was the recommended way before the last release
The script is misc/setup-ext-libs.bash
Use -help for options.
edit:
I'll also try undefining what you pointed out.
CLOCK_MONOTONIC comes from the msys/mingw headers, so one would expect the functions to be available in the runtime libraries if defined. Undefining it would be a last resort.
-
So, there is an automatism I missed or neglected to look for. Good to know.
Setting it up manually was the recommended way before the last release
What a relief, I thought I had missed that it was easy to do. Well, thanks for making it easy.
For anyone doing this later This Msys2 / MinGW writeup seems worthwhile (http://www.gaia-gis.it/gaia-sins/mingw64_how_to.html), details building a lot of other interesting stuff on Windows as well. Once the basic steps are through get CHDKPTP trunk, run reyalps great new script misc/setup-ext-libs.bash and build CHDKPTP with make.
-
I noticed that the GUI buttons for wheel do not use the wheel related camera side functions, but fixed logical events instead. It was a bit misleading until I peeked into the camera log and found events there I did not send.
I then used the following and it worked.
Index: lua/gui.lua
===================================================================
--- lua/gui.lua (revision 829)
+++ lua/gui.lua (working copy)
@@ -366,7 +366,7 @@
title='wheel l',
size='45x15',
action=function(self)
- gui.execquick('post_levent_to_ui("RotateJogDialLeft",1)')
+ gui.execquick('wheel_left()')
end,
},
iup.fill{
@@ -375,7 +375,7 @@
title='wheel r',
size='45x15',
action=function(self)
- gui.execquick('post_levent_to_ui("RotateJogDialRight",1)')
+ gui.execquick('wheel_right()')
end,
},
expand="HORIZONTAL",
The downside of using wheel_left and wheel_right is that some ports do not have the right implementation. On the other hand, there are cameras with wheels that use different levents, or even a sequence of levents. I wonder what could be the best way to deal with this issue.
-
I noticed that the GUI buttons for wheel do not use the wheel related camera side functions, but fixed logical events instead. It was a bit misleading until I peeked into the camera log and found events there I did not send.
Thanks for bringing that up. I switched it to use CHDK wheel functions in r929. I don't remember if I had a specific reason for using levents originally.
The downside of using wheel_left and wheel_right is that some ports do not have the right implementation.
We can fix them if anyone complains.
IIRC, one difference with the events is they work on some cameras without a jogdial. However, it's mostly equivalent to left / right anyway, and people can still use them from the console if they really want.
-
Hi, just discovered the CHDK project and chdkptp and it's phenomenal, really unlocks what Canon in their infinite wisdom have decided to prevent you doing with your camera!
I've been using the live preview feature to get my camera view into OBS and it's been working great except the live preview is definitely not updating at the refresh rate that the Statistics box states, it seems like it's about half of that. Is there some way to get the live preview window in the app itself to run at a higher refresh rate?
edit: Another thought that I had was that you might be able to achieve better quality and framerate at the expense of latency by streaming recorded video onto the host computer as a video file, in a format like mkv that can be read like a buffer. I've tried simply starting to record video and then starting a Pic&Video download but this doesn't seem to work, potentially because the camera is storing the video being recorded seperately then creating the DCIM file once it finishes.
-
I've been using the live preview feature to get my camera view into OBS and it's been working great except the live preview is definitely not updating at the refresh rate that the Statistics box states, it seems like it's about half of that. Is there some way to get the live preview window in the app itself to run at a higher refresh rate?
The way live view works is the client polls the camera periodically for frame data, set the the "target FPS" control, limited to whatever throughput the client can sustain.
This is not synchronized with the actual refresh rate on the camera, and on CHDK ports without vid_get_viewport_live_fb implemented, only every third frame on the camera will actually be seen. What camera are you using?
In low light, some cameras may also reduce the physical refresh rate.
edit: Another thought that I had was that you might be able to achieve better quality and framerate at the expense of latency by streaming recorded video onto the host computer as a video file, in a format like mkv that can be read like a buffer.
Yeah, streaming video file data would potentially be good, but would require a bunch of reverse engineering that hasn't been done.
I've tried simply starting to record video and then starting a Pic&Video download but this doesn't seem to work, potentially because the camera is storing the video being recorded seperately then creating the DCIM file once it finishes.
This definitely won't work. While your computer may present the camera as something like a file system, it actually communicates using PTP, which is much more limited.
-
Thanks very much for responding, my aim at the moment is basically just to get up to maybe 20-30fps to have vaguely smooth video as an alternative to a webcam given that I don't really want to order one atm. The framerate is still noticeably low (I'd judge ~10fps) when the slider is set to 30fps and the reported framerate is at about 20fps, so should I have a go at modifying the PTP live view scripts on the camera itself to change this behaviour?
-
The framerate is still noticeably low (I'd judge ~10fps) when the slider is set to 30fps and the reported framerate is at about 20fps, so should I have a go at modifying the PTP live view scripts on the camera itself to change this behaviour?
There's not much to change. If you post which camera you are using, I can check if vid_get_viewport_live_fb is implemented. If it's not, it can probably be added.
Also, what OS and version of chdkptp are you using?
-
Using a G15 PowerShot with firmware 100e, with CHDK 1.4.1 r5414, and I'm on Windows 10
-
Using a G15 PowerShot with firmware 100e, with CHDK 1.4.1 r5414, and I'm on Windows 10
Thanks. Looks like vid_get_viewport_live_fb is not correctly implemented on this port, so you are only seeing every 3rd frame at most, likely resulting in 10 FPS as you suspected. I should be able to post a test build in the next few days, unless someone beats me to it.
-
G15 test build posted in the porting thread: https://chdk.setepontos.com/index.php?topic=9257.msg143050#msg143050
-
The last few days I've been playing with Ubuntu 20.04 under VM and chdkptp works pretty well, both versions, CLI and GUI.
In the latest distribution libreadline.so.6 has been upgraded to libreadline.so.8, this solves the problem:
cd / lib / x86_64-linux-gnu /
sudo ln -s libreadline.so.8.0 libreadline.so.6
sudo ln -s libhistory.so.8.0 libhistory.so.6I have no clue about working on Linux, the last time I worked on a Unix / Linux system was in the early 90s, maybe there is a better solution but I only remembered this. :D
The problem with gpphoto still exists but this solution works well: https://app.assembla.com/spaces/chdkptp/wiki/Install
Maybe this will help someone even bigger novice than me.
The next step is compiling under Linux. :P
-
The last few days I've been playing with Ubuntu 20.04 under VM and chdkptp works pretty well, both versions, CLI and GUI.
In the latest distribution libreadline.so.6 has been upgraded to libreadline.so.8, this solves the problem:
cd / lib / x86_64-linux-gnu /
sudo ln -s libreadline.so.8.0 libreadline.so.6
sudo ln -s libhistory.so.8.0 libhistory.so.6I have no clue about working on Linux, the last time I worked on a Unix / Linux system was in the early 90s, maybe there is a better solution but I only remembered this. :D
Thanks for the report.
Which chdkptp build is this? The 921 snapshot is supposed have readline and the related libraries statically linked to avoid this.
Using symlinks like this isn't recommended since the ABIs are actually different, but I suspect it would work for chdkptp in this case.
The next step is compiling under Linux. :P
It should be relatively easy these days
download and configure external libraries with
misc/setup-ext-libs.bash
then make to build. editing config.mk shouldn't be required any more (if you are building in an existing source tree, it would be good to remove any old config.mk and start fresh).
-
Which chdkptp build is this? The 921 snapshot is supposed have readline and the related libraries statically linked to avoid this.
Using symlinks like this isn't recommended since the ABIs are actually different, but I suspect it would work for chdkptp in this case.
Older r795,I didn't choose the latest one, I was just interested in whether it works under VM. This way I struggled a bit and learned something new.
It should be relatively easy these days
download and configure external libraries with
misc/setup-ext-libs.bash
then make to build. editing config.mk shouldn't be required any more (if you are building in an existing source tree, it would be good to remove any old config.mk and start fresh).
Thanks for the advice!
-
For review - quick & dirty patch to make chdkptp work with Lua 5.3.
Changes:
- copy code for luaL_register and luaL_optint from Lua 5.2 to luautil.h & luautil.c
- add fixes for deprecated loadstring, unpack and table.maxn functions in main.lua
- change %d format strings to %.0f (Lua 5.3 won't convert float to int unless the float is an exact integer value)
All tests in 'test.lua' and 'camtests.lua' pass on MacOS Catalina and Debian (LMDE 2).
IUP/CD GUI appears to work correctly (Debian).
Notes:
- table.maxn patch uses #t for table length, not sure if this is ok as the two are not identical
- there may still be other '%d' format strings that need changing.
Phil.
-
For review - quick & dirty patch to make chdkptp work with Lua 5.3.
Thanks, much appreciated.
Out of curiosity, did you run into something that requires to you use 5.3? The current recommended process using misc/setup-ext-libs.bash should be completely self contained without dependency on system installed Lua.
Supporting 5.3 and dropping 5.1 support have been on my TODO list forever, so it's not wasted effort in any case.
-
:-[ if (os.stat(LOG_NAME)) then
Lua 5.3.4 Copyright (C) 1994-2017 Lua.org, PUC-Rio
File:52: attempt to call a nil value (field 'stat')
-
:-[ if (os.stat(LOG_NAME)) then
Lua 5.3.4 Copyright (C) 1994-2017 Lua.org, PUC-Rio
File:52: attempt to call a nil value (field 'stat')
os.stat is a CHDK addition to camera side Lua (which is still version 5.1). If you want equivalent operations in chdkptp PC side Lua, you would use lfs.attributes
-
:) Maybe You want to test Emulator with Keywords updated until set_clock here:
-
Notes:
- table.maxn patch uses #t for table length, not sure if this is ok as the two are not identical
I had to jog my memory a bit for this one, but it's not. From the 5.1 manual (maxn was already deprecated in 5.2)
Returns the largest positive numerical index of the given table, or zero if the table has no positive numerical indices. (To do its job this function does a linear traversal of the whole table.)
This allows holes, which ends up being important for cases like camera side code doing
return 1, nil, 2
and the PC side code putting return values the values into an array (see con_methods:exec toward the end)
I should add something to camtests for this.
There are also some other cases that rely on this behavior.
Anyway, this can be fixed with a trivial, inefficient Lua implementation of maxn.
-
Notes:
- table.maxn patch uses #t for table length, not sure if this is ok as the two are not identical
I had to jog my memory a bit for this one, but it's not. From the 5.1 manual (maxn was already deprecated in 5.2)
Anyway, this can be fixed with a trivial, inefficient Lua implementation of maxn.
Thanks for that. To avoid any conversion issue I copied the C code for maxn from 5.2 and added it to the 'sys' table on startup.
Updated patch also fixes lsignal.c (luaL_register), %d format strings in gui_live_stats.lua and a copy/paste typo in gui_user.lua.
Phil.
-
Wow, nice work. I'll have to think about what the way forward is, it would be nice not to maintain two parallel versions of the GUI.
I just checked in the 5.3 support stuff, along with support in makefile and setup scripts, in r948
Everything defaults to Lua 5.2. To use Lua 5.3
misc/setup-ext-libs.bash -lua-ver=53
add USE_LUA_VER=53 to config.mk
misc/bin-snapshot.bash -libs=linux-lua53
(Windows doesn't require -libs since it's all static)
I think there are still some corner cases involving integer format strings, but I don't expect the changes to cause any problems in 5.2.
-
Split the lgi / new gui discussion to https://chdk.setepontos.com/index.php?topic=14117.0
It's a little disjointed with the Lua 5.3 stuff (which I mostly left here), but I think it makes sense to have it's own thread, and this one is already quite long ;)
-
Since my Windows Update from 7 to 10, my CHDKPTP no longer works.
The libusb0.dll cannot be found.
I've already tried to reinstall the driver with zadig-2.5.exe, but it didn't work.
What else can i do?
-
:-[ Use Zadig again, it´s easy to miss a mouseclick.
-
It works again now. I can't say what exactly it was. I just used a different USB port.
-
Build 964 is posted on the files pages: https://app.assembla.com/spaces/chdkptp/documents
Main purpose is to provide a build that supports CHDK 1.5 Canon raw remote shoot. I also added a CLI command 'clock' which allows setting the camera clock or synchronizing it to the host. Other tweaks and fixes are listed in the changelog https://app.assembla.com/spaces/chdkptp/wiki/Changelog
Linux builds tested on Raspberry Pi OS (formerly raspbian) 10, Debian 10, Ubuntu 20.04 and 20.10, Fedora 31 and 33.
These builds are still use Lua 5.2, and do not include philmoz alternate GUI.
-
The chdkptp trunk now supports philmoz lgi gui. Details: https://chdk.setepontos.com/index.php?topic=14117.0
-
The chdkptp trunk now supports philmoz lgi gui. Details: https://chdk.setepontos.com/index.php?topic=14117.0 (https://chdk.setepontos.com/index.php?topic=14117.0)
Awesome!
-
os.stat is a CHDK addition to camera side Lua (which is still version 5.1). If you want equivalent operations in chdkptp PC side Lua, you would use lfs.attributes
http://keplerproject.github.io/luafilesystem/manual.html :)
-
Hi all! Thanks for making this great program!!
I'm using a s95 and my live viewport shows only the top half? What am I doing wrong? Photos turn out fine - I just can't see half of what I'm shooting!!
Thanks for any advice / guidance :)
-
Hi all! Thanks for making this great program!!
I'm using a s95 and my live viewport shows only the top half? What am I doing wrong? Photos turn out fine - I just can't see half of what I'm shooting!!
It looks like the viewport functions in the s95 port are probably incomplete, which firmware do you have?
Also, can you check the zebra function like described here https://chdk.fandom.com/wiki/Testing#Zebra_test (using the camera LCD, not chdkptp)
-
Thank you for the super-fast reply!! <3
It looks like the viewport functions in the s95 port are probably incomplete, which firmware do you have?
Stick installed 100h-1.5.1-5646
Also, can you check the zebra function like described here [link] (using the camera LCD, not chdkptp)
Ok! - the blanked out section identified by the zebra tracked to each of the four corners of the LCD as I moved the camera around, and stayed on top of the bright light.
Cheers
-
Hey I created a svn package for Archlinux with gtk gui enabled https://aur.archlinux.org/packages/chdkptp-svn/
Have fun _)
-
Ok! - the blanked out section identified by the zebra tracked to each of the four corners of the LCD as I moved the camera around, and stayed on top of the bright light.
Thanks. Test build posted in https://chdk.setepontos.com/index.php?topic=5641.msg144858#msg144858
-
Thanks.
No, thank you!! I really appreciate your efforts to try and fix this issue :)
I updated s95 firmware with your test build, new version number was on splash screen. Something has definitely changed - the UI wasn't appearing at all previously, and now displays. However, the halved viewport remains :( I cycled through all the options, and oddly enough FISHEYE shows the entire scene correctly, albeit skewed by the fisheye effect.
Happy to try any troubleshooting directions or advice you might have, let me know how I can help!
Cheers
-
Happy to try any troubleshooting directions or advice you might have, let me know how I can help!
Updated build, turns out the cam I copied from also had the smaller viewport height :-[ https://chdk.setepontos.com/index.php?topic=5641.msg144864#msg144864
If the normal stuff is fixed, fisheye will probably be broken...
-
Hi again! Viewport is full size in the Live View!! <3 Thank you so much for your help, and the speed of your replies!! :)
-
Hello,
New to this all. I have Canon Powershot A550.
I can get live view working by clicking on the play button in teh GUI but I cannot get the overlay to display.
As the camera only has a 2in screen it is very difficult for me to see and really need to be able to use the larger computer screen to make my settings and remote shoot.
Do I have any chance with this camera and CHDKPTP?
TIA
-
I can get live view working by clicking on the play button in teh GUI but I cannot get the overlay to display.
As the camera only has a 2in screen it is very difficult for me to see and really need to be able to use the larger computer screen to make my settings and remote shoot.
I believe live view is known to work on this camera. Maybe if you can provide a bit more detail we can figure out what the problem is.
In general, to use live view you should:
1) Power on the camera in playback mode
2) Connect CHDKPTP
3) In the live tab, check "Viewfinder" and "UI Overlay". You should see the whatever is displaying on the camera screen. If you want a larger view, check "Viewfinder 1:1" as well.
4) To switch to shooting mode, click the "rec" button in the GUI
-
??? Another cam with halfsized fisheye and FHD recording is Ix240 (102a).
Only shoot(/2) and zoom is available with mouse, rec (video) and others need touchscreen buttons.
But the OSD colors are lovely... :-*
Edit: Very similar is Ix310 (101a). The only difference seems: :blink: Here mouse can start&stop video.
-
I can get live view working by clicking on the play button in teh GUI but I cannot get the overlay to display.
As the camera only has a 2in screen it is very difficult for me to see and really need to be able to use the larger computer screen to make my settings and remote shoot.
I believe live view is known to work on this camera. Maybe if you can provide a bit more detail we can figure out what the problem is.
In general, to use live view you should:
1) Power on the camera in playback mode
2) Connect CHDKPTP
3) In the live tab, check "Viewfinder" and "UI Overlay". You should see the whatever is displaying on the camera screen. If you want a larger view, check "Viewfinder 1:1" as well.
4) To switch to shooting mode, click the "rec" button in the GUI
The steps that work partially for me.
1) Power on the camera in Playback mode.
2) Load CHDK(build includes CHDKPTP) in camera
3) Start chdkptp-r964-win-x86_64 on computer
4) Go to Live View tab deselect all
5)Connect USB cable from computer to camera
5a Connect GUI to camera
5b) Only the off button will operate on camera at this stage. Unable to use <alt>
6) Select Live Viewfinder or viewfinder 1:1
6a) Statistics tab may show communications but viewfinder is black screen.
7) Select UI Overlay and the following error is caught in console.
6) Select "Rec" buttton.
7) Viewfinder now displays LiveView from Camera.
8) Viewfinder does not display UI Overlay
9) Navigation buttons navigate the camera UI but no overlay in program. So must still look at camera to see what is being selected.
10) shoot and save works.
Error caught when selecting overlay.
ERROR: ...ds\chdkptp-r964-win-x86_64\chdkptp-r964\lua\gui_live.lua:575: data < palette size
stack traceback:
...ds\chdkptp-r964-win-x86_64\chdkptp-r964\lua\gui_live.lua:575: in function <...ds\chdkptp-r964-win-x86_64\chdkptp-r964\lua\gui_live.lua:542>
[C]: in function 'xpcall'
...ads\chdkptp-r964-win-x86_64\chdkptp-r964\lua\errutil.lua:97: in function 'action'
...ds\chdkptp-r964-win-x86_64\chdkptp-r964\lua\gui_live.lua:464: in function <...ds\chdkptp-r964-win-x86_64\chdkptp-r964\lua\gui_live.lua:424>
[C]: in function 'xpcall'
...ds\chdkptp-r964-win-x86_64\chdkptp-r964\lua\gui_live.lua:519: in function <...ds\chdkptp-r964-win-x86_64\chdkptp-r964\lua\gui_live.lua:517>
(...tail calls...)
[C]: in function 'MainLoop'
...wnloads\chdkptp-r964-win-x86_64\chdkptp-r964\lua\gui.lua:761: in function <...wnloads\chdkptp-r964-win-x86_64\chdkptp-r964\lua\gui.lua:734>
(...tail calls...)
...nloads\chdkptp-r964-win-x86_64\chdkptp-r964\lua\main.lua:304: in main chunk
[C]: in function 'require'
[string "require('main')"]:1: in main chunk
Thanks
-
Error caught when selecting overlay.
ERROR: ...ds\chdkptp-r964-win-x86_64\chdkptp-r964\lua\gui_live.lua:575: data < palette size
Thanks. You found a bug in CHDK. It should be fixed in autobuild 5834 and later, which will be on the autobuilds within the next hour or so.
-
Hello,
Thank you. The update to CHDK has resolved the issue. Though for this camera the A550 need to hit 'rec' to get a display. Then shoot as required.
ps. Norton 360 is now deleting the CHDKPTP.exe file for the following reason. 1. https://app.assembla.com/ is listed as being an unreliable site.
-
ps. Norton 360 is now deleting the CHDKPTP.exe file for the following reason. 1. https://app.assembla.com/ is listed as being an unreliable site.
Thanks for mentioning that. I'd expect the main issue is that it's an unsigned executable. Google used to label the downloads as dangerous too, though it seems to have stopped.
*shrug* I can't control the heuristics others use to guess what is malware.
-
Is it possible to use GetTickCount instead of GetTickCount64 to be compatible with Win XP?
-
Is it possible to use GetTickCount instead of GetTickCount64 to be compatible with Win XP?
AFAIK, chdkptp doesn't use either directly, so it's using whatever the libraries it was linked to use. I'm not going to put effort into supporting an OS that was EOL'd 7 years ago, but maybe if you build with sufficiently old versions of mingw, iup/cd or libusb-win32 it will work.
-
AFAIK, chdkptp doesn't use either directly
Open chdkptp.exe and you will see that it imports "GetTickCount64" from kernel32.dll
-
Open chdkptp.exe and you will see that it imports "GetTickCount64" from kernel32.dll
Grep the source and you will see the string GetTickCount isn't present, so it must be pulled in from a library or a header. But again, I'm not going to expend any effort trying to support XP.
-
:( Have not found N-port...
Here video is upper/2 only in HD & FHD, <rec> & <play>.
Edit: 2nd Bat tells only fisheye is full fine but flickering.
-
Could someone please help me with installing the ptp app? I've downloaded zadig and tried to install libusb but don't think I did it properly because my Bluetooth icon is missing. More importantly, the ptpcam command line immediately closes when opening.
-
;) ... You installed the right driver on the wrong device, need to undo if You need bluetooth. Then list all devices, choose canon, ... ,unplug & restart cam, retry ptp... :-[
-
;) ... You installed the right driver on the wrong device, need to undo if You need bluetooth. Then list all devices, choose canon, ... ,unplug & restart cam, retry ptp... :-[
Ah...The problem is, I don't see 'Canon Digital Camera'. I only see Easy Camera which leads me to believe there's something wrong with my mini USB
-
I only see Easy Camera...
Offtopic ??... :haha
I´ve never seen that. Maybe installed webcam hiding others?
Or something like https://chdk.setepontos.com/index.php?topic=13426.msg142722#msg142722 ?? :-[
-
Ah...The problem is, I don't see 'Canon Digital Camera'. I only see Easy Camera which leads me to believe there's something wrong with my mini USB
Does windows recognize the camera at all? Without the libusb driver installed, when you plug in the camera, it should be visible in windows explorer and you should be able browse and transfer pictures.
-
Ah...The problem is, I don't see 'Canon Digital Camera'. I only see Easy Camera which leads me to believe there's something wrong with my mini USB
Does windows recognize the camera at all? Without the libusb driver installed, when you plug in the camera, it should be visible in windows explorer and you should be able browse and transfer pictures.
No it isn't. In fact, I just double checked with Camera Window and it says "Cannot detect camera" even though it's on and plugged in.
-
No it isn't. In fact, I just double checked with Camera Window and it says "Cannot detect camera" even though it's on and plugged in.
What camera do you have?
Is CHDK installed?
If CHDK is installed, make sure you have "USB remote" disabled
-
No it isn't. In fact, I just double checked with Camera Window and it says "Cannot detect camera" even though it's on and plugged in.
What camera do you have?
Is CHDK installed?
If CHDK is installed, make sure you have "USB remote" disabled
I have a Canon IXUS 185
-
Hmm, :blink: some cables look like USB cables, but are only good for charching,
or to confirm on their way from somwhere to elsewhere, that from there to here it´s just as far as from here to there...