CHDK Forum
CHDK Development => Feature Requests => Topic started by: Aket on 08 / June / 2010, 02:47:12
-
Oh my god it would be so good to have these three things to adjust on my powershot. Please someone out there hear my prayers for developing an update in the firmware to have these three things to control.
Someone out there, please!
-
I second that. It would make video mode on these cameras much more usable. Right now the video features such as zoom and focus are great but having control over shutter and aperture would be excellent. Does anybody have any plans to update this?
-
Don't forget ISO!
See? People want it! As much as the people who demanded manual exposure on dslrs.
C'mon! Pleaseeee!
-
See? People want it! As much as the people who demanded manual exposure on dslrs.
Doesn't matter who wants it, unless they happen to be a programmer with a whole bunch of time and the necessary reverse engineering skills (assuming it's possible at all, which isn't a given.)
Features are generally added because someone who wanted the feature implemented it, not because it would make CHDK more popular with the general public. If you want this feature, you are welcome to dig into the code.
-
What? SO WHY DOES THIS PART OF THE FORUM EVEN EXIST?
Jeez! I'd even do it myself if I knew some programming, or at least some hint on what should I learn to do it, you might have 7420981 posts but you don't even bring an insight on what to do for help in this situation.
It's even a very basic and helpful feature.
Someone who could help should speak up.
And the ones who encourage nothing to be done like you should shut up.
-
What? SO WHY DOES THIS PART OF THE FORUM EVEN EXIST?
So people can make suggestions and discuss ideas. It's not a task list.
Jeez! I'd even do it myself if I knew some programming, or at least some hint on what should I learn to do it,
C (http://en.wikipedia.org/wiki/C_%28programming_language%29) and assembler (http://en.wikipedia.org/wiki/Assembly_language). You're welcome.
And the ones who encourage nothing to be done like you should shut up.
I did not "encourage nothing to be done", I described how the process actually works: Features get implemented because someone with the required skill devotes the required time to it. This is essentially unconnected to how many people request it on the forum.
Exposure control in video is a good idea, and a popular request. I have no objection to it being done, but I don't personally have the time and inclination to work on it. If someone does start work on it, I'll be happy to provide any technical assistance I am able to.
-
@Aket
...or at least some hint on what should I learn to do it
http://chdk.wikia.com/wiki/For_Developers (http://chdk.wikia.com/wiki/For_Developers)
HTH,
wim
PS You might also want to take a look here http://tools.assembla.com/chdk/log/?action=follow_copy&rev=918&stop_rev=&mode=follow_copy&verbose=on (http://tools.assembla.com/chdk/log/?action=follow_copy&rev=918&stop_rev=&mode=follow_copy&verbose=on) to see that reyalp does 'a little' more than bumping his post count :o
-
I did not "encourage nothing to be done"
[/quote]
You basically said/implied: "You can't ask for features here, and it doesn't matter how many people do also, you would need a lot of time in case you knew programming and if it's even posible to do it and since I'm the only one experienced replying here I don't think there's someone else who can, good luck if you do :)"
That's pretty discouraging in my book and I think most people's.
But whatever, thanks for the hint. Just checked what you have to know, looks pretty hard.
How many codes would you have to write and where? The assembler gets the codes into the CHDK firmware?
Thanks if you can answer.
-
@Aket
...or at least some hint on what should I learn to do it
http://chdk.wikia.com/wiki/For_Developers (http://chdk.wikia.com/wiki/For_Developers)
HTH,
wim
PS You might also want to take a look here http://tools.assembla.com/chdk/log/?action=follow_copy&rev=918&stop_rev=&mode=follow_copy&verbose=on (http://tools.assembla.com/chdk/log/?action=follow_copy&rev=918&stop_rev=&mode=follow_copy&verbose=on) to see that reyalp does 'a little' more than bumping his post count :o
I imagined he was a developer but he was very dismissive, thanks anyway, and nice I'll check that out.
-
Aket - please take the trouble to re-read your posts and the replies. So far you've managed to be unpleasant to two people (note that they are both "Guru Members") who have freely given a great deal of their time to (a) work on CHDK and (b) answer lots of questions politely here. As Reyalp said, this thread is so people can make suggestions - not demands. And no matter how many people ask for something, when they are asking (as you were) for something for nothing, whether they get it depends on the goodwill of people like Reyalp and Whim, not how loudly or aggressively they ask.
And by the way, there's lots of information here and on the Wiki about what you need to know to do development. As you say, "it looks pretty hard".
-
How many codes would you have to write and where?
What does your question mean, I cannot understand it ?
Do yourself a favour, buy a Panasonic FZ38 or similar, like I have.
-
Aket - please take the trouble to re-read your posts and the replies. So far you've managed to be unpleasant to two people (note that they are both "Guru Members") who have freely given a great deal of their time to (a) work on CHDK and (b) answer lots of questions politely here. As Reyalp said, this thread is so people can make suggestions - not demands. And no matter how many people ask for something, when they are asking (as you were) for something for nothing, whether they get it depends on the goodwill of people like Reyalp and Whim, not how loudly or aggressively they ask.
And by the way, there's lots of information here and on the Wiki about what you need to know to do development. As you say, "it looks pretty hard".
Got it, sorry I just thought it wasn't so difficult for the guys who know the code, that's why I asked loudly.
How many codes would you have to write and where?
What does your question mean, I cannot understand it ?
Do yourself a favour, buy a Panasonic FZ38 or similar, like I have.
The question is pretty clear and I think we had already too much negativity in here, right? Great suggestion but I already knew of the camera, thanks for helping developing the firmware, but there's a reason we're in Canon forum. Thanks, bye!
-
i'd love this feature too! i'm not a programmer but i have cash. so who wants to get paid?
(hows that for offering my help?)
-
i'd love this feature too! i'm not a programmer but i have cash. so who wants to get paid?
(hows that for offering my help?)
If you are prepared to offer market value for programmer time, I suggest you just buy a DV system with the features you need. It will likely be significantly cheaper, and you will end up with a system much better suited to producing quality video. Also, as I mentioned before, there's no guarantee that all the requested features can be implemented in CHDK. I would guess that it probably can be done, and might even be fairly simple, but no one knows until they've done the research. Just doing that research is likely to take substantial time.
Again, I'm not trying to discourage people from asking for features, or saying this is a bad idea or is not a worthy feature. Quite the opposite: It's a good idea and quite a few people would obviously like to have it.
What I am trying to do is explain why merely asking for something doesn't have a lot of influence on whether it gets done or not. Think about it this way: If some random stranger asks you to spend hundreds or thousands of dollars worth of time on their project, is the major factor going to be how much they want it, or how interesting/rewarding you find the project ?
edit:
Or maybe you'll get lucky and someone who has already spent the time will tell you how to do it :D
-
IMO, manual control of shutter speed and aperture in video can be done using lua script (with event procedures).
1) To turn off auto-exposure and lock ISO, Tv, Av to their current values use ExpCtrlTool.StopConti() function.
2) To change shutter speed, use SetAE_ShutterSpeed() fuction. Remember that exposure time cannot exceed 1/fps.
3) To change apreture, use MoveIrisToAv() fuction. Sometimes it can crash camera.
4) I don't know how to change ISO. Maybe SetAE_CdsGainValue() function?
5) To turn on auto-exposure back, use ExpCtrlTool.StartConti() fuction.
-
edit: since this is in the feature request section instead of the devel one, a disclaimer is probably in order: do not try the code below if you don't know what you're doing :)
Looks like these event procedures aren't registered by default on a570 (call_event_proc always returns -1).
ExpCtrlTool.* event proc table is at 0xffd1f1d4 for a570 100e, function that registers them is at 0xffd1f704. That one gets called from Capture.Create (among a whole lot of other stuff, hopefully nothing too bad).
SetAE_ShutterSpeed eventproc table is at fff345dc, but I couldn't figure out how to register that one so I called it by its a570 100e entry point directly:
buf=call_event_proc("AllocateMemory",4)
if buf > 0 then
poke(buf,tv)
--ret=call_event_proc("SetAE_ShutterSpeed",buf)
ret=call_func_ptr(0xffe0b70c,buf) --SetAE_ShutterSpeed(&tv) on a570 100e
print("AE_ShutterSpeed=" .. ret)
call_event_proc("FreeMemory",buf)
end
and exposure changed. So far I've tried overriding to 1/256 s and 1/4 s, the latter crashed a few seconds later (ROMLOG shows assert in AviWriter.c line 606, tMovieReco task).
Haven't tried Av or ISO yet, but those eventprocs are similar to shutter speed and probably not registered either (MoveIrisToAv entry 0xffe05ba4, eventproc table fff34168 and SetAE_CdsGainValue entry 0xffe0b964 is actually in the same event proc table with SetAE_ShutterSpeed so highly likely not registered).
Also need to find current *v96 values for a starting point for adjustment (I haven't searched, propcases would be an obvious first look).
btw, http://chdk.setepontos.com/index.php/topic,1075.msg19070.html#msg19070 (http://chdk.setepontos.com/index.php/topic,1075.msg19070.html#msg19070)
-
Okay well I wrote a little Lua script VideoExp.lua to control Tv and Av during video record (or idle live view). it's here: VideoExp.lua (http://pastebin.com/zvvYnTuH)
Please note that in it's current form it's strictly for a570is 100e only (and it tries to prevent you from running it on other cameras) because it uses hard coded entry points for the functions that set Av and Tv since I couldn't figure out how to register them using eventprocs only.
It appears that these adjustments aren't the most stable thing out there. It's probably Tv adjust that causes problems. My camera crashes every time I set Tv slower than the 30 Hz frame rate (even in 15 Hz mode), but Tv=1/32 s seems to work fine in the 60 Hz video mode. Worryingly the camera sometimes crashes after Tv adjustments in the faster range too. This doesn't mean Av adjustment would be bug free either, I haven't tested this enough to tell.
ND filter and ISO (Sv) are still missing from the script. ND is something I'm not going to be able to test at all.
Oh, I forgot to make the script test for rec mode. Running in play mode probably results in a crash, I did that at one point by accident.
edit: turns out 'prop=require "propcase"' crashes the camera during video record. Maybe other file access is a no-no during video too? So a new version (link updated) it now checks for rec mode too. It's possible that some crashes were due to file i/o instead of tv adjust...
-
Nice.
<- should spend more time hacking, less http://xkcd.com/386/ (http://xkcd.com/386/)
http://chdk.wikia.com/wiki/User:ReyalP/EventProcNotes (http://chdk.wikia.com/wiki/User:ReyalP/EventProcNotes) may help you find registration functions. As you mentioned earlier, some of them do unknown Other Stuff, so beware.
This is all from a540. Where I've noted something like
RAM 0x9ED8 -> FFEFC3C8
It means that I found the event proc table in the data that gets copied to RAM. Presumably, if they are copied to RAM they some entry points could change before they are registered. The procedure for find the ram based tables is pretty simple. Find name,function pairs in the canon data segment in ROM, translate that to a RAM address (<table address> - <ROM data start> + 0x1900), then search for the resulting address as a literal value. So for example, in a570 100e, SetAE_ShutterSpeed is found in a table starting at FFF33FB8. Data starts at FFF2D320 -> 0x8598. The only obvious code reference to this value is sub_FFE04358. If you backtrack through the callers, you find it associated with InitializeAdjustmentFunction
Regarding the crashes, it is possible that adjusting some of these things are expected to be synchronized.
-
Thanks reyalp, that got all three registered. New version available at http://pastebin.com/Nm5r9V7p (http://pastebin.com/Nm5r9V7p).
This one is no longer camera model dependent, but it's possible that it will still only work (without modification) on a some cameras from the same era (FYI, the a570 is a Digic III vxworks camera from year 2008 or so). To debug you may want to print + sleep after each call_event_proc command to see if they return -1, which for this script quite likely means the event procedure was not found (doesn't mean it doesn't exist, it may just be unregistered).
I used SetCDSGain for ISO control since SetAE_CdsGainValue needed an input value to be placed in RAM (0x8ba4 for a570) with poke. Their effect seems to be the same, a range 0-ish to 1024-ish seems to cover the camera's ISO range (probably just the true ISO range, not artificial software extensions like ISO 1600 on a570, but I really don't know for sure...just a gut feeling that this number is connected to 10-bit PGA HW control).
The script is still not stable (and possibly never will be). Expect crashes every now and then. I didn't experience SD card corruption even though several video recordings got cut with battery removal.
Sv (ISO) adjust doesn't start from startup value but instead resets to zero, sorry.
-
Thanks Fudgey, this is a great start! - being able to lock in the ISO to a low value should improve video quality immensely.
From what I gather, you'll need to "roll your own" CHDK to include the "native call" support, (required to run this LUA script).
I'm not overly confident in doing this, I'd like to know if anyone else has compiled CHDK with "Native Call Support" for a Canon G7?
Perhaps once we can verify this works as a LUA script on a number of camera's, it can be included within the main CHDK build?
Thanks again all for your amazing work!
-
From what I gather, you'll need to "roll your own" CHDK to include the "native call" support, (required to run this LUA script).
I'm not overly confident in doing this, I'd like to know if anyone else has compiled CHDK with "Native Call Support" for a Canon G7?
Building CHDK with native calls enabled is very simple and doesn't really require any programming experience, especially not if you run Windows: Get http://chdk.wikia.com/wiki/CHDK-Shell (http://chdk.wikia.com/wiki/CHDK-Shell) and download latest trunk using it. Go to the "Compile options" menu and check OPT_LUA_CALL_NATIVE.
If you can't find it on the compile options screen (I don't run Windows so I can't check easily), you need to either edit the file trunk/buildconf.inc by removing '#' from start of the line that says #OPT_LUA_CALL_NATIVE=1 or create a file called localbuildconf.inc to the same folder that has a single line that reads
OPT_LUA_CALL_NATIVE=1
in it.
Then you just compile (you'll probably want to select your camera version first, maybe some other stuff too that I don't know about -- see CHDK shell documentation).
The danger of having native calls enabled lies pretty much entirely in that using native calls someone could write a malicious lua script for you and destroy your camera by fooling you into running their script. I assure you my script wasn't written to intentionally destroy your camera... In principle we could have a CHDK config option (e.g. in debug menu) to enable native calls, but the problem is that a malicious Lua script could modify your config using normal file I/O functions. Note that someone could quite as well create a malicious CHDK build that does the same and fool you into installing it. Scripts are just a tad easier to try out than builds.
-
Thanks for the detailed guide Fudgey! I'll give it a try over the weekend & see how I go. The G7 has very similar specs to the A570 so I would expect similar results.
-
I can confirm that this LUA script works perfectly on a Powershot G7!
Compiling a custom CHDK with the shell script was a piece of cake. In the tests I've done to date, I'm leaving the shutter, (Tv), value at the default of 480, (which I presume is 1/60th sec). I'm setting the ISO, (Sv), to 128. I'm seeing virtually zero noise in the dark areas of the image, which is exactly what I hoped to achieve.
A question, in which mode is the Canon MJPEG codec operating, 4:1:1, 4:2:0 or 4:2:2 color space?
Update: I'm now able to record at Quality=99, (around 47.5 mbit/sec or 6MB/Sec), whereas before the camera would crash at these data rates. It's possible that by lowering the ISO value, less noise is now being recorded in the video clip, therefore the video compression is working more efficiently.
-
Tested on a Canon IXUS 100IS or SD780, (DIGIC 4 processor).
- Camera crashes soon after loading the LUA script.
- It seems the "native calls" need to be updated to work on DIGIC 4 based cameras :(
Fudgey - it appears you were spot on in your estimate that this would only work on DIGIC3 series camera's!
Unfortunately, Canon didn't make the switch to HD movie recording on the PowerShots until after the DIGIC4 chip was released, (2008), so we're stuck with 640x480 until we have a break through.
As ISO control has such a huge impact on video quality, it'd be great to see this incorporated in the main CHDK build...?
-
Tested on a Canon IXUS 100IS or SD780, (DIGIC 4 processor).
- It seems the "native calls" need to be updated to work on DIGIC 4 based cameras :(
Native calls work fine on digic 4. The particular functions used in the script may have changed.
s ISO control has such a huge impact on video quality, it'd be great to see this incorporated in the main CHDK build...?
Agreed. That requires someone to do the grunt work to make it work reliably, or figure out which cameras it works on. fudgeys script is a good place to start experimenting.
This one is no longer camera model dependent, but it's possible that it will still only work (without modification) on a some cameras from the same era (FYI, the a570 is a Digic III vxworks camera from year 2008 or so). To debug you may want to print + sleep after each call_event_proc command to see if they return -1, which for this script quite likely means the event procedure was not found (doesn't mean it doesn't exist, it may just be unregistered).
Good advice. Even if the functions are registered, it may tell you which one is crashing.
You can also try getting a ROMLOG http://chdk.wikia.com/wiki/LUA/Scripts:Standard/Test/Romlog (http://chdk.wikia.com/wiki/LUA/Scripts:Standard/Test/Romlog)
-
Although the CHDK does run, I'm getting errors when building CHDK for an IXUS 100IS, (SD780) - which may be effecting my testing of the LUA script...? Here's the error report;
boot.c: In function 'taskCreateHook':
boot.c:36: warning: comparison between pointer and integer
boot.c:43: warning: assignment makes integer from pointer without a cast
boot.c: In function 'dumpCF90_SD7802':
boot.c:144: warning: implicit declaration of function 'Fopen_Fut'
boot.c:145: warning: implicit declaration of function 'Fwrite_Fut'
boot.c:146: warning: implicit declaration of function 'Fflush_Fut'
boot.c:147: warning: implicit declaration of function 'Fclose_Fut'
boot.c: In function 'task_blinker':
boot.c:191: warning: implicit declaration of function 'draw_txt_string'
wrappers.c: In function 'OpLog_Get':
wrappers.c:23: warning: implicit declaration of function '_OpLog_Get'
kbd.c: In function 'dumpProps':
kbd.c:216: warning: implicit declaration of function 'Fopen_Fut'
kbd.c:219: warning: implicit declaration of function 'sprintf'
kbd.c:219: warning: incompatible implicit declaration of built-in function 'sprintf'
kbd.c:220: warning: implicit declaration of function 'Fwrite_Fut'
kbd.c:220: warning: implicit declaration of function 'strlen'
kbd.c:220: warning: incompatible implicit declaration of built-in function 'strlen'
kbd.c:222: warning: implicit declaration of function 'Fflush_Fut'
kbd.c:223: warning: implicit declaration of function 'Fclose_Fut'
kbd.c: In function 'dump1900_SD780':
kbd.c:258: warning: incompatible implicit declaration of built-in function 'sprintf'
kbd.c:262: warning: incompatible implicit declaration of built-in function 'sprintf'
kbd.c:267: warning: incompatible implicit declaration of built-in function 'sprintf'
kbd.c: In function 'my_kbd_read_keys':
kbd.c:377: warning: implicit declaration of function 'draw_txt_string'
Note, when building CHDK for my G7, I don't get any errors at all, so I'm confident that this is a camera specific error.
-
These are warnings, not errors. Most of them look relatively harmless, probably from camera specific debugging / development code.
-
Just delete functions 'dumpCF90_SD7802', 'task_blinker', 'dumpProps', 'dump1900_SD780'.
In boot.c, aHookList[] is declared as an array of 'long' but 'p' is a pointer to an integer value.
-
I've decided to ignore the compiler warnings & proceed, as it doesn't appear to effect the CHDK from functioning normally.
So we know the VidExp.lua script crashes the Digic4 based IXUS 100is, but at what point?
I broke the script down into various sections, remarking or deleting out lines of code until I could isolate the problem.
All of the initialization checks to see if the Camera supported native calls, ExpCtrlTool & ND tests all work fine.
However, the following lines of script would always crash the camera;
Line 95. if (call_event_proc("InitializeAdjustmentFunction") == -1) then
Line 96. error("InitializeAdjustmentFunction failed")
Line 130. ret=call_event_proc("SetAE_ShutterSpeed",tv96)
Line 154. ret=call_event_proc("MoveIrisToAv",av96)
Line 177. ret=call_event_proc("SetCDSGain",sv96)
Are we to assume these particular event procedures have yet to be "enabled" or "mapped out" on the newer Digic4 cameras?
How to move forward? - Is there something a non-dev, such as myself, could investigate?
-
Line 95. if (call_event_proc("InitializeAdjustmentFunction") == -1) then
Line 96. error("InitializeAdjustmentFunction failed")
Line 130. ret=call_event_proc("SetAE_ShutterSpeed",tv96)
Line 154. ret=call_event_proc("MoveIrisToAv",av96)
Line 177. ret=call_event_proc("SetCDSGain",sv96)
Are we to assume these particular event procedures have yet to be "enabled" or "mapped out" on the newer Digic4 cameras?
How to move forward? - Is there something a non-dev, such as myself, could investigate?
Function entry points for ixus100_sd780 sub 100c are
SetAE_ShutterSpeed 0xffa96f60
MoveIrisToAv 0xffa92248
SetCDSGain 0xffa91e6c
InitializeAdjustmentFunction 0xff91d4fc
I suppose the problem is that InitializeAdjustmentFunction isn't registered. The other three funcs don't work because they are supposedly registered by InitializeAdjustmentFunction whose call failed.
It's name+entry can be found at a table that starts at 0xffb5581c but I don't know who registers it. But until someone finds out, if you're feeling brave you could start by replacing
if (call_event_proc("InitializeAdjustmentFunction") == -1) then
error("InitializeAdjustmentFunction failed")
end
with something like
bi=get_buildinfo()
print("platform: ",bi.platform," ",bi.platsub)
if bi.platform~="ixus100_sd780" then
error("wrong camera model")
elseif bi.platsub~="100c" then
error("wrong firmware version")
end
ret=call_func_ptr(0xff91d4fc)
print("InitAdjFunc=",ret)
That effectively calls InitializeAdjustmentFunction directly (not as an event procedure), which should be just as good unless you wish to use the same script on other cameras. That buildinfo stuff should prevent accidentally running this on incorrect camera models.
-
Same seam to happen with anothe digiIV, the sx210
fails at
if (call_event_proc("SystemEventInit") == -1)
keeps going if replaced with
if (call_event_proc("System.Create") == -1) then
and fails againg here
if (call_event_proc("InitializeAdjustmentFunction") == -1) then
and also fails if replaced with
if (call_event_proc("InitializeAdjustmentSystem") == -1) then
Will help a lot with this if there is a new sig file for the dryos,
while the vxworks sig gets 5000 names the dryos gets less than 1000
-
Same seam to happen with anothe digiIV, the sx210
fails at
if (call_event_proc("SystemEventInit") == -1)
keeps going if replaced with
if (call_event_proc("System.Create") == -1) then
Interesting. I guess canon has finally retired SystemEventInit as a compatibility alias for System.Create.
-
Fudgey - calling the InitializeAdjustmentFunction directly works, (thanks!). However, it still crashes on lines,
Line 130. ret=call_event_proc("SetAE_ShutterSpeed",tv96)
Line 154. ret=call_event_proc("MoveIrisToAv",av96)
Line 177. ret=call_event_proc("SetCDSGain",sv96)
Is it possible to also replace these lines with specific IXUS 100 code?
-
Fudgey - calling the InitializeAdjustmentFunction directly works, (thanks!). However, it still crashes on lines,
No it didn't, apparently, since adjustment functions didn't get initialized ;)
Is it possible to also replace these lines with specific IXUS 100 code?
Supposedly yes (using the entry points I listed in the previous post -- the init func call can naturally be removed in that case), this is what I did for a570 in the first version of my video control script in this thread. It would be a good idea to check what all the funcs expect as arguments first (on a570 some take ints, some pointers -- it may not be exactly same for you camera).
-
Some Adavances in the digicIV world, its best to use canonbasic to go forward
I get past the first creating using:
if (call_event_proc("System.Create") == -1) then
error("SystemEventInit failed")
end
Instead of SystemEventInit
and
if (call_event_proc("FA.Create") == -1) then
error("FA CREATE failed")
end
if (call_event_proc("InitializeAdjustmentSystem") == -1) then
error("InitializeAdjustmentSystem failed")
end
instead of InitializeAdjustmentFunction
Get this Reading the info about canonbasic funcs, tells what to call first
now mine fails here ret=call_event_proc("ExpCtrlTool.StopConti")
-
now mine fails here ret=call_event_proc("ExpCtrlTool.StopConti")
from platform/ixus100_sd780/sub/100c/stubs_entry_2.S
NHSTUB(ExpCtrlTool_StartContiAE, 0xFF82FF40) //"StartContiAE"
NHSTUB(ExpCtrlTool_StopContiAE, 0xFF830084) //"StopContiAE"
Maybe they aren't available as eventprocs?
-
thank fudgey, I'm using sx210
and I have these
NHSTUB(ExpCtrlTool_StartContiAE, 0xFF846458) // -> ASM1989 08.21.2010
NHSTUB(ExpCtrlTool_StopContiAE, 0xFF846530) // -> ASM1989 08.21.2010
but It still crash if called
ret=call_func_ptr(0xff846530)
maybe it needs first a call to StopServoAE
-
Don't forget about arguments: ExpCtrlTool_Start(Stop)ContiAE(0,0)
-
Ok now It loads (sx210)
with
function manualexp()
ret=call_func_ptr(0xff846530,0,0)
end
function autoexp()
ret=call_func_ptr(0xff846458,0,0)
end
allows you to change all the settings correctly
but when shutter pressed to start recording hangs, first lines of the romlog:
ASSERT!! ExpProg.c Line 1576
Occured Time 2010:09:28 23:34:06
Task ID: 15466529
Task name: CaptSeqTask
SP: 0x0034D400
full romlog here http://www.zshare.net/download/80898775cccc4365/ (http://www.zshare.net/download/80898775cccc4365/)
-
but when shutter pressed to start recording hangs, first lines of the romlog:
Hm? The problem could be that you're not supposed to start recording while AE is in disabled state. I'm not sure if I've ever tried doing that, actually (the script hangs the cam often enough as is, no need to try and find more things to upset the cam :P). Did you try starting video record before running the script?
-
Right, If I start recording first, and then run the script It hangs at the manualexp() function
-
It'd be great to figure out the final piece of the puzzle in order for this to run on all Digic4 camera's.
Are any of the devs with late model Digic4 camera's able to run this script?
It seems we're very close to cracking this once & for all! - I'm hoping this will become part of the main CHDK once it's all working & we can lock in ISO and Shutter from the Video Parameters menu without all the fiddling about with running scripts.
-
-
Finally, partial success on the IXUS 100IS!!! (& I dare say all other camera's)
See new post below...
-
I'm looking forward for your work, if I can help somehow by testing something on the S95....
-
Progress!
Thanks to ASM1989, I made the same 3 changes to the original script,
Firstly,
-- this is required for event procedure AllocateMemory
if (call_event_proc("System.Create") == -1) then
error("SystemEventInit failed")
end
Second,
-- this is required for event procedures SetAE_ShutterSpeed, MoveIrisToAv, SetCDSGain
if (call_event_proc("FA.Create") == -1) then
error("FA CREATE failed")
end
if (call_event_proc("InitializeAdjustmentSystem") == -1) then
error("InitializeAdjustmentSystem failed")
end
& Finally substituting the last change with specific IXUS 100 values, in my case...
-- go to manual exposure mode
function manualexp()
ret=call_func_ptr(0xFF830084,0,0)
end
function autoexp()
ret=call_func_ptr(0xFF82FF40,0,0)
end
The above memory locations were taken from,
from platform/ixus100_sd780/sub/100c/stubs_entry_2.S
NHSTUB(ExpCtrlTool_StartContiAE, 0xFF82FF40) //"StartContiAE"
NHSTUB(ExpCtrlTool_StopContiAE, 0xFF830084) //"StopContiAE"
For this to function I assume you'll need to find the exact memory locations for your specific camera.
Note the first function called is StopContiAE, which enables you to make manual adjustments.
I run the script, lock in the changes, shutter & ISO, (aperture is not available on IXUS)
While the camera is not recording, these values seem to lock in fine. I can point the camera at a bright target and the camera will not try to auto-adjust.
Unfortunately as soon as I hit record, the camera takes over ISO control again.
Damn! so close!!!
-
-
I've now changed the script to replace the "autoexposure" function with a "movie record" function on the following lines,
elseif is_pressed("set") then
print("recording")
click "shoot_full"
sleep(1000)
It works perfectly now!
For the SX200IS, you'll need to use the following values to replace in the manualexp function
NHSTUB(ExpCtrlTool_StopContiAE, 0xFF830504)
NHSTUB(ExpCtrlTool_StartContiAE, 0xFF8303C0)
This info was obtained here,
http://my-trac.assembla.com/chdkde/browser/trunk/platform/sx200is/sub/100c/stubs_entry_2.S?rev=455 (http://my-trac.assembla.com/chdkde/browser/trunk/platform/sx200is/sub/100c/stubs_entry_2.S?rev=455)
If anyone is interested, I can post the completed script in the CHDK script section, it may be a bit rough around the edges, (hell I'm no coder!), but it achieves the desired results!
-
Hey thanks! Indeed expore is locked for some time. But on my SX200IS as soon as I start recording, even by script, the autoexposure will come in again...
This is the script I tried with, am I doing something wrong?
if (call_event_proc("System.Create") == -1) then
error("SystemEventInit failed")
end
-- this is required for event procedures SetAE_ShutterSpeed, MoveIrisToAv, SetCDSGain
if (call_event_proc("FA.Create") == -1) then
error("FA CREATE failed")
end
if (call_event_proc("InitializeAdjustmentSystem") == -1) then
error("InitializeAdjustmentSystem failed")
end
-- go to manual exposure mode
function manualexp()
ret=call_func_ptr(0xFF830504,0,0)
end
function autoexp()
ret=call_func_ptr(0xFF8303C0,0,0)
end
ret = manualexp()
if ret~=nil then
print("call manualexp failed.")
end
sleep(5000)
click("shoot_full")
sleep(30000)
print "shooting"
-
Please see the section "Completed and Working Scripts"
Video exposure control, modified to work on Digic 4 camera's
If you download the script and substitute with your memory locations it should work fine.
-
I really need these features!! I have an A570IS, already with the latest version of CHDK. Can someone help me getting these on my camera? Is there a file, plugin or anything like that? I have very good knowledge of computers in general, but not specifically about CHDK. What do I need to do to be able to control ISO and aperture in my camera?
-
I really need these features!! I have an A570IS, already with the latest version of CHDK. Can someone help me getting these on my camera? Is there a file, plugin or anything like that? I have very good knowledge of computers in general, but not specifically about CHDK. What do I need to do to be able to control ISO and aperture in my camera?
Compile CHDK with native calls enabled and run the script from my earlier post here http://chdk.setepontos.com/index.php?topic=5295.msg54097#msg54097 (http://chdk.setepontos.com/index.php?topic=5295.msg54097#msg54097)
But it's not stable, meaning you should expect the camera to crash every now and then. During video record, that will probably mean losing the entire recording.
-
Please see the section "Completed and Working Scripts"
Video exposure control, modified to work on Digic 4 camera's
If you download the script and substitute with your memory locations it should work fine.
Hi!
I have a sx130 is. Please tell me how can I upgrade my chdk with manual video control. Unfortunatelly I'm not a big brain in programming but I would to try it. I want to reduce ccd's smear using slower shutter and an nd filter, but I have no chance using auto mode.
Thanks
Roland
-
Great. Works for SX220. I had to comment out the lines autoexp() and manualexp() because ExpCtrlTool_StartContiAE and ExpCtrlTool_StopContiAE aren't needed and caused the camera to crash. On this camera the exposure can be set manually before starting the recording and this disables the continuous AE.
-
Any way to disable continuous AE on other cameras (like A650, A620) the same way as on SX220 ? Current implementation is not useful for me, because zooming unlocks the exposure
-
I did some modifications on the original script. Used PT_DoAELock and PT_UnlockAE to enable and disable AE. I don't know if it will work on other cameras. Works fine on sx220.
The differences are:
--required for PT_DoAELock and PT_UnlockAE
if (call_event_proc("SS.Create") == -1) then
error("SystemEventInit failed")
end
-- go to manual exposure mode
function manualexp()
ret=call_event_proc("PT_DoAELock")
end
function autoexp()
ret=call_event_proc("PT_UnlockAE")
end
elseif is_pressed("set") then
print("recording")
--click "shoot_full"
post_levent_to_ui("PressMovieButton")
.
.
.
-
Based on this script, I've implemented a touch screen version for the IXUS 310 HS.
(Being able to create a custom U/I opens up some interesting possibilities).
Still needs some work - the camera will crash if you change settings too quickly.
Not sure how practical this is for the IXUS 310, being such a small camera and with a 10 minute video clip limit; but it was fun to play around with.
Phil.
-
Damn, just checked this script out on my Elph 300 HS and it works until the record button is pressed. I replaced the values from here http://trac.assembla.com/chdkde/changeset/880 (http://trac.assembla.com/chdkde/changeset/880)
Any ideas on what I should be doing differently? Should I have iso manually set in CHDK before I start the script? It seems like I have tried all combinations but the continuous AE won't lock!
-
Any news about exposure lock during video ?
i am really anxious on buying this camera and my retailer is going out of stock .
Can someone tell me if exposure lock for video is just a matter of time or there is the posiblity that exposure lock will be imposible for this model ?
-
i am really anxious on buying this camera and my retailer is going out of stock .
What camera ?
-
ixus220 / elph 300 :D , oups i tought i was in the ixus220 porting thread
-
Anyone know if this script run on sx230hs?
-
This works on my SX40HS. I need to adjust max/min Av though.
-
Oh my god! I created this thread 2 and a half years ago and can't believe it, does this mean it's actually done? Can't get the final conclusion from the posts.
I no longer have a Powershot but I might get one as my second camera as the manual exposure in video is a very catchy feature.
Thanks a lot to the people who clearly put effort in this feature addition!
If it can be done what are the instructions to make it work?
-
@bigbluezuk: Would you help me to use the script for my SX40? PLEASE HELP!
-
@D@noosh
The script attached to this (http://chdk.setepontos.com/index.php?topic=5295.msg68622#msg68622) post should work on your camera.
However, you need to install the development version (http://mighty-hoernsche.de/trunk/) of CHDK, and enable native calls in the CHDK menu: Miscellaneous Stuff -> Enable Lua Native Calls
-
Thanks, it worked but problems occurred... see here for more information:
http://chdk.setepontos.com/index.php?topic=9545.msg97874#msg97874 (http://chdk.setepontos.com/index.php?topic=9545.msg97874#msg97874)
-
@D@noosh
The script attached to this (http://chdk.setepontos.com/index.php?topic=5295.msg68622#msg68622) post should work on your camera.
However, you need to install the development version (http://mighty-hoernsche.de/trunk/) of CHDK, and enable native calls in the CHDK menu: Miscellaneous Stuff -> Enable Lua Native Calls
Tried that script with the SX230HS, and it crashed after about 3 seconds with the lens still extended.
had CHDK save a log file (cant really make sense of it as it is just a bunch of random values)
-
Tried that script with the SX230HS, and it crashed after about 3 seconds with the lens still extended.
had CHDK save a log file (cant really make sense of it as it is just a bunch of random values)
That's our old "friend", I'm afraid. The script draws on the screen, which causes a crash - the same happens when CHDK OSD is active during movie recording, if I remember correctly.
-
if this script was combined with the motion detection script
although script can also affect pictures (so it can force a high-iso shot
but what's different is that it post-processes it as what the CANON-GUI treats it so that
if canon-set to low ISO there is almost no noise removal from it)
but changing the shutter-speed-pseudo-value also changes the live-view so that it is brighter
so could have a really light sensitive low-iso (but low frame rate ) live view
if could find a tv value so that the live view is max and wont go higher,
and iso to what's represntive of what your shooting (since overexposed wont go higher, and more noisy)
-
hi can any one make the canon sx40 to record video on full manual control ?
when i go to manual mode and take a pic i see very good pic but as soon that i record the video the camera go's to automatic control and its bad ,the pic jast is not good.
can some one make a script for it or is it not possible to do it.
do i need a different camera
thanks
-
Manual exposure control in video mode is not currently available with CHDK. It might be technically possible and people have probably experimented with the idea, but its not supported.
-
hi waterwingz
can you explain more on it ? i saw a post on canon a series can't remember the no,but they say hear that you can record manualy on it with the chdk and can select iso Shutter ...
so if you can explain on what may be the problem,i knew a lot will like it if it can be made full manual
thanks uzi
-
hi can any one make the canon sx40 to record video on full manual control ?
I don't know whether it's working on your camera, but there is this script:
http://chdk.setepontos.com/index.php?topic=5295.msg68622#msg68622 (http://chdk.setepontos.com/index.php?topic=5295.msg68622#msg68622)
Don't expect too much reliability, it can crash the camera easily.
-
hi can any one make the canon sx40 to record video on full manual control ?
I don't know whether it's working on your camera, but there is this script:
http://chdk.setepontos.com/index.php?topic=5295.msg68622#msg68622 (http://chdk.setepontos.com/index.php?topic=5295.msg68622#msg68622)
Don't expect too much reliability, it can crash the camera easily.
This actually runs pretty well on my A1200 & G10 - once I change lines 256/257 to adjust for not having a video button. With a little cleanup of the GUI (using Lua drawing maybe) and some additional code to allow the zoom to operate, this could be quite useful. Especially now that we can enable native calls without a special build.
-
By request, merged sx40 discussion into this thread.
-
I took a few minutes to play with fudgey's script and convert the GUI (attached below). Works with cameras that have a video button (if they are in video mode) and with cameras without a seperate video button. It also adds the ability to use the zoom while the script is running.
It runs well on my G10, A1200 and SD940. As a bonus, on the A1200 & SD940, adjusting the aperture engages the ND filter as those cameras do not have an adjustable aperture. (Note: that if you run the script while not in video mode, the exposure adjusts but the ND filter does not engage when Av is adjusted).
(https://chdk.setepontos.com/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FGmddxkA.png&hash=1d35358cfe1a72c207145844f4e2a87a)
(https://chdk.setepontos.com/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FI9JEQ1Q.png&hash=34649b2b5ce633f2880a9dd3219f344a)
Sadly, with the same script loaded on my SX50 it does not want to stay in AELock - resetting the exposure a few seconds after I adjust it manually. The SX50 also locked up when I ran the ISO up to 3200. I did not see either of these issues with my other cameras so YMMV.
Update : The initialization of the Tv, Av, & Sv values is still not quite correct. To be safe, I think that you need to adjust them each up & down prior to starting recording.
-
Sadly, with the same script loaded on my SX50 it does not want to stay in AELock - resetting the exposure a few seconds after I adjust it manually.
Does it make a difference if you lock AE using the Canon UI before recording?
-
Does it make a difference if you lock AE using the Canon UI before recording?
Not sure that Canon AE lock is an option in video mode - nothing about it in the manual and I can't seem to convince it otherwise.
Using a half press and the UP button on the mode dial engages AEL for the next still shot. Activating video recording in that mode seems to just reset it.
-
Using a half press and the UP button on the mode dial engages AEL for the next still shot. Activating video recording in that mode seems to just reset it.
It should be available in movie mode (mode dial explicitly set to movie mode), but they don't call this AE lock, see manual page 110.
-
It should be available in movie mode (mode dial explicitly set to movie mode), but they don't call this AE lock, see manual page 110.
Well what do you know - there it is! My only excuse is that it's not actually "my" camera :-[
And when locked that way, the rest of the script performs just like my other cameras. So I'm guessing the call to
call_event_proc("PT_DoAELock")needs something different for the SX50?
As a side note, it appears that the SX50 port does not capture the rotary jog dial correctly. Turning the dial in <ALT> or script modes still causes the Canon OSD exposure offset needle gage to move. I'll take a look at that.
-
So I'm guessing the call to
call_event_proc("PT_DoAELock")needs something different for the SX50?
Yes, several event procedures changed names in newer cameras, this cam has "SS.DoAELock".
-
So I'm guessing the call to
call_event_proc("PT_DoAELock")needs something different for the SX50?
Yes, several event procedures changed names in newer cameras, this cam has "SS.DoAELock".
"My" sx50 seems to have gone off on a "walk about". When it returns, I'll see of I can use return codes to figure out which event proc works for which camera. Is there any other way to figure out which one to use?
-
Yes, several event procedures changed names in newer cameras, this cam has "SS.DoAELock".
That works for the SX50. Thanks.
A grep through the funcs_by_name.csv files show either DoAELock or PT_DoAELock. I have the script trying both .. but issuing PT_DoAELock seems to hang the SX50 sometimes. Would be nice to have a different way to pick which function to call.
-
Yes, several event procedures changed names in newer cameras, this cam has "SS.DoAELock".
That works for the SX50. Thanks.
A grep through the funcs_by_name.csv files show either DoAELock or PT_DoAELock. I have the script trying both .. but issuing PT_DoAELock seems to hang the SX50 sometimes. Would be nice to have a different way to pick which function to call.
C stubs like DoAFLock and UnlockAF, with Lua / uBasic hooks?
Phil.
-
C stubs like DoAFLock and UnlockAF, with Lua / uBasic hooks?
Meaning adding a set_aelock() function that works like set_aflock() ? I like that idea a lot!
Not sure why we have not hit that before? Probably because script writer just pound out the set_xv96() commands before every shot and don't need it ? But for manual control of exposure in video, I guess we do need it now.
-
C stubs like DoAFLock and UnlockAF, with Lua / uBasic hooks?
Meaning adding a set_aelock() function that works like set_aflock() ? I like that idea a lot!
Not sure why we have not hit that before? Probably because script writer just pound out the set_xv96() commands before every shot and don't need it ? But for manual control of exposure in video, I guess we do need it now.
Untested patch adds DoAELock & UnlockAE wrappers and set_aelock function for Lua & uBasic.
Note: I had to add NULL_SUB entries for DoAELock and UnlockAE for many older VxWorks cameras so it will not work on those.
Phil.
-
Untested patch adds DoAELock & UnlockAE wrappers and set_aelock function for Lua & uBasic.
Note: I had to add NULL_SUB entries for DoAELock and UnlockAE for many older VxWorks cameras so it will not work on those.
Wow - that was quick. Nice to be able to update the sigfinder rather than hand edit all those files!
Works well on my standard cameras - the sx50 is out "birding" again so I'll check it later.
Updated test script attached - I added set_aelock() and commented out the related event proc calls. There's a user @param to let you selectively enable the function for testing purposes. I'll remove that later when the script goes into general release.
Script still needs a little work - initial values for Tv, Sv, Av from get_xv96() are not the values the video mode uses so you have to adjust the controls to sync. Maybe I'll just default the initial values via a manual overrided to 1/100, f2.8 and ISO100 so that everything starts sync'd. Could make the values @params I guess.
Also need to add a @param value for Maximum ISO - let users with cams like the SX50 that crash at ISO3200 lock that out in their script.
Other than that, I'm pretty happy with how the script works now. Thanks for turning set_aelock() around so quickly!
Note: I had to add NULL_SUB entries for DoAELock and UnlockAE for many older VxWorks cameras so it will not work on those.
So set_aelock(), like set_aflock(), does not return status. Is it worth adding something so that cameras that point to a NULLSUB return 0 and everything else returns 1 ?
Edit : attachment deleted - see follow post later in this thread for newer version of the script
-
add NULL_SUB entries for DoAELock and UnlockAE for many older VxWorks cameras
The attached patch for finsig_vxworks should make the above unnecessary.
-
add NULL_SUB entries for DoAELock and UnlockAE for many older VxWorks cameras
The attached patch for finsig_vxworks should make the above unnecessary.
Thanks, I'll merge that with my changes and add it to 1.3.
Should be added to 1.2 as well for compatibility, might wait a bit so it can be tested more.
Edit Added to 1.3 in revision 3250.
Phil.
-
Updated videxp3.lua script. Check for & requires latest build ( 3250 or better ) and 1.3.0.
I think this is pretty much complete.
Update : attachment deleted - see followup post (below).
-
Updated script that correctly centers the GUI for cameras with 480 pix screens (instead of assuming 360 pix).
Changes (including a small code optimization) courtesy of msl (http://chdk.setepontos.com/index.php?action=profile;u=687).
link > videxp3.lua (https://app.box.com/files/0/f/0/1/f_12028501884)
Edit : Updated to v3.2 - small cosmetic changes.
Edit 2 : moved script to a download link - updated to v3.3 to include philmoz's fixes
-
Created a wiki page for the script : Manual Exposure Control for Video Recording (http://chdk.wikia.com/wiki/Manual_Exposure_Control_for_Video_Recording)
As this script relies on native calls and is therefore somewhat experimental, there is a section called : Tested Cameras (http://chdk.wikia.com/wiki/Manual_Exposure_Control_for_Video_Recording#Tested_Cameras). Hopefully people will update that section with information on how the scripts worked on their cameras.
-
Created a wiki page for the script : Manual Exposure Control for Video Recording (http://chdk.wikia.com/wiki/Manual_Exposure_Control_for_Video_Recording)
As this script relies on native calls and is therefore somewhat experimental, there is a section called : Tested Cameras (http://chdk.wikia.com/wiki/Manual_Exposure_Control_for_Video_Recording#Tested_Cameras). Hopefully people will update that section with information on how the scripts worked on their cameras.
Wow! I just saw this script on the facebook! O have to test that, when I'll get my camera in my hands!
PS - I am very happy to see somebody finds my lua drawings usefull :)
-
Updated script that correctly centers the GUI for cameras with 480 pix screens (instead of assuming 360 pix).
Changes (including a small code optimization) courtesy of msl (http://chdk.setepontos.com/index.php?action=profile;u=687).
Edit : Updated to v3.2 - small cosmetic changes.
The 'build' check fails for custom builds done outside an SVN directory (bi.build_revision = 0) - the build variable ends up 'nil' and the compare fails. May apply to CHDK-Shell builds; but I haven't tested it.
I found the 'Press any key to start' message a bit confusing - it doesn't actually start recording, it just exits the help screen.
On the G12, when I start video recording with the script, the camera crashes after a few seconds - haven't investigated yet. Will try my other cameras later.
Phil.
Edit: On the G12 the camera attempts to do an exposure calculation when the 'shoot_full' button is pressed to start the recording. If the selected values (Tv/Av/Sv) are 'out of range' the camera crashes.
The following changes seem to fix the problem:
...
set_aelock(1) -- go to manual exposure mode
if (vbutton ~= 1) then press("shoot_half") sleep(1000) end -- half press to let cam calc exp before override
tv96=call_event_proc("SetAE_ShutterSpeed",tv96target)
...
if is_pressed("set") then
if ( vbutton == 1 ) then press("video") sleep(1000) release("video") sleep(1000)
else click("shoot_full") end
---
Also noticed that the sv96max value is not used, and av_table and sv_table are defined twice with different values.
-
The 'build' check fails for custom builds done outside an SVN directory (bi.build_revision = 0) - the build variable
ends up 'nil' and the compare fails. May apply to CHDK-Shell builds; but I haven't tested it.
The check is there for the benefit of the casual user to make sure they don't try to run the script without a current versions of CHDK. If the CHDK build revision is not setup correctly for non-svn builds, I'm not sure what to do about that other than assume that anyone building their own CHDK can also edit the script & remove the check?
I found the 'Press any key to start' message a bit confusing - it doesn't actually start recording, it just exits the help screen.
Good point - I'll change that.
On the G12, when I start video recording with the script, the camera crashes after a few seconds - haven't investigated yet. Will try my other cameras later.
Edit: On the G12 the camera attempts to do an exposure calculation when the 'shoot_full' button is pressed to start the recording. If the selected values (Tv/Av/Sv) are 'out of range' the camera crashes.
The following changes seem to fix the problem:
I've noticed that my cams do the exposure check too - it actually makes setting the default values basically useless other than for (in theory) setting them to valid values intially. I think I found the same thing you did and tried to fix it that way.
...
set_aelock(1) -- go to manual exposure mode
if (vbutton ~= 1) then press("shoot_half") sleep(1000) end -- half press to let cam calc exp before override
tv96=call_event_proc("SetAE_ShutterSpeed",tv96target)
...
if is_pressed("set") then
if ( vbutton == 1 ) then press("video") sleep(1000) release("video") sleep(1000)
else click("shoot_full") end
---
Did you intentionally leave the shoot_half set and not release it until the ckick("shoot_full") ? And I guess I'll check my sx50 and see if cameras with video buttons need this too.
Also noticed that the sv96max value is not used, and av_table and sv_table are defined twice with different values.
Whoops .. mixed up versions there. Fixed in the next update.
-
On the G12, when I start video recording with the script, the camera crashes after a few seconds - haven't investigated yet. Will try my other cameras later.
Edit: On the G12 the camera attempts to do an exposure calculation when the 'shoot_full' button is pressed to start the recording. If the selected values (Tv/Av/Sv) are 'out of range' the camera crashes.
The following changes seem to fix the problem:
I've noticed that my cams do the exposure check too - it actually makes setting the default values basically useless other than for (in theory) setting them to valid values intially. I think I found the same thing you did and tried to fix it that way.
Pressing and holding the shoot_half seems to fix both issues - the camera does it's calculation, and then the overrides take effect.
...
set_aelock(1) -- go to manual exposure mode
if (vbutton ~= 1) then press("shoot_half") sleep(1000) end -- half press to let cam calc exp before override
tv96=call_event_proc("SetAE_ShutterSpeed",tv96target)
...
if is_pressed("set") then
if ( vbutton == 1 ) then press("video") sleep(1000) release("video") sleep(1000)
else click("shoot_full") end
---
Did you intentionally leave the shoot_half set and not release it until the ckick("shoot_full") ? And I guess I'll check my sx50 and see if cameras with video buttons need this too.
Yes, pressing and releasing 'shoot_half' doesn't stop the crash - if it's released, then the subsequent 'shoot_full' tries to do the exposure calc again.
The solution isn't a complete fix - if I stop the video recording by pressing 'Set', the start another one (without stopping the script) I get the same crash.
Phil.
-
The solution isn't a complete fix - if I stop the video recording by pressing 'Set', the start another one (without stopping the script) I get the same crash.
So I need to add the half press stuff inside the is_pressed("set") condition? Or maybe reassert the half press after each time we stop recording?
Making me a little nervous about cameras with video buttons here - I'll go see if "my" sx50 has returned home for its day of birding.
Update : sx50 is happy with the changes - although it gets "unhappy" if you try to press("video") when the mode dial is not set to video mode. This works when CHDK is not loaded - I guess for now the warning about not being in video mode applies.
-
The solution isn't a complete fix - if I stop the video recording by pressing 'Set', the start another one (without stopping the script) I get the same crash.
So I need to add the half press stuff inside the is_pressed("set") condition? Or maybe reassert the half press after each time we stop recording?
Making me a little nervous about cameras with video buttons here - I'll go see if "my" sx50 has returned home for its day of birding.
Update : sx50 is happy with the changes - although it gets "unhappy" if you try to press("video") when the mode dial is not set to video mode. This works when CHDK is not loaded - I guess for now the warning about not being in video mode applies.
On the G12, releasing AE lock and re-doing the shoot_half between videos stops the crash.
My hacked up version attached.
Next problem - on the G1X the camera crashes when the script ends after the AE unlock :(
Edit: SX40 mostly works (start, stop, adjust exposure); but crashes if ISO set above 1250.
Edit2: After hacking in support for 'press("video")' for the IXUS310, the script works; but has the same problem as the G1X - crashes on exit after releasing the AE lock.
Phil.
-
On the G12, releasing AE lock and re-doing the shoot_half between videos stops the crash.
My hacked up version attached.
Next problem - on the G1X the camera crashes when the script ends after the AE unlock :(
Somehow, I just knew it was too good to be true when all four of my cams - spanning four years of release dates - all worked with the first version of the script.
Thanks for looking at this!
-
Tested with SX130 IS 101C my build from trunk 3258 and videxp3.lua (the last one)
Tested only indoor with ISO till 1600.No crash occured during tests
Exelent, brilliant job.Thanks very very much to all made this possible.
Pier
-
Hey everyone, i tried this script in my sx150is today and i am getting stuck at ": 225 : native calls disabled"
on sx150is-100a-1.3.0-3259, can you guys please if you can help me out on this? And thank you for making this possible. (if not for my own cam but others :))
-
One thing i do not like on my canons(a590is, sx130): one cannot adjust default-video-exposure. In nikon p50 i can adjust that value. I dont like to adjust that value every time when starting to shoot. depending the situation i have the feeling than canon-videos are overexposing. Yes i know sometime reducing contrast and saturation helps.
had to adjust exposure for this 3dstereovideo(still unofficial-its SDM186-with moviesynch/sensorcable used to adjust synch-lasers were too speedy in that shoot)
www.3dmusic.ch (http://www.3dmusic.ch) or channel www.3dmedia.ch (http://www.3dmedia.ch) more will come.
will start testing a590is. hesitate sx130 since i only have two cams...!
Confusing:
: for CHDK v1.3.0 or greater
i see-some threads earlier- that someone succesfully tested SX130. but there is neighter for SX130 nor A590is version 1.3.0 available.
both still 1.2.0.
-
Hey everyone, i tried this script in my sx150is today and i am getting stuck at ": 225 : native calls disabled"
on sx150is-100a-1.3.0-3259, can you guys please if you can help me out on this? And thank you for making this possible. (if not for my own cam but others :))
Go to the CHDK Miscellaneous menu and set Enable Lua Native Calls.
-
i see-some threads earlier- that someone succesfully tested SX130. but there is neighter for SX130 nor A590is version 1.3.0 available.
both still 1.2.0.
http://mighty-hoernsche.de/trunk/ (http://mighty-hoernsche.de/trunk/)
-
-
Go to the CHDK Miscellaneous menu and set Enable Lua Native Calls.
wow, i should have looked around, thanks! It's working flawlessly on my SX150IS, thanks alot.
i see-some threads earlier- that someone succesfully tested SX130. but there is neighter for SX130 nor A590is version 1.3.0 available.
both still 1.2.0.
http://mighty-hoernsche.de/trunk/ (http://mighty-hoernsche.de/trunk/)
This, v1.3.0 are the developer/unstable versions listed in the wikia.
-
This, v1.3.0 are the developer/unstable versions listed in the wikia.
Yes they are. These new versions contain new features required by the script. Don't worry about the term "unstable" - these builds are very usable and you should not have any problems.
-
An SDM user has asked if this feature is supported.
It is not and I would be very reluctant to add it.
Quite simply, why should it be added ... because it can be or because it is genuinely useful ?
Consider this from a Pro canon 5d user :-
"in filmmaking, your shutter speed will always be half your frame rate for normal film capture.
Anything more or less will reduce the filmic look of your footage"
http://kriskoster.com/2010/08/optimising-your-5d-mark-ii-for-filmmaking/ (http://kriskoster.com/2010/08/optimising-your-5d-mark-ii-for-filmmaking/)
High shutter speeds produce a jerky effect, stopping-down the aperture reduces sharpness.
Part 6: Shutter Speed & FPS on Vimeo (http://vimeo.com/19603537)
-
This is very exciting! Has anyone tested this script out on an Elph 300HS (Ixus 220)?
-
I tested this out on my Elph 300HS(Ixus 220) and sadly it only works until the video recording starts. Then the settings no longer work and auto exposure kicks into gear. Can someone help me fix the script so that it can work?
-
Can someone help me fix the script so that it can work?
Which script is that? Link it or attach it.
-
Can someone help me fix the script so that it can work?
Which script is that? Link it or attach it.
Based on a PM thatmojo43 sent me, I believe he is talking about this : http://chdk.setepontos.com/index.php?topic=5295.msg107544#msg107544 (http://chdk.setepontos.com/index.php?topic=5295.msg107544#msg107544)
https://app.box.com/s/n0ja0wbii7coiz06mdw1 (https://app.box.com/s/n0ja0wbii7coiz06mdw1)
-
Based on a PM thatmojo43 sent me, I believe he is talking about this : http://chdk.setepontos.com/index.php?topic=5295.msg107544#msg107544 (http://chdk.setepontos.com/index.php?topic=5295.msg107544#msg107544)
I see. Apparently this camera unlocks AE when recording starts. What happens if set_aelock(1) is repeated (once) after that...?
-
Based on a PM thatmojo43 sent me, I believe he is talking about this : http://chdk.setepontos.com/index.php?topic=5295.msg107544#msg107544 (http://chdk.setepontos.com/index.php?topic=5295.msg107544#msg107544)
I see. Apparently this camera unlocks AE when recording starts. What happens if set_aelock(1) is repeated (once) after that...?
Attached script puts a set_aelock(1) after a full press / video button press.
@mojo43 : please try it and see if that helps ?
-
Attached script puts a set_aelock(1) after a full press / video button press.
Does not seem to help much on the ixus115 :(
-
None of the scripts work with SX40 HS, even if the maximum ISO is under 1250.... Any possible ways to run it on SX40HS??
-
Thanks so much, I will try it later today when I get back home. Sorry that I didn't respond earlier. I am not sure why, but I didn't receive a notification that anyone responded to the thread. I will let you know soon!
Based on a PM thatmojo43 sent me, I believe he is talking about this : http://chdk.setepontos.com/index.php?topic=5295.msg107544#msg107544 (http://chdk.setepontos.com/index.php?topic=5295.msg107544#msg107544)
I see. Apparently this camera unlocks AE when recording starts. What happens if set_aelock(1) is repeated (once) after that...?
Attached script puts a set_aelock(1) after a full press / video button press.
@mojo43 : please try it and see if that helps ?
-
I tried the script and unfortunately it is still not working. It is like the exposure will change for a brief second and then the autoexposure kicks in. Again the script works perfectly while not recording. I did find something out. The fast EV setting turns off autoexposure while recording video. I manually control the exposure, but at least the exposure is locked... Any other ideas?
Thanks in advance!
-
The solution isn't a complete fix - if I stop the video recording by pressing 'Set', the start another one (without stopping the script) I get the same crash.
So I need to add the half press stuff inside the is_pressed("set") condition? Or maybe reassert the half press after each time we stop recording?
Making me a little nervous about cameras with video buttons here - I'll go see if "my" sx50 has returned home for its day of birding.
Update : sx50 is happy with the changes - although it gets "unhappy" if you try to press("video") when the mode dial is not set to video mode. This works when CHDK is not loaded - I guess for now the warning about not being in video mode applies.
On the G12, releasing AE lock and re-doing the shoot_half between videos stops the crash.
My hacked up version attached.
Next problem - on the G1X the camera crashes when the script ends after the AE unlock :(
Edit: SX40 mostly works (start, stop, adjust exposure); but crashes if ISO set above 1250.
Edit2: After hacking in support for 'press("video")' for the IXUS310, the script works; but has the same problem as the G1X - crashes on exit after releasing the AE lock.
Phil.
After more testing I found the SX40 also crashed on exit after releasing AE lock.
However I've made some progress on fixing this.
Adding
call_event_proc("TerminateAdjustmentSystem")
to the restore() function before calling set_aelock(0) stops the G1X and SX40 from crashing (IXUS310 still crashes a lot).
This still works on the G12 (which did not have the exit crash) - interested to see if it has any effect on other cameras.
Updated script (v3.4) attached, this also gets the initial Tv, Av & Sv values at startup and restores them on exit.
Phil.
-
After more testing I found the SX40 also crashed on exit after releasing AE lock.
Is that just in video mode? And if so, in video mode when you have used Tv,Av,Sv overrides? Or does it crash using AE lock in normal image shooting modes?
-
After more testing I found the SX40 also crashed on exit after releasing AE lock.
Is that just in video mode? And if so, in video mode when you have used Tv,Av,Sv overrides? Or does it crash using AE lock in normal image shooting modes?
Just with this script - the cameras appear to need the 'TerminateAdjustmentSystem' call to avoid the crashing.
So probably not directly related to AE lock.
Phil.
-
the cameras appear to need the 'TerminateAdjustmentSystem' call to avoid the crashing.
A question: do the registration functions initialize something vital, or could the used event procedures work without them when called directly (by address)?
-
the cameras appear to need the 'TerminateAdjustmentSystem' call to avoid the crashing.
A question: do the registration functions initialize something vital, or could the used event procedures work without them when called directly (by address)?
I tried using the event procs directly on the G1X; but the camera crashes straight away.
Haven't investigated to see what the crash is, or tried other cameras yet.
Phil.
-
I tried using the event procs directly on the G1X; but the camera crashes straight away.
Haven't investigated to see what the crash is, or tried other cameras yet.
Thx, looks like subject of further research then...
-
... could the used event procedures work ... when called directly (by address)?
To answer my question, yes, they do work, but they need to be called with the 'even procedure' parameter passing method (i.e. call_event_proc() ). Registering them with RegisterEventProcedure (using their name and address) is possible.
An interesting find: the script does work on the ixus115 in its 'high speed' movie mode (this is one of the few dedicated movie modes on this camera, unfortunately it doesn't have a regular movie mode).
-
... could the used event procedures work ... when called directly (by address)?
To answer my question, yes, they do work, but they need to be called with the 'even procedure' parameter passing method (i.e. call_event_proc() ). Registering them with RegisterEventProcedure (using their name and address) is possible.
An interesting find: the script does work on the ixus115 in its 'high speed' movie mode (this is one of the few dedicated movie modes on this camera, unfortunately it doesn't have a regular movie mode).
I did some more testing on the G1X, calling the event procs directly with C & Lua wrappers works; but only if FA.Create and InitialiseAdjustmentSystem are called first (and TerminateAdjustmentSystem called on exit).
If these are removed the camera crashes straight away.
Phil.
-
@philmoz
I am just wondering, have you tested this out on your ixus310hs? If so, does this script work?
-
I did some more testing on the G1X, calling the event procs directly with C & Lua wrappers works; but only if FA.Create and InitialiseAdjustmentSystem are called first (and TerminateAdjustmentSystem called on exit).
If these are removed the camera crashes straight away.
That makes me curious about the romlog. I'd prefer not having to register dozens of event procedures.
-
@philmoz
I am just wondering, have you tested this out on your ixus310hs? If so, does this script work?
No, I have not had any success with the IXUS 310 yet.
Phil.
-
I did some more testing on the G1X, calling the event procs directly with C & Lua wrappers works; but only if FA.Create and InitialiseAdjustmentSystem are called first (and TerminateAdjustmentSystem called on exit).
If these are removed the camera crashes straight away.
That makes me curious about the romlog. I'd prefer not having to register dozens of event procedures.
It's an odd log, no stack or register trace.
It starts with:
ASSERT!! Head.c Line 3985
Occured Time 2014:01:27 11:08:41
ISR : vector=107
ShootConDump:
0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f
0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f
CameraConDump:
07 0a 02 0d 09 01 0f 0f 0f 0f
Followed by the camera log.
Phil.
-
It's an odd log, no stack or register trace.
It starts with:
ASSERT!! Head.c Line 3985
Occured Time 2014:01:27 11:08:41
ISR : vector=107
ShootConDump:
0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f
0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f
CameraConDump:
07 0a 02 0d 09 01 0f 0f 0f 0f
Followed by the camera log.
Frame timing related interrupt service routine...
http://magiclantern.wikia.com/wiki/Register_Map#HEAD_Timers (http://magiclantern.wikia.com/wiki/Register_Map#HEAD_Timers)
I bet it's SetAE_ShutterSpeed related, but I have no idea about the difference the registration functions make...
Anyway, it probably means that some camera models can exhibit strange issues like this.
Is the script usable on the camera (with FA.Create and InitializeAdjustmentSystem)?
edit: looks like it takes 1.5k posts to become blue :haha
-
It's an odd log, no stack or register trace.
It starts with:
ASSERT!! Head.c Line 3985
Occured Time 2014:01:27 11:08:41
ISR : vector=107
ShootConDump:
0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f
0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f
CameraConDump:
07 0a 02 0d 09 01 0f 0f 0f 0f
Followed by the camera log.
Frame timing related interrupt service routine...
http://magiclantern.wikia.com/wiki/Register_Map#HEAD_Timers (http://magiclantern.wikia.com/wiki/Register_Map#HEAD_Timers)
I bet it's SetAE_ShutterSpeed related, but I have no idea about the difference the registration functions make...
Anyway, it probably means that some camera models can exhibit strange issues like this.
Is the script usable on the camera (with FA.Create and InitializeAdjustmentSystem)?
edit: looks like it takes 1.5k posts to become blue :haha
In the testing I've done with version 3.4 (adding TerminateAdjustmentSystem), the G1X works very well. Have not had any issues so far, I can start and stop movies in the script, and start and stop the script itself without problems.
I noticed there is another event proc called SetShutterSpeed, if SetAE_ShutterSpeed is the only issue, maybe SetShutterSpeed will work if called directly. I'll do some more testing when I get a chance.
Phil.
Edit: Doh, I forgot I added event proc calls to get the current Tv, Av and Sv values - these are what was crashing when I removed the FA.Create and InitialiseAdjustmentSystem calls. After adding all the wrappers I now have 3.4 working, on the G1X, with direct calls to the firmware instead of using event procs. Both SetShutterSpeed and SetAE_ShutterSpeed functions work.
-
Attached script puts a set_aelock(1) after a full press / video button press.
Does not seem to help much on the ixus115 :(
Same on the IXUS310 - you can set the Tv, Av & Sv fine before recording; but as soon as the recording starts the camera resets the exposure and ignores the AE lock.
Phil.
-
In the testing I've done with version 3.4 (adding TerminateAdjustmentSystem), the G1X works very well. Have not had any issues so far, I can start and stop movies in the script, and start and stop the script itself without problems.
I noticed there is another event proc called SetShutterSpeed, if SetAE_ShutterSpeed is the only issue, maybe SetShutterSpeed will work if called directly. I'll do some more testing when I get a chance.
Edit: Doh, I forgot I added event proc calls to get the current Tv, Av and Sv values - these are what was crashing when I removed the FA.Create and InitialiseAdjustmentSystem calls. After adding all the wrappers I now have 3.4 working, on the G1X, with direct calls to the firmware instead of using event procs. Both SetShutterSpeed and SetAE_ShutterSpeed functions work.
Is this general enough to work for all cams that currently work without it? (i.e. add to the "official version" of the script?) I'm trying to maintain a "current copy" in my script svn repository and a download link for the wiki page : http://chdk.wikia.com/wiki/Manual_Exposure_Control_for_Video_Recording (http://chdk.wikia.com/wiki/Manual_Exposure_Control_for_Video_Recording)
-
Same on the IXUS310 - you can set the Tv, Av & Sv fine before recording; but as soon as the recording starts the camera resets the exposure and ignores the AE lock.
Phil.
Damn, that's too bad. I wonder what the "fast EV" function is doing to stop the automatic exposure from happening? If I could find that piece of code then maybe it could get implemented in this script.
-
In the testing I've done with version 3.4 (adding TerminateAdjustmentSystem), the G1X works very well. Have not had any issues so far, I can start and stop movies in the script, and start and stop the script itself without problems.
I noticed there is another event proc called SetShutterSpeed, if SetAE_ShutterSpeed is the only issue, maybe SetShutterSpeed will work if called directly. I'll do some more testing when I get a chance.
Edit: Doh, I forgot I added event proc calls to get the current Tv, Av and Sv values - these are what was crashing when I removed the FA.Create and InitialiseAdjustmentSystem calls. After adding all the wrappers I now have 3.4 working, on the G1X, with direct calls to the firmware instead of using event procs. Both SetShutterSpeed and SetAE_ShutterSpeed functions work.
Is this general enough to work for all cams that currently work without it? (i.e. add to the "official version" of the script?) I'm trying to maintain a "current copy" in my script svn repository and a download link for the wiki page : http://chdk.wikia.com/wiki/Manual_Exposure_Control_for_Video_Recording (http://chdk.wikia.com/wiki/Manual_Exposure_Control_for_Video_Recording)
The 3.4 version I posted earlier works on the G12, G1X and SX40; but it adds four event proc calls that should probably be tested on other cameras.
The direct call version also works on these cameras - it requires changes to the core CHDK and new Lua functions. I'll try and post a patch plus the modified script over the next few days.
Phil.
-
mojo43 has found out (http://chdk.setepontos.com/index.php?topic=6341.msg109727#msg109727) that the CHDK 'fast EV switch' (aka EnterToCompensationEVF() )is able to lock exposure while recording. It even makes the script working (on the ixus115), but exposure is way off.
-
mojo43 has found out (http://chdk.setepontos.com/index.php?topic=6341.msg109727#msg109727) that the CHDK 'fast EV switch' (aka EnterToCompensationEVF() )is able to lock exposure while recording. It even makes the script working (on the ixus115), but exposure is way off.
I was trying to use this in the IXUS 310; but so far no luck.
It works when starting video recording via the Canon UI; but not when started with the script.
This could be related to how I had to 'enable' the Video button on the 310 - it's a touch screen button, so I had to use a call to PostLogicalEventToUI in kbd.c.
Phil.
-
It works when starting video recording via the Canon UI; but not when started with the script.
Actually, I was messing with entering/exiting ALT mode while running the script (fortunately it still works), and modifying 'fast EV' while recording made the exposure lock, and the script controls started to take effect. I have not tried to modify the script yet.
-
The 3.4 version I posted earlier works on the G12, G1X and SX40; but it adds four event proc calls that should probably be tested on other cameras.
The direct call version also works on these cameras - it requires changes to the core CHDK and new Lua functions. I'll try and post a patch plus the modified script over the next few days.
Phil.
Hello Phil, I tested the version of the script on SX40 HS. I found out that in order to enable and run the script, camera should be set in video mode via the ring dial, after that we can run the script. The script does work but the problem is I can't find my recorded videos that I recorded with the script in the play mode of my camera. what's wrong?
Thanks in advance.
P.S: Do you have any fast and brief tutorials in order to learn how to improve this script?
-
The 3.4 version I posted earlier works on the G12, G1X and SX40; but it adds four event proc calls that should probably be tested on other cameras.
The direct call version also works on these cameras - it requires changes to the core CHDK and new Lua functions. I'll try and post a patch plus the modified script over the next few days.
Phil.
Hello Phil, I tested the version of the script on SX40 HS. I found out that in order to enable and run the script, camera should be set in video mode via the ring dial, after that we can run the script.
Well, the help screen at the start does warn you about this (unless you turned it off).
The script does work but the problem is I can't find my recorded videos that I recorded with the script in the play mode of my camera. what's wrong?
Did you press the 'Set' button to actually start video recording in the script?
Phil.
-
Well, the help screen at the start does warn you about this (unless you turned it off).
[/quote]
Well I had thought the "movie mode" means "press the movie recording button :p"....
Did you press the 'Set' button to actually start video recording in the script?
Phil.
I pressed the func/set and the adjusting value box of exposure appeared but didn't record anything :( .
-
Well, the help screen at the start does warn you about this (unless you turned it off).
Well I had thought the "movie mode" means "press the movie recording button :p"....
Did you press the 'Set' button to actually start video recording in the script?
Phil.
I pressed the func/set and the adjusting value box of exposure appeared but didn't record anything :( .
The first button press (any button) just removes the help screen and then starts the script proper.
The script does not automatically start video recording - you have to press 'Set' to then start / stop recording while the script is running.
When video is recording you will see the recorded time at the top of the screen.
Phil.
-
Attached is a patch against 1.3 for using direct calls instead of event procs.
Also attached is an updated version of the script (v3.5) that calls the new Lua functions (get_aperture, get_shutter, get_iso, set_aperture, set_shutter, set_iso).
This only applies to DryOS cameras (unless you want to manually find the relevant firmware functions).
Phil.
-
Works fine on my cameras. That's a good enhancement. Thanks for that.
msl
-
I was playing around with a focussing script to focus while movie recording and I noticed that if I call the fast ev call in the script the exposure will stay locked. I am going to try to mod the script to do the same and I bet you that will work on the ixus 310. I will keep you posted.
-
Attached is a patch against 1.3 for using direct calls instead of event procs.
Also attached is an updated version of the script (v3.5) that calls the new Lua functions (get_aperture, get_shutter, get_iso, set_aperture, set_shutter, set_iso).
Tried on 2 cameras, works on both (a3400, ixus115). Looks like those small changes did the trick.
Some issues:
- Recording starts with "optimal" values, not the ones shown on screen (could be a timing issue)
- An attempt to change Av usually (but not always) locks up both cams (neither has adjustable iris), probably depends on lighting conditions
-
- An attempt to change Av usually (but not always) locks up both cams (neither has adjustable iris), probably depends on lighting conditions
On my non-adjustable iris cameras, and the original script, adjusting Av would engage the ND filter (or disengage). The actual code 'scrolls' though the Av range looking for a "lock". That might have to be changed.
-
How do I apply the patch?
-
How do I apply the patch?
You need to be able to compile CHDK from scratch. You apply the patch to the source code using the "patch" command on the command line or a suitable GUI tool.
If you tell me your camera & firmware version I can post a patched version for you.
-
Wow thanks! I am using the elph 300 HS/ Ixus 220 HS firmware 1.00C
-
Wow thanks! I am using the elph 300 HS/ Ixus 220 HS firmware 1.00C
Here you go : https://app.box.com/s/e8pff7qdpjd2le35faov
Seems like you've been looking for this for over a year.
-
- An attempt to change Av usually (but not always) locks up both cams (neither has adjustable iris), probably depends on lighting conditions
On my non-adjustable iris cameras, and the original script, adjusting Av would engage the ND filter (or disengage). The actual code 'scrolls' though the Av range looking for a "lock". That might have to be changed.
Applied philmoz's patch and tested on A1200. Adjusting Av now hangs the camera as srsa_4c reported.
Original script on patched build still works when adjusting Av ( ND filter goes in and out).
-
Wow it finally works while recording, thanks! I have the same thing to report. It hangs while adjusting the AV. Thanks so much though!
-
- An attempt to change Av usually (but not always) locks up both cams (neither has adjustable iris), probably depends on lighting conditions
On my non-adjustable iris cameras, and the original script, adjusting Av would engage the ND filter (or disengage). The actual code 'scrolls' though the Av range looking for a "lock". That might have to be changed.
Applied philmoz's patch and tested on A1200. Adjusting Av now hangs the camera as srsa_4c reported.
Original script on patched build still works when adjusting Av ( ND filter goes in and out).
All my cameras have a real aperture so I can't test this - anything in the ROMLOG of interest?
Phil.
-
All my cameras have a real aperture so I can't test this - anything in the ROMLOG of interest?
ASSERT!! IrisController.c Line 121
Occured Time 2014:02:02 11:45:07
Task ID: 12451867
Task name: PhySw
-
All my cameras have a real aperture so I can't test this - anything in the ROMLOG of interest?
ASSERT!! IrisController.c Line 121
Occured Time 2014:02:02 11:45:07
Task ID: 12451867
Task name: PhySw
What happens if you leave the calls to FA.Create and InitialiseAdjustmentSystem in the 3.5 script version?
I'm wondering if it is setting some status that causes some errors to be ignored (I think FA means Factory Adjust).
It might be better to replace the Av control with an ND control for cameras without an iris.
Phil.
-
I'm wondering if it is setting some status that causes some errors to be ignored (I think FA means Factory Adjust).
The equivalent-looking part of the ixus30 firmware suggests a failed check on "!fMoving".
It might be better to replace the Av control with an ND control for cameras without an iris.
+1
-
The current script results is abrupt jumps in exposure when making adjustments.
I wonder if it would be possible to adjust the values gradually over time, in smaller increments, until the target value is reached.
This should be possible for Tv, may be possible for Sv; but probably not for Av.
Just throwing out an idea in case anyone has some time to tinker with it.
Phil.
-
My test on SX130IS.Trunk-3347 patched with philmoz's videxp.patch and videxp3.5.lua script.Adjusting Av not hangs the camera, adjusting Tv and Sv also not hangs the camera.I do not reached the reasonable up/down limits in daylight conditions.Great job!
-
works on both (a3400, ixus115)
I have played a little more on the a3400, and I found that something isn't right. When touching the ISO control, sensitivity appears to become over-boosted, resulting in visible noise at all ISO settings.
-
I've done some testing with an A810 which doesn't have a controllable aperture or ND filter. I used version 3.3 of the script from the CHDK wiki page and firmware a810-100e-1.3.0-3429.
On this camera the aperture is a function of the zoom position and the camera will crash if you set the aperture parameter to any other value than the current actual aperture. You'll see this value if you half-press to focus.
With the script running, the Tv and Sv values don't actually take effect when you press SET to start the recording, but if you change either value once it's recording, it begins to work as expected. I managed to capture individual frames of very fast moving targets with hardly any motion blur but unfortunately there is quite a bit of noise despite using low ISO values and bright lights. Maybe it's just pushing the Digic4 a little beyond its abilities.
Thanks to the hard work of all the developers though! It's incredible what the CHDK and scripts allows me to do with entry level cameras.
-
I've done some testing with an A810 which doesn't have a controllable aperture or ND filter.
It almost certainly has an ND filter. The CHDK port is set up for a camera with an ND filter and without and adjustable aperture.
On this camera the aperture is a function of the zoom position and the camera will crash if you set the aperture parameter to any other value than the current actual aperture.
I assume you are talking about the script controls? No CHDK aperture controls (menu overrides or script functions) should be available since the port is set up for no adjustable aperture. It's not surprising that aperture control functions crash on a camera without an adjustable aperture.
-
No CHDK aperture controls (menu overrides or script functions) should be available since the port is set up for no adjustable aperture. It's not surprising that aperture control functions crash on a camera without an adjustable aperture.
From the script's perspective, it's technically an override of the Av setting. On my A1200, changing the setting while the script is running causes the ND filter to engage / disengage. On other cameras, it may very well cause crashes - this is script is definitely "way out there" on the basis of asking the camera to do something it was never really intended to do.
-
Don't get me wrong ... I was blown away that the script also worked for my A810 and just thought I'd post the results. Controlling the shutter speed and ISO during video recording was exactly what I needed and more than you could ask of this particular camera.
-
From the script's perspective, it's technically an override of the Av setting. On my A1200, changing the setting while the script is running causes the ND filter to engage / disengage. On other cameras, it may very well cause crashes - this is script is definitely "way out there" on the basis of asking the camera to do something it was never really intended to do.
Calling the actual ND event procs ("PutInNdFilter", "PutOutNdFilter", names may vary between camera generations...) could be an alternative.
The CHDK ND filter functions won't do it, because they are delayed until half shoot.
-
Updated videxp3.lua script. Check for & requires latest build ( 3250 or better ) and 1.3.0.
I think this is pretty much complete.
Could this be extended to
* allow for re-focusing during video (as CHDK allows)?
Or is it difficult?
-
Could this be extended to allow for re-focusing during video (as CHDK allows)?
I actually have no idea. I hardly ever use video on my P&S cameras and when I do, I stay away from any CHDK setting after seeing what getting the wrong quality setting can do to the results. We could experiment with calling set_focus() but results are so variable between cameras in normal still picture mode that I have to wonder what the chances are in video mode that it will do anything (other than crash). Some of the focus_controller event proc might be interesting too.
Maybe somebody else has tried this?
-
I actually have no idea. I hardly ever use video on my P&S cameras and when I do, I stay away from any CHDK setting after seeing what getting the wrong quality setting can do to the results. We could experiment with calling set_focus() but results are so variable between cameras in normal still picture mode that I have to wonder what the chances are in video mode that it will do anything (other than crash). Some of the focus_controller event proc might be interesting too.
Maybe somebody else has tried this?
IMHO a simple AFL (via shoot_half) is enough, taking in account the "set_focus()" or others "focus_controller event proc" issues with some new cams.
BTW this script deserves new developments.
EDIT
I added these lines at the end of "Main Program" routine (red ones) and the AFL seems to works fine, even if the script crashes often as before.
The focus will be locked to the framed subject at every half shoot during video record.
Also added a sort of key repeat to change values.
.........while true do
show_values(tv96, av96, sv96)
repeat
draw.overdraw()
wait_click(200)
until not(is_key("no_key"))
if is_pressed("set") then
if ( vbutton == 1 ) then press("video") sleep(1000) release("video") sleep(1000)
else click("shoot_full") end
elseif is_pressed("left") then
if gui_index > 0 then gui_index = gui_index - 1 end
elseif is_pressed("right") then
if gui_index < 2 then gui_index = gui_index + 1 end
elseif ( is_pressed("up")) then -- key repeat
while(is_pressed("up")) do adjust_value(gui_index, 1) sleep(200) end
elseif ( is_pressed("down")) then -- key repeat
while(is_pressed("down")) do adjust_value(gui_index, -1) sleep(200) end
elseif ( is_key("zoom_in")) then
press("zoom_in")
while(is_pressed("zoom_in")) do sleep(20) end
release("zoom_in")
elseif ( is_key("zoom_out")) then
press("zoom_out")
while(is_pressed("zoom_out")) do sleep(20) end
release("zoom_out")
elseif ( is_pressed("shoot_half")) then --half press to AFL
press("shoot_half")
while(is_pressed("shoot_half")) do set_aflock(1) sleep(1000) end
adjust_value(gui_index, -1) -- restore AE after AFL
adjust_value(gui_index, 1)
release("shoot_half")
elseif (is_pressed("menu") or is_pressed("shoot_full")) then break
end
end
restore()
-
I have played a little more on the a3400, and I found that something isn't right. When touching the ISO control, sensitivity appears to become over-boosted, resulting in visible noise at all ISO settings.
I have also noted the same problem on my S110.
I would be grateful if I could just lock the shutter speed and let Aperture and ISO be in auto mode; that is in Shutter Priority Mode. It will reduce motion artifact and help control flickering under artificial lighting.
-
I would be grateful if I could just lock the shutter speed and let Aperture and ISO be in auto mode; that is in Shutter Priority Mode. It will reduce motion artifact and help control flickering under artificial lighting.
As you can see if you read through this forum thread, this script is very experimental and does not work well on some cameras. Unless someone does a whole lot more work, possibly involving significant code changes to CHDK as well, that is not going to change any time soon.
On a related note, CHDK exposure overrides don't give you the equivalent of shutter priority or aperture priority modes. When you override one parameter, the others remain under Canon firmware control, which is unaware of the changed value. Unless you override all three parameters, you are unlikely to get the correct exposure.
-
Hi!
Is there a script which allows to set the frames per second video recording. for example. 1fps or less?
This would serve to direct video recording as Time Lapse (intervalometer).
Cameras A810, A3300 have similar functions, called "miniature" but it has blurs the top and bottom of the frame.
Best Regards
-
Is there a script which allows to set the frames per second video recording. for example. 1fps or less?
AFAIK - no. Sorry.
-
(At first I could't get the script working, I missed the part where it says to "enable native calls", eventually I found it on the web, a nice option in the chdk menu, I modified the wiki a bit, perhaps it's better to include the note directly after the text, because somehow I completely missed it).
Anyway, I am a little bit excited about this script and it's capabilities, it seems quite cool. I look forward to testing this script some more tomorrow. I plan to use this script for "low light" conditions. I will also try the "night mode" of the powershot sx50 hs, and something else forgot what it was I guess P mode. Yeah and see if night mode matters for video, I think it does a little bit, yeah and then compare it towards each other.
I have already tested the script a bit, and it does seem to be capable of "beating" the default software of cannon. The video appears to be more bright and thus more can be seen under low light conditions. The video/image does get a bit more grainy though.
My batteries are all dead, fortunately I have a power cable so it can run of the wall socket.
I tested the script some more, trying to read the monitor text and such.
I don't quite understand, shutter speed 10.000 ? or av 12... it all seems somewhat overkill ?
I still tried it though... I hope it doesnt damage my camera or chip. The powershot sx50 hs camera repeatedly shuts off/down under those parameters, so perhaps it's shutting down to prevent damage to the camera.
At first I thought maybe it was because the battery was dead, but it's not... it's shutting down forcefully.
Sometimes the recording will also continue, but the controls will hang. I think these videos are lost, they are not saved... so if it hangs or crashes, video is lost. That's kinda a shame, and makes this script a bit risky.
Also the adjusting the values during "video time/recording time" is kinda cool... but the camera seems to auto adjust exposure/av/tv/shutter speed or whatever. That's mainly why I write this posting ?!
Why is the camera doing that ? Is it to protect itself from damage ? (I guess not cause it would choose to shutdown if it was). I guess it's to enhance image quality. But perhaps this is not desired by the user, so it seems to be an "auto" feature. I have read other peoples posting, somewhat mentioning this auto adjustments especially for this camera... I have also read something about ae lock ? I am not sure what that is ? I guess it's auto-exposure lock ? So I guess I am writing about that.
This powershot sx50 hs apperently has an "auto exposure" "issue" where it automatically adjusts the exposure.... this might be an unwanted feature ?! And somehow this has to be disabled ?!
So that's basically what I am writing about. (What's the best way to disable this ?)
I do know the camera a bit, it has a P-mode which is mostly tested with this script. I think it also has some kind of "locked exposure" mode... a star will appear on the screen.
However getting that all to work is kinda complex have to use special button and so forth.
So perhaps it might be a nice idea to add a feature to this script called: "auto exposure: on/off".
So that the script can automate this tedious task. Perhaps that would make the script even more usefull/easy to use.
Tomorrow I will report back on my findings at night time ;)
(Also I wonder if perhaps other video codecs or such could be embedded into chdk so that the video is not so grainy/distorted, I think some of that distortion is because of jpeg compression artifacts.)
If video codec is a too large under taking... I also wonder if perhaps shooting raws or something continously might be an alternative to this video script thing ? Perhaps raw with some compression format build into chdk if not already done so ? Problem with shooting pictures individually is "click" sound. I want that sound gone ? is that possible at all ? (Ok now I am wondering a bit off-topic sorry for that). Also shooting pictures individually seems a bit slow so far... I wonder what the difference is ? Why can video shoot fast but picture mode slow ? kind weird...
Anyway... congratulations on this script ! This is the main feature of this camera that I wanted to see enhanced ! So this script is kinda making me happy and is offering something to chdk which makes chdk actually worth something to me, as well as the interval-o-meter script.
Also if anybody out there has special scripts for "night time videos" and or "night time pictures" I'd be interested in those scripts as well. Also I cannot garantuee that I can actually test tomorrow it depends on circumstances... but I hope the circumstances are right to do it ! I'm looking forward to that ! ;) :)
Also I noticed the max ISO is 1600 or 3200 ? But the powershot sx50 hs can support ISO 6400 ?
So maybe up the limit a bit ? (Perhaps script should detect camera type and adjust limits accordingly).
(Also one last question, why does this forum report my ip as belonging to "cloudflare"'s ip range ? It's not showing my ip address, but theirs... weird. ?)
-
Script is useless for me for now:
1. ISO 1600 too low.
2. ISO 3200 makes powershot sx50 hs crash before and during video recording.
Default software is better for now.
Hopefully in future script will be better.
Perhaps I will tweak settings to see if that helps.
-
I tried to run it on SX510 HS but it crashes during start just before the window with the settings for Tv, Av and ISO appears. It happened to load once properly and I tried some videos but during the next time I tried to start the script using the same settings it crashed again.
-
I tried to run it on SX510 HS but it crashes during start just before the window with the settings for Tv, Av and ISO appears. It happened to load once properly and I tried some videos but during the next time I tried to start the script using the same settings it crashed again.
If you read through this forum thread, you notice that the script is very experimental and pushes the limit of what CHDK can do on some cameras. On the wikia page for this script there is a list of cameras that work and a (shorter) list of cameras that do not work with this script.
http://chdk.wikia.com/wiki/Manual_Exposure_Control_for_Video_Recording (http://chdk.wikia.com/wiki/Manual_Exposure_Control_for_Video_Recording)
Unfortunately, if your camera does not work with this script there is likely nothing easy that can be done to fix it.
-
Hey all
I am quite an newby with the chdk tool . but it looks really good and has very good explanations.
The script is really great and i've tested it on an G15. I runs very good but crashed from time to time.
Is there a way to debug it proper to see why the script crashes?
And my main goal is to have it running with an external wired remote controller from Canon, so that i can start the recording by pressing the "shoot" button.
So i modified the script in the following way. and it works from time to time but not everytime..
here are the modifications and as well the attachment.
while true do
show_values(tv96, av96, sv96)
repeat
draw.overdraw()
wait_click(200)
until not(is_key("no_key"))
if is_pressed("shoot_full") then
-- press("video") sleep(2000) release("video") sleep(1000)
press("video")
sleep(100)
release("video")
sleep(3000)
press("video")
sleep(100)
release("video")
elseif is_pressed("left") then
if gui_index > 0 then gui_index = gui_index - 1 end
elseif is_pressed("right") then
if gui_index < 2 then gui_index = gui_index + 1 end
elseif ( is_key("up")) then
adjust_value(gui_index, 1)
elseif ( is_key("down")) then
adjust_value(gui_index, -1)
elseif is_pressed("menu") then break
end
end
restore()
-
The script is really great and i've tested it on an G15. I runs very good but crashed from time to time.
Is there a way to debug it proper to see why the script crashes?
If the camera crashes, a romlog may provide some clues about where in the Canon firmware it crashed. See http://chdk.wikia.com/wiki/Debugging#Camera_crash_logs_.28romlog.29 (http://chdk.wikia.com/wiki/Debugging#Camera_crash_logs_.28romlog.29)
Assuming the crash is related to the video control stuff, actually understanding it and finding fixes or workaround will likely take reverse engineering and possibly new CHDK code.
-
would it be possible to call
set_aelock(1)
tv96=call_event_proc("SetAE_ShutterSpeed",607)
av96=call_event_proc("MoveIrisToAv",510)
call_event_proc("SetCDSGain",381)
(example values)
from a ptp interface to control the exposure in video mode. im trying to do just that but not getting any result.
-
would it be possible to call
set_aelock(1)
tv96=call_event_proc("SetAE_ShutterSpeed",607)
av96=call_event_proc("MoveIrisToAv",510)
call_event_proc("SetCDSGain",381)
(example values)
from a ptp interface to control the exposure in video mode. im trying to do just that but not getting any result.
You can call event procs over ptp. It's up to you to determine if the canon firmware does what you want.
I'd suggest you return the value from call_event_proc, like
=return call_event_proc("SetAE_ShutterSpeed",607)
in general it will -1 if the function isn't registered and otherwise 0 or whatever value the function would normally return.
Also keep in mind that each . or = command is a separate script, so you can't set a variable like tv96 in one call and use it in another. If you need to do that, either do it all in one command or return the values so you can pass them to the next command.
Your examples isn't really clear to me, does SetAE_ShutterSpeed actually return a tv96 value?
-
would it be possible to call
set_aelock(1)
tv96=call_event_proc("SetAE_ShutterSpeed",607)
av96=call_event_proc("MoveIrisToAv",510)
call_event_proc("SetCDSGain",381)
(example values)
from a ptp interface to control the exposure in video mode. im trying to do just that but not getting any result.
You can call event procs over ptp. It's up to you to determine if the canon firmware does what you want.
I'd suggest you return the value from call_event_proc, like
=return call_event_proc("SetAE_ShutterSpeed",607)
in general it will -1 if the function isn't registered and otherwise 0 or whatever value the function would normally return.
Also keep in mind that each . or = command is a separate script, so you can't set a variable like tv96 in one call and use it in another. If you need to do that, either do it all in one command or return the values so you can pass them to the next command.
Your examples isn't really clear to me, does SetAE_ShutterSpeed actually return a tv96 value?
i am sorry but are these not the calls which are set in the script to achieve the exposure and aperture control. the script works fine on my SX150 so i was wondering if i can achieve the same contol over PTP.
it doesnt seem to be working but then i think i am doing something wrong.
-
i am sorry but are these not the calls which are set in the script to achieve the exposure and aperture control.
I don't know what script you are referring to, there are a lot of variants of the videxp script floating around. It does look the the version on the wiki uses something similar to what you posted.
the script works fine on my SX150 so i was wondering if i can achieve the same contol over PTP.
it doesnt seem to be working but then i think i am doing something wrong.
Without knowing what *specific* things you tried over PTP, it's impossible for us to know what is wrong.
FWIW, you need to call some registration event proc before "SetAE_ShutterSpeed" is available. Look at the other call_event_proc calls in the script. This would be my first guess as to why it isn't working for you, but again, I don't know what you have actually done. If you follow my suggestion of displaying the return values of these eventproc calls, you will know if the functions are correctly registered.
There is no particular reason that something which works in a standalone script should not work while connected by PTP, but on the other hand both the script and PTP shooting are pretty hacky so it wouldn't be a huge surprise either.
You could try running the script through the menu while PTP is connected. If that works, then calling the equivalent functions over PTP will almost certainly work, and you just need to figure out which parts you aren't replicating. If it doesn't work, then maybe there's some weird interaction with PTP.
-
Seems interesting. I will test it with the SX230HS and demo the features, as well as some of the issues.
Camera used is the Powershot SX 230HS.
What works: Manual controls, put the camera in video mode, then select the script, then press the shutter release button too activate the script. To begin recording, pres the FUNC/SET button, then to stop press the FUNC/SET button again.
While in this mode, you can set the shutter speeds, though only those that are available in standard photo mode, thus no 1/48 FPS on the 230HS which records at 1080P 24FPS
What doesn't work:
Exiting the manual video mode, it does not exit properly. To exit, you must first press the shutter release again, then press the play button.
The problem is that it seems to never fully exit, thus the live preview no longer works when it comes too accurately previewing the exposure. The live preview will change as you adjust the settings, but it will look nothing like the final image.
To fix this issue, you must turn the camera off and then back on. Overall, it is is a simple workaround, and the video controls work well.
just wish it had a focus lock function. It would make it far easier to record closeups of objects such as PCB's (Would love it for a logitech G700 modding video that I have coming up :) )
video demonstration www.youtube.com/embed/DXt5NidnWZ4?feature=player_detailpage (http://www.youtube.com/embed/DXt5NidnWZ4?feature=player_detailpage)
-
Wow thanks! I am using the elph 300 HS/ Ixus 220 HS firmware 1.00C
Here you go : https://app.box.com/s/e8pff7qdpjd2le35faov
I have the same camera and firmware as mojo43 . Like to try patched chdk version if it could work better with this camera?
But the download link is dead... :(
Regards Jani
-
Wow thanks! I am using the elph 300 HS/ Ixus 220 HS firmware 1.00C
Here you go : https://app.box.com/s/e8pff7qdpjd2le35faov
I have the same camera and firmware as mojo43 . Like to try patched chdk version if it could work better with this camera?
But the download link is dead... :(
Regards Jani
Me too. I want to download the patched chdk version but link is dead.
-
How do I apply the patch?
You need to be able to compile CHDK from scratch. You apply the patch to the source code using the "patch" command on the command line or a suitable GUI tool.
If you tell me your camera & firmware version I can post a patched version for you.
I have successfully used in the past CHDK-Shell to compile CHDK.
Today after applying your patch (with the "source tools") and after I hit "Compile selected" I get no results but the following error message:
----
../platform/ixus220_elph300hs/libplatform.a(wrappers.o): In function `GetCurrentShutterSpeed':
wrappers.c:(.text+0x474): undefined reference to `_GetCurrentShutterSpeed'
../platform/ixus220_elph300hs/libplatform.a(wrappers.o): In function `GetCdsGainValue':
wrappers.c:(.text+0x484): undefined reference to `_GetCdsGainValue'
../platform/ixus220_elph300hs/libplatform.a(wrappers.o): In function `MoveIrisToAv':
wrappers.c:(.text+0x4a0): undefined reference to `_MoveIrisToAv'
../platform/ixus220_elph300hs/libplatform.a(wrappers.o): In function `SetShutterSpeed':
wrappers.c:(.text+0x4bc): undefined reference to `_SetShutterSpeed'
../platform/ixus220_elph300hs/libplatform.a(wrappers.o): In function `SetCDSGain':
wrappers.c:(.text+0x4d8): undefined reference to `_SetCDSGain'
collect2: ld returned 1 exit status
D:\gcc\bin\gmake.exe[1]: *** [main.elf] Error 1
gmake: *** [all-recursive] Error 1
----
Any help?
-
You can look for the functions in platform/<your camera>/sub/<your firmware version>/func_by_name.csv and add them to your platforms stubs_entry_2.S
The stubs_entry_2.s lines are
NHSTUB(<function name without leading underscore>, <address>)
The ones in the csv file may have _FW at the end, which you should not include when defining the stub.
Note that your camera doesn't have an iris, so _MoveIrisToAv can just be NULLSUB.
If other functions are missing, you'll need to find them in disassembly.
-
You can look for the functions in platform/<your camera>/sub/<your firmware version>/func_by_name.csv and add them to your platforms stubs_entry_2.S
The stubs_entry_2.s lines are
NHSTUB(<function name without leading underscore>, <address>)
The ones in the csv file may have _FW at the end, which you should not include when defining the stub.
Note that your camera doesn't have an iris, so _MoveIrisToAv can just be NULLSUB.
If other functions are missing, you'll need to find them in disassembly.
I think this is difficult for me to be done.
I will have to wait until someone re-uploads the patched chdk version, (asked also be M141) because the link https://app.box.com/s/e8pff7qdpjd2le35faov (https://app.box.com/s/e8pff7qdpjd2le35faov) is dead.
(This patched chdk version uploaded by waterwingz fits my camera and firmware).
-
I have the same camera and firmware as mojo43 . Like to try patched chdk version if it could work better with this camera? But the download link is dead... :(
Me too. I want to download the patched chdk version but link is dead.
The link was for an experimental build - I don't keep those around for long.
The philmoz patch file used to create the download will not apply cleanly to the current build and I don't really have time right now to fix that.
So here's a rebuild of the stuff you asked for using the older version of CHDK it was created for :
ixus220_elph300hs-100c-1.3.0-3344-full.zip (https://app.box.com/s/aohhhmhlndo8u395y1tplqlfcvgnggxd)
I can build for other cameras but this is a time limited offer :xmas
YWIA
-
I have the same camera and firmware as mojo43 . Like to try patched chdk version if it could work better with this camera? But the download link is dead... :(
Me too. I want to download the patched chdk version but link is dead.
The link was for an experimental build - I don't keep those around for long.
The philmoz patch file used to create the download will not apply cleanly to the current build and I don't really have time right now to fix that.
So here's a rebuild of the stuff you asked for using the older version of CHDK it was created for :
ixus220_elph300hs-100c-1.3.0-3344-full.zip (https://app.box.com/s/aohhhmhlndo8u395y1tplqlfcvgnggxd)
I can build for other cameras but this is a time limited offer :xmas
YWIA
Thank you waterwingz.
I go it and tested on Ixus 220 / elph 300HS and Video Exp Ctrl v3.5 (videx3.lua):
I installed the rebuild on a 4GB SD card with card tricks.
The script videx3.lua (v 3.5) does not need native lua calls enabled with this patched rebuild.
During video capturing with the script Tv (speed control) works and Sv (ISO control) also works.
Av (aperture control) does not work as reported above in previous comments.
I can make a comparison on this camera with the previous version of Video Exp Ctrl v3.4 (videx3.lua):
With Video Exp Ctrl v3.4 you do not need a patched CHDK build, but lua native calls must be enabled.
Even though, Tv (speed control) does not work , Sv (ISO control) works and Av (aperture control) works but gives you only two aperture values.
For both versions(Videxp3.lua v3.4 and 3.5) I can say that they enhance video capturing because they both expand ISO control: you gain higher ISOs.
-
Thanks waterwingz! :)
This build works with v3.5 script like mercier wrote.
I don't like the way my ixus slightly overexposure videos and this gives tools to fix it.
Regards Jani
-
oow :D please build for sx260hs please :)
i would like to have and use this for a upcoming opportunity i have :)
Thank you, for just even offering to build it!
-
I've lost track of what works and what doesn't. I'm traveling this week and not able to do custom builds. Does the standard script on the wiki not work for you?
http://chdk.wikia.com/wiki/Manual_Exposure_Control_for_Video_Recording
-
ok thanks, i'll make do. just thought if it was less buggy then it might have been nice sort of thing.
ive updated now my chdk from 2014 June to current stable today now.
did a little test with videxp3.3 which i have and it seamed ok. did crash when i pressed the play button i think but when i half pressed shutter before pressing menu or other button,i’ve just forgotten which other button it was... seams that what someone said was that you need to half press the shutter button before exit for it to not crash the camera?
the wiki only has version 3.1 and the download link is dead. good thing i have 3.3 :). now you mention it, does anyone have a copy of this 3.4 version people seam to be talking about? I’m not sure what it’s benefits are?
thanks muchly, time for some sleep ;)
-
the wiki only has version 3.1 and the download link is dead. good thing i have 3.3 :). now you mention it, does anyone have a copy of this 3.4 version people seam to be talking about? I’m not sure what it’s benefits are?
The text copy of the script on that page is 3.1 The copy available from the download link is 3.4.
I just tested that link and it seems to work fine for me
link > vid_exp3.lua (https://app.box.com/s/n0ja0wbii7coiz06mdw1)
-
First at all, this script is the real deal! One of the most useful scripts ever written for CHDK, no doubt. I'd like to personally thank Waterwingz for the hard work done & taking into account the suggestions above, making the script even better. Thank you so much.
Also I'd like to report that my SX230 works really well with that one.
The only thing that bothers me is the loud noise of up & down buttons, which is easily heard on record. Since my SX230 have these buttons merged with a turning wheel, that of course makes less noise, I decided to take a try and set the up & down commands to a wheel turn.
(https://chdk.setepontos.com/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FDoWcD8B.jpg&hash=5b6c6470d868fdae504b2745a4500651)
As a newbie in script-writing, I can take a guess that these lines 'is_key("up")/is_key("down")' are standing for up & down commands and insted of 'up' and 'down' I need to desribe a left & right wheel turn, but I coun'd find a name for that command. Please, does anybody know? Or CHDK doesn't support wheel as a button mechanism? Thanks.
-
Or CHDK doesn't support wheel as a button mechanism?
Sorry - it doesn't. There have been a few conversations about how that might be done but AFAIK it never got much farther than that.
-
Thanks, works perfectly on my PowerShot A490
-
Has anybody got the ixus 115hs patched v1.3 1.01a firmware?
-
Updated the experimental patch (http://chdk.setepontos.com/index.php?topic=5295.msg109849#msg109849) to make it compatible with the CHDK 1.4 release source (and current trunk, since they are identical as of today).
It's still DryOS only (minus sx280).
It needs the script from the above linked post. It might be worth reading posts from the above link on, it does not appear to work very well on some cameras.
edit:
to clarify, videxp_chdk14_dryos_only.7z contains a source patch, so it's only for those who can build CHDK for themselves.
-
Hello. I have a Canon IXUS 115 HS, and not quite sure if this script on it work? I tried to copy the script "videxp3.lua" SCRIPTS directory on my card, but it does not work (script terminated). My camera works with CHDK 101c and 101b - if anyone can prepare CHDK, which copies the SD card with a working videxp3.lua?
In the previous post is an attachment to 101a - but it did not work for me.
I ask for help because IXUS 115 does not even exposure compensation in video mode :( I therefore very important to me this script running.
-
Hello. I have a Canon IXUS 115 HS, and not quite sure if this script on it work? I tried to copy the script "videxp3.lua" SCRIPTS directory on my card, but it does not work (script terminated). My camera works with CHDK 101c and 101b - if anyone can prepare CHDK, which copies the SD card with a working videxp3.lua?
In the previous post is an attachment to 101a - but it did not work for me.
I ask for help because IXUS 115 does not even exposure compensation in video mode :( I therefore very important to me this script running.
To use the mod in question, you need the version of the script that is attached to this post (https://chdk.setepontos.com/index.php?topic=5295.msg109849#msg109849).
I tried out briefly the modded CHDK and that script. To use it successfully, you need to lock exposure prior to running the script (press half shoot and "up", AEL will be displayed on the LCD). With running script, you start and stop recording with the SET button. After recording starts, adjust ISO and exposure time, otherwise exposure will be incorrect. Do not touch the Av value as the camera doesn't have adjustable aperture.
The attached special build only supports the locked SD card method.
-
Modified the script so it works like ae/af lock on ixus 115hs. (so i dont have to change iso and tv values every time. Values doesnt seem to be correct aswell)
works like this:
1. start script
2. pressing the set button locks exposure/af and starts recording
3. pressing set button stops recording and unlocks exposure
-
All these scripts do not work well with my IXUS55.
Mainly problems due to ISO: it is too large and does not change, despite the changing values on the LCD screen. because of this, noise, overexposure and distortion appeared.
managed to remove this bug only by changing line "sv_table"
sv_table = { 10, 30, 50, 80, 100, 200, 300, 400 }
BUT now values do not changes (digits on the LCD screen) - only 10, but ISO changes.
How do I make the digits display the value of ISO?
-
Hi
I'm trying to get this mod to work in a "night" mode, so basically lowering the shutter to allow more light (although there will be less frames).
I've modified the file to add some lower values, and they do partially work and the frame rate does visibly drop lower, however, after a few seconds of recording the camera just dies. Any idea how to fix that?
I've attached the modified file below, what I changed was the tv_ref, tv_val, and tv_str. Should I also have changed other things?
-
the frame rate does visibly drop lower, however, after a few seconds of recording the camera just dies.
If the actual frame rate does not match the theoretical one, video and audio will become out-of-sync. The firmware routines do not tolerate that, the camera will shut down with an assert.
Any idea how to fix that?
If your cam has a video recording mode that records no audio, try using that. However, I'm not convinced that the camera will allow you recording with a nonstandard framerate.
-
How do I apply the patch?
You need to be able to compile CHDK from scratch. You apply the patch to the source code using the "patch" command on the command line or a suitable GUI tool.
If you tell me your camera & firmware version I can post a patched version for you.
Would it be possible to prepare a patched version for my Ixus 220HS, firmware 101d ?
-
Hi
I'm trying to get this mod to work in a "night" mode, so basically lowering the shutter to allow more light (although there will be less frames).
I've modified the file to add some lower values, and they do partially work and the frame rate does visibly drop lower, however, after a few seconds of recording the camera just dies. Any idea how to fix that?
I've attached the modified file below, what I changed was the tv_ref, tv_val, and tv_str. Should I also have changed other things?
I managed to get it somewhat working on my Canon PowerShot S3IS, by lowering the fps to 15. Important thing to note is that the whole video becomes really fast and audio glitches.
-
Should I also have changed other things?
Found some time for lines to make it more stable:
-- exit_alt button proof; Leave <alt> for zooming, <rec> or not. repeat sleep(100) until get_alt_mode()
wait_click(200)-- Preset minTv that´s save for Your cam. (Start recording only): Bright preview, std video.
-- Within limits still to explore script works fine, ends smooth. :xmas
Crashing: Try to shoot in exit_alt...
ASSERT!! BrtMthd.c Line 3483
Occured Time 2021:11:22 21:50:20
Task ID: 31457348
Task name: BrtMsrTask
...
00170820: UI:ShtCon_NotifyQuickShooting
00171630: UI:Button:0x000009A4:UnpressSwTwo
00171650: UI:Button:0x000009A2:UnpressSwOneStrange: if Tv<1/10 light & dark preview switching. or Sv>1250 (Sx230) dark again.
Edit: https://chdk.setepontos.com/index.php?topic=13508.msg145115#msg145115 [:o]
-
Should I also have changed other things?
Found some time for lines to make it more stable:
-- exit_alt button proof; Leave <alt> for zooming, <rec> or not. repeat sleep(100) until get_alt_mode()
wait_click(200)-- Preset minTv that´s save for Your cam. (Start recording only): Bright preview, std video.
-- Within limits still to explore script works fine, ends smooth. :xmas
Crashing: Try to shoot in exit_alt...
ASSERT!! BrtMthd.c Line 3483
Occured Time 2021:11:22 21:50:20
Task ID: 31457348
Task name: BrtMsrTask
...
00170820: UI:ShtCon_NotifyQuickShooting
00171630: UI:Button:0x000009A4:UnpressSwTwo
00171650: UI:Button:0x000009A2:UnpressSwOneStrange: if Tv<1/10 light & dark preview switching. or Sv>1250 (Sx230) dark again.
My Canon SX40HS fails around Shutter Speed 1/15 and crashes :lol
-
My Canon SX40HS fails around Shutter Speed 1/15 and crashes :lol[/font]
Everything else is a surprise (as Your S3Is) :lol
-
My Canon SX40HS fails around Shutter Speed 1/15 and crashes :lol[/font]
Everything else is a surprise (as Your S3Is) :lol
So far, the S3IS works well. It's older, and yet it outperforms the newer SX40HS
-
:D Too much to tell yet ... :(
Now it´s possible to ...
Sx230: Use slow motion video spee...eeding up to 1/5 sec. :lol
(Overwritten >:()
ASSERT!! Pwrcnt.c Line 342
Occured Time 2021:11:25 20:05:35
Task ID: 18022442
Task name: CaptSeqTask
...
00537160: UI:Button:0x000009A6:UnpressMovieButton (to stop Rec.)-----------------------------------------------------------------------
Sx270:
FHD with upto ... 0.8 sec. BUT after finishing script a reboot is necessary.
(Even if nothing was done... Edit: No matter, 1/2way gone by cam...) :haha
Need to start with lens open.
Seems an issue with AEL (@ lowlight & ??).
Crashes happen between help screen and 1st drawing draw_box()...
or after script finished.... 1st AEL action --> Cam off.
Manually swapping to <play> [review video|menu action|...] <rec> same.
Edit2: Sx270 works even with ISO 6400 12800, so Sv tables grew...
++ Zoomkeys can be used to adjust ISO for easy dimming... ::)
(... then exit alt to zoom...)
ASSERT!! BrtMthd.c Line 3217
...
00041380: SS:AEL
OR
00190520: SS:CancelPre
Seems to fail set_record(0)
Sx270... seperate Digic 6 version, works very nice in VGA, HD + FHD.
Set menu, then reboot, so settings are valid after crash.
Seems fine so far with Tv>=1/30 and valid ISO on other cams too.
SX240: ISO>3600 crashing ...
D20 could have 6400.ASSERT!! CDSGain.c Line 405
Occured Time 2021:11:26 20:08:56
Task ID: 18022441
Task name: PhySw
...
00049650: SetCDSGain
OR
SetCDSGainStep
Btw. Script crashed (I failed to paste a function :P), video didn´t stop recording...
function sleep(s) sleep(math.max(s, tv96_to_usec(tv96 or 0) or s)) end
--==>> :o *** NOT ENOUGH MEMORY *** :haha :lol
Edit: Work in progress... :-X
Edit2: Btw. images are from a movie recorded @ 5fps. ::)