CHDK Forum
CHDK Development => General Discussion and Assistance => DryOS Development => Topic started by: c10ud on 24 / March / 2012, 10:35:34
-
I'll have the camera for a limited amount of time, i'll try to port as much as i can given my free time.
After dumping the firmware and running through the decompilation, philmoz' finsig and ERR99's sx40hs port i found out some interesting things about this new DIGIC V camera.
I'll keep you updated on progress.
Some early infos:
// Camera info:
// DRYOS R49 (DRYOS version 2.3, release #0049)
// Firmware Ver GM1.00D
// Canon PowerShot S100
Led address: 0xC022C30C
seems like it's not enough anymore to write 0x46/0x44 in order to power on/off the led (where did this come from, anyway?), but it's required to do what ERR99 did with sx40hs
e.g.
volatile long *p=(void*)0xC022C30C;
*p = (*p & 0xFFFFFFCF) | 0x20; // Turn on LED
*p = (*p & 0xFFFFFFCF); // Turn off LED
Today i was talking with philmoz when i had no clue on where to find LED addresses and after some research i found out there's a pattern (at least it these new cameras? i didn't check other dumps) that could be used by finsig to find these addresses (i'm no expert but..), in fact both sx40hs and s100 show this patterns (reflected in ERR99's code):
LDR R2, =0xC022C000
LDR R1, [R2,#0x30C]
BIC R1, R1, #0x30
ORR R1, R1, #0x20
STR R1, [R2,#0x30C]
and
LDR R2, =0xC022C000
LDR R1, [R2,#0x30C]
BIC R1, R1, #0x30
STR R1, [R2,#0x30C]
-
Just realized you're talking about firmware code snippets. Sorry.
Just an idea and it may not help much (based on observations on earlier models):
The 0xc022xxxx GPIO area holds two representations of the GPIO "pins". The first one uses a whole word (32bits) to set up (and read/write) a single "pin", the second one collects the states of multiple "pins" into a few words (1 bit / GPIO).
One can use the 32bit/pin representation to set up hardware properties of that pin (e.g. set it as input or output, set pullup/pulldown resistor, set driving mode, etc). That is the reason for using 0x46/0x44.
I think this still applies to the DIGIC 5 (since manipulating bits of a word without affecting all the other bits is not possible on ARM, and this is not a regular memory area). I think what you've found is the grouped version (1bit/pin).
edit:
I was curious and tried modifying the Canon Basic dumper script to dump the 0xc022.... area. It seemed to work ... on the A410 and the Ixus870.
' dump 0xC022xxxx to A/C022.BIN
' log to A/CBDUMPER.LOG
DIM startaddr=0xC0220000
DIM os="unk"
DIM lcdmsg=0
DIM msgstr=0
private sub RegisterProcs()
' Newest cams (Dryos rel 43 and later) only have System.Create()
' on older dryos cams SystemEventInit is an alias for System.Create()
' ExecuteEventProcedure does is not registered by default on vx,
' but calling an unregistered is not fatal
if System.Create() = -1 then
SystemEventInit()
end if
if ExecuteEventProcedure("UI_RegistDebugEventProc") = -1 then
ExecuteEventProcedure("UI.CreatePublic")
end if
end sub
private sub InitMsg()
lcdmsg = ExecuteEventProcedure("LCDMsg_Create")
msgstr = AllocateMemory(80)
' truncate log
msgfile = Fopen_Fut("A/CBDUMPER.LOG","w")
if msgfile <> 0 then
Fclose_Fut(msgfile)
end if
end sub
private sub PutMsg(msg)
if lcdmsg >= 0 then
LCDMsg_SetStr(lcdmsg,msg)
LCDMsg_ChangeColor(lcdmsg ,6)
end if
msgfile = Fopen_Fut("A/CBDUMPER.LOG","a")
if msgfile <> 0 then
Fwrite_Fut(msg,strlen(msg),1,msgfile)
Fwrite_Fut("\n",1,1,msgfile)
Fclose_Fut(msgfile)
end if
end sub
private sub Initialize()
RegisterProcs()
InitMsg()
PutMsg("Started")
if startaddr <> 0 then
sprintf(msgstr,"%0X %s",startaddr,os)
PutMsg(msgstr)
' romsize = 0xFFFFFFFC - startaddr
romsize = 0xFFFC
dumpfile = Fopen_Fut("A/C022.BIN","w")
if dumpfile <> 0 then
Fwrite_Fut(startaddr,romsize,1,dumpfile)
Fclose_Fut(dumpfile)
Wait(500)
PutMsg("done")
else
PutMsg("file error")
end if
else
PutMsg("not found!")
end if
FreeMemory(msgstr)
end sub
-
Update: CHDK loads correctly. Nothing has been implemented yet, i ran out of battery and i still need to fix the alt button thingie
For those curious, you can take a look at the code here: https://github.com/c10ud/CHDK/tree/s100
@srsa_4c: about LEDs, i tried printing on screen the value of some potential locations (even the correct one) while toying around with LEDDrive but if iirc i got the same value when the LED was on and when it was off, maybe it was just because of cbasic buffering data or something, i don't really know.
Anyway, the firmware snippets look good for finding locations to me.. ofcourse if they're implemented the same in every DryOS but sx40hs was the first one (afaik) to show this new LED handling so.. :)
update 2: kbd now working correctly, chdk menu up and running
note: i've mapped the ALT mode button to the REC button because DISP is also DOWN
-
Excellent progress.
Per this discussion http://chdk.setepontos.com/index.php?topic=6787.0 (http://chdk.setepontos.com/index.php?topic=6787.0) please make play the default alt button. If you implement adjustable alt (recommended) then movie can be an alternate option.
-
Thank you reyalp.
Today i finished porting all chdk tasks, tested the build a bit and updated TODO/known issues (see here (https://github.com/c10ud/CHDK/blob/7021523fde51315be908377335b19983d0e14cb9/platform/s100/notes.txt))
The default alt mode button is now playback, and it's adjustable with the same options as sx150 (they looked fair to me)
edit:
i'm trying to make the shoot() script work but i see an issue: it gets stuck at AS_WAIT_SHOOTING_IN_PROGRESS because shooting_in_progress() is never returning true, even if PROPCASE_SHOOTING is correct, at least when you shoot_half manually.. did anyone see anything similar in other cameras?
-
i'm trying to make the shoot() script work but i see an issue: it gets stuck at AS_WAIT_SHOOTING_IN_PROGRESS because shooting_in_progress() is never returning true, even if PROPCASE_SHOOTING is correct, at least when you shoot_half manually.. did anyone see anything similar in other cameras?
Is your capt_seq task starting ?
-
shooting manually with ISO overriding seems to work, hence i think the answer is yes (?)
also, sending button presses works (e.g. press("shoot_full"))
i still need to check a few values, though
edit: tried blinking in captseq jumptable entry 1 but it didn't work when calling shoot(), on the contrary it did work when pressing the button manually
edit2: manually pressing shoot_half when shoot() script hangs makes it complete successfully
edit3: thank you c10ud from 2010, problem solved: http://chdk.setepontos.com/index.php?topic=5720.msg56168#msg56168 (http://chdk.setepontos.com/index.php?topic=5720.msg56168#msg56168)
-
also, sending button presses works (e.g. press("shoot_full"))
That's handled in the keyboard task.
edit3: thank you c10ud from 2010, problem solved: http://chdk.setepontos.com/index.php?topic=5720.msg56168#msg56168 (http://chdk.setepontos.com/index.php?topic=5720.msg56168#msg56168)
So the half-press key mask was wrong or missing ?
-
turns out i forgot *again* that i mustn't include shoot_half (and shoot_full_only) in the keymask ;)
btw, now the issue is fixed
-
update: corrected a few things in shooting.c, platform_camera.h, etc. (thanks philmoz), code is at the usual place.
i've seen there's an official canon update for this camera, i'll ask if i can upgrade mine so i can port to the new firmware too :)
edit: upgrading with the official updater http://www.canon.com.au/Support-Services/Support-News/Firmware-Updates/PowerShot-s100-Firmware-Update (http://www.canon.com.au/Support-Services/Support-News/Firmware-Updates/PowerShot-s100-Firmware-Update) now i have firmware 101a
-
added code for firmware 101a in github. Looks like the same except for a few addresses :)
also updated todo and fixed some other things
-
Super news on the progress with the S100. Been waiting for CHDK/SDM to be available for this camera. Been using the S95 for a year with CHDK/SDM for kite aerial photography - works great! Love to move to the S100 for a number of reasons. Let me know if you need any beta testers.
-
Ok, new update:
i downloaded firmware 100e and ported chdk to it. This is completely untested since i only own a 101a (not for long..as i said in the first post) but i checked briefly the diff against another 100d and it was pretty small so it *shouldn't* cause issues.
Meanwhile i checked out some raw addresses, fixed some defines (i'm not into the raw field so they might be wrong) and updated code a bit.
You can find the source code at the usual address: https://github.com/c10ud/CHDK/tree/s100
I think i will generate a diff and ask for inclusion in the chdk svn trunk soon so a wider audience can be reached and obvious bugs can be better identified and fixed. I wanted to take a look at gps functionalities first but i don't know if i'll have the time.
For those curious/eager to test, here are my local builds for firmware 100d, 100e, 101a.
USE AT YOUR OWN RISK
-
..and here's the 101a build (2 attachments per post max ;))
-
2 attachments per post max ;)
www.box.com (http://www.box.com)
-
i've received positive feedback from a 100e user, i guess i am ready to ask for inclusion in trunk then ;)
one thing to mention: i didn't implement any multipart support because camera can boot from fat32 (tested)
diff incoming
edit: here it is http://chdk.setepontos.com/index.php?topic=650.msg83736#msg83736 (http://chdk.setepontos.com/index.php?topic=650.msg83736#msg83736)
-
Is there a chance, that CHDK can remove the 30 seconds limit for the slowmotion videos?
edit: How do I get the firmware version on the S100? It works for my A720 with the same SD card, so I guess I'm pressing the wrong buttons ...
-
Hello everyone,
i gave the camera back so i don't have physical access to it anymore.
However, if i can help with something, i will.
@ch01ia: i don't have an answer for that but if that's already implemented in some other camera, it is surely possible and could be easy to port to s100.
You can find your firmware version with a simple tool, see here: http://chdk.wikia.com/wiki/CameraVersion (http://chdk.wikia.com/wiki/CameraVersion)
-
Thanks for the tip. I've got the 1.01a ...
Now I'm trying to get chdk to boot. I tried installing it with licks but nothing happens. The camera just says that the card is write protected.
I'm not sure what I need to put on the SD card apart from what is in the zip from this thread and where to get it.
-
Hello ch01ia,
Check out this page and go down to "New in 2012 for recent cameras!". I used EOScard1.2 Utility for Windows and it works fine.
http://chdk.wikia.com/wiki/Bootable_SD_card (http://chdk.wikia.com/wiki/Bootable_SD_card)
Curt
-
I've been there. But I have only Linux, that's why I used LICKS.
edit: I tried the version from autobuild. Same problem there.
When I try to boot with the firmware update, the camera just shuts down.
-
edit: I tried the version from autobuild. Same problem there.
Neither the svn or "autobuild" servers have a port for the S100 so what did you download ?
-
There is a build here:
http://mighty-hoernsche.de/trunk/ (http://mighty-hoernsche.de/trunk/)
-
When I try to boot with the firmware update, the camera just shuts down.
So if you get a menu item that allows you to try a firmware update, then the only two things that can go wrong at that point are :
- You don't have the right firmware version of the code for your camera.
- The ps.fi2 file in invalid.
-
I never tried with ps.fi2, i always used the lock sdcard method
-
Thankyou so much for doing this S100 port. Today I have successfully loaded chdk on firmware 1.00D and ran my favourite interval script. Great. This is what i have been waiting for.
Some comments. I followed the installation instructions very closely however I could not get the firmware to load via the update firmware menu, so I cannot set the card to be bootable.
However, when I 'lock' the card I can start the camera via the play button and then pressing the shutter opens the lens and takes it into shooting mode.
-
Some comments. I followed the installation instructions very closely however I could not get the firmware to load via the update firmware menu, so I cannot set the card to be bootable.
When you say "could not get the firmware to load", what do you mean ?
- The camera crashes (Screen goes black) ?
- The "firm update" menu does not appear ?
- something else ?
If it crashes, then we should disable FI2 for this camera until someone figures it out. If the menu option doesn't show, you've probably done something wrong.
However, when I 'lock' the card I can start the camera via the play button and then pressing the shutter opens the lens and takes it into shooting mode.
If CHDK is loading (camera doesn't show "card locked", chdk features work), I guess you used some other method to make the card bootable ?
-
ok, I ran through the process again just to be sure.
When attempting to load chdk using the firmware update option. After selecting firmware update it presents a screen that says 1.0.0.0 to 1.1.0.0, and I press OK. After that the screen just goes blank. nothing. pressing the play button brings it back to life.
I then used EOScard1.2 to make the card bootable and 'locked' the card. Now, the camera will only start in play mode (using either on/off button or the play button) but pressing the shutter will then put it into camera mode. pressing play then activates chdk as normal and i can open the chdk menu.
Does that help?
-
ok, I ran through the process again just to be sure.
When attempting to load chdk using the firmware update option. After selecting firmware update it presents a screen that says 1.0.0.0 to 1.1.0.0, and I press OK. After that the screen just goes blank. nothing. pressing the play button brings it back to life.
I then used EOScard1.2 to make the card bootable and 'locked' the card. Now, the camera will only start in play mode (using either on/off button or the play button) but pressing the shutter will then put it into camera mode. pressing play then activates chdk as normal and i can open the chdk menu.
Does that help?
Yes, very clear, thanks :)
It sounds like it's crashing when using the firmware update method, so we should document that on the wiki + notes.txt and remove the fi2 file from the build until it's fixed.
The starting in play is normal for CHDK. By the time CHDK boots, we don't know which button the camera was started with. If things are implemented correctly, you can hold down the power button a bit longer to boot directly into record mode.
edit:
ch01ia reported the same thing on 101a, so I'm guessing it's broken for all firmware versions.
edit:
If the FI2 loading crash generates a romlog, that might help figure out what is going wrong.
This page http://chdk.wikia.com/wiki/Debugging#Camera_crash_logs_.28romlog.29 (http://chdk.wikia.com/wiki/Debugging#Camera_crash_logs_.28romlog.29) describes how to save the romlog.
-
i didn't touch anything related to fi2 so i guess it just auto-broken or not-implemented-yet ;)
as for the boot, unfortunately i've been unable to find the correct value to check during boot in order to choose between play or rec so the camera only boots in play mode and then you have to switch manually (left as a todo in notes.txt)
-
Hello everyone,
i gave the camera back so i don't have physical access to it anymore.
However, if i can help with something, i will.
c10ud: Where do you live?
-
Hello everyone,
i gave the camera back so i don't have physical access to it anymore.
However, if i can help with something, i will.
c10ud: Where do you live?
italy
however i think the porting already is in a very good shape, ready to use and test extensively (in the end, i'm not a "pro" ;))
-
Hello everyone,
i gave the camera back so i don't have physical access to it anymore.
However, if i can help with something, i will.
c10ud: Where do you live?
italy
however i think the porting already is in a very good shape, ready to use and test extensively (in the end, i'm not a "pro" ;))
Damn. I was hoping you'd say "Arizona" or "New York." But I've never been to Italy.
-
Hi, I'm able to load the chdk using cardtrick144, format as fat, make bootable then load the chdk 101a-1.1.0 into sdcard, but I can't find the interval function on the menu when i press play button then menu button, someone can help, thanks.
-
Hello & welcome, ivanwhlee !
I can't find the interval function
This is not an internal CHDK function, this is done with CHDK scripting; you'll find some scripts here in the forum or in the wikia, search for "intervalometer"...
* http://chdk.wikia.com/wiki/UBASIC/Scripts#Intervalometer (http://chdk.wikia.com/wiki/UBASIC/Scripts#Intervalometer)
* http://chdk.wikia.com/wiki/Lua/Scripts:_Accurate_Intervalometer_with_power-saving_and_pre-focus (http://chdk.wikia.com/wiki/Lua/Scripts:_Accurate_Intervalometer_with_power-saving_and_pre-focus)
* http://chdk.wikia.com/wiki/Lua#Some_Lua_scripts (http://chdk.wikia.com/wiki/Lua#Some_Lua_scripts)
* http://chdk.wikia.com/wiki/User:Fe50#double_intervalometer (http://chdk.wikia.com/wiki/User:Fe50#double_intervalometer)
CHDK User Manual, about scripting:
* http://chdk.wikia.com/wiki/CHDK_User_Manual#Scripting_Parameters (http://chdk.wikia.com/wiki/CHDK_User_Manual#Scripting_Parameters)
-
This is not an internal CHDK function, this is done with CHDK scripting; you'll find some scripts here in the forum or in the wikia, search for "intervalometer"...
There is also a simple script included in the CHDK installation file - look on the SD card in CHDK/SCRIPTS for interval.bas or interval.lua.
-
Hi, I think someone asked this before, but does CHDK remove the 30 second time limitation on the slow motion video recording modes?
-
Hi, I think someone asked this before, but does CHDK remove the 30 second time limitation on the slow motion video recording modes?
Yes, it can be done if someone implements it like it's already done on some other cameras.
-
@c10ud
Where you able to load chdk usign the FI2 file, via fimware update menu?
I think s100 & sx260 have the same issue with this, and blocks the use of sd cards greater than 32Gb.
-
@asm1989
... and blocks the use of sd cards greater than 32Gb
Strictly speaking, this is true only if one relies on native (camera or Windows) formatting.
FAT32 supports up to 2 TB partitions (many external HD's are sold preformatted as FAT32 !),
but M$ seems to only licence the use of their file system if licensees agree to enforce the
32 GB limit in their formatting routines ...
Fortunately, a free and open source solution exists, check my post here (http://chdk.setepontos.com/index.php?topic=7915.msg83517#msg83517)
cheers,
wim
-
thanks whim, It worked fine
we have to resolve why new cams fail to load the FI2,
I mean manualy loading you can allways use canon firmaware with outoload you need another sd card.
-
@c10ud
Where you able to load chdk usign the FI2 file, via fimware update menu?
I think s100 & sx260 have the same issue with this, and blocks the use of sd cards greater than 32Gb.
No, but i never tested it.
But i saw other people testing this and reported it failing. I'm not really into this FI2 thing (i find diskboot much better) so i don't know what to say..
-
Hi c10ud,
Following this thread closely as I can't wait to use CHDK on my S100! :)
When can we expect an official release?
And can I participate in the beta?
-
Hello, you can find the s100 beta build in the autobuild website already:
http://www.mighty-hoernsche.de/trunk/ (http://www.mighty-hoernsche.de/trunk/)
beware this is not a stable release
-
I wish I could code so that I could help more. Except for the battery levels being wrong issue, this build is pretty solid so far. I personally used EOScard 1.2 to make my SD card bootable, loaded my CHDK files on the card, then locked my card. I can now just turn on my camera by pressing and holding the play or on/off button. (no FI2 file needed) :D
I searched the internet for specific information about this build and could not find any. So I will write the specific information for anybody who is looking for it.
Features I have tested and work (so far):
* ISO override from 50 to 7500
* shutter speed override from 1/5000 to 2048 (34 minutes :o )
(I actually set a timer and returned just in time to here here the shutter close. 1 Picture took about an hour total an completely drained the battery)
* Aperture seem to stay within specs 2 to 8 (override higher than 8 seems to nothing)
* USB remote features all work well using a simple remote (could not test Ricoh CA-1)
I don't have a lot of time because of work. In my spare time I have been testing out this build of CHDK. I will write more as I get a chance.
EDIT:
hey c10ud.....when you try and choose a script from shooting mode it brings up the file browser but nothing gets highlighted so you can't really see what your are choosing. I mean it is minor since in play mode the browser is a bit different and it does highlight things. Kind of weird but just noticed it.
-
hey c10ud.....when you try and choose a script from shooting mode it brings up the file browser but nothing gets highlighted so you can't really see what your are choosing. I mean it is minor since in play mode the browser is a bit different and it does highlight things. Kind of weird but just noticed it.
Welcome to the world of Canon color palettes. Canon changes the palette it uses as it enter different modes ( playback, shooting, setup, video etc). CHDK currently has no good way to track this so the menu and OSD colors change as the Canon mode changes. Careful selection of colors can help but a good fix has not been worked out for this ( although philmoz has implemented a specialized fix for a few cameras).
-
I finally figured out I don't need to know coding that much using one of the gui's . So my question is what would I have to do to make things better.
For example how do I find battery max and min?
how do I help with circle of confusion?
....ect?
I dont have all the time in the world but with a little guidance maybe I can really help.
-
I finally figured out I don't need to know coding that much using one of the gui's . So my question is what would I have to do to make things better.
Probably the biggest thing you could do to help is test each version that you see released here. Especially the changes. Feedback from users is really really valued by the CHDK developers !
For example how do I find battery max and min? how do I help with circle of confusion?
....etc? I dont have all the time in the world but with a little guidance maybe I can really help.
I really hate to "rain on your parade" here, but by the time someone walks you through what it takes to make these sort of changes, they can make the changes themselves and post patches. However, just testing what works and does not work AND POSTING YOUR RESULTS is a really important thing - the devs do fixes and mostly hope nothing else breaks. Feedback helps a lot.
Update : okay, if you really want to try out making a change, compiling it and seeing it take effect, then to change the values for battery min and max at the bottom of the main.c file in trunk/platform/s100/main.c.
long get_vbatt_min()
{
return 3000; // 3 volts
}
long get_vbatt_max()
{
return 4100; // 4.1 volts
}
Play with the values until they work well for the S100.
-
colon247 ,
for Circle Of Confusion
using exiftool-8.90 on a JPG taken by your cam will get something like this:
......
"Circle Of Confusion : 0.005 mm"
....
-
waterwingz......thanks, I know it is a bit hard but I learn quick. I will soon try changing those numbers and see where I get. No promises but if I get somewhere with these numbers I will post.
asm1989.....thanks a lot......the circle of confusion right now in "shooting.c" is
int circle_of_confusion = 5; //TODO:
I am assuming this is wrong. So far after checking all my pictures and every picture on flickr taken with a s100 is seem that the number is .006 instead of .005
This might be a dumb question but what happens when this number is wrong?
-
This might be a dumb question but what happens when this number is wrong?
Nothing much. The calculated information for hyperfocal distance / depth of field information reported in the CHDK OSD will be slightly off - depending on how wrong the circles of confusion number is.
-
as for the boot, unfortunately i've been unable to find the correct value to check during boot in order to choose between play or rec so the camera only boots in play mode and then you have to switch manually (left as a todo in notes.txt)
I found this when looking for sx260 power on button.
for s100 in boot.c it should be
*(int*)(0x26E0+0x4) = (*(int*)0xC022F48C)&4 ? 0x200000 : 0x100000;
@colon247 would be great if you could test this.
-
I found this when looking for sx260 power on button.
for s100 in boot.c it should be
*(int*)(0x26E0+0x4) = (*(int*)0xC022F48C)&4 ? 0x200000 : 0x100000;
@colon247 would be great if you could test this.
Great news it works!!!!!! I compiled it and now I can hold my power button and it goes straight into shooting mode instead of play mode like before. :D
Edit:
I have also had time to test the battery levels. And the correct min max are:
long get_vbatt_min() // TODO:
{
return 3200;
}
long get_vbatt_max() // TODO:
{
return 4050;
-
Nice one funnel, how did you find the value?
I remember struggling a bit around that address and the value for a correct power on in play/rec mode but no luck :)
-
how did you find the value?
ROM:FF00FE48 loc_FF00FE48 ; CODE XREF: sub_FF00FDDC+10j
ROM:FF00FE48 ; sub_FF00FDDC+1Cj
ROM:FF00FE48 MOV R0, #0x36 ---------v Plug this value
ROM:FF00FE4C BL sub_FF02BC18 <-------< down here |
ROM:FF02BC18 sub_FF02BC18 ; CODE XREF: sub_FF00FDDC+24p
ROM:FF02BC18 ; sub_FF00FDDC+34p ...
ROM:FF02BC18 LDR R1, =dword_FF452BDC
ROM:FF02BC1C LDR R2, [R1,R0,LSL#3] //0xFF452BDC+(0x36<<3)==0xFF452D8C==0xC022F48C
ROM:FF02BC20 LDR R2, [R2]
ROM:FF02BC24 ADD R0, R1, R0,LSL#3
ROM:FF02BC28 LDR R0, [R0,#4] //0xFF452D8C+0x4==0x00000004
ROM:FF02BC2C ANDS R0, R0, R2
ROM:FF02BC30 MOVNE R0, #1
ROM:FF02BC34 BX LR
that's it 0xC022F48C & 0x00000004
-
Got it, thanks!
-
WOW.....did you guys go to a university to learn this. Those two codes that funnel wrote went way over my head :blink: ....jajaja
You smart people figure out anymore codes that might work, throw them at me I will try it.
for now I will stick to the simple stuff
-
sent patch for trunk: http://chdk.setepontos.com/index.php?topic=650.msg85140#msg85140 (http://chdk.setepontos.com/index.php?topic=650.msg85140#msg85140)
-
was reading through c10ud's changes about Fi2 and.....
Does anybody actually know the Fi2key for the s100 yet?
If nobody has it....is it hard to find?
Will the Fi2 fix for the SX260 work for this camera?
c10ud-----if you are working on this already, let me know and I will just wait :)
-
since i don't have the camera anymore i'm not working on this, but i am confident that the fix for sx260 will apply to s100 too, just wait until it gets upstreamed or apply the patch by yourself ;)
-
I have already placed the new Fi2enc.c in "tools\packfi2". I just need the "Fi2key" and "Fi2IV" values for the "fi2.inc" and I can test it.
I also already removed:
#suppress FI2 since it doesn't work
override OPT_FI2=
I get an error right now because I don't have the Fi2 values
if anyone can find these please share with me :)
-
for ver 101a you can find them
FI2KEY is at offset 0xFF3B28
FI2IV offset 0x63AF20
they look like this
FI2KEY=F7ABABABABABABABABABABABABA70
FI2IV =F7ABABABABABABABABABABABABA98
first and last byte are correct for orientation. You can use a simple hex editor.
http://chdk.wikia.com/wiki/For_Developers/fi2offsets (http://chdk.wikia.com/wiki/For_Developers/fi2offsets)
EDIT: typos
-
since i don't have the camera anymore i'm not working on this, but i am confident that the fix for sx260 will apply to s100 too, just wait until it gets upstreamed or apply the patch by yourself ;)
Unlikely, the S100 has DryOS version R49. I checked and it has the same block record size as other cameras up to that version.
Do you get an 'Update file error' when you try and manual boot or does the camera simply lock up?
The 'Update fle error' will occur if the file size or checksum are wrong, the platform id is wrong or there is no boot block record in the file. The new entry in the block record for R50 threw off the file size calculation which is why the SX260 gives this error.
Phil.
-
I have been working on this all day and failed.
philmoz....I think originally it just locked up. people stated it went to black screen and that was that.
I just wish I knew the right offsets for 101a so that I could help with this.
I might have found one but not the other.
Funnel was talking about 101b. I did not think there was a 101b.
:blink: maybe someone will figure this out. someone smarter than me....hahahaha
-
I did not think there was a 101b.
Sorry, I meant 1.01a.
-
Okay I after setting the keys and builing a PS.FI2 these were the results:
old fi2enc.c - when I choose the firmware update....the camera just turned off
SX260's fi2enc.c - when I go to try and choose update I get an update error
-
SX260's fi2enc.c - when I go to try and choose update I get an update error
This will create a PS.FI2 file with the wrong block record size so the file will fail the validation checks (the file size calculation will fail). Hence the 'update file error' message.
There are a number of cameras that just don't work with manual booting at the moment.
It should be possible since Canon has released a real firmware update for the camera; but it will require more detailed investigation into the boot process and perhaps detailed analysis of the Canon firmware update file.
Phil.
-
I used for a long time a S95 camera with CHDK, and now I have a S100 on my hands but I'm not figuring out how to boot the CHDK on this camera, I saw that the firmware version is 1.01a so I formated the card and make it bootable with cardTricks then copied the right files, but when I locked the card and put it on the camera, it doesn't boot (the same thing happens in S95 if put the wrong firmware version on the card).
Am I doing something wrong ? I really need the CHDK, because I use the camera in UAVs and I need the remote trigger function and to run a script that I developed to set some configs like Focus.
Thanks in advance.
-
fvztdk ---
Dont know if it makes a difference but I made my card bootable with EOScard 1.2
Just format your card, use EOScard 1.2, then place the right files from 101a you just unzipped.
press and hold play to turn on your camera you will see CHDK logo. then have fun. :D
if it still does not work---- :(
Are you sure you have 101a. take a picture (of something like your wall for simplicity) with your camera, upload it to Flickr, then post a link I will double check the firmware version for you.
-
fvztdk ---
Dont know if it makes a difference but I made my card bootable with EOScard 1.2
Just format your card, use EOScard 1.2, then place the right files from 101a you just unzipped.
press and hold play to turn on your camera you will see CHDK logo. then have fun. :D
if it still does not work---- :(
Are you sure you have 101a. take a picture (of something like your wall for simplicity) with your camera, upload it to Flickr, then post a link I will double check the firmware version for you.
I tested the firmware version with CameraVersion13 that I get on CHDK website.
I will try the EOScard software.
-
The EOScard worked very well, I just don't know how the other software don't.
Thanks colon247
-
I have another question.
Is the focus setting and zoom setting already working ?
In my script I use this code to set to manual focus, set the zoom and then set the focus
press "shoot_half"
sleep 5000
press "left"
sleep 500
release "left"
release "shoot_half"
sleep 500
print "manual focus set"
print a
set_zoom_speed 20
sleep 100
rem set_zoom 5,844
set_zoom a
sleep 2000
print "zoom set"
set_focus f
press "print"
sleep 200
press "display"
sleep 300
release "display"
release "print"
print "focus to infinite"
The manual focus is set, but the zoom does nothing, and when the set focus commands switch the camera to playback mode.
Anything changed in the language ?
-
I have another question.
Is the focus setting and zoom setting already working ?
In my script I use this code to set to manual focus, set the zoom and then set the focus
press "shoot_half"
sleep 5000
press "left"
sleep 500
release "left"
release "shoot_half"
sleep 500
print "manual focus set"
print a
set_zoom_speed 20
sleep 100
rem set_zoom 5,844
set_zoom a
sleep 2000
print "zoom set"
set_focus f
press "print"
sleep 200
press "display"
sleep 300
release "display"
release "print"
print "focus to infinite"
The manual focus is set, but the zoom does nothing, and when the set focus commands switch the camera to playback mode.
Anything changed in the language ?
I figure it out, since the button layout changed I used the set_focus command since the key combination that I was using before doesn't work anymore
-
I tested this today :) :
Manual video focus while recording and it works.....on this camera instructions are (in case anybody wants to know) :
-----set to video on dial
-----set to manual focus
-----press record button
-----activate <ALT>-mode
-----press left on back ring (MF) 2 times
-----use zoom to adjust focus
-----now just toggle <ALT> now to switch between the 2
Anybody know why I have to push left 2 times to get the manual focus to work?
Is that how my camera is or CHDK in general?
-
old fi2enc.c - when I choose the firmware update....the camera just turned off
Can you do the following:
- build CHDK with the PS.FI2 file (using original fi2enc.c)
- manual boot the camera from the PS.FI2 (Firm Update menu option)
- after the camera shuts down wait a few seconds then remove and re-insert the battery
- boot CHDK from an autoboot SD card
- run the 'Save ROM crash log' option in the Miscellaneous stuff --> Debug Parameters menu
- post the ROMLOG.LOG file saved on the SD card here.
Phil.
-
Here it is....I read though it and read something about lens error. I know I turned on my camera yesterday with the lens blocked just in case it matters. I really don't know much else about this file.
I followed your directions exactly though.
-
Here it is....I read though it and read something about lens error. I know I turned on my camera yesterday with the lens blocked just in case it matters. I really don't know much else about this file.
I followed your directions exactly though.
Thanks for that.
I wanted to see if it was logging any debug assert errors when running the PS.FI2 file.
It doesn't look like it has - as you said the error is a lens error unrelated to booting the PS.FI2.
Back to the drawing board.
Phil.
-
What bout the wrong lines in loader/cam/entry.S ? Do they affect anything?
@colon247
You could try to comment them out to see if it makes any difference.
leave just this lines
MOV SP, #0x1900
MOV R11, #0
B my_restart
-
What bout the wrong lines in loader/cam/entry.S ? Do they affect anything?
@colon247
You could try to comment them out to see if it makes any difference.
leave just this lines
MOV SP, #0x1900
MOV R11, #0
B my_restart
Tried this before going to work. This one did not change anything though. The camera still turned off.
-
One thing you could do is try blinking LEDs at various points to see how far it gets.
-
Hello all
I've finally jumped in after reading about CHDK for a while and got it running on my S100. I've managed to get the intervalometer working (which is what I need) but I was wondering, I noticed that when selecting the script, there is no icon/shading etc in the script library to indicate which script is selected, so you kind of have to guess how far you've scrolled to see if you've selected the right script. Is this normal or a bug? Part of the alpha process on the CHDK? (Also, the OSD flickers slightly during use)
Sorry if it's common knowledge, this is all totally new to me!
-
I've managed to get the intervalometer working (which is what I need) but I was wondering, I noticed that when selecting the script, there is no icon/shading etc in the script library to indicate which script is selected, so you kind of have to guess how far you've scrolled to see if you've selected the right script. Is this normal or a bug?
The selected item in a menu or file browser should be highlighted with different color background. Note that camera color palettes change depending on what mode the camera is in, so the colors might be right in playback and wrong in record.
Example of what it should look like: http://images2.wikia.nocookie.net/__cb20091206143845/chdk/images/thumb/0/0f/TextFileRead-Change_Font_etc.jpg/830px-TextFileRead-Change_Font_etc.jpg (http://images2.wikia.nocookie.net/__cb20091206143845/chdk/images/thumb/0/0f/TextFileRead-Change_Font_etc.jpg/830px-TextFileRead-Change_Font_etc.jpg)
You can customize all the colors, but the default should allow you to tell which item is selected. The exact colors may be different from what's in the screenshot, because the cameras have a limited palette that varies between models.
(Also, the OSD flickers slightly during use)
This is probably normal, the CHDK and original firmware drawing routines aren't really aware of each other.
-
One thing you could do is try blinking LEDs at various points to see how far it gets.
How and where do I set that up? Or point me to instructions. :) Thanks!
zpyder----Playback mode is fine so if you select the script in playback mode you will see the highlighted scripts. The problem is the shooting mode palette.
-
One thing you could do is try blinking LEDs at various points to see how far it gets.
How and where do I set that up? Or point me to instructions. :) Thanks!
http://chdk.wikia.com/wiki/Debugging#LEDs (http://chdk.wikia.com/wiki/Debugging#LEDs)
Probably not worth attempting if you aren't a programmer, if you don't know what you are doing it's very easy to cause new crashes rather than actually discovering where it's crashing now.
-
reyalp----it okay I figured as much : )
I will just keep doing what I can
-
Figured out how to fix the script highlight issue :D :
in \platform\camera\platform_camera.h
we just need to change the 9 to 7:
#undef CAM_BITMAP_PALETTE
#define CAM_BITMAP_PALETTE 7
With this all menu are readable.
It is not as colorful though. If you don't like the colors change it using.
Alt menu>Visual Setting>
Change "Menu background" and "Symbol Background Color" to change colors
Question ??? :
Can I set individual colors manually in "platform_camera.h" or another file?
Just so I can refine this a little more.
-
Question ??? :
Can I set individual colors manually in "platform_camera.h" or another file?
The colors used by CHDK are defined in palettes contained in core/gui_draw.h. These values map against the colors you see when you use the Visual Settings menu to look at any of the color choices. Unfortunately, if you look at that CHDK menu when the camera is in different modes ( shooting, playback, menu, ...) you will get much different colors. For many cameras, the first 32 colors (or so) stay the same across modes so if you can select from them it helps a bit. There is a really complicated fix that philmoz got working for a couple of his cameras but it has not been extended to any other cameras.
-
:-[ oops....earlier I made a mistake.....I did not update all the files in my chdk folder.....so I ended up with semi transparent window in play.
well turn out it was actually solid grey.....small mistake and I just dont want to give misinformation
I fixed that post for anyone who reads it in the future.
Question:
how long does it take for changes to make it into the trunk?
I ask because c10ud posted a patch/update on may 7th and it still has not gone in.
How do I make one so I can add the palette change to the trunk?
-
Thank you everyone, it's so much easier to set things up in playback mode, I didn't realise!
Will it be likely do you think that there will ever be an option to disable the screen without needing to use the AV socket trick? I ask as I am using the CHDK with an underwater housing, and can't really fit anything in the sockets whilst the camera is in the housing.
-
how long does it take for changes to make it into the trunk? I ask because c10ud posted a patch/update on may 7th and it still has not gone in.
It usually takes just a day or two. All depends on how busy the devs are with other things in their lives. Sometimes it goes faster if they know the submitter already and it always goes faster if you submit a patch file to the right forum thread :
[REQ]Adding new cameras, applying patches into trunk (with source code prepared) (http://chdk.setepontos.com/index.php?topic=650.0)
I see c10us submitted a file there but did not use a .patch or .diff extension (even though it appears to be a valid patch file) so it might have been overlooked.
After a suitable wait, you can always ping one of the devs via PM - there are really only three of them who are active these days. Just don't abuse that option obviously.
How do I make one so I can add the palette change to the trunk?
You basically need to have a download of the svn source tree and a working development environment to test things. On windows the easiest way to do that is to use CHDK-Shell. Or find somebody who is setup correctly to do it for you ? Here's an example of what I think you want. Feel free to submit it to the patch thread if so :
-
Thanks! That is exactly what I needed. I submitted it to the patch thread with thanks given to you for preparing the patch file :)
-
Hey guys,
I'm very interested in contributing and helping test this. However I'm getting nowhere getting this installed! ???
When trying to check the firmware installed using the Play, then Set + Disp buttons I get nothing but the clock. I have vers.req on my formatted 2GB card.
Even if I go to look for the Firmware Update menu item, it's not there. I tried pressing Play button twice as per the Readme with no joy.
Any anyone got S100 specific step-by-step instructions to get this loaded?
Thanks!
-
Take a look at this : http://chdk.wikia.com/wiki/Prepare_your_SD_card (http://chdk.wikia.com/wiki/Prepare_your_SD_card)
You probably want to pay particular attention to the part about using the Acid application to determine your firmware version.
-
I just prepared a quick guide for this camera :)
Any anyone got S100 specific step-by-step instructions to get this loaded?
Thanks!
It is the step by step you were looking for
http://chdk.wikia.com/wiki/CHDK_quick_install_Guide (http://chdk.wikia.com/wiki/CHDK_quick_install_Guide)
-
Thanks for your hard work guys. I had a s95 that I used for time lapse until sand killed it.
It was a task to get the 16GB SD card bootable, partitions did not work. HDHacker and xvi32 worked, however.
Appreciate the work you guys are putting into getting this out.
-
What would it take to make this a BETA build?
It seems pretty stable and most of the issues seem to be minor in my opinion.
The only big issue I can think of is maybe the movie override quality.
Here are the issues below. I just have no idea where to start.....if I can attack this at all.
I have seen some of the disassembled dump. :o
How do you guys find anything in there?
I think I need to go back to a school for this...haha
From Notes.txt
CAMERA TODO/KNOWN ISSUES:
- manual loading with "firm update" loading crashes (confirmed on 100d and 101a), so PS.FI2 is not included in the autobuild. (to be fixed soon http://chdk.setepontos.com/index.php?topic=7889.msg85060#msg85060 (http://chdk.setepontos.com/index.php?topic=7889.msg85060#msg85060))
- various defines in platform_camera.h needs to be checked
- value for SleepTask in kbd.c instead of hardcoded 10 (minor issue)
- values for Jogdial events in lib.c
- 100d, 100e, 101a: movie override quality seems to be working but values might be wrong (stock Canon reaches 4MB/s, CHDK quality 99 2MB/s)
- 100d, 100e, 101a: jogdial is untested and needs correct rear_dial_position address in stubs_min.S
-
Quick comments:
Just note i've been wrong with the PS.FI2 issue, it's been found it's not the same as SX260HS so it's not "easy" nor "soon".
The defines must be checked with features and so far they turned out pretty good.
The value for SleepTask is a non-issue.
Jogdial values/rear dial position: unknown and untested.. (and useless?)
Movie override quality is interesting though, even if i wonder if overriding quality is needed..
-
I would personally like to know the LED address for the AF led.....I have no idea how to look for it though.
I also think we should update the note.txt removing SleepTask and platform_camera.h
The rear Jogdials don't seem to have a use right now......but in the future you never know.
Last is how do we verify if we need movie override quality setting?
edit:
quick question I keep getting unable to split patch.txt in chdk shell when trying to make diff......anybody ever get that?
-
sx200is 100c
Full display EdgeOverlay if CHDK in EXMEM.
SCREEN_COLOR to 15 (was white in playback mode).
-
quick question I keep getting unable to split patch.txt in chdk shell when trying to make diff......anybody ever get that?
I gave up on the CHDK-Shell diff function some time ago. Maybe whim has improved it since but I now use Tortoise_svn (on windows) or svn command line (on Linux) to get the latest source versions, edit those and then use the built-in patch functions to make patch files.
-
waterwingz thanks again :D that is exactly what I wanted!
Hey is there any way to map the ring function button on the back?
Also I have been testing scripts and I have a question:
What would cause image fish-eye when using zoom script?
-
waterwingz thanks again :D that is exactly what I wanted!
Its a little difficult to swap between the CHD-Shell environment and an svn directory tree. There is probably an easy way to make them work together but I finally gave up and created batch files that use the CHDK-Shell environment (gcc etc) to compile svn downloaded directories in a batch file / command window.
Hey is there any way to map the ring function button on the back?
If you can figure out which bits change in the memory mapped I/O registers then adding new functions seems easy.
Also I have been testing scripts and I have a question: What would cause image fish-eye when using zoom script?
RAW or jpg ?
-
What would cause image fish-eye when using zoom script?
My guess:
At the wide end the lens has barrel distortion that is removed in software when the JPEG is produced. As you zoom in this distortion quickly disappears.
The lens_set_zoom_point function in wrappers.c is used by scripts to zoom the lens.
On some cameras (G10 & G12) extra code is needed to tell the camera where the lens has been zoomed to.
Without this the camera still thinks it's at the wide end and applies the distortion correction even when it is not needed.
Phil.
-
waterwingz
I shot it a jpg.
you have any tips on where to start looking for a new button?
philmoz
Thanks! that makes complete sense.
Later I will try shooting in raw without a script to see if it still produces a fish-eye.
-
you have any tips on where to start looking for a new button?
so far most of the memory mapped i/o for buttons etc has ended up in a three word array. It's read in platform/s100/kbd.c at the start of the routine my_kbd_read_keys(). At one point I printed the whole array to the screen from the spytask() when I was looking for something. If you look at the bottom of the spytask code in core/main.c you can still see where I inserted the hack - its commented out now with a #ifdef DEBUG_PRINT_TO_LCD ....
-
you have any tips on where to start looking for a new button?
so far most of the memory mapped i/o for buttons etc has ended up in a three word array. It's read in platform/s100/kbd.c at the start of the routine my_kbd_read_keys(). At one point I printed the whole array to the screen from the spytask() when I was looking for something. If you look at the bottom of the spytask code in core/main.c you can still see where I inserted the hack - its commented out now with a #ifdef DEBUG_PRINT_TO_LCD ....
Or enable the 'debug keymap' code in the gui_draw_debug_vals_osd() function in core/gui.c.
Phil.
-
you have any tips on where to start looking for a new button?
so far most of the memory mapped i/o for buttons etc has ended up in a three word array. It's read in platform/s100/kbd.c at the start of the routine my_kbd_read_keys(). At one point I printed the whole array to the screen from the spytask() when I was looking for something. If you look at the bottom of the spytask code in core/main.c you can still see where I inserted the hack - its commented out now with a #ifdef DEBUG_PRINT_TO_LCD ....
Or enable the 'debug keymap' code in the gui_draw_debug_vals_osd() function in core/gui.c.
Phil.
Having said all this, I realized that the jog dial on the G10 (and I assume other cameras) is not interfaced through the keymap. You mentioned earlier that you were looking for the "ring dial" on the back of the camera - it might not be their either.
-
Has anyone used the Motion Detect script on the s100?
The MD script tries to focus after detecting motion unless you have MF set up on the ring.
Even when it does not adjust focus prior to shooting it still takes a very long time to shoot (even in high lighting, Manual, quick shutter speed, JPEG, dark frame subtraction shouldn't be an issue at quick shutter speeds).
Does anyone have any ideas? Is this a delay built into the script?
Moreover, instead of taking just 1 picture or a quick burst it continuously takes pictures untill manually stopped.
Thanks in advance.
-
I use a lightning script that takes a pictures super quick, but for some reason you have to wait like 1 or 2 seconds when you first start it before it will work right.
Mine also continues taking pictures until manually stopped as well.......so is this a script problems or chdk problem? ???
Edit:
The normal motion scripts seem to sometimes start shooting by itself when left alone a few second and no movement. If I set shutter speed less and make the image darker it stops sometimes.
-
The normal motion scripts seem to start shooting by itself when left alone a few second and no movement.
This probably means either your sensitivity is set too high, or there is something wrong with the buffer addresses or dimensions which causes it to read garbage
edit:
By sensitivity I mean md threshold (low = more sensitive to changes), but higher ISO will mean more noise, which will require a high threshold.
-
I am using the normal motion script. I dont think it is the sensitivity.
sometimes I also get this on the screen when trying to end the loop:
":23: attempt to compare number with nil"
here is a video and a picture of the error if it helps:
http://youtu.be/tCIBezuJ828 (http://youtu.be/tCIBezuJ828)
(https://chdk.setepontos.com/proxy.php?request=http%3A%2F%2Ffarm8.staticflickr.com%2F7082%2F7230182386_60eedef6eb.jpg&hash=1ac3539b17f93dae085003f0ad9930ef)
-
I am using the normal motion script.
If by "normal" you mean the one that's packed into the CHDK distribution then you need to know that script is a simple "throw away" included just to demonstrate how to call the MD function. The parameters it uses were quite frankly pulled out of air and will need to be tuned for each camera and shooting situation. Some of the more sophisticated shooting scripts (expecially those specifically for lightening) might be a better starting point.
-
My head is about to explode.....hahahaha :lol
I have been at this for a couple hours now.....and I am talking about:
Or enable the 'debug keymap' code in the gui_draw_debug_vals_osd() function in core/gui.c.
Phil.
and
so far most of the memory mapped i/o for buttons etc has ended up in a three word array. It's read in platform/s100/kbd.c at the start of the routine my_kbd_read_keys(). At one point I printed the whole array to the screen from the spytask() when I was looking for something. If you look at the bottom of the spytask code in core/main.c you can still see where I inserted the hack - its commented out now with a #ifdef DEBUG_PRINT_TO_LCD ....
I go uncomment these... build... and then have no idea what I am supposed to do after that....or if I am even doing it right :(
am I missing something?
Can you guys explain a little more?
-
On the first script issue I had with the script causing fisheye. I tried shooting in raw (canon raw) and got no fish-eye distortion.
Could the camera be correcting this even in Raw?
-
On the first script issue I had with the script causing fisheye. I tried shooting in raw (canon raw) and got no fish-eye distortion.
Could the camera be correcting this even in Raw?
If you mean canon native raw, I'd guess the canon software knows how to correct it.
-
I go uncomment these... build... and then have no idea what I am supposed to do after that....or if I am even doing it right :(
am I missing something?
Can you guys explain a little more?
In both cases, what you get is the ability to "dump" information from the cameras memory to the screen. You use that to look for values that change when the ring dial is activated.
-
Has anyone used the Motion Detect script on the s100?
The MD script tries to focus after detecting motion unless you have MF set up on the ring.
Please disable the "SafetY-MF".
Then the Motion Detection will work fine in MF-Mode !
-
Hi guys, I have been using CHDK on my SD900 & SD990, just got the S100 and loaded it today. I will be testing the port based on my other cameras usage. So far the loading and card setup is much easier, Thanks for all your efforts.
Hans
-
I did have some time to play today and checked out most over rides SS, Aperture, ISO, Focus, Quality (SF), and additional display info, DOF Calc, Time, Battery, and Remote control. and many menu functions, DNG, and Raw save incl. the resulting images in PS Elements. All works like my SD990. I did notice the battery voltages were not the same as my SD900 or SD990 that use the same battery??? both my SD's use 3975 - 3425 the S100 has 4050 - 3200
I didn't read the entire thread so I assume all the functionality has already been checked.
I am running firmware 1.01a
Hans
update after running several battery cycles is seems the 4025 and 3425 works for me on my S100 and the SD's using the same type battery
-
Hnikesch
I noticed that after a while that the battery percent voltages were not the same among all my batteries. Perhaps it is not such a perfect system. I have gotten used to it though. I tested my number using the factory battery. Maybe it is just different on every camera. The ebay battery never worked well the battery percent I have now.
Hnikesch are you a programmer?
-
I tried .dng raw for some images and when I shoot at the wide end the image is distorted (fisheye like) in the .dng image but the camera fixes the distortion in Canon Raw and jpeg images. It's so bad I don't want to use CHDK .DNG. I didn't see this on my SD990 .DNG images. It's interesting how much the image is manipulated by the in camera image processor. Too bad PSE can't import S100 Canon raw without first running Adobe conversion to .dng.
-
Hnikesch
I tested my number using the factory battery. Maybe it is just different on every camera. The ebay battery never worked well the battery percent I have now.
Hnikesch are you a programmer?
No just a shooter, I am using all Canon batteries. It's amazing to see what you guys have done on just over 2 months, the SD900 & SD990 ports were a lot longer in process. Great job
-
I found a back door to load Adobe Camera Raw 6.6 into SPE 9, the wonders of Google. Now I can directly edit Canon S100 raw in PSE
-
I've loaded the latest version for the S100 (s100-101a-1.1.0-1916) and have the time lapse feature working. To save on battery, I'm trying to get the display to turn off between shots. I've tried "Ultra-intervalometer" and "Accurate Intervalometer with power-saving and pre-focus" but neither will turn off the display. I've read that I can plug in an HDMI cable, but I would think that would consume more battery if it is trying to drive an external monitor. Is that not the case? Is there some way to get the display to go off without having to use an HDMI cable?
-
I've loaded the latest version for the S100 (s100-101a-1.1.0-1916) and have the time lapse feature working. To save on battery, I'm trying to get the display to turn off between shots. I've tried "Ultra-intervalometer" and "Accurate Intervalometer with power-saving and pre-focus" but neither will turn off the display. I've read that I can plug in an HDMI cable, but I would think that would consume more battery if it is trying to drive an external monitor. Is that not the case? Is there some way to get the display to go off without having to use an HDMI cable?
If you look through old posts here you will find that the LCD backlight does not actually consume a lot of power compared to the rest of the camera electronics. So don't expect much more than 10% - 20% battery life improvement with the backlight off.
Here's a link to a modified version of the default intervalometer script with code to turn off the backlight after each shot :
http://chdk.setepontos.com/index.php?topic=8216.msg86424#msg86424 (http://chdk.setepontos.com/index.php?topic=8216.msg86424#msg86424)
-
If you look through old posts here you will find that the LCD backlight does not actually consume a lot of power compared to the rest of the camera electronics. So don't expect much more than 10% - 20% battery life improvement with the backlight off.
Here's a link to a modified version of the default intervalometer script with code to turn off the backlight after each shot :
http://chdk.setepontos.com/index.php?topic=8216.msg86424#msg86424 (http://chdk.setepontos.com/index.php?topic=8216.msg86424#msg86424)
I'll take the 10-20%! Thanks for the link to the set_backlight code--it works great on my S100.
Here is intervalometer code with optional focus lock and adjustable delay before backlight goes off:
rem Intervalometer with backlight control
rem and focus lock. Note: focus lock happens
rem not on first focus, but after the first
rem shot and just before the backlight goes
rem off. Adjustable delay before backlight
rem goes off (b) allows time for lengthy
rem post-shot activities like review. If
rem none, b can be shortened to 1.
@title int_BLFL
@param a = interval (sec)
@default a 10
@param b = backlight delay (sec)
@default b 3
@param c = use focus lock? (1/0)
@default c 1
if get_mode = 0 then goto "in_rec"
sleep 1000
set_record 1
:wait_rec
sleep 100
if get_mode <> 0 then goto "wait_rec"
:in_rec
s = (a*1000)+get_tick_count
shoot
sleep b*1000
set_aflock c
set_backlight 0
do
sleep 500
until (s <= get_tick_count)
do
s = (a*1000)+get_tick_count
shoot
sleep b*1000
set_backlight 0
do
sleep 500
until (s <= get_tick_count)
until ( 0 )
:restore
set_backlight 1
set_aflock 0
sleep 1000
end
-
I've been following this thread and I am very impressed with the work accomplished
I apologize if this has been addressed or inappropriately placed, but has anyone been able to get a script to work allowing the flash ttl to function in M mode
I believe there has been a script bouncing around that would do this in the S95…but with the Digic processor change, it is doubtful that this would work
-
First, thank you to everyone who works on this. I can't imagine getting started on this myself!
On the S100, when you go over a 1 second exposure, the ISO is forced to ISO 80.
Is there a way to change this via CHDK? If yes, a pointer would be appreciated. I have reviewed the ISO section in the menu but am not sure how to alter it to achieve this.
Thank you,
David
-
On the S100, when you go over a 1 second exposure, the ISO is forced to ISO 80.
Is there a way to change this via CHDK? If yes, a pointer would be appreciated. I have reviewed the ISO section in the menu but am not sure how to alter it to achieve this.
Yes, once you load the CHDK onto your camera hit the play button (alt) then menu. This will take you into the CHDK Menu. Go into Extra Photo Operations, there you can change the ISO Value manually (imput a value and a multiplier). Make sure you change Disable Overides at the top as well. While you are shooting it will tell you the ISO you're using in the top Left.
I think this is one of the best features of CHDK on the s100.
Matt
-
I think this is one of the best features of CHDK on the s100.
As a matter of interest what practical benefits have you seen from this and under what situations ?
David
-
Yes, once you load the CHDK onto your camera hit the play button (alt) then menu. This will take you into the CHDK Menu. Go into Extra Photo Operations, there you can change the ISO Value manually (imput a value and a multiplier). Make sure you change Disable Overides at the top as well. While you are shooting it will tell you the ISO you're using in the top Left.
Thank you! That was simple enough!
David
-
I think this is one of the best features of CHDK on the s100.
As a matter of interest what practical benefits have you seen from this and under what situations ?
David
Since the s100 auto sets the ISO to 80 stars and other real low light items do not show up well. The override makes very low light photography possible for example. It's better than post production on the computer. If your exposure is too long you get streaking stars (which might be desirable).
Matt
Edit: I uploaded a test video of the ISO override filming the stars to youtube Time Lapse Afghanistan Stars (http://www.youtube.com/watch?v=ZqEYj4dePGc#ws). It's not the best quality, but will demonstrate the potential capability of one aspect of CHDK.
Edit2: I'm sorry it put the video in here, I didn't mean for it to do that, but can't remove it without taking the link out.
-
Thanks for that.
Can you explain what difference I am looking for ?
If you did not use override what would the difference be ?
I bet you get really clear skies there !
David
-
Thanks for that.
Can you explain what difference I am looking for ?
If you did not use override what would the difference be ?
I bet you get really clear skies there !
David
The Canon S100, unlike the S95, automatically sets the ISO to 80 when the exposure time goes over 1 second due to the CMOS sensor it has (most likely). If you were taking pictures of the night sky with an ISO of 80 there would be nothing besides blackness. With the manual override turned on with CHDK you can set up to I think 20000 or something rediculous like that. With higher ISO it will break out the dark objects without sacrificing an extremely long shutter speeds. You can also change shutter speed, aperature, etc overrides as well thanks to CHDK.
Matt
-
Hi,
first I want to thank all developers here who did a great job for porting the s100.
I saw (on http://chdk.wikia.com/wiki/For_Developers (http://chdk.wikia.com/wiki/For_Developers)) that the color for the s100 turns from pink to green - yeah!
On http://chdk.wikia.com/wiki/S100 (http://chdk.wikia.com/wiki/S100) there is a link to the trunk:
>CHDK is available as an ALPHA version for the Powershot s100 with firmware versions 1.00D, 1.00E,and 1.01A from >http://www.mighty-hoernsche.de/trunk/ (http://www.mighty-hoernsche.de/trunk/)
But if I click on it it just shows:
CHDK-SVN Autobuild Download
This is the development version of CHDK which is considered "Unstable"
For the stable release click here
Complete zips contain additional files like scipts, grids, language files, RBF fonts and curves
Small zips contain the bare DISKBOOT.bin and PS.FIR/PS.FI2
Camera FW Complete Small
Errors occured during this build! Old version available here
But neither under the link 'here' not the link 'Older versions...' a trunk for s100 can be found. :(
Could someone of the developers please check?
Thanks a lot!
-
the autobuild website is probably being updated since chdk stable version is going to change (trunk will become stable and heavy development will resume), you may need to wait a bit until everything is restored (and probably will find s100 in the 'stable' autobuilds)
-
the autobuild website is probably being updated since chdk stable version is going to change (trunk will become stable and heavy development will resume), you may need to wait a bit until everything is restored (and probably will find s100 in the 'stable' autobuilds)
That probably won't happen until next weekend. The build broke last night for other reasons related to fixing some weirdness in one of the Makefiles.
-
OK guys,
thanks for reply!
-
I really don't know if this is the right place to ask this but I assumed this was the right place. I am really sorry if im wrong. ;)
I don't want to push or anything, just wondering as I have the S100 with firmware 1.01B. And there's no CHDK for 1.01B available yet. Is there already development on 1.01B? I saw it was already dumped here July 02. :)
-
I don't want to push or anything, just wondering as I have the S100 with firmware 1.01B. And there's no CHDK for 1.01B available yet. Is there already development on 1.01B? I saw it was already dumped here July 02. :)
I can understand your concern - its frustrating when you want to play with something like CHDK and it just not available for your firmware version. Sometimes the original person who did the port will convert for another version. But otherwise, you're kind of stuck until somebody with the right skills who typically owns the same camera comes along.
In general, if somebody is working a port (or a firmware conversion) they post in the porting thread - so you are looking in the right place.
Incidentally, did you try the 1.01a version to see if it will work on your 1.01b camera ?
Standard FAQ answer here : CHDK FAQ : My camera isn't ported yet (http://chdk.wikia.com/wiki/FAQ#Q._My_camera_isn.27t_ported_yet._Is_a_port_planned.C2.A0.3F_When_will_it_be_ready.C2.A0.3F_How_can_I_help.C2.A0.3F)
-
Hello, I did the original port but I'm currently very busy..
I don't exclude that in future I could try porting 101b too but in general what waterwingz said stands correct. (and I'd add that once you have a camera ported, another firmware version isn't very difficult).
-
Hello c10ud, thanks for bringing CHDK to the S100. I just purchased an S100, and to my disappointment, it is firmware 1.01B.
I will gladly help beta test 1.01B, and thanks a million for all your help and effort.
Kind regards,
-
same issue...waterwingz...wher can we get the "A" version of firmware. I've searched the canon site, but they only post the latest
-
same issue...waterwingz...wher can we get the "A" version of firmware. I've searched the canon site, but they only post the latest
Basically, you can't. Canon does not typically provide firmware updates unless there is a major bug. And without their update, you can't change your camera's firmware version. Sorry.
-
worth the try...I'll post results later today
-
sorry...I meant I'll try the version "A" CHDK
-
S100 "A" does not appear to work with firmware version "B"
The camera actually hangs up with card locked and battery has to be removed to get camera to start with card unlocked
Verified boot sector was in place with HDHacker. Made disk bootable with EOS card and CHDK files were unzipped directly to SD card, not copied
-
The camera actually hangs up with card locked and battery has to be removed to get camera to start with card unlocked
I can confirm the same behavior when attempting to use the "s100-101a CHDK firmware" on my S100 (FW: 1.01b).
-
101a and 101b are different firmware. grep from German forum found the differences and compiles a running 101b version.
http://forum.chdk-treff.de/viewtopic.php?p=26046#p26046 (http://forum.chdk-treff.de/viewtopic.php?p=26046#p26046)
$ diff -r 101a 101b
diff -r 101a/boot.c 101b/boot.c
150c150
< " LDR R0, =0xFF64BE6C \n"
---
> " LDR R0, =0xFF64BECC \n"
158c158
< " LDR R1, =0x195D34 \n"
---
> " LDR R1, =0x195D34 \n"
Only in 101b: boot.c~
Binary files 101a/boot.o and 101b/boot.o differ
Only in 101b: copybin.sh
Only in 101b: dumpelf.sh
Binary files 101a/libplatformsub.a and 101b/libplatformsub.a differ
Only in 101b: primary.asmdump
Binary files 101a/PRIMARY.BIN and 101b/PRIMARY.BIN differ
Only in 101b: primary.elf
Only in 101b: stubs_entry.diff
diff -r 101a/stubs_entry.S 101b/stubs_entry.S
6c6
< // Firmware Ver GM1.01A
---
> // Firmware Ver GM1.01B
22c22
< // Firmware modemap table found @ff09cf84 -> ff099208 -> ff205770 -> ff3877c4 -> ff626550
---
> // Firmware modemap table found @ff09cf84 -> ff099208 -> ff205770 -> ff3877c4 -> ff6265b0
28,29c28,29
< //DEF(levent_table ,0xff5905cc) // Found @0xff5905cc, stubs_min = 0xff5905cc (0xff5905cc)
< //DEF(FlashParamsTable ,0xff6267b4) // Found @0xff6267b4, stubs_min = 0xff6267b4 (0xff6267b4)
---
> //DEF(levent_table ,0xff59062c) // Found @0xff59062c, stubs_min = 0xff59062c (0xff59062c)
> //DEF(FlashParamsTable ,0xff626814) // Found @0xff626814, stubs_min = 0xff626814 (0xff626814)
106c106
< NSTUB(ExecuteEventProcedure ,0xff08d868) // 1
---
> NSTUB(ExecuteEventProcedure ,0xff08d868) // 2
Binary files 101a/stubs_min.o and 101b/stubs_min.o differ
diff -r 101a/stubs_min.S 101b/stubs_min.S
5,6c5,6
< DEF(levent_table ,0xff5905cc) // Found @0xff5905cc, stubs_min = 0xff5905cc (0xff5905cc)
< DEF(FlashParamsTable ,0xff6267b4) // Found @0xff6267b4, stubs_min = 0xff6267b4 (0xff6267b4)
---
> DEF(levent_table ,0xff59062c) // Found @0xff5905cc, stubs_min = 0xff5905cc (0xff5905cc)
> DEF(FlashParamsTable ,0xff626814) // Found @0xff6267b4, stubs_min = 0xff6267b4 (0xff6267b4)
Only in 101b: stubs_min.S~
Only in 101a: .svn
Only in 101b: t
Maybe he provides a complete patch file for the svn. I asked him.
msl
-
Thanks..I guess there is hope
I am really new at this...the code you posted is what or goes where???
-
Firmware version 101b was added in changeset 2001 (http://trac.assembla.com/chdk/changeset/2001/trunk).
Thanks goes to grep.
The S100 101b should be available soon as download.
msl
-
Thanks goes to grep.
I was trying to understand how the Unix "grep" command was useful in porting to another firmware version for the S100. Then I realized that grep is a user nickname on the CHDK-DE forum. :-[
-
You guys Rock! Thank you c10ud, grep msl and everyone who made this possible. CHDK now runs on my S100 Firmware 1.01B.
-
I must be an idiot....I do what with the changeset...I appologize for my ignorance
-
Thanks...I should have checked...the "B" version is posted
Thanks to all
As I understand, I should unzip directly to SD card, correct???
-
As I understand, I should unzip directly to SD card, correct???
I believe it doesn't really make a difference. Just make sure:
- If your SD card is between 4GB and 32GB (inclusive), format it in camera
- Make the card bootable (e.g. using EOScard (http://chdk.wikia.com/wiki/EOScard))
- Copy "DISKBOOT.BIN" from the CHDK zip file into the SD card's root directory
- Lock the SD card (slide the lock switch)
- Place the SD card in your S100, keep holding the On button for couple of seconds, and CHDK will start.
-
Thanks...I understood that CHDK might not start with "on" button....that you would have to initialize with movie button first and then 1/2 press shutter button to switch to camera mode..but apparently you have it working with "on" button
I appreciate the input
-
that you would have to initialize with movie button first
That doesn't work for me. I can, however, start the camera by holding the "Play" button for 2 seconds.
but apparently you have it working with "on" button
That is correct. Just "keep holding" the On button for 2 seconds. With a non-CHDK card, a single click of the On button will start the camera.
-
Thanks to all who developed this..works very well with power on button
-
Hi
Thanks for the firmware.
I have a 101A.
1. I Formatted my 16Gb memory with the camera.
2. Then used EOSCard to enable the boot
3. Copied the CHDK to the root of the card.
4. Lock the card, and place back the card
5. Turn on the camera
Now, when I press and hold PLAY button, the CHDK does not show up.
Is there any other trick I am not aware of?
Thanks
-
Is there any other trick I am not aware of?
A couple of things to try :
1) Did the camera format the card as FAT32 or exFAT ? It has to be FAT32 for it to boot.
2) Here is a posting about problems with EOScard : CHDK Forum : can't get CHDK to work on my new S100 (http://chdk.setepontos.com/index.php?topic=8330)
Did it look like the first or second screenshot here when you used it : EOScard (http://chdk.wikia.com/wiki/EOScard) . It needs to be the second at 0x1E0.
3) Are you using a Mac ? If so, read this carefully : Problems loading CHKD on SD cards with a Mac computer (http://chdk.wikia.com/wiki/FAQ/Mac#Still_Having_Trouble.3F)
Lots of good information here :
link> Prepare Your SD Card (http://chdk.wikia.com/wiki/Prepare_your_SD_card)
-
101a test build with #define CAM_KEY_CLICK_DELAY 150
-
#define CAM_KEY_CLICK_DELAY 10
-
Testing by user nbdi on IRC has confirmed this is required for the click script function to work correctly. I've checked the 10ms version into the trunk and release branches.
-
Thanx guys.....this works great ;)
-
Please guys, look at this curiosity, too. chdk do not abite by custom auto iso when creating a dng-file. Is this a S100-problem or in general?
http://chdk.setepontos.com/index.php?topic=8617.msg90303#msg90303 (http://chdk.setepontos.com/index.php?topic=8617.msg90303#msg90303)
-
Hello!
It seems like the 'ring func' button is completely ignored on the S100 by chdk.
I would like to be able to press it from my lua script to shut off the display. The S100 standard menu's let me resign that functionality much like with the S95 did with the print button.
I looked in the kbd.c and it is not in the keymap.
I tried using the memory browser to look at physw_status (0x000386bc), and the reading was 0xFFBFF... when I pressed the ring func button it switched ti 0xFFBFE ... does that mean in keymap the ring func should be 0x00000001 ? Was this the right way to find it?
When referring to getting the keys working, the porting guide says: "To figure out which bit is what, one can use the debug On-Screen Display (OSD) of CHDK." I have not been able to find they particular debug screen (only the props and the params) ... or at least I am not sure how to use those for this purpose. Maybe I am supposed to modify gui_draw_debug_vals_osd() to display the values I need?
I think it will also need a new 'keyname' in core/script.c ... or should I just use erase since there is a little blue trashcan next to it? Or would that be a problem too since that may be assigned to 'raw toggle'.
I'm not quite brave enough yet to put my own complied version on the camera yet.
Thanks!
M.
-
I tried using the memory browser to look at physw_status (0x000386bc), and the reading was 0xFFBFF... when I pressed the ring func button it switched ti 0xFFBFE ... does that mean in keymap the ring func should be 0x00000001 ?
Yes
Was this the right way to find it?
Yes
I think it will also need a new 'keyname' in core/script.c ... or should I just use erase since there is a little blue trashcan next to it? Or would that be a problem too since that may be assigned to 'raw toggle'.
Use KEY_ERASE - that's what the button does. Curiously, the platform_camera.h file for the S100 has
#undef CAM_HAS_ERASE_BUTTON
so I believe the shortcuts will not use that button anyway.
I'm not quite brave enough yet to put my own complied version on the camera yet.
The risk is low as you are starting with working code. But the S100 is an expensive P&S camera so I can understand your caution.
-
I think it will also need a new 'keyname' in core/script.c ... or should I just use erase since there is a little blue trashcan next to it? Or would that be a problem too since that may be assigned to 'raw toggle'.
Use KEY_ERASE - that's what the button does. Curiously, the platform_camera.h file for the S100 has
#undef CAM_HAS_ERASE_BUTTON
so I believe the shortcuts will not use that button anyway.
Cool. Thanks!
I got the compiler from the A2200 porting thread and everything compiled and the new image is working. The ring func/erase is not quite working though.
I used the stable build and I just added the one definition of erase to keymap in kbd.c as described above.
I ran a button test script from the wiki (http://chdk.wikia.com/wiki/UBASIC/Scripts:_Button_test (http://chdk.wikia.com/wiki/UBASIC/Scripts:_Button_test)) and when I press the ring func button, the
output from the button test script does print erase, but the command that the camera maps to the rung func button also activates. I tried a couple functions... assigning ISO or white balance function to the button makes those functions activate and popup behind the OSD. If I assign screen off, the screen turns on... when I turn it back on, I see that the erase button was pushed twice, as expected.
What is interesting is that in the button test script none of the other buttons actually activate any features they would normally activate, for instance 'menu' and 'video'.
I also made a lua script that just does click "erase". It does not activate the screen sleep or any of the functions I map to the ring func button using the standard camera menus. Maybe it needs some sleeping in there?
I think something is missing... I'll keep looking. Anyone have any suggestions where to look?
-
I think something is missing... I'll keep looking. Anyone have any suggestions where to look?
After you added the new button definition, you need to add the newly found bit to the respective KEYS_MASKn #define at the top of platform/s100/kbd.c. In your case it's probably KEYS_MASK0? Since the camera now has an erase button, you can remove
#undef CAM_HAS_ERASE_BUTTON
from platform_camera.h
If your modifications work well, you can submit a patch to include them in the official CHDK source.
-
Since the camera now has an erase button, you can remove #undef CAM_HAS_ERASE_BUTTON from platform_camera.h
That will cause CHDK to use the button for shortcuts and user menu edits. Might not be what he wants based on his original post ?
-
That will cause CHDK to use the button for shortcuts and user menu edits.
I don't see how that should prevent him from pressing the erase button from a script?
-
That will cause CHDK to use the button for shortcuts and user menu edits.
I don't see how that should prevent him from pressing the erase button from a script?
You're correct - it won't. But it will enable some shortcut modes that he might not want. (I'm not a big shortcut fan). I guess to be consistent with other cameras it should be added.
-
That will cause CHDK to use the button for shortcuts and user menu edits.
I don't see how that should prevent him from pressing the erase button from a script?
You're correct - it won't. But it will enable some shortcut modes that he might not want. (I'm not a big shortcut fan). I guess to be consistent with other cameras it should be added.
Adding the bit to the KEY_MASK0 worked! Thanks so much! I can submit a patch... its a two line change though... maybe just an email to someone? :D
I did notice some raw images started showing up on my SD card even though I did not turn on raw in the cameras standard menus or the CHDK menus as the lua script was running. Is this from pressing the set button... this page says thats what may be doing it: http://chdk.wikia.com/wiki/CHDK_User_Manual (http://chdk.wikia.com/wiki/CHDK_User_Manual).
I have not tried to un-undef CAM_HAS_ERASE_BUTTON yet. I may try and I can report the behaviour. I can't seem to find any hints on the wiki what will happen.
While my script runs, should I take the camera out of alt mode?
Thanks again!
-
Adding the bit to the KEY_MASK0 worked! Thanks so much! I can submit a patch... its a two line change though... maybe just an email to someone? :D
Patch files posted here <<link>> (http://chdk.setepontos.com/index.php?topic=650.0) work best. Might as well give it a try - this might not be your only one !
I did notice some raw images started showing up on my SD card even though I did not turn on raw in the cameras standard menus or the CHDK menus as the lua script was running. Is this from pressing the set button... this page says thats what may be doing it: http://chdk.wikia.com/wiki/CHDK_User_Manual (http://chdk.wikia.com/wiki/CHDK_User_Manual).
I usually notice it when the save time goes from 1/2 second to 4 or more seconds.
I have not tried to un-undef CAM_HAS_ERASE_BUTTON yet. I may try and I can report the behaviour. I can't seem to find any hints on the wiki what will happen.
Probably the biggest change is that when you are creating user menu entries, you can use the Erase button rather than half-press of the shutter button. (I really dislike anything that needs a "half press" - about 50% of the time I end up with a full press and not the result I was trying for).
Grep the core directory in the source tree for "CAM_HAS_ERASE_BUTTON" if you want to see where less it shows up.
While my script runs, should I take the camera out of alt mode?
Typically not - when you do that, button presses start going through to the Canon firmware.
-
Quote
and unfortunately, the wheel_left (or right) is not effective with the S100. So i cannot simulate button clicking.
any idea ?
This sounds like a bug - you should report it in the S100 porting thread
Refering to an other discussion, did someone already test the
wheel_left Y Y simulates moving jog dial wheel to the left
wheel_right Y Y simulates moving jog dial wheel to the right
on the S100 ?
I cannot effectively use it. Apparently no effect !
I wanted to try these function to change drive and bracketing mode.
thanks for support
-
Jogdial is currently not implemented because i couldn't get my head around it at the time.
I don't have the S100 anymore, I hope another developer will take care of it
-
Quote
and unfortunately, the wheel_left (or right) is not effective with the S100. So i cannot simulate button clicking.
any idea ?
This sounds like a bug - you should report it in the S100 porting thread
Refering to an other discussion, did someone already test the
wheel_left Y Y simulates moving jog dial wheel to the left
wheel_right Y Y simulates moving jog dial wheel to the right
on the S100 ?
I cannot effectively use it. Apparently no effect !
I wanted to try these function to change drive and bracketing mode.
thanks for support
Are you talking about the rear dial among the buttons or the front ring around the lens?
Phil.
-
Are you talking about the rear dial among the buttons or the front ring around the lens?
I was talking of rear dial wheel. (but did not find either way to use front wheel !)
M.
-
Are you talking about the rear dial among the buttons or the front ring around the lens?
I was talking of rear dial wheel. (but did not find either way to use front wheel !)
M.
Ok, just to confirm - the rear dial works correctly in the CHDK menus; but the Lua script functions 'wheel_left' and 'wheel_right' don't work. Correct?
Phil.
-
Correct, the wheel works correctly in the chdk menu but I cannot simule the whhel action with the basic command. ( Sorry i'm not familiar with lua)
Michel
-
Correct, the wheel works correctly in the chdk menu but I cannot simule the whhel action with the basic command. ( Sorry i'm not familiar with lua)
Michel
Attached is a test version for firmware 1.01b that should fix the problem.
Please try this and let me know.
Phil.
Edit: non-working attachment removed.
-
I just tried with a small script to change iso with no positive result.
@title test config
click "set"
wheel_left
sleep 1000
wheel_left
sleep 1000
click "set"
sleep 1000
click "shoot_half"
get_iso_mode a
release "shoot_half"
sleep 1000
print "iso " ; a
end
the wheel is not changing. and consequently the iso is not changing.
-
I just tried with a small script to change iso with no positive result.
@title test config
click "set"
wheel_left
sleep 1000
wheel_left
sleep 1000
click "set"
sleep 1000
click "shoot_half"
get_iso_mode a
release "shoot_half"
sleep 1000
print "iso " ; a
end
the wheel is not changing. and consequently the iso is not changing.
Ok, please try this version.
Phil.
-
Thanks,
I've tried with this new version.
the goods news come from the fact that wheel_left is active.
the bad news is that it works randomly. only 2 clicks were effective out of 3
maybe some problem with the speed of clicks.
I will test adding some delay
Michel
-
Thanks,
I've tried with this new version.
the goods news come from the fact that wheel_left is active.
the bad news is that it works randomly. only 2 clicks were effective out of 3
maybe some problem with the speed of clicks.
I will test adding some delay
Michel
I suspect a short delay will be needed after using wheel_left and wheel_right to allow the system to process them.
Let me know how it goes.
Phil.
-
I've have tested with different delays. It works and I can change drive mode. Thanks !
surprisingly sleep 250 is okay while sleep 1000 seems to miss command
what is you experience wrt "short" delay after such command ?
do all the click / wheel ... require the same delay
Michel
-
surprisingly sleep 250 is okay while sleep 1000 seems to miss command
This actually makes sense. Waiting 1/4 second is okay but waiting for a full second means you will miss some wheel clicks.
-
Does uBasic command 'set_focus' work on this camera ?
-
Does any of the current work on CHDK for the S100 lend itself to forcing TTL flash in Manual metering mode? This is a *very* desirable feature for using the S100 in underwater strobe photography.
There is a script available for the S95 CHDK, but as the S100 has a different processor it won't work as-is.
-
Does any of the current work on CHDK for the S100 lend itself to forcing TTL flash in Manual metering mode? This is a *very* desirable feature for using the S100 in underwater strobe photography. There is a script available for the S95 CHDK, but as the S100 has a different processor it won't work as-is.
Post a link to the script ? Might be easier to convert it than make up something new.
-
Certainly! The author posted it here:
http://www.scubaboard.com/forums/canon-corner/415870-s95-manual-mode-ttl.html#post6297438 (http://www.scubaboard.com/forums/canon-corner/415870-s95-manual-mode-ttl.html#post6297438)
Note that the first post on that page has his original script, but he posted an update partway down, and the link above should take you there.
The author has also said that even though the TTL-Manual script does not work, it is possible to override aperture in shutter priority mode, which is another way to get to a similar end. I haven't yet experimented with that myself--still researching how to *install* CHDK over here, in fact. :)
Thanks a bunch for the help. TTL in manual mode would be the cat's pajamas for myself and many other underwater shooters.
-
Note that the first post on that page has his original script, but he posted an update partway down, and the link above should take you there.
Looks like the original script should work just fine without modification for all cameras except the very old ones (2006 or so).
The "improved" script uses a propcase value (127) not documented in the CHDK include files but that does show up in the ProperyCase wiki page. From what it says there, the improved script should also work for all but the oldest camera models.
Why did you think the script would work for the S95 but not the S100 ?
-
Having not tried it myself yet, I was operating on forum hearsay. In another forum thread, the author relayed a report from an S100 owner claiming that the script did not work. (http://www.scubaboard.com/forums/canon-corner/425075-chdk-s100.html (http://www.scubaboard.com/forums/canon-corner/425075-chdk-s100.html))
That is not a direct source, though. it was also in June, early in S100 CHDK development, which could have been the problem.
If you think it looks good, that is great news! Thank you kindly for taking the time to look.
-
Replying to myself: Thanks to Acid and SDMInst I got my S100 booting CHDK. It took some fiddling to get that TTL script installed and learn my way around the OS, but... with the linked script, TTL flash in manual does seem to work. I tried some test exposures with my housing and scuba strobe and exposures looked pretty good at a variety of manual exposure settings.
Things of note for anyone else who wants to try this--
- The S100's own 3-step flash power setting is still active when TTL is forced on via the script. I found that exposures looked best with this setting at its lowest value. YMMV.
- The script has its own power override too, in the script config menu. and I do not know how the two values might interact--didn't play with that. I left it at its default value.
- If your strobe has a TTL-friendly power dial, it too factors in to the exposure. It seemed to me that the adjustable power on my S&S DS-01 did not produce as wide a range of adjustment as I see in an unmodified Canon aperture priority mode with TTL.
I think this would be a nice feature to add to CHDK's own configs, but the script definitely does the job. Thanks for the help Waterwingz, without your assistance I probably would have just believed those old forum posts and never tried this out.
-
Replying to myself: Thanks to Acid and SDMInst I got my S100 booting CHDK.
Glad you got things loaded. I really should have pointed you here :
CHDK Wiki : Prepare your SD Card (http://chdk.wikia.com/wiki/Prepare_your_SD_card)
which would have given you this fairly simple process that does not need SDMInst :
Cameras released after 2010 (http://chdk.wikia.com/wiki/Prepare_your_SD_card#For_Cameras_Released_After_2010_:)
-
This is my first post ever on CHDK. I have the S100 and have installed CHDK on my card and it works great except for one problem, and that is the over-ride function does not seem to be working. I set the camera to M (manual) mode and just to be thorough I set the settings that I would like there just for good measure, even though I will be over-riding them. This is what I have done:
power up
playback to get to alt mode
menu
enhanced photo operations>
disable overrides "no"
override Av "4.00"
override ISO "200"
override JPEG quality "Sup.Fin"
disable overrides on startup (disabled)
exit back into camera mode and the override shows up on the display so I know that it is activated. Great! good to go right? Not so much, when I halfway depress the shutter release the problem manifests itself, the ISO goes from 200 to 320 and the AV goes from F4.0 to F4.0 -x (depending on light it says -1/3 right now.) Why is this not truely manual mode and why is it not overriding?
If anyone can help I would love to know what I have missed.
Thanks
-
+1
I am having the same problem using the s100 with my usb shutter release. The overrides are... well overridden when you focus.
Any ideas?
-
This is my first post ever on CHDK. I have the S100 and have installed CHDK on my card and it works great except for one problem, and that is the over-ride function does not seem to be working. I set the camera to M (manual) mode and just to be thorough I set the settings that I would like there just for good measure, even though I will be over-riding them. This is what I have done:
power up
playback to get to alt mode
menu
enhanced photo operations>
disable overrides "no"
override Av "4.00"
override ISO "200"
override JPEG quality "Sup.Fin"
disable overrides on startup (disabled)
exit back into camera mode and the override shows up on the display so I know that it is activated. Great! good to go right? Not so much, when I halfway depress the shutter release the problem manifests itself, the ISO goes from 200 to 320 and the AV goes from F4.0 to F4.0 -x (depending on light it says -1/3 right now.) Why is this not truely manual mode and why is it not overriding?
If anyone can help I would love to know what I have missed.
Thanks
Sounds like it is working correctly.
In M mode the '-x' next to the aperture is telling you the camera thinks the shot will be underexposed based on your settings.
CHDK uses 'real' ISO values, Canon displays 'market' ISO values so a CHDK ISO of 200 is equivalent to a Canon ISO of 320 (search the forums for real vs market ISO for more detail).
Phil.
-
The "script" does work with the S100......what I found was similar in respect to flash level
The down side of thescript is that if you have a user menu in CHDK and want to toggle between the script "on" and "off" you need to power the camera off....or eliminate the menu
For underwater use I've found that setting the camera in Tv and using chdk to set the aperature was more convienient than the afore mentioned script
Of course, if you want to leave it it ttl manual then there is no issue
-
Any issues with hdr timelapse using shutter bracketing ? The higher dynamic range makes this a perfect PnS for HDR timelapse.
-
So, it was a long time ago, how did you get on with the bullet sequences ?
-
I gave up mate. There were too many series voltage drops with my 3.3V Voltage stabilizer, and I did not want to redesign the circuit for 5v. The circuit worked for 2 cameras and then failed.
I ended up using slow mo to film the gymnasts. Not too bad..
www.youtube.com/watch?v=AAZ62ws4dZs (http://www.youtube.com/watch?v=AAZ62ws4dZs#ws)
So, it was a long time ago, how did you get on with the bullet sequences ?
-
Any issues with hdr timelapse using shutter bracketing ? The higher dynamic range makes this a perfect PnS for HDR timelapse.
I'm not sure what question you are asking here? It is easy to adapt most timelapse scripts to use shutter bracketing for HDR - just a question of adding a couple of lines of code to the shooting sequence. For example, here's a combination of the simple Lua scripts included in the default CHDK distribution (save it as hdrlapse.lua) that will take 3 Tv bracketing shots at each interval.
--[[
@title HDR Intervalometer
@param a = interval (sec)
@default a 15
@param f 1/2 stop range
@default f 4
--]]
repeat
start = get_tick_count()
shoot()
set_aflock(1)
p=get_av96()
s=get_sv96()
t=get_tv96()
set_tv96_direct(t-(f*48))
set_sv96(s)
set_av96(p)
shoot()
set_tv96_direct(t+(f+48))
set_sv96(s)
set_av96(p)
shoot()
set_aflock(0)
sleep(a*1000 - (get_tick_count() - start))
until ( false )
Or you could modify one of the more sophisticated intervalometer scripts.
-
Hello there,
here are the patches for porting S100 to the new loader code:
1) https://github.com/c10ud/CHDK/commit/a94ca402bf13c11ac473bd8c49c38a41fc78c6da.patch
2) https://github.com/c10ud/CHDK/commit/a8ad484aa8d8268d7592dfec370ffc35268e3eaf.patch
(cross-posted to the patches-for-trunk thread)
-
There seems to be a bug when power on the camera: a short press of the ON buton should start the camera but with CHDK nothing happens - one needs to press about 2 seconds until camera stats - this can be frustrating when someone is used to press th on button short like for most other Canon/CHDK cameras. Would it be possible to fix this?
thanks
Werner
-
You are right, there's a bug with that.. However as you can see with the discussion in page 4 of this thread the issue was sorted out.. I don't understand why it isn't working :X
-
Is there someone interested in CHDK-GPS function for S100?
I created patch for all fw versions, It was tested in 101b by c10ud. So, Is there any tester for other firmware versions?
-
Canon have released a firmware update (to 1.02a?) for the s100. Has anyone started work on a port to the new version?
See http://usa.canon.com/cusa/support/consumer/digital_cameras/powershot_g_series/powershot_s100?pageKeyCode=prdAdvDetail&docId=0901e02480443f3a (http://usa.canon.com/cusa/support/consumer/digital_cameras/powershot_g_series/powershot_s100?pageKeyCode=prdAdvDetail&docId=0901e02480443f3a)
-
If I can help, I'm the proud owner of an s100 with the new 1.02a firmware.
It came back from Canon's lens error repair with that update. (Sadly, I've lost the USB shutter release that CHDK provided -- I only use the camera for digiscoping.)
I'd be glad to do a firmware dump and upload it. I tried to do a dump, but haven't succeeded yet. It seems I need step-by-step instructions. Please pardon me if this isn't where I should post this.
In a nutshell, here's what I tried:
formatted card in camera
using EOSCard.exe, made card bootable CHDK raw
using EOSCard.exe, prepared the cards boot sector with the "SCRIPT" string.
made a script.req file with the text "for DC_scriptdisk" on the card
copied the text on the Canon Basic/Scripts/Dumper page to a file named extend.m & saved it on the card
I put the card in the s100 & pushed the play button, then the func.set button.
I only get the standard message, "No image."
No new files get written to the card.
I'm attaching my "extend.m" file in case it's the issue.
-
Upon posting my message with the attachment, my problem was obvious. Windoze hid the file extension .txt. I'd not reset that after a Windoze reinstall.
I removed the extra extension & it did it's thing, without any on screen messages visible, but with a slight interruption in the border around the message, "No image."
I'll now try it again, see if I get the same result, and post it to the P&S FW Dumps google docs folder.
-
I've now done 6 dumps from the s100 firmware 1.02a, and using fc at a windows command prompt, they're all different. Any pointers?
Thanks,
vikingcove
-
I've now done 6 dumps from the s100 firmware 1.02a, and using fc at a windows command prompt, they're all different.
This is normal - but it's typically up near the end of the file. That's where the camera stores some non-volitile data / variables. Post one of your dumps and someone will let you know if its okay.
-
Thanks for that answer.
I've compressed a primary.bin file & created an info.txt file. I nested it in folders and 7zipped it as I've seen done at the P&S FW Dumps google docs.
Now I need help in uploading it, as I don't have permission to add items to the S Series folder, & it's too large to attach here, at 2.93 MB.
-
Now I need help in uploading it, as I don't have permission to add items to the S Series folder, & it's too large to attach here, at 2.93 MB.
You can use a file sharing server (filedropper, 4share, etc) and post the link here or to Firmware Dumping board (http://chdk.setepontos.com/index.php?board=5.0)
-
I've uploaded a s100 102a firmware dump to my google drive in a folder I'm sharing with this link:
https://docs.google.com/folder/d/0B0Yv5Y78C-IwZ0VxY0pyTU1PNEE/edit?usp=sharing
I've not tried sharing a folder there before. It should work.
If someone can check the validity of this dump file and let me know, I'd appreciate it. If it's not valid, I'll try again.
I'll have the camera for another day. Canon has graciously agreed to revert the firmware to 101a for me. They're sending a shipping label tomorrow.
Thank you for all your efforts,
vikingcove
-
I've uploaded a s100 102a firmware dump to my google drive in a folder I'm sharing with this link:
https://docs.google.com/folder/d/0B0Yv5Y78C-IwZ0VxY0pyTU1PNEE/edit?usp=sharing
Firmware dump is right.
// Camera info:
// DRYOS R49 (DRYOS version 2.3, release #0049)
// Firmware Ver GM1.02A
// Canon PowerShot S100
-
Blind port for s100 102a.
Source code is here (http://subversion.assembla.com/svn/nafraf/chdk/platform/s100/sub/102a/)
vikingcove: If you have time, please test it and report.
-
nafraf: Canon gave me the shipping label today, so I sent it back in this afternoon for the install of the old firmware, so I can't test it. I apologize. It's my only way of digiscoping -- something I do almost every day.
-
nafraf: Canon gave me the shipping label today, so I sent it back in this afternoon for the install of the old firmware, so I can't test it. I apologize. It's my only way of digiscoping -- something I do almost every day.
I'm really surprised they agreed to do that. What did you tell them about why you wanted it swapped back? Are they doing it for free?
-
I told them exactly what I was doing with it -- digiscoping using software to enable remote USB shutter release, and that their update of the firmware, that they did while repairing the lens error, disabled my use of the software, hence disabled use of the USB shutter release. I told them that was the reason I bought this camera & the only thing I use it for. I told them I use my other cameras for general photography. All of that is true, & I didn't try to hide anything. They showed no hesitation. I spoke with an operator, a technician, and a higher level repair person. The 3rd person was who could verify that they could do it. Yes they are not charging for it. I didn't even have to ask. She said they'd send out a form tomorrow & a shipping label. Before noon today they'd sent a "Courtesy Repair" form for me to give precise details regarding the firmware version it had, & a prepaid UPS label, so back off it went. Canon has been excellent by me.
Probably in the more-than-you-need-to-know category: I take a lot of photos of birds, partly to help me with identification & proof of my sightings, and also just because I like photos of birds and don't have a big lens. I've used birdwatching as therapy for an injury. Early this year I was able to get photos that proved my sighting of a Red-shouldered Hawk -- a species never reported before in Yakima County, Washington. Plenty of other more experienced bird nerds followed up by coming here just to see it to add it to their lists. I have a couple of photos of an earlier version of my digiscoping setup on my motley website at kevinslucas.com in the "digiscoping adapter" gallery. I've since made a wireless remote control and changed the way the bracket clamps on the scope eyepiece.
nafraf: Canon gave me the shipping label today, so I sent it back in this afternoon for the install of the old firmware, so I can't test it. I apologize. It's my only way of digiscoping -- something I do almost every day.
I'm really surprised they agreed to do that. What did you tell them about why you wanted it swapped back? Are they doing it for free?
-
nafraf: Your 1.02A alpha works on my cam. I have used chdk only very briefly on the old firmware version, is there anything I should test?
Thx for your work!
-
nafraf: Your 1.02A alpha works on my cam. I have used chdk only very briefly on the old firmware version, is there anything I should test?
Please try the test scripts listed in http://chdk.wikia.com/wiki/Testing (http://chdk.wikia.com/wiki/Testing)
-
llibtst.lua and ubtest.bas passed
setmode.lua did not pass: http://pastebin.com/BvXNDW5H (http://pastebin.com/BvXNDW5H)
-
llibtst.lua and ubtest.bas passed
setmode.lua did not pass: http://pastebin.com/BvXNDW5H (http://pastebin.com/BvXNDW5H)
Please modify "mode change delay" parameter and try again, there is not modemap table warnings in source code, so I expect that setmode.lua pass without problem.
Another features to test:
- quality video override. Check Video Parameters section in http://chdk.wikia.com/wiki/CHDK_User_Manual (http://chdk.wikia.com/wiki/CHDK_User_Manual)
- RAW capture
- CHDK-GPS? If you want to test it, I'll send you a new version with GPS functions enabled.
-
ok, my longer reply didn't make it, so here is the short version:
- setmode passed with 100ms delay
- video: quality settings + quick quality change working (checked bitrate of video)
- raw works
@gps: yes please, but I don't know how much time I'll have the next weeks to test it.
thx
-
- setmode passed with 100ms delay
- video: quality settings + quick quality change working (checked bitrate of video)
- raw works
thanks for report, s100 102a should be added to autobuild in a few days.
@gps: yes please, but I don't know how much time I'll have the next weeks to test it.
I checked my code, GPS is enabled by default, so it should works in version that you have.
CHDK GPS manual: https://chdkde.box.com/s/ftdby4qlyuvsd7o2kl2s
-
posted a patch to address some issues/misconfigs: http://chdk.setepontos.com/index.php?topic=650.msg99709#msg99709 (http://chdk.setepontos.com/index.php?topic=650.msg99709#msg99709)
hacked loader, removed useless comments, fixed platform_camera
with the hacked loader now booting with power button short press works
fixed defines in platform_camera for correct dng generation
tested movie_rec and it works
+ other stuff
-
Hi,
I have three questions:
1.
The last entry for s100 inside this porting thread is three month ago.
Does that mean porting for s100 is finished?
2.
On following page:
http://chdk.wikia.com/wiki/S100 (http://chdk.wikia.com/wiki/S100)
The chdk for S100 is marked as BETA, what does that mean exactly? What is missing to become a final version?
3. Can I use the BETA version without problems?
What problems does the BETA version have compared to final version?
Thanks for making it clear to me!
-
The last entry for s100 inside this porting thread is three month ago.
Does that mean porting for s100 is finished?
Essentially - yes.
The chdk for S100 is marked as BETA, what does that mean exactly? What is missing to become a final version?
BETA status is arbitrary. It usually gets set that way when the port first becomes fully functional and is released to the public. The BETA status is removed when somebody remembers to do so - which is often never.
3. Can I use the BETA version without problems?
Probably. CHDK is a hack - there are always "problems" but they are usually minor and many people never even notice them. Use it at your own risk - there are no guarantees.
What problems does the BETA version have compared to final version?
The best way to understand that is to read through this forum thread.
-
We got a custom palette recently, which improves the histogram display, (Thx). More features such as shot meter from @lapser, may appear, you never know.
-
I'm not sure if this is the best place to ask for some help w/ a script for the S100...so pls let me know if I'm wrong.
I'm trying to get an intervalometer script that shuts off the LCD once it has started taking photos. I found an earlier entry in this thread (entry #125) w/ a script that does this but I can't get the script to work on my camera. I've got the 101a firmware and I'm running CHDK version s100-101a-1.2.0-2994-0 on it. I keep getting errors that leads to no photos even getting taken. I'm not good at programming so I don't know how to fix the script for this latest CDHK version.
Can anyone out there help? Thank you.
-
I'm trying to get an intervalometer script that shuts off the LCD once it has started taking photos. I found an earlier entry in this thread (entry #125) w/ a script that does this but I can't get the script to work on my camera.
The easiest way to do that is to add a line that uses the set_backlight command.
http://chdk.wikia.com/wiki/Script_commands#set_backlight.28.29 (http://chdk.wikia.com/wiki/Script_commands#set_backlight.28.29)
You need to put it after each shoot command as that turns the backlight back on.
If you post the script file here as an attachment, I'll show you where to put it. Usually when people can't get scripts to run that they have cut & pasted from this forum, its because the selected the wrong file extension in the file name or they failed to save the text as simple ASCII - UTF8 (no formatting).
Edit : as you learn more about scripting, you might want to look at how this script does battery saving : http://chdk.wikia.com/wiki/Battery_Intervalometer (http://chdk.wikia.com/wiki/Battery_Intervalometer)
-
Thanks for that link, waterwingz. I saved that script you sent as a *.lua. But when I tried to run it, I got a error:
:29: unexpected symbol near 'char(194)'
and it terminated. What does t his mean? I don't really need the logging feature so I guess I can remove that section once I figure this one out.
This was the original script I was playing w/. But this also give me an error. Thank you for your help.
@title int_BLFL
@param a = interval (sec)
@default a 7
@param b = backlight delay (sec)
@default b 3
@param c = use focus lock? (1/0)
@default c 1
if get_mode = 0 then goto "in_rec"
sleep 1000
set_record 1
:wait_rec
sleep 100
if get_mode <> 0 then goto "wait_rec"
:in_rec
s = (a*1000)+get_tick_count
shoot
sleep b*1000
set_aflock c
set_backlight 0
do
sleep 500
until (s <= get_tick_count)
do
s = (a*1000)+get_tick_count
shoot
sleep b*1000
set_backlight 0
do
sleep 500
until (s <= get_tick_count)
until ( 0 )
:restore
set_backlight 1
set_aflock 0
sleep 1000
end
-
Thanks for that link, waterwingz. I saved that script you sent as a *.lua. But when I tried to run it, I got a error:
:29: unexpected symbol near 'char(194)'
and it terminated. What does t his mean? I don't really need the logging feature so I guess I can remove that section once I figure this one out.
What are you using on your PC to create / edit the script file? You need to use something simple like notepad.exe - something that creates basic ASCII UTF-8 text files. It looks like you are using a word processor or other editor that is embedding formatting information.
-
I was using a Mac and TextEdit which I thought was a notepad equivalent. But I guess I was wrong. I just used a PC (Notepad) and got the Battery Miser to finally work on my S100. Thank you very much for your help. I really appreciate it. Now, I don't have to lug around a video cable to get the camera to disable the LCD.
One final question about the Battery Stop Voltage setting on Battery Miser...
What's the lowest setting you've tried? Any danger in going below the default 1000mV? I want to squeeze as many photos as possible for time lapse purposes. I'm assuming the script will continue to run as long as there is enough power and will automatically stop just before the battery runs out. Thanks again.
-
What's the lowest setting you've tried? Any danger in going below the default 1000mV? I want to squeeze as many photos as possible for time lapse purposes. I'm assuming the script will continue to run as long as there is enough power and will automatically stop just before the battery runs out. Thanks again.
If you set it low enough, the camera will shut down with the script in an indeterminate state when it decides the battery is too low.
-
Hello,
I found a bug within the DNG implementation on my 102A S100.
The DNGs it produces (either with STABLE 1.2.0-3475 or TRUNK 1.3.0-3496) are always corrupted:
Adobe Camera Raw says "bad format" and dng_validate outputs:
*** Error: ForwardMatrix2 does not map equal camera values to XYZ D50 ***
*** Error: File format is invalid ***
I compared with Exiftool a CR2 converted to DNG by Camera Raw and the DNG from CHDK:
$ exiftool -ForwardMatrix1 -ForwardMatrix2 IMG_2542.dng
Forward Matrix 2 : 0.6242 0.4092 -0.0691 0.188 1.1431 -0.3312 -0.042 -0.1341 1.0012
$ exiftool -ForwardMatrix2 CRW_2575.DNG
Forward Matrix 2 : 0.6242 0.4092 -0.0691 0.0188 1.1431 -0.3312 -0.042 -0.1341 1.0012
the 4th parameter is 1/10th of what should be.
Issue is at line #94 of platform_camera.h (revision 2730);
here is the patch:
Index: platform_camera.h
===================================================================
--- platform_camera.h (revision 3496)
+++ platform_camera.h (working copy)
@@ -91,7 +91,7 @@
-1633, 10000, -3155, 10000, 13040, 10000
#define CAM_FORWARDMATRIX2 \
6242, 10000, 4092, 10000, -691, 10000, \
- 188, 10000, 11431, 10000, -3312, 10000, \
+ 1880, 10000, 11431, 10000, -3312, 10000, \
-420, 10000, -1341, 10000, 10012, 10000
#define CAM_DNG_EXPOSURE_BIAS 0,1
Can anybody apply it to both trunk and stable release?
-
Can anybody apply it to both trunk and stable release?
Thanks for that. Added in revision 3497 & 3498
msl
-
Good catch, but why DNG when you can shoot native Canon RAW with this camera?
-
Good catch, but why DNG when you can shoot native Canon RAW with this camera?
Canon RAW might include some lens corrections and a little lossless compression and that is good. But DNG is more of an "open" format and so may work with more software packages.
-
There is a bug in CHDK port for the S100 which causes a crash when shooting:
if these conditions are ALL true:
- shooting with external remote
- remote options set to: TwoPush AND Normal AND Synchro on
- camera detects a face (face detection in Canon menu disabled)
one can test it by shooting the own face in front of a mirror (so camera detects a face)
Can this be fixed e.g by setting in the code the face detect counter to zero?
thanks
Werner
-
Some cameras have a ResetFaceDetect() function, maybe that will work ?
Strange problem .....
-
There is a bug in CHDK port for the S100 which causes a crash when shooting:
A romlog (http://chdk.wikia.com/wiki/Debugging#Camera_crash_logs_.28romlog.29) could shed more light on this. It wouldn't surprise me if other cameras were affected too.
-
Some cameras have a ResetFaceDetect() function, maybe that will work ?
What happened when you tried it ? ( http://chdk.setepontos.com/index.php?topic=11671 (http://chdk.setepontos.com/index.php?topic=11671) )
-
What happened when you tried it ?
I have never compiled CHDK.
-
if these conditions are ALL true:
- shooting with external remote
- remote options set to: TwoPush AND Normal AND Synchro on
- camera detects a face (face detection in Canon menu disabled)
If you follow exactly the same sequence but have sync off does it crash ?
What about if you follow exactly the same sequence but use OnePush rather than TwoPush?
My suspicion is that the wait for the remote release code sitting in a tight loop causes problem for the face detection code. Strange that it should be active when you have disabled it in the Canon menu though.
Update : SDM uses exactly the same code for wait for the remote release. Does it exhibit the same crash?
-
A romlog could shed more light on this.
attached
-
If you follow exactly the same sequence but have sync off does it crash ?
no
What about if you follow exactly the same sequence but use OnePush rather than TwoPush?
no, does not crash
SDM uses exactly the same code for wait for the remote release. Does it exhibit the same crash?
yes
greetings
Werner
-
Strange that it should be active when you have disabled it in the Canon menu though.
Hmmm .... a quick Forum search that I have just done shows that this was known two years ago :-
http://chdk.setepontos.com/index.php?topic=8243.msg86889#msg86889 (http://chdk.setepontos.com/index.php?topic=8243.msg86889#msg86889)
So, during the half-press, the number of faces detected variable (in the structure) must get updated.
As Werner suggests, continually forcing to zero while switch is pressed should disable it.
-
SDM uses exactly the same code for wait for the remote release. Does it exhibit the same crash?
yes
What happened when you tried it ?
I have never compiled CHDK.
Cute. So I'll be more explicit. What happened when you tried to fix this in SDM?
Hmmm .... a quick Forum search that I have just done shows that this was known two years ago :-
As Werner suggests, continually forcing to zero while switch is pressed should disable it.
Before anyone spends any time on this, it would be nice to know what else you have already attempted and what other tidbits you've discovered in your forum searches?
-
What happened when you tried to fix this in SDM? .
I have not tried to fix this in SDM.
It is a beautiful day, time for some photography.........
-
Here's what can be worked out from the romlog (used the 100d firmware here):
assert happens here due to the failure of TryPostMessageQueue (assumption: the queue became full):
loc_ff0ec028: ; 7 refs
ff0ec028: push {r3, r4, r5, r6, r7, lr}
ff0ec02c: ldr r5, =0x5ff4
ff0ec030: mov r6, #0
ff0ec034: mov r4, r0
ff0ec038: str r6, [sp]
ff0ec03c: ldr r0, [r5, #116] ; 0x74
ff0ec040: mov r1, sp
ff0ec044: bl loc_ff02b098 ; <TryReceiveMessageQueue>
ff0ec048: ldr r1, [sp]
ff0ec04c: orr r0, r0, r1
ff0ec050: tst r0, #1
ff0ec054: ldm r4, {r0, r2}
ff0ec058: movne r1, r6
ff0ec05c: stm r1, {r0, r2}
ff0ec060: ldr r0, [r5, #72] ; 0x48
ff0ec064: bl loc_ff02b1d4 ; <TryPostMessageQueue> @ 0x5ff4 + 0x48
ff0ec068: cmp r0, #0
ff0ec06c: beq loc_ff0ec07c
ff0ec070: ldr r1, =0x10f ; 271
ff0ec074: add r0, pc, #524 ; *"ChaseFrame.c"
ff0ec078: bl loc_ff00edc8 ; <DebugAssert>
loc_ff0ec07c:
ff0ec07c: pop {r3, r4, r5, r6, r7, pc}the message queue is read by this task:
NSTUB(task_ChaseFrame, 0xff0ec080):
ff0ec080: push {r3, r4, r5, r6, r7, lr}
ff0ec084: ldr r4, =0x5ff4
ff0ec088: ldr r6, =0x131
ff0ec08c: add r5, r4, #152 ; 0x98
loc_ff0ec090:
ff0ec090: ldr r0, [r4, #72] ; 0x48
ff0ec094: mov r2, #0
ff0ec098: mov r1, sp
ff0ec09c: bl loc_ff02afd0 ; <ReceiveMessageQueue> @ 0x5ff4 + 0x48
...this routine tried to send the message:
loc_ff0ec17c:
ff0ec17c: push {r2, r3, r4, lr}
...
ff0ec22c: bl loc_ff0ec028
loc_ff0ec230:
ff0ec230: pop {r2, r3, r4, pc}
loc_ff0ec17c is registered as a function pointer by loc_ff16a660
ff0ecc24: add r0, pc, #500 ; *"ChaseFrame"
ff0ecc28: bl loc_ff02b808 ; <CreateTaskStrictly>
ff0ecc2c: ldr r0, =0xff0ec17c
ff0ecc30: bl loc_ff16a660
...
loc_ff16a660:
ff16a660: ldr r1, =0x7a94
ff16a664: str r0, [r1]
ff16a668: bx lrthe function pointer is called by this task:
NSTUB(task_MotionVector, 0xff169de8):
ff169de8: push {r4, r5, r6, r7, r8, r9, sl, fp, lr}
ff169dec: ldr r9, =0x7a94
...
ff16a0e4: ldr r1, [r9]
ff16a0e8: cmp r1, #0 ; can be NULL !
ff16a0ec: beq loc_ff16a118
ff16a0f0: ldr r0, [r9, #36]
ff16a0f4: str r0, [sp, #228]
ff16a0f8: ldr r0, [sp, #500]
ff16a0fc: str r0, [sp, #224]
ff16a100: ldr r0, [r9, #40]
ff16a104: str r0, [sp, #236]
ff16a108: ldr r0, [sp, #496]
ff16a10c: str r0, [sp, #232]
ff16a110: add r0, sp, #224
ff16a114: blx r1
...So, the routine that causes the assert can be disabled by setting 0x7a94 to 0. I have no idea what the consequences of this can be, it will likely still crash, but somewhere else.
I haven't been able to reproduce the issue on my cameras (tried 3 of them).
-
.
So, the routine that causes the assert can be disabled by setting 0x7a94 to 0.
Well .................... as I have never compiled CHDK builds I will try on an SDM build.
For quite some time the double-click method has been disabled for the S100 because a user reported this problem.
The parameters override code (on half press) is only entered once so even if you zero at the start of half press it will probably be quickly set again by the system.
While waiting for switch release you could continually zero the value, if that is not too late.
-
So, the routine that causes the assert can be disabled by setting 0x7a94 to 0.
yes this fixes the problem with face detection
Werner
-
So, the routine that causes the assert can be disabled by setting 0x7a94 to 0. I have no idea what the consequences of this can be, it will likely still crash, but somewhere else.
Thanks to the always-helpful, friendly and knowledgeable srsa_4c that solves the problem :)
In SDM, I continually set 0x7a94 to 0 in the code waiting for switch release.
CHDK developers need to do the same.
Some general questions for srsa_4C .................
Do you use IDA ?
If so, your disassembly is different to mine.
Also, do you have to manually force disassembly to code of many sections ?
Where are NSTUB(task_MotionVector, 0xff169de8) and NSTUB(task_ChaseFrame, 0xff0ec080) defined ?
loc_ff0ec17c is registered as a function pointer by loc_ff16a660
loc_ff16a660:
ff16a660: ldr r1, =0x7a94
ff16a664: str r0, [r1]
ff16a668: bx lr
Can you explain what is meant by that ?
-
In SDM, I continually set 0x7a94 to 0 in the code waiting for switch release.
CHDK developers need to do the same.
Actually, I think that the firmware only sets 0x7a94 once, not continuously. What I would do is to save its original value before the critical operation and restore it afterwards. (I could be wrong of course.)
Do you use IDA ?
If so, your disassembly is different to mine.
No, the excerpts are from a "GPL" disassembly, hand-edited a bit. Objdump blindly disassembles everything, no need to force it.
Where are NSTUB(task_MotionVector, 0xff169de8) and NSTUB(task_ChaseFrame, 0xff0ec080) defined ?
See the funcs_by_*.csv files under /platform/<cam>/sub/<...>/
loc_ff0ec17c is registered as a function pointer by loc_ff16a660
loc_ff16a660:
ff16a660: ldr r1, =0x7a94
ff16a664: str r0, [r1]
ff16a668: bx lr
Can you explain what is meant by that ?
The firmware variable at 0x7a94 is a function pointer. loc_ff16a660 is a simple function that takes a function pointer and sets that variable.
-
Do you use IDA ?
I don't use IDA either but you seem to be struggling with it.
So if you are trying to use the Canon signature file and/or debug scripts for CHDK mentioned here :
http://chdk.wikia.com/wiki/Loading_dump_to_IDA (http://chdk.wikia.com/wiki/Loading_dump_to_IDA)
then you probably want to take a look at how they are setup. The profile is for an old A-series camera and the debug scripts (CHDK.IDC etc) have all kinds of hard coded addresses (look for things like ROM_START & sb = 0xFF000000;) built in that will not match the ROM size of more recent cameras. In addition, many recent cameras relocate part of the code in ROM to RAM, which is also not handled automatically by the CHDK debug scripts.
-
In SDM, I continually set 0x7a94 to 0 in the code waiting for switch release.
CHDK developers need to do the same.
Perhaps wait_until_remote_button_is_released is called too early. Here is a test version for 100d.
-
Here is a test version for 100d.
I could do the test if you could compile and upload the 101b version
Werner
-
Test version for 101b.
-
I think that the firmware only sets 0x7a94 once, not continuously.
The crash occurred on switch release.
If you immediately zero 0x7a94 on switch release it still crashes.
-
I think that the firmware only sets 0x7a94 once, not continuously.
The crash occurred on switch release.
If you immediately zero 0x7a94 on switch release it still crashes.
What's curious to me is that "one press" mode in CHDK (and presumably the equivalent in SDM) works.
In that mode, when the USB power is applied, the code does the equivalent of an immediate "full_press" of the shutter button. I believe that causes the camera to focus and set exposure right away and then proceed to shoot - where it gets trapped by the "wait_untill_remote_button_released" hook.
In two press mode, the initial press looks like a "half_press" the camera. It will focus and set exposure and apparently look for "faces". Quickly releasing and repressing the remote button triggers the additional "full-press" shot and the "wait_untill_remote_button_released" hook. Going there with face recognition events queued up seems to be a bad thing if the shooting task "waits". It's hard to understand why that would be the case as with sync disabled it goes through exactly the same code except for not waiting.
-
(and presumably the equivalent in SDM) works.
Yes.
I will now be offline for many hours.
-
Test version for 101b.
yes this version works - no crashes
Werner
-
Test version for 101b.
yes this version works - no crashes
Very interesting.
Suggests that nafraf's fix of moving the "wait_for_remote_release" farther down the shooting sequence gives the camera time to "cleanup" all the face events it detected prior to the shooting wait.
Obviously, a much cleaner solution to the "two press with S100" problem.
-
yes this version works - no crashes
Thanks. The patch is now checked in for CHDK 1.2 and 1.3. Changeset 3516 (https://www.assembla.com/code/chdk/subversion/commit/3516) and 3517 (https://www.assembla.com/code/chdk/subversion/commit/3517)
-
The patch is now checked in for CHDK 1.2 and 1.3.
Yes, good work, that is the 'proper' fix.
I doubt that any other cameras with face-detect have the same problem.
-
A couple of things I noted today while working on MF testing. I'll drop them here in case I don't get around to fixing them.
- using the set_zoom() command in scripting crashes the camera. I tried a changing a couple of the #defines in platform_camera.h but no luck. Needs a deeper investigation.
- when shooting DNG images, if the DNG Crop Size is set to [ Full ] then you get purple images. Setting to [ Active ] or [ JPEG ] works properly.
-
when shooting DNG images, if the DNG Crop Size is set to [ Full ] then you get purple images. Setting to [ Active ] or [ JPEG ] works properly.
CAM_ACTIVE_AREA_Y1 is odd (11) - despite the warning in camera.h that it must be even ???
When you choose full for the DNG crop, CAM_ACTIVE_AREA_Y1 is set to 0 in the image file.
So the Bayer decoding is starting on different rows in the Bayer matrix - odd vs. even.
This also means the cam_CFAPattern value is wrong.
If you take a Canon RAW image, you can use the Adobe dng_validate program (from the DNG SDK) to get the correct values for cam_CFAPattern, and active area. Use the -v option on dng_validate.
Might also be worth checking the COLOR_MATRIX values - the comments in platform_camera.h say the values are from the G15.
Phil.
-
If you take a Canon RAW image, you can use the Adobe dng_validate program (from the DNG SDK) to get the correct values for cam_CFAPattern, and active area. Use the -v option on dng_validate.
Might also be worth checking the COLOR_MATRIX values - the comments in platform_camera.h say the values are from the G15.
dng_validate doesn't seem to like Canon CR2 files? ( dng_validate version 1.3 )
-
If you take a Canon RAW image, you can use the Adobe dng_validate program (from the DNG SDK) to get the correct values for cam_CFAPattern, and active area. Use the -v option on dng_validate.
Might also be worth checking the COLOR_MATRIX values - the comments in platform_camera.h say the values are from the G15.
dng_validate doesn't seem to like Canon CR2 files? ( dng_validate version 1.3 )
Sorry, missed a step. You need to convert the CR2 to a DNG with the Adobe DNG convertor first :)
Phil.
-
Sorry, missed a step. You need to convert the CR2 to a DNG with the Adobe DNG convertor first :)
This just is not my day - the Adobe DNG Convertor app ( v6.2.0.28 ) won't open the Canon CR2 files.
Curiously, RawTherapee opens the CR2 files with the same borked purple coloration.
-
Sorry, missed a step. You need to convert the CR2 to a DNG with the Adobe DNG convertor first :)
This just is not my day - the Adobe DNG Convertor app ( v6.2.0.28 ) won't open the Canon CR2 files.
Curiously, RawTherapee opens the CR2 files with the same borked purple coloration.
Can you upload or email me a sample CR2 file.
Edit: Found a sample S100 CR2 file online - Adobe DNG convertor 8.5 works with it.
Edit2: Values from the DNG file match what is currently in CHDK platform_camera.h, so it looks like Canon is writing the odd CAM_ACTIVE_AREA_Y1 value to the CR2 file ::) RawTherapee may also be expecting an even value.
Phil.
-
Edit: Found a sample S100 CR2 file online - Adobe DNG convertor 8.5 works with it.
Edit2: Values from the DNG file match what is currently in CHDK platform_camera.h, so it looks like Canon is writing the odd CAM_ACTIVE_AREA_Y1 value to the CR2 file ::) RawTherapee may also be expecting an even value.
Yea - things got better once I downloaded the 2014 version of Adobe DNG Convertor rather than the one from 2010. Strange that they leave that obsolete link laying around.
-
Edit: Found a sample S100 CR2 file online - Adobe DNG convertor 8.5 works with it.
Edit2: Values from the DNG file match what is currently in CHDK platform_camera.h, so it looks like Canon is writing the odd CAM_ACTIVE_AREA_Y1 value to the CR2 file ::) RawTherapee may also be expecting an even value.
Yea - things got better once I downloaded the 2014 version of Adobe DNG Convertor rather than the one from 2010. Strange that they leave that obsolete link laying around.
Can you see if this patch fixes the DNG files when set to 'Full' for the crop size.
Phil.
-
Can you see if this patch fixes the DNG files when set to 'Full' for the crop size.
Patched and tested all three "sizes". They all look good now - thanks!
-
Just a reminder, "firm update" booting FI2 support is broken on this cam http://chdk.setepontos.com/index.php?topic=12153.msg119427#msg119427 (http://chdk.setepontos.com/index.php?topic=12153.msg119427#msg119427)
-
Hi, a quick question concerning ND filter state support:
Both S100 and S110 have ND filters. Why does the S110 have the CAM_HAS_ND_FILTER / CAM_HAS_NATIVE_ND_FILTER flags in the platform_camera.h but not the S100?
Is there some problem with controlling the ND filter on this model?
-
Hi, a quick question concerning ND filter state support:
Both S100 and S110 have ND filters. Why does the S110 have the CAM_HAS_ND_FILTER / CAM_HAS_NATIVE_ND_FILTER flags in the platform_camera.h but not the S100?
Is there some problem with controlling the ND filter on this model?
If it isn't discussed somewhere earlier in this thread, I would guess that the person doing the S100 port just didn't know about it.
If you can verify that ND control works with these defines, we can add them.
-
So it looks like the platform_camera.h file for the S100 needs both :
#define CAM_HAS_ND_FILTER 1
#define CAM_HAS_NATIVE_ND_FILTER 1
Tested successfully and patch for 1.3.0 and 1.4.0 has been submitted for inclusion in the autobuild.
-
Just a reminder, "firm update" booting FI2 support is broken on this cam http://chdk.setepontos.com/index.php?topic=12153.msg119427#msg119427 (http://chdk.setepontos.com/index.php?topic=12153.msg119427#msg119427)
I just built a ps.fi2 file the normal way for the 1.02a firmware version of this camera. Works fine - firmware update method loads correctly.
So is this something specific to only a few firmware versions (possible but unlikely)? Or maybe an issue in the original porting process that nobody ever went back and looked at?
Edit : Patch file for 1.4.0 attached. Should we add to autobuild and look for testers?
-
Can you see if this patch fixes the DNG files when set to 'Full' for the crop size.
Patched and tested all three "sizes". They all look good now - thanks!
Hi
I tried shooting DNG with my S100 using the HDR option from the top select wheel. This usually seems to shoot three exposures and then combine them, as a JPEG. I tried it with CHDK DNG set to on and it does produce a DNG file- but the results have a purple cast. Shooting single DNG files gives correct looking DNG. I looked at the DNG exceptions list and everything is set to off
-
I tried shooting DNG with my S100 using the HDR option from the top select wheel.
It seems very unlikely that this will work, assuming that you were hoping to get an HDR image in DNG format. And trying to hook into the process such that CHDK can capture a buffer full of Raw image data that has been combined into an HDR image prior to conversion to JPG format would be a lot of work, assuming such a buffer even exists.
-
I tried shooting DNG with my S100 using the HDR option from the top select wheel.
It seems very unlikely that this will work, assuming that you were hoping to get an HDR image in DNG format. And trying to hook into the process such that CHDK can capture a buffer full of Raw image data that has been combined into an HDR image prior to conversion to JPG format would be a lot of work, assuming such a buffer even exists.
Intriguing tho. I also tested hi speed capture with DNG set to on. My S100 struggled to save more than one DNG, but on my Ixus 300 HS it runs like a train, with 8 DNG images saved. Does that seem like a difference in the way buffers are working?
-
Looking at this, it seems we might be close to being able to play with "in camera" HDR algorithms now. (scripting or embedded C)
As a CHDK user, not a coder, this kind of thing is useful coded not scripted.
Do you think the recent changes made to DNG saving code for the Ixus 300 HS are relevant to the S100 inability to save DNG during Hi Speed capture?
-
Do you think the recent changes made to DNG saving code for the Ixus 300 HS are relevant to the S100 inability to save DNG during Hi Speed capture?
I doubt it. But it's easy enough to run the file counter test script and ensure that the S100 is setup correctly. I'll take a look tonight on mine.