mc:cmd('call reboot()')I registered today at forum just to share my project and exchange info and tips with you all.Welcome! I started this a couple of days ago for people just like you :
First of all i need to say that everything i did so far is by gathering info from this forum and other places , so nothing is actually *my* creation , i just put them together to serve my purpose.
**Thats why cameras run chdk with patched kbd.c (Credits go to waterwingz :) )**.. and a few other people.
1.Is there a way to reboot or disconnect multiple cameras? I have found the command for mass-shutdown.Is something likeI've been working on a customized version of multicam.lua (seperate camera & PC versions of the script) and it has commands to do what you want.Code: [Select]mc:cmd('call reboot()')gonna work?I tried it and somehow cameras stucked/crashed.About disconnecting multiple cameras , is a new function needed in multicam.lua i imagine?
2.I saw a thread somewhere in the forum discussing how to be possible to "name" each camera so u know that upper left is camera1 , bottom right camera2 , etc etc.Yea .. I started that here :
Is it possible to rename a photo when chdkptp downloads it from cli ?My next versions of bcamHost.lua & bcamRem.lua use the unique camera ID and the shot number to create unique file names and place the same shot from multiple cams in the same folder.
3.When i press shoot and cameras are standing by for usb voltage change (for me to click the switch in other words) i noticed that shooting happens after ~10 secs if i dont click the switch.Can i change this 10secs behavior?This one goes way back. The idea here is that when you get to this stage in the sync process, the shooting task is in a tight loop waiting for the USB 5V signal to go away. Many other camera functions are essentially suspended as a result and at some point the camera will do a "watchdog reset". So 10 seconds was picked as a "safe" value. It's likely this varies a bit with different camera models and also possible that 60 seconds would work as well. I can make you a custom build if you want to play a bit and find the limit for the A2500.
2.I tested a bit your files .To be honest the bcamHost.lua file only , as i prefer to run scripts from pc to the camera . I am not programming expert , or lua for that matter. But i have some common sense and i try to figure things out by comparing and analyzing them.My version of the host script (bcamHost.lua) depends on having the related camera script (bcamRem.lua) running. They work as a pair. I needed to do that in order to have the script on the camera side have a unique ID number like you see in the linked image. So you can't just run the host side alone - it needs the script on the camera side to communicate with.
So , i tried some commands of that file and after connect() , everything else fails.Script cannot "send" them to camera and the error is the classic "no script running".
I noticed that there is no start() function on the .lua file .Shouldn't be one there to start the camera-part code execution and allow the other commands to function ?Just an observation , i might be talking nonsense here.
Thanks.
3.i have read the threads about unique id numbers and stuff. I will try to see if i can come up with something at the direction reyalp suggested e.g. set some numbers/names at the serial numbers in a script and handle the camera through them.For many cameras setup , that would be a boring job to do , but i believe its a one-time job.To match up some variables to ALL serial numbers.See my comment above.
4.About "i will take the photo in 10 secs" annoying thing. I understand the concept you are describing. My friend was thinking something like.. shooting task in loop forever and we walk around with the switch in our hands and take the shot in whatever moment we feel like .As i understand this won't happen.So the best thing that can be done is to raise that "safe limit". I will keep it in mind and think it over and let you know..no need to make something for me at this point..not yet at least. I was also thinking of some kind of countdown timer in chdkptp gui when i press shoot to inform of the remaining time and some sound alarms too .Probably easy task with some lua programming ...If you can figure out how to read that remote switch from your PC then the rest is easy. Some sort of Arduino clone board acting as a USB slave would be simple to rig up. Search eBay for "wireless remote control" - there a lots of $5 key fob transmitter/receivers you could use as the remote part of the equation.
And a last thing that came up my mind right now.When i click the switch to take the shot , cameras naturally disconnect from pc...Ah, I think you miss the point of the trick you mentioned in your first post.
... Is there something else that i can do ?
Shooting Method : I read a lot about this phase.What to use and what not to use.We started experimenting with multicam.lua (credits to reyalp :) )and its commands.Syncing was working good with 2 cameras.With 8 cameras connected we had some hicups .Some cameras were losing sync by a little bit.Not more than 40-50msecs.Out of curiosity, what version of chdkptp was this using? In chdkptp r602, I added shoot_hook_sync which should have substantially better sync than the previous method.
what shooting method is "known" to have good sync with multiple cameras?
None.
It is a statistical problem.
With two cameras I have found that 70% of the time the sync error is less than one msec.
For 30% of the time it is tens of msec, presumably because the Canon firmware is busy with an 'important task'.
So, does that mean for any shoot 19 of your cameras will have a sync error of tens of msec ?
If by "i will download from cards" u mean u will get the cards out of the cameras in some card reader , then this script wont do you any good.
If not , then gladly to post it.
Dim FSO
Set FSO = CreateObject("Scripting.FileSystemObject")
BasicFolder="./"
FolderPrefix="shot"
FormatName="0000"
FolderPostfix=0
Do
FolderPostfix=FolderPostfix+1
last_string=right(formatname+cstr(FolderPostfix),len(formatname))
NewFolder=BasicFolder+"\"+FolderPrefix+last_string
Loop Until not FSO.FolderExists(NewFolder)
FSO.CreateFolder(NewFolder)
Set wshshell = CreateObject("WScript.Shell")
Dim WshSySEnv
Set WshSysEnv = wshshell.Environment("Volatile")
Wscript.Echo FolderPrefix+last_string
Set WshSySEnv = Nothing@echo off
cls
chdkptp -elist > id.txt
for /f "tokens=*" %%i in ('cscript //nologo folder.vbs') do set Value=%%i
for /f "tokens=3 delims=-" %%A in (./id.txt) do (
chdkptp -e"connect -d=%%A" -e"!require 'extras/dcimdl'" -e"!dcimdl('%Value%/%%A/',true,false)"
>nul 2>nul dir /a-d "%Value%\%%A\*" && (echo Files exist) || (echo No file found in %%A > check.txt)
)
Thanks, I will try that this evening.
As I said, I have a friendly PTP command-line and gui client that handles the shooting and saving to separate folders and lots, lots more but quite honestly if others are willing to devote considerable time to this problem I would rather be out shooting photos.
I will possibly work on it again during the northern Winter.
I don't see any problem with your clients standing still for tenths of a second !
What problems do you reffer to ?Problems with your client?Bugs?
Can i test it with my cameras?I mean are they supported ?.
1.@waterwingz : I suspected that your script might work that way (one script on the pc and the other on the camera).But the whole situation process raises a conflict in my eyes.There is essentially no such thing as a true "Default Script". It's just telling you that there is no script loaded (or assigned to load when you press the shutter button) when you see that.
When i mass-connect to the cameras and they go into "rec mode" , ready to shoot , they kinda start "default" script running.I mean i see the "Default Script <ALT>" at the lower left side.
Won't this whole process fail if some other script (yours lets say) is running already on the camera?Not at all - you've missed the basic concept here. The whole point of what I did was to keep the camera script running at all times and connected to the host code on the PC. Things like the shoot command happen because the host program tells the script on the camera to shoot and it does so. You need a script running on the camera that understands how to talk to the script on the host. They all stay sync'd and happy that way.
3.I see that you quoted two lines i wrote but you left out some others that was the whole point.I got your point and left out all the text that was all related to the same thing. Per my comment above, if the script on the camera stays connected to the script on the host the whole time then you won't need to worry at all about disconnecting and reconnecting.
4. @reyalp : Cameras are using chdk 1.3 r599 .That the version STICK chose for my camera and i dont see a reason not to believe it :)He is talking about the version of CHDPTP - not CHDK. STICK has nothing to do with that.
There is essentially no such thing as a true "Default Script". It's just telling you that there is no script loaded (or assigned to load when you press the shutter button) when you see that.
Not at all - you've missed the basic concept here. The whole point of what I did was to keep the camera script running at all times and connected to the host code on the PC. Things like the shoot command happen because the host program tells the script on the camera to shoot and it does so. You need a script running on the camera that understands how to talk to the script on the host. They all stay sync'd and happy that way.
3.I see that you quoted two lines i wrote but you left out some others that was the whole point.
I got your point and left out all the text that was all related to the same thing. Per my comment above, if the script on the camera stays connected to the script on the host the whole time then you won't need to worry at all about disconnecting and reconnecting.
I get the concept that "Default Running" means there is no script to run actually. But when this indicator is ON i have noticed that i cant run a script from pc to the camera let's say.You can only run one script at a time on the camera. When chdkptp wants to run a script there cannot be one already running. I think that when it does run a script, it does not provide a script name to the camera so the "default script" name defaults in the CHDK code and that is what you are seeing.
At your last phrase "you won't need to worry at all about disconnecting and reconnecting". But with the "usb switch" method a disconnection occurs no matter what. At that point the two script won't lose "connectivity"?When you used CHDKshell to build your own version using my simple patch, you bypassed that. The patch tricks the Canon PTP code into not seeing the disconnection (i.e. USB power going away) when you press the button. The PC also can't tell that the button was pressed so both the host script and the camera scripts keep running as if nothing has happened. That was the whole point of doing the patch in the first place - you could just use the stock build otherwise.
Although i will insist on what i said before.Hmmm ... well then I will insist that it works for me. :P
I don't know what scripts think it is happening when the switch is pressed for shooting.What i see and what computer knows is that it "loses" cameras at that point. And cameras are getting online again when i press switch again.I think we need to discuss your switch hardware? Do you have a circuit diagram of what you created? The patch assumes that you only open the +5V wire in the USB cable (typically the red wire - leave the green, white and black connected). Usually you would use a momentary contact "normally closed" type switch to do that .
I think we need to discuss your switch hardware? Do you have a circuit diagram of what you created? The patch assumes that you only open the +5V wire in the USB cable (typically the red wire - leave the green, white and black connected). Usually you would use a momentary contact "normally closed" type switch to do that .
i was looking/testing your two scripts (bcamhost/bcamrem).I was wondering how easy (for someone who knows about lua apparently) to embed your (mass)download function into current multicam.lua.bcamHost.lua is just a modified version of reyalp's multicam.lua that I'm working on so that it lets me run multiple cameras the way I'd like. I posted the original version so that novsela would have something to test with but have made many changes to the work flow and added several new "commands" since.
As far as "mass download" goes, multicam.lua already has the a function called mc:download_last() that does that.
http://chdk.setepontos.com/index.php?topic=11583.msg114183#msg114183 (http://chdk.setepontos.com/index.php?topic=11583.msg114183#msg114183)As far as "mass download" goes, multicam.lua already has the a function called mc:download_last() that does that.Are you sure about this? If you say that such function already exists in multicam.lua feel free to enlighten me :)
http://chdk.setepontos.com/index.php?topic=11583.msg114183#msg114183 (http://chdk.setepontos.com/index.php?topic=11583.msg114183#msg114183)As far as "mass download" goes, multicam.lua already has the a function called mc:download_last() that does that.Are you sure about this? If you say that such function already exists in multicam.lua feel free to enlighten me :)
Damn i missed you for a little bit.I was exactly at the same thread/post and just finished the test of the *new* lets say multicam.lua.Helps to keep track of new versions and updates on the svn site : http://trac.assembla.com/chdkptp/browser/trunk/lua/multicam.lua (http://trac.assembla.com/chdkptp/browser/trunk/lua/multicam.lua)
I was thinking to use like 8x 10port usb hubs (8 cameras on each of them) and plug them all in 1x 10port usb hub connected to the pc.How do you plan to power the 9 USB hubs?
A switch on that "last" hub and play with usb-remote and switch on/off method.I know its a very simple concept and i am missing something.
How do you plan to power the 9 USB hubs?
If you want to use CHDK's USB remote "sync" feature, you need to be able to disconnect the 5V "red" wire to all 80 cameras at exactly the same time. If you don't want to lose USB communications, then you can't simply turn off the power to all the hubs (even supposing that causes the individual cameras to all see the power go off at exactly the same time).
If you can make reyalp's calibrated sync shooting mode in multicam.lua work acceptably then you are spared the pain of trying to switch the hubs. Note that your earlier tests on two cameras don't tell you what will happen with 80 cameras - the sync error is not 80x(two camera sync error). It might actually be okay for your application.
3. 1x 10-port usb hub powered .The 8x hubs of step-2 will connect to it.The switch will be on the cable from this hub to pc.I don't think that's what you want. See below.
So , if i am getting this right, somehow , when the shoot task is in loop...i have to press switch FIRST and cut power on all hubs AFTER.And after shot is taken.. i have to give power back to hubs FIRST and then press the switch again AFTER.No - not really. What you want is to set things up so that everything is hooked up normally ( i.e. all cameras powered and plugged into a hub, all the individual hubs connected to a central hub, and the central hub connected to your PC). Then you use the PC to issue a "shoot" command to all cameras. At that point the camera will all start the shooting process and halt just before completing it, waiting for the USB 5V power at their input jack to go away. You need to figure out a way to disconnect the USB 5V power (red wire) to each camera at exactly the same time.
Am i getting this right?
If you can make reyalp's calibrated sync shooting mode in multicam.lua work acceptably then you are sparedI think you can do the sync thing once and then just shoot with the values it figures out. Have only issued the command once while experimenting but that seems to make sense to me.
In other words , you are suggesting to avoid switch thing?Enlighten me a bit about "calibrated sync shooting mode".When i was using multicam commands for shooting (no switch involved) i was using shoot command with syncat parameter.Is there something else there?
Do i have to issue a sync command to ALL cameras with this method?because issuing sync to 8 cameras was taking *some* secs..i cant imagine what time is needed with ~64....
In other words , you are suggesting to avoid switch thing?Enlighten me a bit about "calibrated sync shooting mode".When i was using multicam commands for shooting (no switch involved) i was using shoot command with syncat parameter.Is there something else there?With the latest lua files from chdkptp svn and CHDK 1.3 (not currently in a release zip, but I'll probably get another one out this weekend), you can use shoot_hook_sync instead of shoot, which should have substantially better sync.
Do i have to issue a sync command to ALL cameras with this method?because issuing sync to 8 cameras was taking *some* secs..i cant imagine what time is needed with ~64....Yes, it would be quite slow. It's possible this process could be sped up, but in any case I wouldn't bet much on the reliability with 64 cams.
I think your script(s) are what i'd like for my projects but i am not very comfortable with the way they work.Here's the problem.
I mean one script on pc , another on cam.I'd prefer multicam.lua way.
I mean , script is running on pc and runs a part of the "code" from itself to the camera.
Can't you do it this way? :)
Just replace shoot() command with shoot_hook_sync()? is that what you mean?if you were using mc:cmd('shoot',{syncat=100}) you would use mc:cmd('shoot_hook_sync',{syncat=100}) instead.
And sync() is still required i suppose even with the above command?mc:init_sync() is required if you want synchronized commands. It is only required once after mc:connect()
Also , are you saying that i can issue like 20x sync() commands kai write down an average sync timing of every camera and issue them through a file somehow?In principle, it seems like this should work. If the camera is on the same interface every time (or the interfaces are all equal), then the delay shouldn't change between sessions.
Isn't any way the host script to "read" the serial numbers and cross reference with a specific number?As you suggested.And then pop up a big-fat font message to respective lcd of the camera.That leaves you with big-fat font messages showing the camera numbers all mixed up and out of sequence on the shooting rig. I wanted them in order - and if I need to swap out a camera, I just put the new one in place and set the camera number with the script @param value.
commands that could read the contents of a file with the structure <serial number>=<number> in each line and compare a given string to the first part of every line (that is the serial number part) and take the number as a result and do something with it.Yes, that has been my plan for multicam.lua. You can make a table indexed by serial number, and then you can associate whatever information you want with the serial.
I assume it would be *rather* easy to be done with lua commands...
@reyalpThis should be fixed in rev 602. This happened if the synctime given was too short (which could also happen if you didn't specify one)
First of all testshots didn't work for me last time i checked..program unresponsive and had to force close it.
Don't know if it will behave the same with the latest version i compiled for future tests.
I got all 8 cameras here , had only 2 for testing while partner had the rest..so i will try some syncing and shooting and see what will happen.I'll try to look into it, but I can't promise any particular timeframe. If you verify that the new method gives you acceptable results, I'd at least know it had the potential to be useful.
If you feel like to implement the thing about issuing sync timings through some file...let me know :)
I was reading novsela thread and i see that he is trying something similar with my project,although i believe our cameras wont be on the same level..but anyways.
I was seeing there some very complicated diagrams about the connections of the hubs etc.
I was thinking to use like 8x 10port usb hubs (8 cameras on each of them) and plug them all in 1x 10port usb hub connected to the pc.
A switch on that "last" hub and play with usb-remote and switch on/off method.I know its a very simple concept and i am missing something.
I am guessing it wont work as i imagine right?
How i measure sync?Probably with some lame way , since i don't have any crt monitor lying around for some reliable measurements.This will not give you a very precise measurement, for the reasons described in http://chdk.setepontos.com/index.php?topic=11583.msg114389#msg114389 (http://chdk.setepontos.com/index.php?topic=11583.msg114389#msg114389)
Last time i used an online meter ( this one http://stopwatch.onlineclock.net/ (http://stopwatch.onlineclock.net/) ) and tried to focus all cameras on it.Then checked pictures to see what sync was achieved.
@Hardware_Hacker
Thanx for your input on the matter , will keep them in mind.
@reyalp
I know its a lame way but it's the best one i can come with since i dont own a crt monitor anymore.
I am working on a, low cost, simple, multiple 8x8 LED Dot Matrix Array Sync Tester using aThat's kind of what I did here : http://chdk.setepontos.com/index.php?topic=8312.msg104805#msg104805 (http://chdk.setepontos.com/index.php?topic=8312.msg104805#msg104805)
32khz watch crystal ["PAL" crt monitors have a horizontal frequency of ~~15.750 kHz.]
The concept is similar to Slow Scan TV but "ONLY ONE" LED in 8x8 LED Dot Matrix Array is on at a time.
The, 16x32, or 16x40, LED Dot Matrix Array can then have various scan times. i.e. 1x, 2x, 4x, 8x, etc.
The Slow Scan LED Array will is "Reset" by the shoot command, the camera test images will be simple
"Bar Graphs" in Hexadecimal time. this can also record the S:M:H see also here.
But everything is "Digital" these days, I traded my Old Analogue Junk for a "Free" Ixus 265 camera.Offer them a case of beer or the equivalent in local currency to trade back?
At syncing process , i noticed that the program went unresponsive for few secs at the middle of the process.If you are using the chdkptp GUI, I would strongly suggest switching to the CLI for multicam. Start with chdkptp -i
That happened to me before when i was testing 8 cameras , but after some syncing , then it went smoothly.
Today i hit 2-3 syncs just to see the behavior , but on all syncs , the "problem" remained.
No impact to the shooting as i see , since all cameras were mostly synced.
I thought to mention it in case that indicates some problem...
@reyalpThat makes sense. FWIW, you could also make Lua functions or CLI commands that do this. I have never used the GUI with more than 3 cameras connected, so I wouldn't be confident that it will behave nicely with 64.
Since there are some commands involved when handling multiple cameras...you know..start multicam , sync , preview mode , rec mode , download images , and all these commands again and again...i am bit bored typing in CLI :)
So i have made some buttons in the gui for more easy use of the commands.
When program was processing the sync timing of each camera ...it got "stuck"..probably operation took a bit longer at camera no 3.Then after like 5-6 seconds , messages in the console were shown all together..like something were holding them back.This sounds fairly normal. Long running calls block the GUI in some cases. This may vary depending on whether you are issuing the commands in the input box or using code directly from your buttons.
Anyways , there was no practical impact at the shooting.Although one camera at try no 1 , didn't shoot.At tries no 2 and no 3 all were smooth and ok.Shoot failing (where the camera never gets to the point it thinks it's ready to shoot) is something of a known issue. This may be more likely if you are in full auto mode (AUTO rather than P) or if the flash is enabled.
I was seeing there some very complicated diagrams about the connections of the hubs etc.Another Design Setup Point and another "...very complicated diagram..." A590IS-Current [5x7].png
I am guessing it wont work as i imagine right ???
Ok it's a bit more work writing commands in CLI but i can live with it if that means more reliable conditions.The GUI might work for you, there's just a lot more room for things to go wrong. In the long run, it would certainly be nice to have multicam controlled from the GUI.
So for now i will stick to this "method" and see how it goes with more cameras , when we get the rest i mean :)Since it seems like this approach might be usable, I'll try to get serial number mapping / download stuff sorted out.
@Hardware_Hacker
Ok i got the point.It's not that easy as i thought :)
The GUI might work for you, there's just a lot more room for things to go wrong. In the long run, it would certainly be nice to have multicam controlled from the GUI.
If you want to share you code I can look into incorporating it into multicam.
Since it seems like this approach might be usable, I'll try to get serial number mapping / download stuff sorted out.
One thing to be aware of with multicam is that the time it takes to shoot will go up with the number of cameras. It works by sending a message to each cameras that says shoot at time X in the future, and sending the message to each camera takes a certain amount of time (there is no broadcast in PTP). The "minimum sync delay" listed after init_sync() is an estimate of this, although in practice you probably want to leave some head room. On my setup this seems to be about 4 ms/cam with Digic 4 cams, but I don't know if there will be additional overhead if you have a bunch of hubs and cams.
* There is NO External (sneaky) available path for the 300 watts to flow through.This is nonsense. Watts are a measure of power dissipation - they do not "flow" or "sneak" around. Current flows and is measured in amps.
P.S. : Did some testing without syncing on the cameras.They were rather synced all of them.As much as i can tell from my lame online-testing method.How are you shooting for these shots? Specific sequence of function calls.
But i believe 64 without syncing will be a bit mess at the best.Each command is just sent sequentially to each cam, so if you aren't using sync, 4ms per cam there would be a minimum 1/4 second between the first and last cam.
So syncing process must be sorted out to be fast and accurate as much as it can be done.If you always get approximately the same sync values for all the cams, then we can just use a fixed value.
What you are describing here is a simple exercise in Ohm's law where you have multiple power sources. If the DC side of the power sources all use a common (low resistance) grounding point there is no issue. That simply comes down to a large enough conductor and good bonding to minimize "Electrical Length".
In chdkptp changeset 610 I made some changes which speed up the sync process a lot.
I removed the check phase since it basically didn't do anything. It can still be run manually using check_sync_single(mc.cams[camera number])
I also removed some unneeded delay from init_sync, and changed the statistics to include min, max and standard deviation. You can also pass in the number of iterations, like mc:init_sync(5). In general, I don't think a lot of iterations is going to be helpful, although there are occasional outliers in send time which could throw things off if you got unlucky. You do need to run at least one to establish the clock offsets.
Do i grab multicam.lua from https://www.assembla.com/code/chdkptp/subversion/nodes/610/trunk/lua (https://www.assembla.com/code/chdkptp/subversion/nodes/610/trunk/lua)You should make sure all the lua files you use are from the same version. You can get a zip of all the files using the download button on the link you quoted.
or do i wait for some new windows binary at some point? :)
You should make sure all the lua files you use are from the same version. You can get a zip of all the files using the download button on the link you quoted.
Alternately, you can use svn and check out http://subversion.assembla.com/svn/chdkptp/trunk/lua/ (http://subversion.assembla.com/svn/chdkptp/trunk/lua/)
This also makes it easy to switch back to an older version, and to deal with any local modifications. If you are using windows, tortoisesvn is a good svn client.
Now i have 2 different choices when i right click the folder. SVN update , SVN commit.Unless you have commit access to the repository, it won't make any difference what you do with the "second one".
I think i MUST NOT , touch the second one right ? :)
Unless you have commit access to the repository, it won't make any difference what you do with the "second one".
1.Set focus on multiple cameras at once.I have made it work with one camera.Tried to connect 2 cameras and play with set_aflock and set_focus and only one camera was affected.How are you trying to do this?
!return mc:cmdwait('call function cmds.foo() print(mc.args) end')
creates a new command names foo, where mc:cmd("foo hello world") will print hello world on the camera screen.2.Get current focus.I mean camera gets an initial focus with set_aflock(1).Before i start issuing new focus distances , i want to see whats the current focus distance.Do you expect to do this across all the cameras, or one camera at a time? Are you trying to return the focus distance value?
3.get_zoom , set_zoom didn't seem to work for me , even with one camera.Do i miss something in the syntax of the command?Do i need to do something else prior of it?You must be in record mode for these to take effect, other than that there should be nothing special. Examples of the actual code you are using would be helpful.
EDIT : Number #1 solved.You should not need af_lock before setting zoom (in fact, zooming with aflock set may cause problems), do you mean focus related commands?
Number #2 solved (thanx to a thread of waterwingz.set_aflock() needed before any zoom related commands)
Then i was fooling around in forum and found a thread of waterwingz who was trying to see why his cameras were shutting down after using a "zoom" script .At some point he threw an idea , putting a set_aflock inside his script before the actual zoom commands.And no problems with his cameras.If you are talking about this thread : set_zoom problems in uBASIC & Lua scripts (http://chdk.setepontos.com/index.php?topic=7071) then a number of improvements were found and many others tried. However, I still have at least one camera (SD940), and there are several others like it, that will not zoom reliably so good luck!
If you are talking about this thread : set_zoom problems in uBASIC & Lua scripts (http://chdk.setepontos.com/index.php?topic=7071) then a number of improvements were found and many others tried. However, I still have at least one camera (SD940), and there are several others like it, that will not zoom reliably so good luck!
So an idea popped to issue a set_aflock(1) before set_zoom..and TAAA-DAAA ..lens moved!OK, this is strange, but as waterwingz says, some cameras have problems with zoom. In a worst case scenario, you should be able to adjust zoom by sending key presses. This is inconvenient on cameras with a large number of zoom steps though.
Overall , zoom and focus worked for multiple cameras.Only thing remained now is ISO and shutter speed...i think i will hardcore ISO from the chdk menu in every camera and i think i found the command for shutter speed.See http://chdk.wikia.com/wiki/CHDK_Scripting_Cross_Reference_Page (http://chdk.wikia.com/wiki/CHDK_Scripting_Cross_Reference_Page)
About getting the initial focus distance.No , i dont expect to do it on all cameras at once.I was thinking the process of setting up the cameras and finding what zoom/focus each one should have so they will be targetting and focusing in the center of the rig.I'm still not clear how you expect this procedure to actually work.
In few words all cameras will be targetting a specific spot.It would be rather stupid to start throwing values at focus or measuring the distance with some tool .
I was thinking since set_aflock(1) , takes an initial focus before hand over the control of focus..i can target the center of the rig and then issue the command.So it will focus there..if i can get back the distance of THAT focus , probably with get_focus , then i can put the same value of focus to all cameras , since they are gonna targetting the same spot.
con 1> !mc.cams[1]:write_msg("call return get_focus()")
And to get the results, you could use something like this messcon 1> !r={} mc:get_single_status(mc.cams[1],'call',r) return r
={
status={
status={
[1]=-1,
},
cmd="call",
},
done=true,
}
The values of the inner status table are the return values (-1 in this case)As far as iso and tv are concerned , since iso will be the same at all times for all cameras , i was thinking to put it in the chdk menu...to all cameras...and then "play" with tv to see what value gives the best result.Why not just set the ISO in the Canon menu for each camera? You only ever need to do it once.
a)Take a measure tool and start measuring the distance , convert it to mm and set it with set_focus.If the object is centered, you can probably just take the radius of the ring, and always use that value. Or if your object is large compared to the ring, subtract it's radius. As I said, the cameras have large depth of field so unless the subject is quite close it doesn't have to be very precise.
Zoom is something that came up to my partner's mind.Thinking that maybe the "object" could be small..like a pet , or a small child..cameras should be able to zoom+focus to them .So all the cameras would have the same zoom, that makes sense.
Why not just set the ISO in the Canon menu for each camera? You only ever need to do it once.
If the object is centered, you can probably just take the radius of the ring, and always use that value. Or if your object is large compared to the ring, subtract it's radius. As I said, the cameras have large depth of field so unless the subject is quite close it doesn't have to be very precise.
That said, you could easily use the code I posted to get focus on one camera and then then set focus on all of them. If you use the GUI may even be able to check focus in the live view.
How big is the ring?
How big the ring will be ?Hmm i don't know the specifics yet...i assume around 4-5 meters in diameter at maximum.Something like that.With a human sized subject standing ~2 meters from the cameras, I'd expect you can just set the focus to about that distance and never need to change it.
With a human sized subject standing ~2 meters from the cameras, I'd expect you can just set the focus to about that distance and never need to change it.
* There is no support yet for controlling which id is associated with which serial number, they are just set by the original connect order.Do you have any thoughts on how to number cameras sequentially by physical position (i.e. left to right) on the rig?
Do you have any thoughts on how to number cameras sequentially by physical position (i.e. left to right) on the rig?Yes, that plus a function to re-assign the id is the plan, just haven't got there yet.
Maybe something to pop the index number in the saved list onto the camera's LCD ?
First of all , just to let you know , probably you know it already , there is an error everytime mc:connect() is issued.Nothing to do with latest changes , this happens from day 1.This error doesn't affect the connect() or anything else after that , so i just ignore it..but i thought to let you know.I think I fixed this in recent versions (607, 614). I can start the gui and run !mc=require'multicam';mc:connect() without any errors. But as I mentioned, I don't test much with the gui.
"ERROR: D:\Downloads\project3d\chdkptp-r599-win32\lua\gui.lua:138: attempt to index field 'apiver' (a nil value)"
1.first of all , svn update didn't go smoothly :) Had 2 "conflicts" , i had to manually copy/paste the new files just to be sure.But this process , i can't use it for gui.lua , since i have added things , to make my own tab.Tortoise have a pretty good interface for editing the conflicts, see http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-conflicts.html. (http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-conflicts.html.) You can reduce the chance of conflicts by putting most of your code in it's own file and just calling functions a few points.
So every time i just believe that svn update works for this file (it always has a red "!" on it even now as we speak :P )
4.Let's say i turn on cameras one by one , with some delay , the way i want them to be physically numbered.This is what mc:connect{list=...} option does. The initial connections don't happen in order, but the ID numbers are preserved, and any operations on the cameras happen in the same order.
And then i connect() to them and issue an mc:save_list().IDs in the file will be as i want them (physically) to be.
Is there a way to put a parameter in mc:connect() to take as an input this file and connect to cameras per id order?This way every time camera with id=1 (id=1 in the file that is) will be connected first , camera with id=2 connected second , etc etc.Regardless in what way and order will be powered on in the future.Just a thought.
EDIT : ignore the problem with buttons , nothing to do with the latest changes...found the problem :)When I post code here, I usually post it as I would enter in the CLI. In the CLI !return mc:cmdwait(...)
I used some mc:cmdwait command , and worked perfectly , then i remembered that the syntax is return mc:cmdwait blabla and correct it , and error occured... it assumes that "return" is closing some function..nice mess...pfff
EDIT no #2 : To add something to the idea on no #4 above. If such thing is possible then someone can create groups of cameras.Lets say i will have 8 poles of 8 cameras each.I can , let's say , connect the cameras of one pole (create the file of ids of these cameras) and do some testing.Do the same thing for every pole.If you made a list with all the cameras, you could use a text editor to create sub-lists. The format is just a lua table. Note that the table is not necessarily in any specific order, so you would need to pay attention to the IDs.
Then if i want to "work" with a specific set of cameras (of specific pole) , i can just connect using the apoppriate id file.
And create buttons named "Pole 1" , "Pole 2" , etc etc and each one of these buttons will connect to the specified by the file cameras....am i getting this right?Yes.
And a last thing... the syntax of list=true would be something like mc:connect({list=true}) ?Yes. But if you have multiple files as mentioned above, you'll need to use the filename instead.
PS : Can some deletion or mass download command be implemented? :)I plan to add both, but as always there is no particular schedule.
But the thing is that the order of powering up doesn't ensure the given ids.Somehow, this still feels to me like a better solution : http://chdk.setepontos.com/index.php?topic=11631 (http://chdk.setepontos.com/index.php?topic=11631)
So it might need some copy pasting serials into the file , to achieve the wanted order....but atleast it will be done once...when the time comes...
I powered cameras up , one by one..in order...i noticed that the last one that was powered up took id no #1 ! :blink:I did warn you that I hadn't tested this thoroughly. It was just casual observation with 3 cameras that might have provided a shortcut to getting them in order.
I did warn you that I hadn't tested this thoroughly. It was just casual observation with 3 cameras that might have provided a shortcut to getting them in order.
Not a big problem...power up the cameras..check what id each one is taking and then just start editing the file with ids to the desired physical order... :)In changes through r624, I added a function set_id(old_id,new_id). If the script is running, the IDs on the camera will be updated immediately so you can see it on the ID display.
Command is , mc:download_images() right ? i mean it can be run as it is ? and it takes the default values for dst?Yes, most complicated functions in chdkptp take a table of options, and anything not specified uses the default.
Something else , in the example you provide "!mc:download_images({verbose=true,delete=true,overwrite=true,dst="test/${name}",fmatch='DNG$'})"
if someone wanted dst with default parameters..he should simply exclude it at all from the command?
And one last thing ...i understand that delete function is somehow connected (as a parameter) to the downloading ALL files process.So i guess deletion cannot be combined with other commands ...? let's say download_last?There is a function mc:delete_images_list() which you could call directly. It expects a list in the same format produced by mc:imglist(), so you can use that to generate a list without downloading. imglist takes the same file selection options as download_images.
@reyalpimglist takes a table of options, which are passed to rlibs.lua find_files. This is the same thing used for chdkptp's mdownload command. It returns a Lua table, which I described earlier.
ok i missed something... i dont get how imglist() and delete_images_list() work.I mean what they take as a parameter.
And a last thing.. what do you mean "mc:download_images() does not affect all files" ?Right, the default is everything, but what I meant is you can modify the criteria used by find_files. If you just wanted to match image numbers 1-3, you could use fmatch='_000[1-3]%.JPG' or something like that. But for multicam this is not useful unless you can keep the image counters exactly in sync.
Doesn't download EVERYTHING? i did 3-4 tests , did 3-4 shoots and used download_images().Found and downloaded correctly all images...with default parameters of course.
@reyalpimglist() returns a list of files. You can pass that list to delete_images_list.
ok , i am really confused about imglist() and delete_images_list()
imglist , produces a list that to be honest isn't practically helpful.So maybe i am missing its true purpose.
It suppose to be combined with some other command?
!mc:delete_images_list(mc:imglist(),{pretend=true,verbose=true})
or equivalently!mylist=mc:imglist()
!mc:delete_images_list(mylist,{pretend=true,verbose=true})
As i see it (although practical application will tell better) , last image (last ONE) and ALL images would be the most used and needed to be handled.If you do lastimg=1, it gets you the last image, and it does it consistently with getting all.
I have them in the Remote Parameters set up - enable remote, one push, Normal control, synch enabled, synch delayNote this is for the DIY electronic remote (http://chdk.wikia.com/wiki/USB_Shutter_Remote (http://chdk.wikia.com/wiki/USB_Shutter_Remote)). mphx is attempting to use only software PTP control (http://chdk.wikia.com/wiki/PTP_Extension (http://chdk.wikia.com/wiki/PTP_Extension)) so your setup is quite different.
My ideal wish list to perform:There is certainly no existing system which will do this for you. It should be possible to build with enough effort.
I want to take three photo shoots - verify that each camera took and recorded a picture and move to next photo shoot (2)...photo shoot(3) - if a camera didn't record a picture - erase all pictures on the other cameras and redo that shoot. At the end of photo shoot (3) - disable the remote parameters.
If not then take X number of photo shoots and then disable the remote parameters.If you are using the USB remote, then some electronic control will have to be responsible for doing the X number of shots.
One last thing - is there something where I can make sure all my cameras are set up with the same configuration - iso,shutter speed...etc...and just get an "All cameras setup the same" type message?It would probably be simplest to just set the parameters before each shot. You are going to need scripting anyway.
Thanks reyalp and mphx - I will use the chdkptp - after reviewing this topic again that will provide what I need.Note that chdkptp will not give you the same level of sync available with USB remote. If you want to capture moving objects, then it probably won't be good enough.
My biggest issue - If I'm taking a few shots in a row a random camera will miss a shot.The best solution to this would be to figure out why they are missing shots and fix it. With some additional information like
Now i have to install chdk into 64 sd cards !!Refresh my memory? How are you planning to trigger all these cameras? ( i.e. will you be needing precision sync and if so, via battery terminal or USB 5V?)
Now i have to install chdk into 64 sd cards !!Your mileage may vary, but I would approach this by setting up one card, making a disk image, and then writing that to the remaining cards. On linux (or using a live CD) this can be done easily with dd. I'm sure there's some windows software that will do it too.
After the cards are bootable, you can update by uploading files through chdkptp.
Other than the first time I setup an SD card for CHDK, it almost never comes out of the camera again. Script and CHDK core code get downloaded as updates appear or I make changes while working on code. Downloading to multiple cameras would be a simple extension for multicam.lua (assume it does not already do that?)
After the cards are bootable, you can update by uploading files through chdkptp.
What do you mean by this ? That you can update chdk , by uploading some "files" of chdk through chdkptp ?
And it can be done for multiple cameras lets say? :)
What do you mean by this ? That you can update chdk , by uploading some "files" of chdk through chdkptp ?Yes, chdkptp can upload files. See the upload and mupload commands.
And it can be done for multiple cameras lets say? :)There isn't currently code in multicam.lua to do this, but it could be done similarly to how the old download_last command was implemented.
Other than the first time I setup an SD card for CHDK, it almost never comes out of the camera again. Script and CHDK core code get downloaded as updates appear or I make changes while working on code. Downloading to multiple cameras would be a simple extension for multicam.lua (assume it does not already do that?)
copy diskboot.bin or are more files involved to the "update"?For an updated build, you should copy the files in the "small" download package on the autobuild site. This is DISKBOOT.BIN, PS.FI2 and the stuff in CHDK/MODULES
For an updated build, you should copy the files in the "small" download package on the autobuild site. This is DISKBOOT.BIN, PS.FI2 and the stuff in CHDK/MODULES
PS.FI2 is only used for manual loading with firm update, but it can be useful to have on the card.
For an initial install, you need everything in the large download. This includes some script libraries and other files.
If you need specific CHDK settings, you could also copy the .cfg files between cameras. This should be totally fine if they are all the same model. If you copy between different models, some settings will be reset. Alternately, you could use set_config_value with multicam.
How overwriting is handled?The current upload functions overwrite existing files without any prompt or notification.
@reyalp
1. Zoom -
So an idea popped to issue a set_aflock(1) before set_zoom..and TAAA-DAAA ..lens moved!
And i created another button in the GUI , with exactly what you said.. !mc:cmd('call ... your lua code').Worked like a charm.
I've been following this thread but I can't understand this...
can you tell me what you did step by step for this zoom command, I really dont understand how to zoom all cameras with chdkptp multicam
!mc:cmdwait('call set_aflock(1)')to the console.!mc:cmdwait('call set_zoom(12)')!mc:cmd('call set_focus(10)')can you tell me what you did step by step for this zoom command, I really dont understand how to zoom all cameras with chdkptp multicamSomething like
!mc:cmdwait('call set_zoom(2)')
Where 2 is the zoom step you want to zoom to.!mc:cmdwait('call click("zoom_out")')
but this will be slow if your camera has lots of zoom steps.YEs!! I did it.
trying to go to the next step
many many thanks to you @mphx, @reyalp
.
Syncing was very good
"object" is rather still .
So, how do you know the syncing is 'very good' ? :)
.
As a conclusion , syncing for the project requirements was "very good" :)
and if nothing moved at all, sync would be excellent.
In fact, you could just walk around the subject with a single camera and take as long as you like :)
When all shooting is completed you can swivel each camera and either remove the SD card or insert a normal USB cable.For 24 cameras ? Really? Every time you want to transfer images?
Keep it simple .........If your cameras don't support simultaneous PTP and USB remote precision sync then I guess that's your only choice.
For 24 cameras ? Really? Every time you want to transfer images?
If your cameras don't support simultaneous PTP and USB remote precision sync then I guess that's your only choice.
P.S. : that PS is for reyalp :) I noticed that when i had X number of cameras working ok and doing stuff..deleting images from them (multicam command) was missing some cameras when trying to delete images.I had to issue the command twice to be sure that all images from all cameras were deleted.Cameras were still connected to the program (i could go from rec mode to preview mode and vice versa but delete command was misbehaving)This doesn't really give me much information to go on. I would expect failures to generate some warning messages in the console.
This doesn't really give me much information to go on. I would expect failures to generate some warning messages in the console.
Regarding the issues with lots of cameras connected: If you are still using the GUI to control, I would strongly trying using the CLI. You could also try
set gui_dev_check_interval=0
in the GUI.
Well , when multicam has "lost" some camera(s) , it pop ups a blank popup window with nothing on it.When i see this popup i know that a camera has lost connection.From this point no command can be issued so i have to reconnect them.Did I mention you should try not using the GUI? ;)
Another "message" i see with "delete" command is (i will try to describe it since i don't quite remember it)..it displays in the console the actual command that is used and below that something like <id> : I/O error.IO error means that some problem has happened with the USB connection. So this is probably due to your general USB stability problems, and not specific to delete.
PS : at some point of the tests... i had an error/message ...something like "cannot send <name of command> command : msg queue full. From that point nothing was working..i had to reboot ALL cameras.Any ideas about that?That should mean that the one (or more) of the cameras was not processing messages as fast as you were sending them. Without knowing more about the specific sequence of events, I would be very difficult for me to guess what is happening.
Did I mention you should try not using the GUI? ;)
If you are using custom GUI code that's just calling multicam functions from a button callback or something like that, it would also have this problem. Since you haven't published the code, I can't give you much help with that.There is nothing fancy.Added one tab in gui.lua and a new lua file for that tab that just contains my buttons.Which buttons are copy/pasted from other buttons and i just changed the commands :)
IO error means that some problem has happened with the USB connection. So this is probably due to your general USB stability problems, and not specific to delete.Yes , i thought so too , but the strange thing is that other commands (preview , rec mode , shoot) continue to work to ALL connected cameras like no camera had lost connection..that's the strange thing.Anyways....
That should mean that the one (or more) of the cameras was not processing messages as fast as you were sending them. Without knowing more about the specific sequence of events, I would be very difficult for me to guess what is happening.
multicam commands are implemented as messages sent with chdkptp <connection>:write_msg. The camera side script (rlib code at the bottom of multicam.lua) sits in loop waiting for messages. The message system has a queue that can hold up to 15 messages. Normally, you should wait for the previous command to be processed before attempting a new one, by using cmdwait or a hard coded delay.
There is nothing fancy.Added one tab in gui.lua and a new lua file for that tab that just contains my buttons.Which buttons are copy/pasted from other buttons and i just changed the commands :)It doesn't matter if it is "fancy" or not, it is much more difficult to give you specific advice when I don't know what you are actually doing.
So i have to turn some cmd to cmdwait.Is there a rule ?What commands need to be "cmdwait"?As I said, you should wait for the previous command to finish before issuing a new one. You can use cmdwait with any command that uses write_status, which AFAIK is just about everything but quit. Note that depending how your code is set up, using cmdwait in the gui may make it effectively lock up until the command finishes.
Is it possible , if i connect to x number of cameras , and y number of them lost connection to continue working (issue multicam commands) to the remaining ?It should be possible to flag cameras when they hit an error or remove them from the list of active connections. This is something I've thought about but haven't written any code for yet.
Right now if atleast one camera lose connection..i can't do anything...i have to reconnect to all.
Is it possible to turn chdkptp into client/server ? :) I mean ...to be able to run chdkptp to let's say two different pcs and each one will connect to a specific number of cameras... then hit shoot to one pc and check in the local lan and sync shoot to all running instances of chdkptp... something like that :)Of course it's possible in theory. In practice, I don't see any way to do it without writing a lot of new code.
This thought arises another pack of problems..how to click / shoot synced at the different computers.As I suggested earlier, you should be able to do this programmatically if you use the CLI and feed commands over ssh or similar. You could also do it with some fairly trivial scripting using control files on a network filesystem.
We are thinking touch screen and use of teamviewer..still it will be tricky.
I will be straight .. how much do you want to make chdkptp work in a network :)Spending much more time than I do now to chdkptp would require quitting my day job.
As I suggested earlier, you should be able to do this programmatically if you use the CLI and feed commands over ssh or similar. You could also do it with some fairly trivial scripting using control files on a network filesystem.
Did you ever try using a linux host? Or using the CLI?
Do you have any more details of the specific errors and when they happen? Does it only happen if you shoot, or if you just connect to the cameras do they stop being connected after a while?
What specific errors do you get?
How are you powering the hubs and cameras?
Could it be the case that the power supply is the cause of your woes, rather than the hubs themselves?
A previous rig suffered from earthing (electrical grounding) issues. You might like to take a look at this thread http://chdk.setepontos.com/index.php?topic=10385.120 (http://chdk.setepontos.com/index.php?topic=10385.120)
I don't know about power grounding...i mean if it creates problems or not in my case....i can't check it ....This is almost certainly a grounding problem on the low voltage side.
Another question , how do you control on camera setting ? ISO , speed shutter ,aperture ?Did you read my response the first time you asked this ?
Post a picture of your USB hubs, power supplies, and camera power supplies? Or a link to where you bought them?
Hint : USAGE.TXT line 268
Another question , how do you control on camera setting ? ISO , speed shutter ,aperture ?
There is no specific error and it doesn't occur in a specific moment..it can happen during "connecting" or during sync/shoot or during download/delete.It just pops a blank error window and when i see it i know that one or more cameras have lost connection.I explained previously how to make this give you a more informative error message: http://chdk.setepontos.com/index.php?topic=11667.msg116130#msg116130 (http://chdk.setepontos.com/index.php?topic=11667.msg116130#msg116130)
Line numbers probably aren't useful unless you specify a revision ;)Hint : USAGE.TXT line 268
looks like 368.
There is no specific error and it doesn't occur in a specific moment..it can happen during "connecting" or during sync/shoot or during download/delete.It just pops a blank error window and when i see it i know that one or more cameras have lost connection.I explained previously how to make this give you a more informative error message: http://chdk.setepontos.com/index.php?topic=11667.msg116130#msg116130 (http://chdk.setepontos.com/index.php?topic=11667.msg116130#msg116130)
Did you try a linux host? If nothing else, linux system logs might provide more information about what is actually going on.
I would not be at all surprised if the is a hardware issue (power, grounding, cabling, hubs...) but I also wouldn't be surprised if it were a software issue.
I've never used chdkptp with more than 3 cameras, so this is unknown territory for me.
Pfff it's gonna be messy to ground all these things...You might think about using something like this : http://www.ebay.com/itm/like/151098536728?lpid=82 (http://www.ebay.com/itm/like/151098536728?lpid=82) but in the correct connector sizes for your hubs & fake batteries.
let me see if i get it right... i get the first one and connect one side to the dummy battery and the one of the 2 other sides to the power cord of it. Second side that is left free , i end it with the second thing... And then i connect with some kind of wire all the "second image" things through that green thing to create a common ground spot or something?Correct. You could also buy the appropriate male plugs & female jacks, suitable for mounting on a cable, and solder together to create your own adapter cables.
If the above is correct it can be done for the dummies...i dont get it how can be done with hubs.The pictures you posted of your hubs show that is uses a "wall wart" style power supply that plugs into the hub to provide power. See the center jack in this picture.
What was the other thing you said in earlier post?Connect the ground of one port of every hub all together?This will do partially the trick?I was just trying to suggest another method to get all the grounds connected. The metal shield on the USB hubs or the 0V power pin on the USB jack might be all connected to the 0V line from the powerpacks. You will need to check that with an ohm meter. If they are, then any method that connects them all together will help create a common ground point.
Lets put your ideas on hold a bit waterwingz.Congratulations! You have just proven exactly what I was trying to tell you.
...
And a really good source of noise is cheap switching mode power supplies.
...
...go figure...pathetic country with pathetic people when it comes to do a job right.
In my region (Greece) , grounding is not something that is setup properly.My friend asked the electricity technician that he setup the electric stuff on the studio and he told him that even in more complex buildings , ground wire in the sockets is not even connected somewhere..just hanging in there...go figure...pathetic country with pathetic people when it comes to do a job right.The discussion here about the grounding system in your building, and the importance of protection circuits on the AC high voltage side, is a valuable discussion about electrical safety.
The discussion here about the grounding system in your building, and the importance of protection circuits on the AC high voltage side, is a valuable discussion about electrical safety.
However, it has almost nothing to do with your problems.
What you are dealing with is a whole lot of floating DC low voltage systems (cameras & hubs) without a common voltage reference point (sometimes mistakenly called ground). This gives you all kinds of current paths and voltage drops - made worse by high frequency noise and coupling between cables. Ideally your common voltage reference point ( the thick wire I talked about earlier ) would also be connected to an earth ground provide by your building but just having a common reference is 95% of the battle.
Are you using the hubs with power supplies or using them unpowered?
.
Here is a rough example of a test we did http://p3d.in/GA01v (http://p3d.in/GA01v)
Here is a rough example of a test we did http://p3d.in/GA01v (http://p3d.in/GA01v)Very nice. Displays perfectly on my low end Win7 laptop.
Very Good result mphx.. What software are you using for this?
Apart from that, let me ask you a basic question ...............
you create a 3D model of a person, what then, what is it for ?
looking good !!!
could u send me pic of your rig ?
I would like to see how u managed to take pic from of the head from top view
thx
So it all comes to good quality cables and hubs and keep them away from power sources :) We wasted too much time and money to find good cables and hubs...The key feature of the "good quality" cables that probably matters is the gauge of the shield layer and its ability to carry enough current to equalize variation in ground potentlal between all those floating power supplies you are using. In other words, rather than hooking up a common heavy gauge ground bus like I suggested, you now have cable with enough current carrying capacity to mostly serve the same functions. If that works for you then it's good enough - but if it was me I would hook up a separate common ground.
Poor quality cables are a notorious problem with USB. Not sure how to test them, but they can cause all sorts of problems with drives, etc. They'll work well enough to make trouble. >:(
If you check the photos that i posted , you will see around the tripods on the floor stacks of cables that we used , they didn't work and are going to be a money (and it was time loss too) loss.On final time, for the record, I'll point out that with better grounding, those cables might have worked just fine.
If you check the photos that i posted , you will see around the tripods on the floor stacks of cables that we used , they didn't work and are going to be a money (and it was time loss too) loss.On final time, for the record, I'll point out that with better grounding, those cables might have worked just fine.
Poor quality cables are a notorious problem with USB. Not sure how to test them, but they can cause all sorts of problems with drives, etc. They'll work well enough to make trouble. >:(
Sadly you can't test them if you don't buy them :) A cable that works well with usb sticks/disks or printers is not guaranteed that will work well with a bunch of cameras.
If you check the photos that i posted , you will see around the tripods on the floor stacks of cables that we used , they didn't work and are going to be a money (and it was time loss too) loss.
Is there a way probably through some lua commands to switch between jpg and raw format at will ?set_raw(off/on) (http://chdk.wikia.com/wiki/CHDK_scripting#set_raw) ?
set_raw(off/on) (http://chdk.wikia.com/wiki/CHDK_scripting#set_raw) ?
it means photos ...right? :)Yes.
Also since i am not lua expert.. what should be the code of a "button" that switches on/off raw recording?I don't know what your existing "button" code looks like but you are probably also looking for the get_raw() (http://chdk.wikia.com/wiki/CHDK_scripting#get_raw) function ?
probably getting current status and turning on or off accordingly raw mode.
Some tests with zoom came up with some distortion...if we take the photos as raw then the problem is solved.It's not clear what you mean. Are you saying the jpeg has distortion but the raw doesn't? Usually, it's the other way around, the camera applies distortion correction to the jpeg, while the raw is uncorrected.
It's not clear what you mean. Are you saying the jpeg has distortion but the raw doesn't? Usually, it's the other way around, the camera applies distortion correction to the jpeg, while the raw is uncorrected.
There are also some ports which have bug where using the set_zoom function causes the jpeg to not have the normal distortion correction applied. In this case, we may be able to fix the bug, or you can use repeated clicks of zoom_in and zoom_out to set the zoom.
I was at studio today.There is a distortion at photos with zoom. straight things appear bent.The same distortion in dng format is way less.The only way I can see this happening is if the camera firmware is incorrectly applying the distortion correction. This could happen if the part of the firmware that does the correction thinks it's at a different zoom level.
The only way I can see this happening is if the camera firmware is incorrectly applying the distortion correction. This could happen if the part of the firmware that does the correction thinks it's at a different zoom level.
Are you using the set_zoom function to change the zoom?
Do you still get the same effect if you use key press functions, like click('zoom_in') ?
If you shoot without zooming in, is the DNG more or less distorted than the jpeg?
Of course, if DNG works for you then you can certainly use it, but looking into the root cause might save you trouble elsewhere.
Maybe set_zoom function has issues?:)What version of CHDK are you using? According to the SVN log, an issue like this was fixed in CHDK 1.3 rev 3586 for A2500.
What version of CHDK are you using? According to the SVN log, an issue like this was fixed in CHDK 1.3 rev 3586 for A2500.
So true , i am several versions behind. So remind me again how updating of chdk works.I download the "small" package and i replace some specific files ?Which ones.Upload the complete contents of the small package to each camera. Strictly speaking you don't need the .txt files, and you don't need PS.FI2 if you are going to use "firm update" loading.
And how can i do it for 64 cameras .Any chance for some multi-upload function ? :)http://chdk.setepontos.com/index.php?topic=11667.msg115482#msg115482 (http://chdk.setepontos.com/index.php?topic=11667.msg115482#msg115482) still applies
savecon=con
for lcon in mc:icams() do
con=lcon
cli:print_status(cli:execute('mup c:/path/to/update A/'))
end
con=savecon
http://chdk.setepontos.com/index.php?topic=11667.msg115482#msg115482 (http://chdk.setepontos.com/index.php?topic=11667.msg115482#msg115482) still applies
Assuming you've extracted the zip into c:/path/to/update, and have loaded multicam and connected to all the cameras you want to update, something like the following ought to work:Code: [Select]savecon=con
for lcon in mc:icams() do
con=lcon
cli:print_status(cli:execute('mup c:/path/to/update A/'))
end
con=savecon
If the multicam script is already running (mc:start() has already been called) you will need to call mc:cmd('exit') first, followed by a small wait.
Didn't work.And by that i mean , it wasn't executed.Some error in the script or it wasn't supposed to be ran like this.Without any output or other information, it would be very difficult for me to know. I did run pretty much the exact same code using an ! command.
Any ideas?
Without any output or other information, it would be very difficult for me to know. I did run pretty much the exact same code using an ! command.
Edit : If I have a few minutes later today, I'll try to create a wiring diagram that shows all of this.would still appreciate that.
Ok , i added some buttons for raw mode and for manipulating dng files apart from jpeg.I will put them in test tomorrow and will post the code for anyone that would like to do something similar.yes please.
Thing is the same error is produced whether i change something in the script or empty it entirely.So it has nothing to do with code I posted.
How are you trying to execute the script?
I would suggest either !dofile'mup.lua'
or change your lua file to define a function and the use
!require'mup.lua' your_function()
exec mup.lua or!mup.luaI am missing something here , i feel it .Yes. exec (AKA !) runs lua code not lua files. If you want to run a lua file, you need to use a lua function that executes the file, like the examples in my previous post.
Yes. exec (AKA !) runs lua code not lua files. If you want to run a lua file, you need to use a lua function that executes the file, like the examples in my previous post.
Next problem that came up : ISO doesn't stay stable. i have set it up in the chdk menu in all cameras but we have noticed that in extreme lighting occasions iso changes from that pre-determined number.1) What is the ISO mode set in the canon firmware?
1) What is the ISO mode set in the canon firmware?
2) What *specific* chdk settings are you using.
3) How are you determining that the ISO has changed?
4) What does "extreme lighting" mean?
If you just want a fixed ISO value, I'd suggest setting it in the canon firmware rather than in the CHDK menu. I realize this is fairly annoying with a large number of cameras, but doing it in the canon menu shouldn't be more so than the CHDK menu.
If you want to adjust it per shot, then you probably want to send overrides in your shooting script.
cli:print_status(cli:execute('mup c:/path/to/update')) cli:print_status(cli:execute('mup c:/path/to/update /')) cli:print_status(cli:execute('mup C:/path/to/update2 CHDK/MODULES/')) 1)Do you mean what is the by default iso value in the camera?I don't know.It changes according the conditions.So ISO is set to auto in the func menu? Every powershot I know of allows you to set the ISO manually in P mode.
2)I don't get what you are asking here.Only thing i have set up in chdk menu is ISO VALUE , nothing else is changed there.At a minimum, you'd need to make sure "disable overrides on startup" isn't checked, and the box next to "override ISO" is checked.
3)Right click the photo , settings , details and checking the info there.When using CHDK overrides, it's not always safe to assume the exif reflects what the camera actually did. If in doubt, you should hold the shutter speed constant and examine the actual images. That said, I suspect in your case the override simply isn't active at all.
When you say set it up in the canon firmware what exactly do you mean?If it means what i am imagining , it won't be easy task.I meant setting it in the menu of each camera. It would not be fun, but it should be saved between reboots and give you exactly the setting you set.
Overriding through the shooting script guarantees that it will shoot with that value and cameras won't take initiatives of their own and change it ?Nothing in chdk is guaranteed ;)
About that last , what's the command ? "set_iso_real"?or "set_iso_mode"?See the links available from
And a last thing.We need to control white balance...what's the proper way?play with set_prop/get_prop or is there any more easy way?Do you need to set white balance mode (like daylight, tungsten etc), or specific custom values?
First of all script needed a correction.I don't know what you copied. The code I posted in http://chdk.setepontos.com/index.php?topic=11667.msg117270#msg117270 (http://chdk.setepontos.com/index.php?topic=11667.msg117270#msg117270) includes the target directory, 'A/'
The commandCode: [Select]cli:print_status(cli:execute('mup c:/path/to/update'))
toCode: [Select]cli:print_status(cli:execute('mup c:/path/to/update /'))
In few words target dir was added :)
In few words only files in root dir of the update folder were copied and i had to take away the subfolder CHDK in order to be able to copy the root dir files.The code I posted correctly uploads the source directory and all it's sub-directories. I don't know what caused your "general error", it might happen if you have files or directory names in the tree that are not compatible with the camera file system.
My question is , are these files i didn't copy (CHDK/MODULES/*) necessary ?Or i can "forget" them at all?You need them.
The 2 cameras with the new version (3636) shutdown randomly when we "play" with the zoom (aflock-1 , zoom , aflock-0)...while another camera with older version of chdk works fine.I told you before the aflock zoom thing was suspect. Since the zoom code has changed, it's not surprising that it causes problems. You should check whether the aflock workaround is still required.
But it got fixed partially..if you zoom a little bit , distortion is little...if you zoom more , distortion is more.Are you saying that you still get distorted JPEGs at the tele end of zoom? Here (http://chdk.setepontos.com/index.php?topic=10626.msg115958#msg115958)'s a user that claims otherwise. The changes mentioned in the linked post are now part of the CHDK 1.3 release for the a2500.
2.ISO (in an effort to reduce noise). In chdk menu "disable overrides in startup" is unchecked and iso override is checked.But as i said in previous post iso is sometimes different in some photos.Please check the camera's Rec menu (the Canon menu in record mode) whether "servo AF" is enabled. If it's enabled, disable it.
3.White balance. We need (...) fixed white balance.There is currently no way to set a fixed white balance with CHDK, the only way to do it is to use the Canon shooting menu with simulated keypresses. Note that the camera will still (more or less depending on the preset) continuously adjust white balance, unless you set a custom white balance.
Are you saying that you still get distorted JPEGs at the tele end of zoom? Here (http://chdk.setepontos.com/index.php?topic=10626.msg115958#msg115958)'s a user that claims otherwise. The changes mentioned in the linked post are now part of the CHDK 1.3 release for the a2500.
Can you compare JPEGs made
- after zooming with set_zoom
- after zooming manually
?
Canon A2500 suck.It is a bottom of the line P&S, so this shouldn't be a huge surprise.
Big time.Noise in the photos is pathetic.We did a test.3 cameras shooting the same thing in daylight conditions.I'm not surprised the A2500 sucks, but I am somewhat surprised it is much worse than the S4. Can you upload the sample shots somewhere?
A canon dslr camera , a canon A2500 compact camera and galaxy s4 , my phone.
Dslr result was nearly perfect..minimum to none noise, expected.galaxy s4 , second place , minimum noise and last position belongs to A2500...pa-the-tic.
That's why we got into the thing of updating chdk in the cameras in order to "fix" the zoom thing.Can you verify whether or not the same distortion appears if you zoom using the physical zoom controls (or simulated key clicks)?
But it got fixed partially..if you zoom a little bit , distortion is little...if you zoom more , distortion is more.
More distortion = more screwed up models produced = no go.
1.With manual zoom , there is no distortion.Again sample images would be interesting.
Download them , and zoom in at the wall at the right side of that green window in the building...the difference in noise is clear there..Agree the S4 is less noisy, and sharper over all. The A2500 isn't quite at minimum ISO, but its very unlikely that will make up the difference.
Again sample images would be interesting.
Agree the S4 is less noisy, and sharper over all. The A2500 isn't quite at minimum ISO, but its very unlikely that will make up the difference.
With F8.0 (A2500) you get a lower depth of field than with F2.2 (S4). There is also a difference with the ISO values, A2500 => ISO 125 and S4 => ISO50.
Use the same conditions with both devices and compare the images, preferably as raw files.
msl
With F8.0 (A2500) you get a lower depth of field than with F2.2 (S4).Isn't that the other way around? Although on those little lenses, F8 might be approaching the diffraction limit?
Isn't that the other way around?Yes, you're right. I meant the hyperfocal distance. Regardless of this the test should be performed with the same settings.
The whole point of the "experiment" wasn't to compare results with dslr or s4.We wanted to see if the noise is reducing with brighter scenes (daylight conditions).And as you can see , noise is still in high levels.
"Maybe flash is the way to go?"
1.With manual zoom , there is no distortion.Coming back to this, it should be possible to work around use key presses, something like
!mc:cmdwait('call repeat click("zoom_in") until get_zoom() >= 10')
press('zoom_in')
repeat sleep(10) until get_zoom() == 10
release('zoom_in')
Just noticed this "3D Pandoras(s)?" referred to on the Agisoft site http://www.3dpandoras.com/#section03 (http://www.3dpandoras.com/#section03)
Edit: Oh, and a placeholder for my memory:
http://www.agisoft.com/forum/index.php?topic=2654.msg14413#msg14413 (http://www.agisoft.com/forum/index.php?topic=2654.msg14413#msg14413)
"...Also very important, try to go away from auto focus. It is not as important in a constant light situation as yours compared to the flashes but still you can get a few cameras that didn't focus correctly on each session and you will loose important info for the PS process.
You should get someone with nice easy to focus clothes (jeans for example) in the center of the shooting and manually (or automatically) focus all the cameras. When you are sure all of them are well focused (you should zoom in at least 200% to verify) then you turn them to manual focus and leave them that way."
that script finshes with "exit-ALT" (does that even exist?)link> exit_alt() (http://chdk.wikia.com/wiki/CHDK_scripting#exit_alt)
1.Any good and reliable svn update/sync program (with gui if possible) for syncing lua files ?I tend to use command line svn, probably just called 'subversion' or maybe something like 'subversion-client' in your package manager. The last time a looked (not recently) there wasn't anything remotely comparable to tortoise.
2.I created a launcher for the program ...is there any ico to put to it ? :)Not in any normal format. The one that appears on the program at run-time is in gui_icon.lua. msl made that, I'm not sure what the source file is. I'm sure you can find the chdk logo on the wiki.
The last time a looked (not recently) there wasn't anything remotely comparable to tortoise.
!mc:cmdwait('call repeat click("zoom_in") until get_zoom() >= 10') (http://chdk.setepontos.com/index.php?topic=11667.msg117482#msg117482 (http://chdk.setepontos.com/index.php?topic=11667.msg117482#msg117482) ) should solve it.Attached here example of set_zoom distortion (i am not sure the specific value but i assume it is around zoom=20)I see the problem now! Somebody bent the poles & bars that hold your cameras in place. :lol
higher the zoom , higher distortion (fish eye)
If anyone comes to greece , visit us :) http://www.its-you.gr (http://www.its-you.gr) .Friendly prices :)Very cool!
mphx / reyalp, Can you confirm it solved the issue ? (second, Will it work on my FW version 1.3.0-3492)?Using key clicks should be exactly equivalent to using the actual controls on the camera, so it should work if doing it manually on the camera gives correct results.
However, as I noted in the earlier posts, you will need to make sure all the cameras end up on the same zoom step. On elph130 at a least, this requires additional logic, because the number of steps it moves per click does not appear to be completely deterministic. It's possible that using levent functions would be more predictable.By "additional logic" I assume you mean a small script that handles the clicks and checks the zoom position and corrects where necessary?
By "additional logic" I assume you mean a small script that handles the clicks and checks the zoom position and corrects where necessary?Right, instead of
repeat click'zoom_in' until get_zoom() >= 50
something likerepeat
if get_zoom() < 50
click'zoom_in'
elseif get_zoom() > 50
click'zoom_out'
end
until get_zoom() == 50
(edit: the above code would try indefinitely, which may not be what you want...)con 28> =repeat click'zoom_out' until get_zoom() <= 20 return get_zoom()
29:return:20
con 29> =return get_zoom()
30:return:19
It's possible that having a sleep would also avoid the overshoot issue.Is it worth doing :Code: [Select]repeat
if get_zoom() < 50
click'zoom_in'
elseif get_zoom() > 50
click'zoom_out'
end
until get_zoom() == 50
press("zoom_in")
sleep(delay)
release("zoom_in") Is it worth doing :There is already some delay built into the press/release functions. I tried using just press'zoom_in' release'zoom_in' and it didn't seem to move less than click.Code: [Select]press("zoom_in")
sleep(delay)
release("zoom_out")
where delay is a small value ?
> =i=0 repeat click'zoom_in' i=i+1 z0=get_zoom() sleep(100) z1=get_zoom() until z1 >= 50 sleep(500) return i,z0,z1,get_zoom()
15:return:22
15:return:50
15:return:53
15:return:53
> =i=0 repeat click'zoom_in' i=i+1 z0=get_zoom() sleep(1000) z1=get_zoom() until z1 >= 50 sleep(500) return i,z0,z1,get_zoom()
24:return:11
24:return:49
24:return:52
24:return:52
Note the number of iterations drops by half with the longer sleep between clicks.=i=0 repeat post_levent_to_ui('PressTeleButton') sleep(50) post_levent_to_ui('UnpressTeleButton') i=i+1 z0=get_zoom() sleep(250) z1=get_zoom() until z1 >= 50 sleep(500) return i,z0,z1,get_zoom()
43:return:12
43:return:52
43:return:54
43:return:54
PS: i can link you the footage from yesterday's live if you like people , but its a greek tv show and i don't know if you will understand anything :)Please do (i'd love to see it at least: "Leonidas (the return, value)" :D - maybe reyalp, WW (if they started to charge) & you could buy the Hellenic Republic shortly, or Santorini https://www.youtube.com/watch?v=hVkA7G33EGk (https://www.youtube.com/watch?v=hVkA7G33EGk) at least (that'd do)!!).
If you want to use CHDK's USB remote "sync" feature, you need to be able to disconnect the 5V "red" wire to all 80 cameras at exactly the same time. If you don't want to lose USB communications, then you can't simply turn off the power to all the hubs (even supposing that causes the individual cameras to all see the power go off at exactly the same time).
If you can make reyalp's calibrated sync shooting mode in multicam.lua work acceptably then you are spared the pain of trying to switch the hubs. Note that your earlier tests on two cameras don't tell you what will happen with 80 cameras - the sync error is not 80x(two camera sync error). It might actually be okay for your application.
There is one thing I don't get:
"If the Enable Sync option is set in CHDK then each camera will wait for the final transition of the USB signal ( 5V to 0V )."
It seems just to be the opposite, with Sync enabled my camera takes a shot immediately when it gets 5V on the usb port and as reslult the camera's are not in sync. (elph300hs, one push, normal control mode)
With sync disabled** it works as I would like it takes the shot as soon as the 5v is switched off, just like the inverted remote script.
Any chance a kind guru could comment on or, even better, fix the "capt_seq.c"Whatever you are seeing, it is unrelated to the thread you linked. The necessary code is in capt_seq.c for the SX150HS.
Whatever you are seeing, it is unrelated to the thread you linked. The necessary code is in capt_seq.c for the SX150HS.
@andrew
and... santorini is overrated ...and not for sale last time i've checked :)
the footage for anyone that cares :) https://www.dropbox.com/s/1qk0t09tm8fll43/john_skai_part1-cropped.mp4?dl=0 (https://www.dropbox.com/s/1qk0t09tm8fll43/john_skai_part1-cropped.mp4?dl=0)
feel free to yell "it's all greek to me" :)
I get the concept that "Default Running" means there is no script to run actually. But when this indicator is ON i have noticed that i cant run a script from pc to the camera let's say.You can only run one script at a time on the camera. When chdkptp wants to run a script there cannot be one already running. I think that when it does run a script, it does not provide a script name to the camera so the "default script" name defaults in the CHDK code and that is what you are seeing.QuoteAt your last phrase "you won't need to worry at all about disconnecting and reconnecting". But with the "usb switch" method a disconnection occurs no matter what. At that point the two script won't lose "connectivity"?When you used CHDKshell to build your own version using my simple patch, you bypassed that. The patch tricks the Canon PTP code into not seeing the disconnection (i.e. USB power going away) when you press the button. The PC also can't tell that the button was pressed so both the host script and the camera scripts keep running as if nothing has happened. That was the whole point of doing the patch in the first place - you could just use the stock build otherwise.
If I use bcamhost and bcamrem，should I build the special version for my A1200？That should not be necessary (see below).
Another question，what is the mask script （novsela called it mask code，see 1.png）？That post refers to a specially modified version of CHDK that allowed the concurrent use of USB "sync" and ptp communications on the same setup. It was added to the autobuild some time ago and enabled on a few cameras (those that were tested with the patch and confirmed to work). The A1200 is one of those cameras.
Thank you so much！waterwingz
That's really a good news to me :)
Then，I could go to the next work.
Is it possbile to add some commands ，such as“exec bc=require('bcamHost') bc:connect() bc:cmdwait('shoot')”， to CHDK PTP-- User Tab as a button just like what mphx did.
If it is possbile，could you give me an example？Thus I can learn from it to edit some other commands by myself.
Thanks！
@ reyalp：Is it possible to improve the Synchronization of the multicam way？I'm not sure which commands you used. To get the best sync you should
@mphx：You said the multicam way is enough for building 3D model，do you use faster shutter speed? Thus I think you must use brighter lights.
Very nice work :)I didn't run step2 init_sync. And I will replace shoot command with shoot_hook_sync command.@ reyalp：Is it possible to improve the Synchronization of the multicam way？I'm not sure which commands you used. To get the best sync you should
1) Use CHDK 1.3
2) init_sync
3) preshoot and wait for all cameras to be ready
4) ensure sync time is far enough in the future that the shoot command can be sent to all cameras.
5) shoot using the shoot_hook_sync command
If you post the exact code you used to shoot, I can probably tell you if anything is missing. The testshots function might be a useful example.
If more movement is involved i believe that we will have problems :)
...[]...
Finally if you are thinking of making 3d models with the whole setup you are making , lets hope you have good 3d modelling skills , because the produced 3d model needs A L O T O F W O R K to become ready for printing or whatever...low quality of these canon series , don't produce the best images for 3d modelling...
PS: we have bright lights in the shooting area..we don't mess with shutter speed , only iso and zoom.Some photos are taken bright and few (2-3 out of 64) a bit darker...so maybe we should mess with shutter speed at some point..but we can handle the difference in light in those few photos in the 3d modelling procedure for the time being.
Quote from: RalfHI agree with Mr. Curious but want to stress that "bright lighting" is too simple: ideally, the lighting should be such that small detail (e.g. skin pores in this case) will be enhanced rather than subdued in the images. Visually smooth surfaces are really difficult because PhotoScan needs to be able to detect features. Experimentation with multi-directional vs. homogenous diffuse lighting might be interesting in this respect.
The reason bright light is highlighted here is because of the experimentation with continuous light. To mimic the same light levels one gets with flash light which is VERY bright but at a short burst of time, anything around 1/10,000th of a second. To match that same level of light to use similar camera settings, low ISO (very important) but high exposure speed 1/100th you need bright light just to match that same quality. Obviously not over bright as this will wash out any details. The alternative is noise projection but this introduces other problems of being able to capture a color pass quickly straight after, or using additional separate texture cameras. Multi directional lighting is possible but you need VERY fast capture if you are doing scanning of live subjects.
Hello James,
full format sensors usually have better image quality (e.g. less sensor noise and less "bleeding" between pixels). For close-range applications they are often not advantagous because at the same field of view (larger sensor in combination with a longer focal length) they have a smaller depth of focus. For facades of buildings, air photos etc., full format sensors would be preferable, for close-range applications you'd have to find a compromise between image quality and depth of focus.
Do I need run step2 each shot or just sync one time before taking shots?Just once per session. The "sync" process attempts to create a mapping between the tick counter on each camera and the PC system clock, so the you can issue a command to shoot at PC clock time X and multicam translates this into a camera tick time.
> !mc=require'multicam'
> !mc:connect()
+ 1:Canon PowerShot D10 b=\\.\libusb0-0001--0x04a9-0x31bc d=bus-0 s=...
> !mc:start()
> !mc:cmdwait('rec')
1:rec
> !mc:init_sync()
1: send 3 diff 11 pred=53251 r=53260 delta=-8
...
1: send 6 diff 221 pred=53461 r=53470 delta=-8
1: ticks=10 min=-11 max=1 mean=-6.993300 sd=3.577292
1: sends=10 min=2 max=7 mean=4.400000 sd=1.800000
minimum sync delay 6
Note I suggest switching to rec mode before doing init_sync: The camera CPU is busier in rec mode, so the latency is higher.> !mc:cmdwait('preshoot')
1:preshoot
> !mc:cmdwait('shoot_hook_sync',{syncat=100})
1:shoot_hook_sync 499081
..but noise still remains.
Here's a link on the off chance you are not aware of semi-automatic masking http://www.agisoft.com/forum/index.php?topic=2846.msg15090#msg15090 (http://www.agisoft.com/forum/index.php?topic=2846.msg15090#msg15090)
Update the sync results：This conclusion confused me until I studied your attachments more carefully. I think what this shows is that using a USB hardware sync solution (e.g.bcam) still results in about 10x better sync precision than the best ptp sync option (e.g.multicam)? But your conclusion is that the multicam solution is "good enough"?
..
Anyway，I think the multicam way is a worthy of choice method：）
PS2 : Best way to mask images in my opinion is "import masks from background".The idea is , you take shots of the client and then you take ONE shot in empty studio...then you import this shot as a mask to every each one of the photos...
We are thinking to implement that in future shots.Best masking ever :)
Hi all. We've been using PhotoScan's built-in tool to get masks from background images (i.e. a second set of clean plate/empty background images taken right after the subject is photographed). It does quite a good job, but seems to have the following issues:
1) the edge of the mask is often too generous in letting in the background, which lets through the white background; this is particularly problematic when creating textures for hair and areas where 'webbing' is likely (fingers, armpit, crotch)
2) it often ends up masking out dark portions of the subject if they are in the same spot as a camera lens in the background image
3) due to diffuse reflection of the subject on our white floor, the contact point of their feet with often includes a significant portion of the floor around their feet
So far we have been manually cleaning up these problem features using the PhotoScan tools, which ends up taking a good 60-90 seconds per photograph on average. Obviously I'd like to take this number down to zero, so have been looking at alternative methods for background subtraction, which I could then feed into PhotoScan. This project looked like a good option, but ended up having its own problems, and being rather slow:
http://docs.opencv.org/trunk/doc/tutorials/video/background_subtraction/background_subtraction.html (http://docs.opencv.org/trunk/doc/tutorials/video/background_subtraction/background_subtraction.html)
Is anyone else using external programs for mask generation? I should know the answer to this but for some reason it is eluding me...
Thanks!
Quote from: tommyboy
1) the edge of the mask is often too generous in letting in the background, which lets through the white background; this is particularly problematic when creating textures for hair and areas where 'webbing' is likely (fingers, armpit, crotch)
It doesn't really matter how accurate the masks are in this regard as Photoscan still doesn't take into account masks during hole fill stage. Webbing will always occur until hole fill is taking masking into account. I believe this is a complex problem to solve.
It's just as fast to do your editing after dense point cloud reconstruction. Edit / delete the points directly in 3D, then build the mesh. Photoscan will still web but it will produce better results and will be faster than manually editing each mask image by hand.
After optimizing the codes，I tested them again and maked a comparison.It really took me some time.Thanks for testing and reporting.
In the end，I find that reducing the syncat number as far as possible can improve the results.If this is correct, it is a bug. All syncat should do tell the cameras to fire N ms in the after the command is issued on the PC. If you set it too short, then some cameras will not have received the command. Any larger value should have the same sync accuracy, only the latency will be higher. Clock drift should be insignificant on the timescale involved.
When I set syncat =50，I got the best result which is less ten times of the result of bcam way.
Of course，the setting is depanding on the number of your cameras.
:DUpdate the sync results：This conclusion confused me until I studied your attachments more carefully. I think what this shows is that using a USB hardware sync solution (e.g.bcam) still results in about 10x better sync precision than the best ptp sync option (e.g.multicam)? But your conclusion is that the multicam solution is "good enough"?
..
Anyway，I think the multicam way is a worthy of choice method：）
@ waterwingz：Now I use three a1200s，I can shoot just by controlling the switch of the central usb hub to disconnect the USB 5V power without any modification（see b.jpg）. Could I still use this method when using 40+ cameras？@waterwingz
@andrew
The whole idea in "masking" is to mask photos with optimal way...and by optimal i mean..don't waste a lot of time masking since a more rough masking would lead to the same results...
post-processing this could be a real headache https://www.youtube.com/watch?v=kF8SYObx1Fg (https://www.youtube.com/watch?v=kF8SYObx1Fg). Wonder what's in the 5Mpix boxes.
Edit: having said that, they capture 2 frames to each camera (admittedly it takes 0.2secs). The second with noise projection with 300 ms flash (seems very long)
Edit2: same guys (I think) http://www.agisoft.com/forum/index.php?topic=1802.msg11496#msg11496 (http://www.agisoft.com/forum/index.php?topic=1802.msg11496#msg11496)
Removing or replacing the background is greatly simplified if the background is a uniform color.A Studio "Bullet Time Rig -SETUP" Example is Here
http://en.wikipedia.org/wiki/Chroma_key (http://en.wikipedia.org/wiki/Chroma_key)
Shooting through small holes in a colour separation overlay screen would seem like an avenue worth exploring.
we are thinking some kind of projectormphx,
We use LED strips, powerful ones. 19watts per meter. We have 20 poles of 2 meter, so 760 watts of LED at about 90cm away from the person.
We have dimmed the LEDs a bit, not using PWM but decreasing the voltage from 24v to 19volt. This is to allow our projection system still to be able to project over the LED light.
Wishgranter, I still get the feeling that - rather than an optimal model - the thesis of the paper is to throw everything [including the kitchen sink] at it -
"For multiple stereo models, small such measurements can be useful for the validation of measurements with strong intersection geometry. Even though small intersection angles lead to noisy results, models with small base lines should be acquired and used within the surface reconstruction. Since large baseline models have lower image similarity - which is challenging for the matching method, small baseline models are required additionally. Furthermore, highly overlapping imagery leads to high redundancy, which is beneficial for the precision in object space."
Maybe [with a supercomputer and deeeep pockets] that is the optimal model...
Quote from: PorlyThe bigger the distance between stereo-pairs, then better the results. With a short basis between pictures the angel for triangulation is small what causes errors(In object direction). I was always using all pictures because I was sure that photoscan is using more Stereo-pairs to estimate one point...
Yes, this is generally true, but only to a certain extent. If the distance (viewing angle) between images becomes too large, new problems will appear, mainly related to increasing difficulties of matching features because (a) the changes are too large between images and (b) low incidence angles (i.e. grazing view of objects). In essence, image distance should be neither to small nor too large.
@H-H
..Try human language !
rick - i'll defer to a guru to, perhaps, answer directly.I tried to use “nshot=2”，but there were around 5 seconds between the 2 capture events.
Two frames to the same camera and a long time between the 2 capture events ? maybe an artec scanner (or more) and some Hao Li "non-rigid registration" (Artec studio) could be a better idea https://www.youtube.com/watch?v=7vkfyCutBjY (https://www.youtube.com/watch?v=7vkfyCutBjY) ?
I tried to use “nshot=2”，but there were around 5 seconds between the 2 capture events.It is likely possible to get this close to the "continuous shooting" spec for your cameras. Generally this is ~1 FPS on low end cameras, so likely still too long to be practical with people.
Yes，it was too long for a living human. :(
We expect work to slow down in the future..but of course we hope for the opposite.
Also , today we did a test shooting with a projector projecting a pattern to the person being shot.
Results were veeeery good up to the point we are thinking to buy 3 projectors to cover all angles .
Since projectors are a bit expensive we put it on a "todo" list if things go well in the future.
For sure the result is very good and can save us some hours of manual modelling work ....
would, sometime, like to hear test results/comment for a tailors dummy (static object) with:
(i) half camera count in continuous light&no projection (texture)
(ii) half camera count in continuous light & projection (geometry)
insofar as time saving is concerned (or lack of - in post processing).
The test , in fact , was two shootings , one with projection on and one with projection off , to compare results.
Very informative mphx. Thanks.
Was the camera count split between the two shootings (or full for both)?
PS: Things are a bit better with dng format (raw format) because we can mass manipulate photos in photoshop and remove noise BUT jpeg photo is like ~4mb and dng photo is like ~20mb.
Transferring photos from cameras to pc take ages with dng..not very practical...so we are sticking to jpeg for the time being..since the job is done with them...
Quote from: chadfx
If I am using CDHK with a Canon compact camera (A3300 IS) and shoot in DNG raw, it does not automatically correct for the lens distortion...so it appears different from the JPGs coming out of the camera. ...
On this part of the original question... I wouldn't do any distortion correction prior to using Photoscan as you can either provide calibrated values to Photoscan or have it calculate distortion parameters for you. If the image offset calculated by Photoscan is different to that used in the in-camera correction then you will effectively be using distorted images.
That makes sense, thanks. I know that outside perspective correction is a usually a strict no-no for Photoscan. It sounds like it will figure it all out on its own either way (camera corrected JPGs or uncorrected RAWs). I certainly haven't had poor results from the RAWs, but it would be worth a comparison at some point I suppose (if only time were more plentiful...sigh)
Photoscan will figure "something" out regardless but not neces4444444sarily "it"... eg. you can feed it fisheye images and process them as rectilinear and it will figure something out. The calculations for lens distortion are all done from the optical centre of the image. If you in-camera correction does this on the geometric centre of the image file and the optical centre of the image is in a different position to this then the final result will be technically distorted, resulting in a mathematical best fit of all of the criteria put together. As a result, camera positions and rotations will also have small errors, compensating for the incorrect distortion correction and you'll see more noise in the sparse point cloud.
If you want a comparison, try creating unfiltered dense clouds.
I tried it with only one camera connected (i remind i am using canon A2500).I set it up to take 2 photos.testshots was not made fore speed. It does a full half shoot, wait for camera to focus and measure exposure, shoot cycle. It also prints to the screen for 1/2 second and sleeps for another 1/2 second after that.
It worked well , but there was a pause between of the two shots of around 5 secs.
For the project we want shorter pause , let's say around 2 secs max. Is this hardware related ? or it can be configured in chdkptp ?
We did some manual shooting.. preshoot + shoot...1st shot , plain shoot...2nd shot...2nd shot was messy...so as i said its logic that preshoot is needed before every shot.But it consumes time...You need to us continuous mode, or keep shoot_half held down between the shots.
I am trying to figure out what do you mean exactly with the (1) approach..You mean i will make a new command in multicam.lua ?A variation of testshots?Something like this?And put the preshoot thing out of the main loop of this command ?You would need a variation of testshots, but also new camera side code like shoot or shoot_hook_sync, because the current versions of these do release('shoot_full') which also releases half shoot.
Its a project we need it done in like 2 months (if we can't manage it no big deal , but it will help us alot in our work)..so take your timeI think this will be fairly simple, and a shooting function more optimized for real use than testshots would be good.
1.shoot_half must be issued and held.right
2.use shoot_full_only so it will go back to shoot_half and not go to off position.
So what you are saying is , that shoot_hook_sync that i am using (or even the simple shoot) , issues shoot_full and not shoot_full_only that will do the trick.Yes, although I was looking at the code last night and there are some other complications, so it's not quite as simple as just replacing shoot_full with shoot_full_only.
So it needs some change in the structure of these commands , am i getting it right ? :)
PS : By the way whats the difference of shoot_half and preshoot i am using ?What you send with mc:cmd or mc:cmdwait are messages to the camera side multicam script. The script reads these messages and uses them call functions in the cmds table. When you send "preshoot" it calls cmds.preshoot, which presses the shoot_half button, waits for get_shooting() to become true (meaning the focus, auto exposure etc has finished) or time out, and the returns a status.
@reyalpNot as easy as I hoped, but definitely doable. I've attached an updated multicam.lua
Hey , thanks for looking into this.
So , is it doable or not ?As you say its not an easy task , but...can it be done?
I reload everything when i re-select all cameras , and maybe it's not needed and i lose time for no reason.I'm not sure what you mean by "reload everything", but you should be able to select cameras without resetting anything. Like
--[[
take one ore more shots
opts:{
tv=number -- APEX*96 shutter speed
sv=number -- APEX*96 "real" ISO
av=number -- APEX*96 aperture
nd=number -- nd filter state 0=canon fw, 1=in 2=out
synctime=number -- number of milliseconds in the future to shoot, must be >= min_sync_deley
shots=number -- number of shots, default 1
interval=number -- number of milliseconds between shots, default 2000
--]]
function mc:shoot(opts)
opts = util.extend_table({
},opts)
if not self.min_sync_delay then
warnf('sync not initialized\n')
return
end
self:flushmsgs()
if not opts.synctime then
opts.synctime=self.min_sync_delay + 50
elseif opts.synctime < self.min_sync_delay then
warnf("synctime %d < min_sync_delay %d, adjusted\n",opts.synctime,self.min_sync_delay)
opts.synctime = self.min_sync_delay + 50
end
local init_cmds = {}
local init_cmd
if opts.tv then
table.insert(init_cmds,string.format('set_tv96_direct(%d)',opts.tv))
end
if opts.sv then
table.insert(init_cmds,string.format('set_sv96(%d)',opts.sv))
end
if opts.av then
table.insert(init_cmds,string.format('set_av96_direct(%d)',opts.av))
end
if opts.nd then
table.insert(init_cmds,string.format('set_nd_filter(%d)',tostring(opts.nd)))
end
if #init_cmds > 0 then
init_cmd = 'call '..table.concat(init_cmds,';')
end
if init_cmd then
self:print_cmd_status_short(self:cmdwait(init_cmd))
end
self:print_cmd_status_short(self:cmdwait('preshoot'))
self:print_cmd_status_short(self:cmdwait('shoot_burst',{
syncat=opts.synctime,
args=util.serialize{shots=opts.shots,interval=opts.interval}
}))
self:print_cmd_status_short(self:cmdwait('call release"shoot_half"'))
end
--[[
take one ore more shots, printing timestamps on the screen to allow rough sync comparison
opts:{
tv:number -- APEX*96 shutter speed
sv:number -- APEX*96 "real" ISO
shoot_cmd:string -- shoot type, either shoot or shoot_hook_sync
synctime:number -- number of milliseconds in the future to shoot, must be >= min_sync_deley
defexp:boolean -- use tv=1/256 sv=400
--]]function cmds.shoot_burst()
if type(hook_shoot) ~= 'table' then
write_status(false, 'build does not support shoot hook')
return
end
local synctick,rest=string.match(mc.args,'^([%w_]+)%s*(.*)')
synctick=tonumber(synctick)
local opts,err
if string.len(rest) > 0 then
opts,err=unserialize(rest)
if not opts then
write_status(false,'unserialize failed '..tostring(err))
return
end
end
opts=extend_table({
shots=1,
interval=2000,
shoot_hook_timeout=mc.shoot_hook_timeout,
shoot_hook_ready_timeout=mc.shoot_hook_ready_timeout,
},opts)
hook_shoot.set(opts.shoot_hook_timeout)
for i=1,opts.shots do
press('shoot_full_only')
local wait_time = 0
if not hook_shoot.wait_ready({timeout=opts.shoot_hook_ready_timeout,timeout_error=false}) then
release('shoot_full_only')
write_status(false, 'hook_shoot ready timeout')
return
end
wait_tick(synctick)
hook_shoot.continue()
synctick=synctick+opts.interval
release('shoot_full_only')
-- ensure shoot_full released for some noticable time. TODO could use raw hook
sleep(opts.interval/2)
end
hook_shoot.set(0)
write_status(true)
end
@reyalpI understand that, but I'm sure you understand that I don't want to write code just for the specific random development version you were using. I try to support the current stable and development branches.
That answer was a knife in my heart :)
We are using a rather old version of chdk 1.3 ...from the time 1.3 was still in development branch.
Thing is , that the whole setup is in "production" mode , we cant mess with it , because if something goes terribly wrong..we are fcked up :)
In any case i downloaded the latest chdk 1.4 for our cameras.Note that you do not need to update to 1.4, you just need a version of 1.3 from after it was released.
Last time i updated chdk on all cameras i used a lua script and the "update" version chdk.
Going from 1.3 to 1.4 can/will be smooth or it's gonna be messy?I wouldn't expect it to be a big deal. Note that 1.4 hasn't quite become the "stable" branch yet, but should very soon.
EDIT : i noticed that the files that were used for the update were diskboot.bin , ps.fi2 and modules folder.You should update the entire CHDK folder from the zip. You can do this with a single mupload command, so there should be no reason to get more specific than that.
Now i see new files lets say in lualib folder.
So the real question is , what folders/files will be needed for a correct update ? either to a latest 1.3 version or even to 1.4 version?
savecon=con
for lcon in mc:icams() do
con=lcon
cli:print_status(cli:execute('mup path/to/update/files A/'))
end
con=saveconAs far as "entire CHDK folder" ..you probably mean take all folders in there..from the full zip right?Unzip the zip to a directory, like c:\temp
@reyalpThis is probably obvious, but just in case: I'd strongly recommend making sure you have a copy of the build you are currently using saved somewhere, and making sure the update works as expected on one or a few cameras before updating them all.
Ok , thanks for the instructions.
Thing will go down tomorrow , since today there is a shooting scheduled.
I will come back with news tomorrow.
With 64 cameras we cant "play" with interval lower of 4000ms.Second shot is going all over the place.Are you shooting raw? The interval should be similar to what you can get on one camera, which I would normally expect to be under 2 sec if you aren't using raw.
With interval of 4000ms ..shots are seemed to be synced (first and second) although in 2nd shot there are some errors in console (unexpected error from cmd "shoot_burst" blablah , failed=true etc etc)..and its repeated for some or even all cameras.Despite the fact that the second shot is "heard" to be synced on all cameras.Example output for one camera might be helpful. blahblah doesn't help me much with debugging ;)
As far as synctime is concerned..we set it up to 800ms , because we have seen min sync delay ranging from 300ish up to 700ish...i saw that if synctime < min sync delay , command adjusts it..but we set it up to 800ms to be safe.Since just sending to each cam takes takes several ms, this sounds fairly reasonable.
In both cases after the second shooting , there are the aforementioned "error messages" that as you understand i don't remember them exactly :)In the future, I suggest you copy and paste a sample somewhere. I don't have 64 cams, if I am going to debug the problem, I need some better idea of what is happening.
I noticed some changes to some commands output ...less messages , doing the job hard to monitor.I reduce the output because even with 3 cameras the flood of messages was difficult to follow. With 64, it's probably enough to slow things down noticeably...
Since we can work with 1-2 cameras less ,and during a shooting is bad to say to client...wait a moment..technical issues...etc etc... is there a way when a camera loses connection , chdkptp will ignore this camera and keep working with the rest?It will be very handy if this can be done.Yes, being able to ignore failed cams is something I would like to add, but it will take some work.
chdkptp-r658-win32\lua\main.lua:225: incompatible chdkptp binary version@reyalpYou need to download the lastest chdkptp.exe from the file area. See the compatibility warning on https://www.assembla.com/spaces/chdkptp/wiki/Changelog (https://www.assembla.com/spaces/chdkptp/wiki/Changelog)Code: [Select]chdkptp-r658-win32\lua\main.lua:225: incompatible chdkptp binary version
Imagine a folder where i just mess around with my custom lua file , i dont touch anything else and i just "svn update" once a while , when i remember to do so.
Today , i had this message , i updated to revision 694 , but it keeps popping the same error.
Any ideas?
thanks
chdkptp_gui: symbol lookup error: /usr/lib64/libiuplua52.so: undefined symbol: luaL_setfuncsAnyone using linux version of it ?FWIW, I was recently able to build it all on the latest Fedora release and Lua 5.3.
I don't know what is going on with IUP and CD , but i dont really like them :)Are you trying to use the pre-compiled binary, or build your own?
I installed the necessary libs..and i was forced to install lua 5.2 since thats the version chdkptp is supporting right?(Installations had lua 5.3 installed)
And in both cases i ended up to thisI'm not really sure the exact cause of this, but incorrect libraries or bad LD_LIBRARY_PATH seems likely.Code: [Select]chdkptp_gui: symbol lookup error: /usr/lib64/libiuplua52.so: undefined symbol: luaL_setfuncs
1.Can't you not implement the linux version using some other "tools"?Qt?Gtk?I am not programmer..i dont know what is needed..I haven't had time to improve the existing GUI much, let alone switch to a new framework. I chose IUP and and CD because they make it easy to implement the GUI in Lua, and it is easy to make a GUI that works on both Linux and windows.
IUP and CD arent even in the official repos :) Atleast in two distros i was messing around.
2.Maybe support lua 5.3?So no need to install the older version..maybe to avoid errors or whatever?I will add official support for this eventually, but again it's a matter of time. I still haven't removed support for 5.1. Every permutation makes things harder to maintain and test.
Ok i give up :)This is exactly the opposite of what I suggested. Lua is easy to build, and self contained. The other things are not. Therefore, you are much better of using a locally built copy of Lua, and not worrying about what your particular distro decides to provide.
I removed ever trace of cd,im,iup
And the system uses lua 5.3
So i did the following (just for the fun).The whole point is to compile everything against lua 5.3
3. CD and IM compiled nicely.IUP had issues..was trying to find lua5.1 despite i tried to "fix" the references in the config files.FWIW, I strongly recommend against trying to compile any of the libraries other than Lua yourself. I do it for the raspberry pi builds because there are no precompiled binaries available, but otherwise, I stick to the pre-built ones.
1. Download binaries of cd/im/iup for lua 5.3 and installed them#2 should only minor config.mk changes (though as noted before, I won't promise that it actually runs correctly.) So if you can provide more information about what specifically went wrong, I could probably help.
2. Tried again to compile chdkptp for lua 5.3 ...no-go.
2.As i said i am not a programmer...so i can't help you at changing framework or anything..i have alot of free time and i can test stuff..but i cant create something :)Yeah, and if someone wants to build me a hot-rod, I'll be happy to test drive it ;)
I mentioned if it was possible to change framework at some point , because i was messing around with Agisoft Photoscan today...it has win/linux/macos builds.That's nice. Agisoft has full time employees who are paid to make this kind of thing happen.
I checked out the linux version..and it needed like zero libs/headers...pre-built binary..u click it...it works.
Same interface/gui with the windows version.
And from the little things i can understand it uses QT libs for the GUI...
Just throwing ideas here...
Surely photoscan has nothing to do with lua...entirely different program...but just saying :)chdkptp is already written in Lua, with a GUI written in Lua and IUP. That may have been the wrong decision, but changing it would be a lot of work. Personally, I have a lot of things I'd rather do than re-write stuff that already works just because you couldn't get it to run on some particular distro.
Is it possible to use a rather updated distro... compile locally lua/cd/im/iup..compile locally chdkptp using locally built lua/cd/im/iup and fix the config files..so the chdkptp binary will use these locally built dependencies ?(dependencies = lua/cd/im/iup)The whole problem is without a lot of research and testing, I can't say what will or will not work. In general though, stuff built on older distros is more likely to run on newer ones than the reverse. IIRC, the binaries I built on ubuntu 10.04 still ran on 14.04.
...
You can tell me that maybe this wont work..different compilers/libs and stuff..but if the distro on which the compile was made is pretty good updated..like a bleeding edge distro , maybe then things might work well :)
gcc -o chdkptp lfs/lfs.o properties.o ptp.o chdkptp.o lbuf.o liveimg.o rawimg.o luautil.o sockutil.o -g -L./lua-5.3.2/src/ -L./iup-3.17/ -L./cd-5.9/ -liuplua53 -liupluacd53 -lcdlua53 -llua -liupcd -lcd -liup -lusb -lfreetype -lz -lm -ldl -lreadline -lhistory
/usr/bin/ld: cannot find -liupcd
/usr/bin/ld: cannot find -liup
collect2: error: ld returned 1 exit status
Makefile:125: recipe for target 'chdkptp' failed
On the other hand , there are several pre-built binaries of these packages..and i hope i am picking the right one :)If you go to the file downloads for each project, pretty much every previous version is available, e.g. http://sourceforge.net/projects/iup/files/ (http://sourceforge.net/projects/iup/files/) there is both source and binaries in each version directory. The directory you linked to was the 5.9 subdirectory, so it only has one source.
After yesterday's failure , i thought to try my luck with Manjaro (Arch-based) since many packages that dont exist on official repos..exist in the community repo (aka https://aur.archlinux.org/ (https://aur.archlinux.org/))Personally, I'd suggest picking one distro, and working methodically through each problem/error rather than trying stuff and hoping it works.
So i thought to try the other thing i was thinking yesterday...a locally compiled chdkptp with everything in local files.How many times did I advise against using Lua 5.3?!
1. I compiled lua 5.3 locally.
This error means the compiler didn't find those libraries. The most likely causes are:Code: [Select]gcc -o chdkptp lfs/lfs.o properties.o ptp.o chdkptp.o lbuf.o liveimg.o rawimg.o luautil.o sockutil.o -g -L./lua-5.3.2/src/ -L./iup-3.17/ -L./cd-5.9/ -liuplua53 -liupluacd53 -lcdlua53 -llua -liupcd -lcd -liup -lusb -lfreetype -lz -lm -ldl -lreadline -lhistory
/usr/bin/ld: cannot find -liupcd
/usr/bin/ld: cannot find -liup
collect2: error: ld returned 1 exit status
Makefile:125: recipe for target 'chdkptp' failed
I am just saying , there is only one source file for each package (either im , cd , iup) and multiple pre-built binaries.I don't understand the point then? Of course there is only one source package per release ???
You advised against that alot of times..but i have bleeding edge hardcoded in my dna..its a bad thing sometimes..but...i cant help it :)OK. It's more than a little frustrating for me that you come here and complain about how difficult it is, and then repeatedly ignore advice on how to minimize the difficulty.
They could easily distribute pre-built binaries packages (rpm,deb etc) , so at some point distros can put them in official repos.Again, I specifically recommended against trying to build them yourself.
If you try to compile them from source , you see that even if these packages can be compiled for lua5.3 , config files are still written to search previous versions.
Maybe for someone who knows his way around config files its easy task..i was lost at some point..going for one config file to another..searching the spots to change .
@reyalp
1. Zoom -
So an idea popped to issue a set_aflock(1) before set_zoom..and TAAA-DAAA ..lens moved!
And i created another button in the GUI , with exactly what you said.. !mc:cmd('call ... your lua code').Worked like a charm.
I've been following this thread but I can't understand this...
can you tell me what you did step by step for this zoom command, I really dont understand how to zoom all cameras with chdkptp multicam
mc:shoot{shots=2,interval=5000,synctime=100}We have set the cameras to shoot twice in a 5sec time frame with the commandIf it's working correctly, the mc:shoot() command should only pre-shoot once, not for every exposure. If shots is more than 1, it should keep half shoot held down and click shoot_full_only for each shot.Code: [Select]mc:shoot{shots=2,interval=5000,synctime=100}
We tried to lower the time as much as possible , but from a point and beyond cameras are losing their sync.So the lower it can go is 5 secs (for the Canon A2500)
We are experiencing with some Canon ixus 160 , and while we dont have many , so we cant be sure about our test results -one thing to test times in 2-3 cameras and another in >60)..we noticed that ixus 160 can shoot "faster"
So my question is , how can we lower the multiple shooting times ?
I am guessing that at some point its all about hardware...but i noticed and correct me if i am wrong that the above command , does a "preshoot" before every shoot...so maybe somewhere there time is lost.
Thing is that in between the two shots we project a pattern to the person being shot (pattern from projectors).And i wonder if the change in brightness produced by this pattern causes the cameras to re-focus or re-adjust iso/exposure and stuff like this (although we setup these values before every shoot)..so it wastes time..I may saying stupid things here...If the script is working, half press is held down and none of these things should be updated between shots.
And as i mentioned before , ixus 160 shoots faster than a2500 ..maybe its partially a hardware limitation...of how fast can the camera shoot.It is extremely unlikely that a2500 can only sustain 1 shot every 5 seconds.
I have seen that camera struggles during multiple shots.What i mean by struggle is that shoots-photo taken remains for msecs in display-it goes back to rec mode display-shoots the next one.Something like that.Is "review" enabled in the canon menu?
That would be an interesting script.
As I mentioned before, having multiple cameras should not affect performance. Testing what rate a single a2500 can sustain would be a good place to start. I'll see if I can come up with a simple script to check this.
Is "review" enabled in the canon menu?
In the regular canon settings menu, when you press the menu key in shooting mode, there's an option called "review" which keeps the last shot image on screen for some time. It should be "off" for your purposes.QuoteIs "review" enabled in the canon menu?
I am not following you here..when you say canon menu you mean the menu camera has or some chdk menu ?
In the regular canon settings menu, when you press the menu key in shooting mode, there's an option called "review" which keeps the last shot image on screen for some time. It should be "off" for your purposes.QuoteIs "review" enabled in the canon menu?
I am not following you here..when you say canon menu you mean the menu camera has or some chdk menu ?
Anyways i have to check A2500s' menu at studio to see what's the setting of "review" ..that would be a pain in the [admin: avoid swearing please] to change the setting to all of them :)You may be able to set this from script using http://chdk.wikia.com/wiki/User:Srsa_4c/UI_properties
We set the time between the 2 shots around to 1500 msecs (0.8 shots/sec in continuous mode is around 1 shot every 1.25 sec)This sounds like a bug of some kind, but I really have no idea what could cause it. There really shouldn't be much difference between the first call to mc:shoot() and subsequent calls. Knowing the exact sequence of commands you used might help.
First "double shot" was spot on.Both synced..then hell got loosed.Shots were all over the place..it never worked again.
mc=require('multicam')
mc:connect({list=true})
mc:start()
mc:cmd('id')
return mc:cmdwait('rec')mc:init_sync()mc:shoot{shots=2,interval=5000,synctime=100}So the question is , can chdkptp implement an encrypt/decrypt function?Encrypt somehow the photos when it copies them to disk and decrypt them with some command in order to be "readable" from windows.This is certainly not something I would spend time implementing. There's enough DRM in the world already, and I have other more fun things I'd prefer to work on ;)
PS : Whats wrong with "code" button ..when i press it , it goes in reverse ..slash in the first bracketed code..not the second...just saying...I have the WYSIWYG editor turned off in my profile and just type the code tags manually.
True , the solution of lets say securing the use of photos wont be entirely bulletproof..because as you said , they will still control the cameras...BUT , what will be left to do?Pull out around 80-100 sd cards and copy the photos?I don't think they will go into such trouble.
A secure solution would be difficult if not impossible, since they still control the cameras.
One could theoretically modify chdkptp to encrypt the files on download, but please remember that chkdptp is licensed under the GPL, so if you modify it, you must make the source available to anyone you provide your modified program to.
Regarding your problem with burst shooting:
I'm still thinking about it, I just had some stuff come up that doesn't leave me with much time for CHDK. Maybe after the weekend I'll have something to test.
I recently found out that someone can issue commands through the serial port of these projectors..either with python scripts or simply by creating plain text files with the desired commands and "copying" these texts over the serial port of the projector.chdkptp can execute external commands with the normal lua os.execute function (http://www.lua.org/manual/5.2/manual.html#6.9). So if you have a python script or whatever that sends the commands, you could just run that.
Question is , can we use some way and issue these commands (with any way i dont really care which one) through chdkptp ?
To test shooting rate using on a single camera without involving PTP, you can use my fixedint.lua scriptQuoteRegarding your problem with burst shooting:Any input on it will be much appreciated and useful.
I'm still thinking about it, I just had some stuff come up that doesn't leave me with much time for CHDK. Maybe after the weekend I'll have something to test.
Right now i have 2 x ixus 160 in my home and i can test it. Theoritically under the same setup , A2500 should perfom more or less the same since they have the same specs (0.8 shoots per second).In theory, but I would highly recommend testing using the actual camera and cards used in the rig
So if i get this right.. a rig of x ixus can go as low as ~1.7-1.8 secs between shots regardless the number of them ?(of the cameras)If you want sync, the interval has to be longer than the longest time, so in practice you'd want some margin. I'd guess 2 seconds should be achievable, though you might find there are longer outliers with a bigger sample size than 10. It may also depend on the SD card, beyond just the "class" speed, they have wear leveling and garbage collection logic that can cause unpredictable performance.
Always in theory...
I can say that 2000msecs is a safe interval.How sure we are that this interval will work the same way with more cameras (with the same configuration apparently)?In theory.
Theoritically it should work..right?
1. Address of the function i need to change.You need the ID of the UI property, and the values. To change it, you can use the eventprocs mentioned in the forum thread.
2. The actual command to do the change.
I can say that 2000msecs is a safe interval.How sure we are that this interval will work the same way with more cameras (with the same configuration apparently)?In theory.
Theoritically it should work..right?Quote1. Address of the function i need to change.You need the ID of the UI property, and the values. To change it, you can use the eventprocs mentioned in the forum thread.
2. The actual command to do the change.
To find the ID and values
In the debug menu, set the "ALT +/- debug action" to CmpUIP
enter alt and press the debug key
leave alt and change the setting
enter alt and press the debug key again
The differences in UI prop values will be displayed
The debug key is port specific. It should be shown in the alt help screen.
However, on D10, review time doesn't appear to be a UI prop. It does appear to be one (ID 129) on ixus140_elph130, which was released much closer to a2500.
call_event_proc("PTM_SetCurrentItem",0x800c,0) didn't work with the 2 ixus at home (where 0x800c and value i put the correct ones ofc).Unless the syntax is different than the above and i don't know it :)If there was an error message, that probably means you didn't use the correct syntax to send the command. Assuming you doing this with regular chdkptp (not through multicam) you should use something like
(And by "didn't work" i mean the command produced error , it didnt get through to the cameras , i can copy/paste the error when i get back home and repeat it)
=return call_event_proc("PTM_SetCurrentItem",0x800c,0)
Note that you have to call the eventproc registration function first (once after startup, not before every PTM_* call), like=return call_event_proc("UI.CreatePublic")
For both of these, if the return value is -1, the function doesn't exist or isn't registered.it seems i am losing something as far as A2500 is concerned.I dont find any reference about "debug key" in alt help menu.Check the photo below (not the best but u can see what it displays :P )It's there in your photo: DISP Alt +/- Debug action
I changed manually the settings of 8x A2500s to "play" with the intervals.I would suggest starting with just one or two. As I've said before, there really shouldn't be a difference, and it will be easier to keep track of the results.
At 2000msecs 1-2 double shots were synced , the rest not.At 2500msecs , same result.Some synced , some not.Were you using the most recent multicam.lua?
=return call_event_proc("UI.CreatePublic")=return call_event_proc("PTM_SetCurrentItem",0x800c,0)I would suggest starting with just one or two. As I've said before, there really shouldn't be a difference, and it will be easier to keep track of the results.We had tested 4 of them , and the results were more or less the same.
Were you using the most recent multicam.lua?What were the status values?Have you run fixedint.lua on one of these cameras?
I didn't say this was the *only* way to do this.Code: [Select]=return call_event_proc("UI.CreatePublic")andCode: [Select]=return call_event_proc("PTM_SetCurrentItem",0x800c,0)did the trick AFTER
1.I enabled "native lua calls" on the cameras
2.I single-connected the camera to chdkptp (not using multicam)
But the idea was , to change the setting on all A2500s at the same time.If i have to connect each one of them , one by one , is pointless :)
The DISP key.QuoteIt's there in your photo: DISP Alt +/- Debug actionOk , seriously i feel dumb , what is the debug key according to this ? :)
Nope , there were some shootings the last days , didn't want to mess up with multicam or any other file.Then this test didn't really tell you much, except that the problem wasn't all due to the review setting. If you want to *fix* the problem, you need to do the testing.
So for your next 2 questions the answers are obvious...no status values , no running fixedint.lua.
Testing with them is a bit delicate matter since its "production" rig and i wouldn't like to fck it up while shooting is pending :)Hence my suggestion to use only one or two cameras...
Theory says A2500s *must* have more or less the same times with ixus 160 , since they have the same specs regarding *shots/per sec*.But having different hardware/firmware times may vary.It should be in the same ballpark if the specs are the same, but there might be other factors like SD card or camera settings. ISO is one setting to watch out for, high ISOs can add a significant amount of processing time. (I'd guess you use low ISO for the rig anyway?)
EDIT : i am all about messing with the rig , my friend who really owns it , is not :PSeems like it would be worth having a couple of "spare" cameras of the same type used in the rig.
To enable native calls, you will probably have to set it on one camera through the UI, then upload the CFG to the remaining cameras.
@reyalp@mphx
First of all we are not shooting raw.
5secs is slow...and if we lower it , we hear the shooting clicks getting out of sync.At 5secs the "clicks" are all synced.Someone could think that "hearing" isn't a sure confirmation.But it is..photos are not synced judging from the result since in some of them the person has moved....so the photos were not synced.
Thing is that in between the two shots we project a pattern to the person being shot (pattern from projectors).And i wonder if the change in brightness produced by this pattern causes the cameras to re-focus or re-adjust iso/exposure and stuff like this (although we setup these values before every shoot)..so it wastes time..I may saying stupid things here...
And as i mentioned before , ixus 160 shoots faster than a2500 ..maybe its partially a hardware limitation...of how fast can the camera shoot.
Anyways if we can't find a solution to lead us to shoot only once (not going to happen any time soon as long as we have cheap compact cameras) , fast multiple shooting will be always an issue.
EDIT : now that i am thinking of it , you are right ...preshoots only once and then shoots as many times as it has been set up.I have seen that camera struggles during multiple shots.What i mean by struggle is that shoots-photo taken remains for msecs in display-it goes back to rec mode display-shoots the next one.Something like that.
So its all going down to how fast the 2 steps (photo taken remains-go back to rec mode display) are happening.
I saw that in ixus 160 , this whole thing goes down faster than a2500 , thats why i said that partially maybe its a hardware thing/limitation since as you said after the first shot camera is running on its own...
Why you need to ...
Why you need to project a pattern to the person being shot ?
Sorry for the unreadable trouble :lol :lol [size=78%]. [/size]Why you need to ...
@cdg : if looks like you formatted part of your response with very small font that makes it unreadable for most of us. I think what you were trying to say was :QuoteWhy you need to project a pattern to the person being shot ?
Edit : in case you don't get a response as the formatting of your questions made it unreadable, the pattern is projected to allow post processing of any resulting 3D image. How that post processing is done is complicated - more so than than my response implies.
Its all about how Agisoft Photoscan (or any other software of this kind) works.I am kind of understand now.more points more details
Photoscan produces a rough 3d model from a series of images.In order to do so , it tries to find common "points" in the images so it can calculate/guess the depth of the things in the images.
So , by projecting a pattern into the thing/person we are shooting , we just put more "points" for the Photoscan to find.
As a result , the produced 3d model , is very smooth , and the post-3d-processing is minimal.
Believe me when i say , if someone wears black/white/one-colored clothes or something that shines ...the model is a real mess...gaps everywhere , gaps we have to "close" by hand..not good.
@cdgThank you very much with such many information ！！Yes for CHDK cameras ,it's looks two separate banks of cameras could be a easy way.
For DSLR & DLP projector combination - details were provided by Magnus in this thread:
http://www.agisoft.com/forum/index.php?topic=1324.0 (http://www.agisoft.com/forum/index.php?topic=1324.0)
With his multiple DLP projectors continuously running, he:
simultaneously triggered a group of Canon DSLR and Nikon DSLR. He took advantage of the shorter shutter lag of the Nikons to get all their shutters open & closed in 5ms and fire multiple off camera flash before the Canons' had opened their shutters:
- ran 18 Canons (2 of 600D + 16 of 1100D) at "long" 20ms shutter to pick up the projected noise for geometry
Simultaneously heMy memory is he had all camera remote shutter release wires (Canon & Nikon) simply connected together with splitters and a radio transmitter on one of the D3200 to trigger several off camera flash.
- ran 4 cameras (Nikon D3200) at "short" 5ms shutter to pick up for texture only (i.e. not "drowned" by the continuous, relatively low intensity projected noise.
The benefits were impressive and described here:
http://www.agisoft.com/forum/index.php?topic=1324.msg6668#msg6668 (http://www.agisoft.com/forum/index.php?topic=1324.msg6668#msg6668)
"This first one was shot just with flash and as you can see it got 15877 points."
Then
"This next one we used the projectors too and this is what we got, 45733 points"
Based on this https://chdk.setepontos.com/index.php?topic=8312.msg107601#msg107601 (https://chdk.setepontos.com/index.php?topic=8312.msg107601#msg107601), it seems very unlikely to get all the "shutters" on a large bank of chdk cameras open and closed in a 5ms period - maybe 40ms, but that amount of dlp projected noise would probably adversely affect the flash texture capture.
To do this somewhere nearly as quickly (Edit1: maybe around 80ms across two separate banks of cameras) as the process that Magnus described using chdk cameras it therefore seems likely that the noise pattern must be projected using flash e.g. http://www.agisoft.com/forum/index.php?topic=1542.msg7960#msg7960 (http://www.agisoft.com/forum/index.php?topic=1542.msg7960#msg7960)
Edit2: I don't know how long the period was between the last Nikon shutter closing and the last Canon shutter opening so I don't know how long Magnus's 2 stage capture took from start to finish.
for CHDK cameras ,it's looks two separate banks of cameras could be a easy way.
I will avoid this situation.for CHDK cameras ,it's looks two separate banks of cameras could be a easy way.
Not necessarily easy & obviously expensive compared to image capture on the same cameras (if you can live with a second or two between the 2 capture events).
Hi @reyalpNot a big problem...power up the cameras..check what id each one is taking and then just start editing the file with ids to the desired physical order... :)In changes through r624, I added a function set_id(old_id,new_id). If the script is running, the IDs on the camera will be updated immediately so you can see it on the ID display.
Once you are satisfied with the ID order, you can save the list.
If the new id is already in use they will be swapped. You can pass an optional third parameter 'error' to generate an error in this case instead.
Additionally, you can now select a range of cameras with mc:sel{min=number, max=number}
save_list works on the selected cameras, so this should make it easy to make subset lists.
I also fixed some bugs, see the svn log for details.
I am tried with this "set_id(old_id,new_id)",but still not know how to make it work.I don't really know what you are trying to do. I would suggest referring to the posts before that, where I added the list features, starting around https://chdk.setepontos.com/index.php?topic=11667.msg114745#msg114745 or referring to the source https://app.assembla.com/spaces/chdkptp/subversion/source/HEAD/trunk/lua/multicam.lua#ln197
For multi-cam, how to give the IDs? one by one(i don't think so)?should be a list right?IDs are assigned when you connect, in whatever order the USB library gives them. The set_id function is only needed if you want to change them, for example if you want a subset of cameras to have a particular ID range.
!mc:cmd('id')
@reyalpIn both cases after the second shooting , there are the aforementioned "error messages" that as you understand i don't remember them exactly :)In the future, I suggest you copy and paste a sample somewhere. I don't have 64 cams, if I am going to debug the problem, I need some better idea of what is happening.QuoteI noticed some changes to some commands output ...less messages , doing the job hard to monitor.I reduce the output because even with 3 cameras the flood of messages was difficult to follow. With 64, it's probably enough to slow things down noticeably...
If you are using mc:cmd() or mc:cmdwait() you can pass the option printcmd=true, like
!mc:cmdwait('rec',{printcmd=true})
If you only want to print once for each command rather than each camera you can use
!mc:cmdwait('rec',{printcmd='once'})
It the moment there is no way to do this with other functions like shoot that call cmdwait(). I will add a way to change the defaults for this at some point.
Some kind of status in the download command would be good.
edit:
Actually, you should be able to pass verbose=true in the mc:download_images options to see whats being downloaded.QuoteSince we can work with 1-2 cameras less ,and during a shooting is bad to say to client...wait a moment..technical issues...etc etc... is there a way when a camera loses connection , chdkptp will ignore this camera and keep working with the rest?It will be very handy if this can be done.Yes, being able to ignore failed cams is something I would like to add, but it will take some work.
@reyalphttps://chdk.setepontos.com/index.php?topic=11667.msg128954#msg128954 ?
I can't find how the burst mode shooting is working .Can you provide a sample of the command?
Thanks
Ah , yes , we had discussed it earlier..tried to solve the same problem as i had back then (it still remains) and i had a crazy idea that "shoot_burst" was command at its own.I admit I don't recall what exact details of the problem you were having, but burst shooting works for me, so if you want to make any further progress, you'd probably need to do debugging on your end.
But i had the feeling that it was a camera-side command , triggered by the "shoot" command...and the link reminded me that fact.
Anyway , something irrelevant.Is there a way to reload "lua" config files without closing/re-opening the program?Lua files are not config files, they are code that runs in chdkptp. So whether reloading makes sense depends on how the code you are loading interacts with the rest of the code.
mc:shoot{shots=2,interval=2000,synctime=100,cont=true}where interval value is something i change for testing.So i was changing things in the lua file i have created for this "new tab" , to play with the shoot command.Thing is that for every change i make to the lua file...i close the program..and re-open it so it will re-read the file and the changes.In this case, your file is probably changing global state (IUP controls and so on) that doesn't get reset when you re-load the file. E.g. if your module creates a tab, it might create a new tab every time you load it instead of changing the behavior.
The problem is that for our shooting needs , we shoot 2 shots , 5 secs apart.5 secs is something we wish to reduce..at about 2secs max.One thing I would suggest is testing what shooting rate you can get with a single a2500, and whether it maintains an accurate interval. If there isn't some configuration error (review mode, raw enabled, etc.) figuring out the real cause will probably require recording timing information in the camera code to figure out where it's getting out of sync.
Thing is , that the second shot at 2secs or below is out of sync.
At this point i am down to the following command:Code: [Select]mc:shoot{shots=2,interval=2000,synctime=100,cont=true}where interval value is something i change for testing.
Testing with 2 ixus 160 at home , things go smoothly...testing with x number of canon a2500 at the studio , same problem , 2nd shot out of sync.
I'm gonna do some more tests next days , re-check that all cameras have the same settings (mostly review image off , continuous mode on ) and see what'll happen .
@reyalpYes, absolutely. Whether it makes a difference depends on how long saving the image takes relative to other parts of the process, but I'm not surprised card speed has an impact. I'd suggest using class 10 cards everywhere. There's no point going to the higher UHS levels, because the camera hardware doesn't support them.
Is this something that could be affecting the shooting ? Meaning that some cameras would take longer to save the first image and so to be out-of-sync for the second shoot?
Something else we noticed.If we press the shutter button continuously (without chdk involved) , camera is shooting as supposed...display stays always on and just shoots.Generally, the camera keeps the image on the screen in continuous mode, and blinks black if you use the "hold down half shoot, click full shoot" approach.
When we are shooting through chdk/chdkptp , after every shot display flashes on/off + probably saves the photo before shoot the next image.
Why this difference in behavior?Something to do with the shoot command or chdk in general?
Yes, absolutely. Whether it makes a difference depends on how long saving the image takes relative to other parts of the process, but I'm not surprised card speed has an impact. I'd suggest using class 10 cards everywhere. There's no point going to the higher UHS levels, because the camera hardware doesn't support them.
One thing I have noticed is that the first shot after booting tends to be a lot more variable than later shots. So it might help to have a single "warm up" shot before you try to take a synced burst.
Generally, the camera keeps the image on the screen in continuous mode, and blinks black if you use the "hold down half shoot, click full shoot" approach.
Assuming you are using the latest multicam.lua, mc:shoot should use continuous mode if it's enabled in the canon UI, unless you pass cont=false. So the fact it's going black suggests it might not be using continuous mode, but it could also just be a side effect of the hook used to synchronize continuous shooting on this particular camera.
We , either decide to replace them or go on another approach.Thinking of reducing the mpixels of photos being taken.It's worth trying, but beware that on some cameras smaller images require noticeably more processing time, so it can actually be slower. I think this mostly affected older cameras, but you should test to be sure. You could also try lower jpeg quality.
Less mpixels , less image size , less data to be written on the card.So the card speed would have less impact on this part of the process.
When i tried "continuous mode" in a single camera , as i said , without chdk involved..it was like....shooting photos at a steady rate...display always on and no obvious signs of saving anything.I don't understand what you mean by "obvious sign of saving anything". As far as I know, the only indication of saving is the LED blinking, which might happen other reasons (especially when using CHDK). The "Busy" message you sometimes see does not specifically indicate saving to SD.
PS : its a bit of big trouble to upload your script to every mounted camera and single-test it on each one of them...There is no reason whatsoever to upload it to every camera.
So if the writing speed of sd cards was the suspect , then ixus 160 should must have achieved larger interval times since they had to write bigger image files (20mp vs 16mp) and the sd cards are not that speedy as class6 cards of A2500s...I would not assume this, because there are other significant hardware differences, and the byte size of the file depends on the scene and jpeg quality too. Test and let the data tell the story.
So i come down to what you said , that "busy" time between shots is not necessarily meaning "saving to sd card" .Maybe means "i process the image , wait a bit" thing?Most often, it's shown when doing noise reduction at high ISO or dark frame subtraction for long exposures, but it might show up for other reasons. It's possible it could even show up as a side effect of CHDK blocking the shooting process.
And maybe ixus 160 cameras have faster image processor than A2500s and thats why they achieve lower interval times?I can confirm that having the same Digic number does not mean identical performance. Newer Digic IV definitely have faster SD and USB performance than old ones, and I wouldn't be surprised if they have faster image processing too. Different cameras can have different amounts of memory, and different image quality settings too.
Test #3 settings are the settings we use at studio , where we have strong lights , but at my house where lights are lower , images were darkish and so i dont know if this test has any meaning at all.We're not interested in the images, that's why the shutter speed is fixed (I guess you edited it to 1/40th for test 3) Otherwise, if you shoot in dim lighting, the camera might choose say, 1/2 sec exposure which would throw off the results.
I made an xls with formatted cells , because the produced csv file is a bit messy :)In general, I'd rather have the original data, but no need to re-post it for this run.
interval = 1000msec (i know that camera cant get this time , so it will shoot as fast as possible.)It looks like this was actually 0, but that has the same effect. The code where it says "for PTP testing" is only used if you didn't run the script from the script menu.
What i noticed is that apparently different sd cards , dont have any impact on shooting speeds if i read the results correctly.This does seem to be true in this case, the total variation is only ~200ms and most of that does not seem to depend on the card.
We're not interested in the images, that's why the shutter speed is fixed (I guess you edited it to 1/40th for test 3) Otherwise, if you shoot in dim lighting, the camera might choose say, 1/2 sec exposure which would throw off the results.The content of the image may affect the result, because the file size can change a lot depending how much detail there is.
It looks like this was actually 0, but that has the same effect.
(I guess you edited it to 1/40th for test 3)
So overall conclusion is none of this make much difference on this camera. I wouldn't assume that A2500 behaves exactly the same.
I did not read all 41 pages of this thread, but am working on it. Will take a week probably.
Anyways. what software is best for quickly post processing the images and outputting to a big 55" tv?
I want to make a 12 or more camera array for events where people jump or do other cool action moves and them within a few minutes the results are displayed for them to see.
I have seen optical flow and adobe after effects mentioned, but after searching google for a few days dont' see a single tutorial. Thanks in advance for any ideas.
"...I want to make a 12 or more camera array for events where people jump or do other cool action moves ..."There are about 70 Canon a450 and a460 camera's located in Sydney Australia if you are interested in them.
.... I do not want to make 3d models I want to make a time slice bullet time effect video/gif.
what I really need help with is downloading the images and quickly making them into a video clip. I've emailed several companies, no response, guess I will slowly figgure it out on my own. Hopefully I can make a tutorial because all the information is so spread out and it will take days/weeks to figgure it all out.You could start by updating this page with what your learn?
....but after searching google for a few days dont' see a single tutorial. Thanks in advance for any ideas....Try Hugin's "align image stack" here
....video creation part....
... If someone can tell me one or two softwares I can research and learn it....
...auto correct for alignment so footage is smooth....
My question is , is there a command or a way , to "report" the number of connected cameras.Issue the command and the command will return the number of connected devices.Something like
for lcon in mc:icams() do
if not lcon:is_connected() then
printf('%s not connected\n',lcon.mc_id)
end
end
should do it.mc:describe ? what this command does ?Never heard of it :)You can find it in the source ;)
Gonna try it at Monday before the shooting.
function mc:which_cams_are_not_connected()
for lcon in mc:icams() do
if not lcon:is_connected() then
printf('%s not connected\n',lcon.mc_id)
end
end
mc:describe ? what this command does ?Never heard of it :)
We are facing a rather stupid problem lately.If you are using windows.
Sometimes cameras are disconnected during photo shooting , most of the times because some cable is moved and lost connection to the camera.
Lately we have noticed that some cameras when they lost connection ..they turn off by themselves for some strange/unknown reason.
My question is , is there ..... a way , to "report" the number of connected cameras.
...
Thanks in advance.
The SD-Cards have limited number of "Guaranteed" Read-Write cycles. This is why wear leveling is used on the SD-Cards. So may be there approaching "Old Age".Very unlikely. All modern SD cards can stand 100,000 Program/Erase Cycles per memory cell and many can do 10x that. With wear leveling enabled and a small 4G card, if you were to shoot a 4MB picture every minute in an eight hour day, it would take you about 136 years to hit that limit
I don't think windows are involved in all this.Cameras tend to turn off since day one.This may or may not be your problem, but make sure "disable display off" is set in your CHDK settings. For your situation, "always" is probably the best choice. You can use multicam call and set_config_value to set it on all cameras.
I had noticed that when running chdkptp and connect all cameras , if i issued an "exit" command , meaning disconnecting and stop running camera-side script,
then a random number of cameras would turn off.
USB Device View has several options that may be useful for additional USB Monitoring:-
a/ Display a Tray Balloon when a USB Device is Disconnected.
b/ Execute the following command when you unplug a USB device. (In Advanced Options.)
"You can use the following variables in the command string:- "...................."
All modern SD cards can stand 100,000 Program/Erase Cycles per memory cell
This may or may not be your problem, but make sure "disable display off" is set in your CHDK settings. For your situation, "always" is probably the best choice. You can use multicam call and set_config_value to set it on all cameras.
Background:
When the screen goes off for power saving, you can still wake the camera up with a key press sent through chdkptp, but if it's not woken up in a certain time it will shut down completely.
function mc:which_cams_are_not_connected()
for lcon in mc:icams() do
if not lcon:is_connected() then
printf('%s not connected\n',lcon.mc_id)
end
endProbably at some point must read the file with the ids and do some more calculations...
function mc:which_cams_are_not_connected()
for lcon in mc:icams() do
if not lcon:is_connected() then
printf('%s NOT connected\n',lcon.mc_id)
else
printf('%s connected\n',lcon.mc_id)
end
end
endJust to be clear my multi-camera arrays have a customized setup that is standardized even when using different camera models.USB Device View has several options that may be useful for additional USB Monitoring:-
a/ Display a Tray Balloon when a USB Device is Disconnected.
b/ Execute the following command when you unplug a USB device. (In Advanced Options.)
"You can use the following variables in the command string:- "...................."
I just read that USBDeview has "all kinds of snazzy, user-callable command line capabilities as well as the basic GUI" - hadn't realised that...potentially useful for further (e.g. AutoIt) automatic analysis.
Thanks.
function mc:camstatus()
local cn=0
local nc=0
for lcon in mc:icams() do
if not lcon:is_connected() then
nc=nc+1
printf('#%s NOT connected\n',lcon.mc_id)
else
cn=cn+1
printf('#%s connected\n',lcon.mc_id)
end
end
printf('\nSummary: %d cameras (%d connected, %d disconnected)\n',cn+nc,cn,nc)
end
Cameras that turn off: do they turn off properly (including retracting the lens)?
Something like this?Code: [Select]function mc:camstatus()Cameras that turn off: do they turn off properly (including retracting the lens)?
local cn=0
local nc=0
for lcon in mc:icams() do
if not lcon:is_connected() then
nc=nc+1
printf('#%s NOT connected\n',lcon.mc_id)
else
cn=cn+1
printf('#%s connected\n',lcon.mc_id)
end
end
printf('\nSummary: %d cameras (%d connected, %d disconnected)\n',cn+nc,cn,nc)
end
I believe the most probable scenario is that some camera(s) are losing connection and some (other) cameras turn off at the same time.This is IMHO unlikely to be a software issue. If things worsen gradually, it might be that the camera power supplies deteriorate (especially if they are cheap Chinese ones). It's also possible that you have ground loop (https://en.wikipedia.org/wiki/Ground_loop_(electricity)) issues (computer / usb hubs and camera power supplies are not on the same ground).
I believe the most probable scenario is that some camera(s) are losing connection and some (other) cameras turn off at the same time.This is IMHO unlikely to be a software issue. If things worsen gradually, it might be that the camera power supplies deteriorate (especially if they are cheap Chinese ones). It's also possible that you have ground loop (https://en.wikipedia.org/wiki/Ground_loop_(electricity)) issues (computer / usb hubs and camera power supplies are not on the same ground).
I something goes wrong I can then do a soft-reset back to the standard.
I don't understand what you mean by "preview mode".
Shoot_burst + preview mode.
We did MANY MANY tests doing "preshoot" + shoot_burst x multiple times...the moment we pressed preview mode , cameras were turning off (90% of the turned off cameras were the same every time).
I don't understand what you mean by "preview mode".
I also don't really get from your post which specific sequence of calls causes the problem or not. I would like to fix or at least understand crashes, but I do not have enough information to do anything.
Ah yes my bad , when i say "preview mode", i mean the "play" mode.Thanks, I understand now.
So the sequence of calls is "preshoot" + "shoot_burst" (the number of shoot_burst used is irrelevant , the problem occurs even with one shoot_burst) and then issuing "play" command (you know so you can review the photo taken on camera's display).Does the camera crash (shut down) or just stop responding to chdkptp?
Does the camera crash (shut down) or just stop responding to chdkptp?
At what point does the problem happen, immediately after switching to play mode, or subsequently when you try to switch back to rec or try to shoot again?
If it crashes, please get a ROMLOG from one camera. See http://chdk.wikia.com/wiki/Debugging#Camera_crash_logs_.28romlog.29 (http://chdk.wikia.com/wiki/Debugging#Camera_crash_logs_.28romlog.29)
Occured Time 2015:06:21 23:08:31So unless the clock is a couple years off, it's not related to the crash.
Can you check if the clock is approximately correct on the camera?
The romlog saysQuoteOccured Time 2015:06:21 23:08:31So unless the clock is a couple years off, it's not related to the crash.
The romlog i attached was created exactly after the crash.I don't know if it contains anything related to the crash but having a past date is normal.The romlog is saved to internal flash memory by the canon firmware when the crash occurs. The CHDK romlog just copies the most recent saved romlog to the SD card so you can download it. It is possible that the problem you have with switching to playback doesn't generate a romlog.
The romlog is saved to internal flash memory by the canon firmware when the crash occurs. The CHDK romlog just copies the most recent saved romlog to the SD card so you can download it. It is possible that the problem you have with switching to playback doesn't generate a romlog.
I am asking whether that specific cameras clock is set to 2015. YES or NO. I don't want to spend time trying to debug a log that has nothing to do with the problem you reported.
Also, please tell me which camera model and firmware version this came from.
so i bought a DC 12V power supplies and some DC-DC convertersDigital cameras need a lot of current when running motors, charging flash capacitors, and writing to the SD card. So your power supplies need to be able to handle high current bursts. What are the ratings of your 12 V supply and the DC-DC converters? Did you mount a converter at each camera so that the lowest voltage / highest current wire runs are the shortest?
A wiring diagram and photos showing your complete setup would be useful to see here.Here is the diagram.
Here is the diagram.If your DC-DC converter really only has a 800mA rating, that might not be sufficient for supplying the camera. Choose a converter that can handle the camera's peak currents (which could probably exceed 2A). Take a look at the specs (output current) of the original Canon power supply to get an idea.
Take a look at the specs (output current) of the original Canon power supply to get an idea.Thank you ! i will try to find out that current.
As srsa_4c suggests, your DC-DC converter is almost certainly too small. The moment the camera starts to zoom, the current draw needed will overload it. As you have already observed. There are several posts on this forum documenting measured brief current draws of about 1.5 amps IIRC! Those extra capacitors you added will not help enough to overcome that.Take a look at the specs (output current) of the original Canon power supply to get an idea.Thank you ! i will try to find out that current.
Hi mphx：
I have 8 cameras and it's make me crazy to charger them everytime,so i bought a DC 12V power supplies and some DC-DC converters tried to power the cameras,but it's failed at the beginning with one camera,when i try to zoom in ,camera died, i think maybe because of the length of the DC12 power and the camera.The length I need is 4 meters.
Could you help me with your experience?
Thanks.
通过我的 MX5 上的 Tapatalk发言
Only bad thing about dummy battery packs is that they can get really expensive if you have to buy lots of them (dummy battery pack for my model is around 10-11 euros on ebay and i don't think they are the original ones..so 10 x 64 cameras...you get the idea...)Just like you said,not cheap for the dummy battery pack.
Atleast we know they have the correct specs .
[size=78%]I going to buy some DC-DC [/size][/size]converters with 2A or 3A to see if it's working.[size=78%]As srsa_4c suggests, your DC-DC converter is almost certainly too small. The moment the camera starts to zoom, the current draw needed will overload it. As you have already observed. There are several posts on this forum documenting measured brief current draws of about 1.5 amps IIRC! Those extra capacitors you added will not help enough to overcome that.Take a look at the specs (output current) of the original Canon power supply to get an idea.Thank you ! i will try to find out that current.
You need something that can source at least 1.5 amps for several seconds without overloading.
How do you load the bcamHost.lua?It's been a while since i was playing with lua scripts in chdkptp.So i dont quite remember :) But have a look at this (https://github.com/simonswine/chdkptp/blob/master/USAGE.TXT) link.Start cli mode of chdkptp and my bet is on this :
I don't understand how to run it on the PC, I've successfully run the bcamRem.lua on the camera by loading it via card reader to the card and run it with "Load Script from File..."
exec (!) <lua code> : - execute local lua How do you load the bcamHost.lua?It's been a while since i was playing with lua scripts in chdkptp.So i dont quite remember :) But have a look at this (https://github.com/simonswine/chdkptp/blob/master/USAGE.TXT) link.Start cli mode of chdkptp and my bet is on this :
I don't understand how to run it on the PC, I've successfully run the bcamRem.lua on the camera by loading it via card reader to the card and run it with "Load Script from File..."Code: [Select]exec (!) <lua code> : - execute local lua
To integrate the script in GUI , its a bit more complicated if i remember well...
How do you load the bcamHost.lua?It's been a while since i was playing with lua scripts in chdkptp.So i dont quite remember :) But have a look at this (https://github.com/simonswine/chdkptp/blob/master/USAGE.TXT) link.Start cli mode of chdkptp and my bet is on this :
I don't understand how to run it on the PC, I've successfully run the bcamRem.lua on the camera by loading it via card reader to the card and run it with "Load Script from File..."Code: [Select]exec (!) <lua code> : - execute local lua
To integrate the script in GUI , its a bit more complicated if i remember well...
As i said , its been a while since i was playing with these things.I use chdkptp (gui) for specific actions and i haven't update/change anything in chdptp for months if not years.So i don't remember much about stuff :) Reyalp or anyone else watching this thread might have better answers than me.
Sorry this reply took so long, I was caught up in something.
Anyway the script works, turns out I've downloaded the wrong chdkptp, what I had was an entirely different program, oops.
I've successfully connect the scripts to the camera but for some reason I cannot use the remote?
I've checked the "use remote sync?" option on the script setting but still cant, and everytime after I run the bcamRem, my remote parameters setting resetted (previously I've checked it and use the one shot)
but when I load the default.lua I can use the remote no problem
can you help point me in the right direction?
Thanks!
I've successfully connect the scripts to the camera but for some reason I cannot use the remote?Are you trying to use a USB remote like the one describe here? (https://chdk.fandom.com/wiki/USB_Remote) If so, how do you have that wired to your USB connection to your PC?
I've checked the "use remote sync?" option on the script settingThat option is only needed when you are trying to get two or more cameras to shoot at almost exactly the same time.
and everytime after I run the bcamRem, my remote parameters setting resetted (previously I've checked it and use the one shot)Is that the script I posted almost five years ago? If so, I'll have to drag it out of my svn archive and try to figure out what I was doing way back then. IIRC, it sets up the remote parameter configuration - overriding the current settings and does not politely reset them when it is done. Sorry.