CHDK Forum
Using CHDK => CHDK Releases => Topic started by: tbaker2500 on 27 / November / 2013, 15:03:45
-
Hi all!
First post here, hope I'm not out of line.
I have a project I'm really trying to get going with the SX510, but being new, it doesn't have a CHDK release yet. I'm not smart enough to do a port myself. But, I'd be happy to send a 510 to someone who is a developer, who has an interest in doing a port.
Thanks for considering it,
Tom
-
Maybe I can help you, I sent you a private message.
-
Thanks, got the email.
-
I just bought this camera, and I'm looking for info on porting CHDK to it too. I'm looking through the developer docs but not too sure what I'm doing yet.
-
Well, I obviously don't know what I'm doing. For some reason I didn't think I needed to check my firmware version. Of course, I wasn't making much progress. :P
Now I've got the right firmware dump (http://chdk.setepontos.com/index.php?topic=11001.msg107611#msg107611). Hopefully I'll be able to put the things I figured out to good use...now for attempt #2.
-
I just bought this camera, and I'm looking for info on porting CHDK to it too. I'm looking through the developer docs but not too sure what I'm doing yet.
Well, I obviously don't know what I'm doing. For some reason I didn't think I needed to check my firmware version. Of course, I wasn't making much progress. :P
Now I've got the right firmware dump (http://chdk.setepontos.com/index.php?topic=11001.msg107611#msg107611). Hopefully I'll be able to put the things I figured out to good use...now for attempt #2.
Welcome! And good luck with this project - most of us started off pretty much the same way you are.
If you have specific questions, please ask here. Or drop into the CHDK IRC channel (#CHDK on freenode IRC) - evenings (USA time) are usually the best time to find help there.
-
Thanks for the welcome! I'll check out the IRC when I have some time.
So far, I'm...somewhere. I don't have much time to work on this during the week due to work, but I'm doing a little more every day.
I've got all but 10 addresses in stubs_entry.S and stubs_entry_2.S
I'm decently sure that the address of the main LED is 0xC0220120.
But I can't get my DISKBOOT.BIN to boot at all. I tried putting code to turn on the LED from the Debugging page in both loader/sx510hs/entry.S and loader/sx510hs/main.c, but when I insert the (locked) SD card into my camera and try to turn it on with either the power button or the play button, nothing happens. No LED or LCD action at all. The camera hangs up until I remove and reinsert the battery.
The stubs entries that I'm missing are:
WriteSDCard
apex2us
time
viewport_fb_d
active_palette_buffer
palette_buffer
active_bitmap_buffer
bitmap_buffer
palette_control
recreview_hold
SetZoomActuatorSpeedPercent
Anyone have any ideas for my current situation? Do I need to get the rest of these stubs entries before it will boot at all? I was under the impression that I could boot something not-exactly-perfect and then get the rest working after. Am I just missing something stupid? (it wouldn't surprise me given my experience so far...)
-
But I can't get my DISKBOOT.BIN to boot at all. I tried putting code to turn on the LED from the Debugging page in both loader/sx510hs/entry.S and loader/sx510hs/main.c, but when I insert the (locked) SD card into my camera and try to turn it on with either the power button or the play button, nothing happens. No LED or LCD action at all. The camera hangs up until I remove and reinsert the battery.
This could happen if your diskboot encoding is wrong.
I'm decently sure that the address of the main LED is 0xC0220120.
You could test this with Canon Basic if you want http://chdk.wikia.com/wiki/Canon_Basic (http://chdk.wikia.com/wiki/Canon_Basic)
-
According to my tests, SX510 requires new dancing bits.
To create the patch, is there any list of dancing bits flavors to follow?
I have not found all the missing stubs entries, but source code is here (http://subversion.assembla.com/svn/nafraf/chdk/platform/sx510hs/)
-
To create the patch, is there any list of dancing bits flavors to follow?
You get to select the flavor ;)
-
According to my tests, SX510 requires new dancing bits.
To create the patch, is there any list of dancing bits flavors to follow?
Any luck with figuring out the new dancing bits? I don't see that in your repo. Here's a list of flavors! (http://www.taquitos.net/snack_guide/Doritos)
I have not found all the missing stubs entries, but source code is here (http://subversion.assembla.com/svn/nafraf/chdk/platform/sx510hs/)
Thank you! You've got a lot more than me. I can't look through everything right now, but this is starting to look like it may happen :) I should be able to get back to work on this on Monday. I at least got a couple of things that match up with yours. That's good.
-
Any luck with figuring out the new dancing bits? I don't see that in your repo. Here's a list of flavors! (http://www.taquitos.net/snack_guide/Doritos)
Thanks, guacamole patch in attachment.
I made more changes, please update your working copy. recreview_hold is missing.
-
Been without Internet for a week, but I'm back & working on this again :)
-
Ok, had to fix some issues with my computer, but here's an update.
I'm using the latest code from your repo & the guacamole.patch. When I run make rebuild-stubs I still get // NEED_ENCODED_DISKBOOT = ? Not found, possible new 'dancing bits' entry needed. // Found @ 0xffff399c in my stubs_entry.S, but I CAN compile the DISKBOOT.BIN with make clean fir. I do see a couple assembler messages, though:
>> Entering to platform/sx510hs/sub/101a
boot.c -> boot.o
/var/folders/pz/yh03kz357m59g900v_m568c80000gp/T//cc5Jsnm9.s: Assembler messages:
/var/folders/pz/yh03kz357m59g900v_m568c80000gp/T//cc5Jsnm9.s:41: Warning: (null)
stubs_min.S -> stubs_min.o
...
/var/folders/pz/yh03kz357m59g900v_m568c80000gp/T//ccgKmTvi.s: Assembler messages:
/var/folders/pz/yh03kz357m59g900v_m568c80000gp/T//ccgKmTvi.s:59: Warning: (null)
blobs.S -> blobs.o
-> main.elf
main.elf -> main.bin
<< Leaving loader/sx510hs
dance -> DISKBOOT.BIN ver 11
**** Firmware creation completed successfully
and I still can't boot the camera with the new DISKBOOT.BIN. Still hangs until I remove & reinsert the battery.
-
Did you apply guacamole.patch (http://chdk.setepontos.com/index.php?action=dlattach;topic=10984.0;attach=9351) to your working copy? It should solve dancing bits issue.
-
Yes, I did. It didn't help.
-
Thanks to nafraf & switching SD cards, I can make the LEDs flash now :D making progress! Will try to get a little further into it tonight & tomorrow.
For reference, here are the LED addresses:
Rear green LED: 0xC022302C found @ 0xFF175150
Front AF LED: 0xC0223030 found by nafraf
-
Now I have access to a SX510 101a. I'm trying to fix the boot.
-
That's happy news indeed, as I'm not making much progress.
-
Some tests fw 101a:
- llibtst.lua runs without problems (log in attachment)
- ubtest runs without problems
- remote capture works
- setmode.lua: Even using 2s delay, some modes fails, but using chdkptp all modes works without problems
TODO:
- Raw colors are wrong
- file counter is implemented as done in ixus140, but I have not tested if it is 100% reliable. Edit: +PAUSE_FOR_FILE_COUNTER and tested using rs -cont=5 -jpg
- Liveview fails in some modes.
- Zebra has wrong xoffset if 1:1 aspect ratio
-
Hi there. My programming skills are fairly new, but I have a basic grasp on the development process for chdk. Is there anything I can do to help? I'd love to be a part of making it happen for this awesome camera :)
-
bigolpete,
What is the firmware version of your camera?
-
Looks like I'm running 100d
-
hi i newly buy a sx510 and waiting for chdk for this camera.can somebody tell me how long can it take?sorry for my english .thanks
-
hi i newly buy a sx510 and waiting for chdk for this camera.can somebody tell me how long can it take?sorry for my english .thanks
link> 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)
-
the sx500 and sx510 are almost the same.it dosnt help?
and in two next week ill go nature photography.please somebody do something.just develop aperture and raw file part.
-
the sx500 and sx510 are almost the same.it dosnt help?
No. There are somerare cases where two Canon models have identical firmware (like sx240/sx260), but that cannot be the case for sx500 and sx510 because they have different sensors (among other things)
just develop aperture and raw file part.
Unfortunately, that's not how it works. Most of the effort is making it work at all, you can't just do one or two features.
-
Amateur question here, but what would happen if I tried using the sx500 version instead of sx510? Would it work at all? All I really need it the intervalometer feature...
-
Amateur question here, but what would happen if I tried using the sx500 version instead of sx510? Would it work at all? All I really need it the intervalometer feature...
Nothing would happen - your camera would simply hang and become non-responsive, requiring you to remove the battery to reset it.
As mentioned above, individual features require the core CHDK to be implemented. They are not added one at a time.
-
That makes sense.
Looking forward to the release
Thanks
-
i just wanna know .is anybody here work on this camera? :'(
-
i just wanna know .is anybody here work on this camera? :'(
link> 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)
-
ah comon
-
i just wanna know .is anybody here work on this camera? :'(
What is the firmware version of your sx510hs?
@patrick.madden2
I sent you a PM with a version for test. Please report the results to the forum.
-
i just wanna know .is anybody here work on this camera? :'(
What is the firmware version of your sx510hs?
@patrick.madden2
I sent you a PM with a version for test. Please report the results to the forum.
men there is no pm .i send pm my email to you.and check my firmware version ASAP.thank u so much
my firmware is 101a
-
my firmware is 101a
OK. I sent you a PM with a version for test. Please report the results to the forum.
-
ok it did run.but with problems.but solvable.
first problem u can see in first picture.its like to watch through a antique telescope in raw mode sure
first picture is raw converted to jpeg
i dont know its normal or not?but this problem soluble in light room "lens correction"
(https://chdk.setepontos.com/proxy.php?request=http%3A%2F%2Fi.cubeupload.com%2F8NYxQl.jpg&hash=b1bb58202d54b9a36db56dc5c9a60a71)
look at the lines in picture
same image but jpg from camera itself
(https://chdk.setepontos.com/proxy.php?request=http%3A%2F%2Fi.cubeupload.com%2FA1XNl1.jpg&hash=bf8a56e5d51fe3f79f0ca91659e64460)
and the other problem ,i think the subjects in screen like battery indicator and other labels misplaced.
(https://chdk.setepontos.com/proxy.php?request=http%3A%2F%2Fi.cubeupload.com%2FwziEEs.jpg&hash=4d17270a192f27e5316913f9be9bfe1e)
and when i searching in chdk menus i run a somthing i dont know what it is but camera switched off and i scared to run or test other things .but thank u @nafraf
a few hours later i tested script again like hdr .and its ok.and overrides like aperture and shutter speed is work.
i really thank you @nafraf.
-
ok it did run.but with problems.but solvable.
first problem u can see in first picture.its like to watch through a antique telescope in raw mode sure
first picture is raw converted to jpeg
i dont know its normal or not?but this problem soluble in light room "lens correction"
Yes, it's normal, Canon does lots of lens correction in software, the raw is what it actually sees.
-
hi.ok .the test version expired.i did feedback before .why nobody port the full version?please someone do that. @nafraf
-
I have a SX510 with firmware version 1.00d
If there is something I could do to help test, just let me know.
Regards.
-
@vb.mohsen2
I sent you a new file valid for 3 weeks, I expect to commit sx510 port on next week.
@pozole
I sent you a test version for sx510 100d. Please test it and report. Thanks
-
Also need an MF test for this camera please.
http://chdk.setepontos.com/index.php?topic=11078.msg108859#msg108859 (http://chdk.setepontos.com/index.php?topic=11078.msg108859#msg108859)
TIA
-
when use live histogram camera turn of after shot."photo not save".if i run default script and then use live histogram its work correct.but after a restart its happend again.sorry for my english.im sort of sick
-
Testing on 100d firmware:
Here is my report on running the test on http://chdk.wikia.com/wiki/Testing (http://chdk.wikia.com/wiki/Testing)
TL/DR: Everything went ok, no serious issues found.
RAW/DNG:
- All DNG shots were validated correctly by the Adobe dng_validate app in verbose mode.
- Numbering was correct and no skipped photos in both individual and continuous. All DNG pics had the same numbering as the JPG counterpart.
- When selected the option, the DNG are saved on the same folder as the JPG with correct numbering.
Memory:
- Memory shows around 1.7 MB free
Viewport buffers:
- Zebra shows overexposed areas , with not offset related to the scene on viewport.
Testing with scripts:
- mftest.lua Ok all tests!
- llibtst.lua Ok all tests!
- setmode.lua 4 modes failed
- ubtest.bas Ok! all buttons ok, shoots ok.
Regards.
-
Also need an MF test for this camera please.
http://chdk.setepontos.com/index.php?topic=11078.msg108859#msg108859 (http://chdk.setepontos.com/index.php?topic=11078.msg108859#msg108859)
TIA
Here is, attached
-
Here is, attached
Thanks - spreadsheet updated.
-
when use live histogram camera turn of after shot."photo not save".if i run default script and then use live histogram its work correct.but after a restart its happend again.
Please make a romlog and attach it here. "miscellaneous stuff" -> "debug parameters" -> "save rom crash log"
Also, please use the latest release from this page: http://mighty-hoernsche.de/trunk/ (http://mighty-hoernsche.de/trunk/)
-
Tests with sx510hs-101a-1.3.0-3400-full_ALPHA from autobuild:
ROMLOG.LOG was generated after a crash like the crash described by vb.mohsen2.
But it does not seems to be strictly dependent of histogram, sometimes if zebra enabled the same crash occurs, sometimes shoot works without problems.
Some other bugs:
- recreview_hold: its address is wrong, histogram appears only when "Show Live Histogram [Shoot]"
- custom palette: green color turns white after half shoot pressed, this is visible in battery icon and RGB live histogram.
A new version of mf_sx510hs.csv in attachment.
-
Tests with sx510hs-101a-1.3.0-3400-full_ALPHA from autobuild:
ROMLOG.LOG was generated after a crash like the crash described by vb.mohsen2.
But it does not seems to be strictly dependent of histogram, sometimes if zebra enabled the same crash occurs, sometimes shoot works without problems.
And notes.txt says that
- If zebra enabled, rs -cont=X -jpg has errors
What kind of errors?
Romlog: vector 0x10 exception (data abort) in an unrelated task.
Sounds like buffer overflow aka memory corruption. The sx230 port used to suffer from a similar problem. Could be any of the firmware variables CHDK writes into, or a bug in CHDK.
-
And notes.txt says that
- If zebra enabled, rs -cont=X -jpg has errors
What kind of errors?
IIRC, camera crashed occasionally. With current version, camera has not crashed, but in some cases first image is overwritten. This bug does not depends on zebra status.
EDIT: This recreview_hold address works. Histogram appears according to CHDK Menu option selected. But it does not solve the crash reported by vb.mohsen2.
DEF(recreview_hold, 0x000028f4+0x84) // @0xff04563c + 0x84 (offset used by A2500)
-
@nafraf
Some ideas if you want to investigate.
- Does the camera crash if zebra is enabled, but there's no overexposure (and underexposure)?
- From your romlog, the crash happened because the firmware tried to read from an address held by R1. That register has a very suspicious value, 0x90909090, that's four 0x90 bytes. The port's CHDK_COLOR_BASE is 0x90, and it's red:
pal[CHDK_COLOR_BASE+0] = 0x3F3ADF62; // Redcore/conf.c shows that
CONF_INFO( 62, conf.zebra_color, CONF_DEF_VALUE, cl:MAKE_COLOR(COLOR_RED, COLOR_RED)),COLOR_RED is the default zebra color. So, I suspect that the mentioned two modules somehow manage to write screen content to somewhere else in memory...
- You could try to choose another color for zebra and then crash the camera - if the offending byte changes from 0x90 to your newly chosen color, then... that could prove my above theory.
- Do any other CHDK drawings have a similar effect (crash)?
-
Test with sx510hs-101a-1.3.0-3402-full_ALPHA.zip.
Camera crashes if histogram and zebra enabled simultaneously (the existence of overexposure regions is not required to crash). The problem is that camera does not crash in 100% of cases, then it is being hard to isolate the problem. The attached file contains ROMLOG for 3 different crashes:
- zebra enabled - nooverexposure - histogram - crash after 1st shoot.
- zebra enabled - overexposure - histogram - crash after 1st shoot.
- zebra enabled - overexposure - histogram - crash after 2nd shoot.
- You could try to choose another color for zebra and then crash the camera - if the offending byte changes from 0x90 to your newly chosen color, then... that could prove my above theory.
Your theory is confirmed by third ROMLOG, zebra color selected was 0x97, and R1=0x97979797
-
Perhaps the palette buffer is invalid at some point?
-
The address which surely gets overwritten is [0x185c4 + 0xc]. The exception happens inside the firmware's malloc() function, in sub_6b74d4.
Camera crashes if histogram and zebra enabled simultaneously
So, enabling only one of these is not enough?
Do you get the same when using your own CHDK build (made with another toolchain)?
edit (my first sentence was ambiguous)
The word @ (0x185c4 + 0xc) surely gets overwritten.
-
The address which surely gets overwritten is [0x185c4 + 0xc]. The exception happens inside the firmware's malloc() function, in sub_6b74d4.
Suggests heap corruption, so a bad pointer is very like.
Try disabling CHDK palette overrides?
-
The address which surely gets overwritten is [0x185c4 + 0xc]. The exception happens inside the firmware's malloc() function, in sub_6b74d4.
Suggests heap corruption, so a bad pointer is very like.
Try disabling CHDK palette overrides?
Could it be the problem some cameras have when writing to the inactive bitmap buffer?
Phil.
-
Could it be the problem some cameras have when writing to the inactive bitmap buffer?
I personally don't believe that writing to the inactive buffer's memory area should cause any problems - it's just regular RAM, only used as bitmap buffer.
What I do believe is that there are bugs - either in CHDK (core / module(s) / some of the ports) or in the fw - which corrupt memory. These may go unnoticed if the area they corrupt is not "important". For example, a possible memory corruption surfaced while doing my last trials for SticK's s90.
In this case, I'm not sure how the palette buffer's wrong address could cause corruption when histogram+zebra is enabled, and not cause anything when they are not. But I don't have a better idea either. Trying a build made by a different toolchain could give some additional hints.
-
New tests (patch in attachment):
- CHDK palette override disabled
- recreview_hold found
- bitmap_buffer, active_bitmap_buffer found by comparison with ixus140
-#define DRAW_ON_ACTIVE_BITMAP_BUFFER_ONLY 1
- Compiler gcc 4.6.0 (main.bin.dump (http://www.filedropper.com/mainbin))
Camera still have the same behavior, it crashes if histogram+zebra enabled.
@reyalp, could you test zebra+histogram using ixus140?
Camera crashes if histogram and zebra enabled simultaneously
So, enabling only one of these is not enough?
Enabling only one of these is hard to have a crash. During previous test, IIRC camera crashed once with just zebra enabled.
vb.mohsen2 reported crash using histogram (http://chdk.setepontos.com/index.php?topic=10984.msg111418#msg111418), but I'm not sure if zebra was enabled during his test. I could not reproduce it.
-
- Compiler gcc 4.6.0 (main.bin.dump (http://www.filedropper.com/mainbin))
Camera still have the same behavior, it crashes if histogram+zebra enabled.
So, different compiler (= different CHDK code), same memory area getting trashed. And, if you're using zebra+histogram, there's a higher chance for crash. IMHO this scenario means that the zebra module is calling a routine in the histogram module.
I have experimented on my a3200 with zebra+histo, no crash, memory around 0x185c4 is not touched...
-
@reyalp, could you test zebra+histogram using ixus140?
Is there anything else I need to do to reproduce the crash?
I enabled zebra and histogram (set to always on in rec) and shot a few different sets in continuous without problems. Also did 50 shots with rsint -cont
-
sorry my mistake .it like to problem with draw zebra.not histgram.i test it and im sure about it.and thanks for everything
-
@nafraf
The following mod enables permanent zebra display in play mode - would be interesting to know whether the corruption/crash is still there when zebra is used in play mode (this would make the investigation easier and also spare unnecessary lens actuations).
Index: core/gui_osd.c
===================================================================
--- core/gui_osd.c (revision 3416)
+++ core/gui_osd.c (working copy)
@@ -1291,7 +1291,7 @@
return;
if (conf.zebra_draw)
- if (libzebra->gui_osd_draw_zebra(conf.zebra_draw && camera_info.state.is_shutter_half_press && camera_info.state.mode_photo))
+ if (libzebra->gui_osd_draw_zebra(conf.zebra_draw))
return; // if zebra drawn, we're done
#if !CAM_SHOW_OSD_IN_SHOOT_MENU
-
@srsa_4c
Test with patched version. Camera crashes occasionally when it starts in play mode.
-
Test with patched version. Camera crashes occasionally when it starts in play mode.
Thanks. Same crash reason, inside malloc().
So, you now have a camera with a reproducible memory corruption that always seems to affect the same memory area. But the corruption only happens occasionally.
I'm not exactly sure what the next step should be. Maybe the zebra code could be modified to not write anything to
a) the cam's bitmap overlay
or
b) its internally malloc'd memory
but make boundary checks instead.
Or, does anyone have a better idea?
-
Hi All, I am new in CHDK and looking for a hint about the possibility (if any) to get live video output via USB or HDMI ports while shooting (and or not) recording the video. From all I have read so far, it seems that this is not possible(?!). My Camera is SX 510 HS, FW-101a.
-
Hi All, I am new in CHDK and looking for a hint about the possibility (if any) to get live video output via USB or HDMI ports while shooting (and or not) recording the video. From all I have read so far, it seems that this is not possible(?!). My Camera is SX 510 HS, FW-101a.
Some older Canon Powershot camera would output live video while shooting. That feature has been removed by Canon on more recent models. There is nothing CHDK can do to fix that. Sorry.
-
Hi All, I am new in CHDK and looking for a hint about the possibility (if any) to get live video output via USB or HDMI ports while shooting (and or not) recording the video. From all I have read so far, it seems that this is not possible(?!). My Camera is SX 510 HS, FW-101a.
Some older Canon Powershot camera would output live video while shooting. That feature has been removed by Canon on more recent models. There is nothing CHDK can do to fix that. Sorry.
Not all recent models. The Canon manual should say if video out works in shooting mode. The SX510 manual says
"When the camera and TV are connected, you can also shoot while previewing shots on the larger screen of the TV..." (p130)
I think this will only work with the USB plug adapter (NTSC/PAL SD), not HDMI.
With CHDK, PTP live view might also be an alternative, depending on the application.
-
waterwingz; reyalp;
Thank you for the quick response. I will explore the case in depth. If I get some satisfactory result, will share here.
-
Hello everybody ;
I´am new here , i hope i'm asking in the right post :( .
I have a sx510 hs and i want to know if the chdk for 1.00d is valid for a 1.00c version
firmware .
Thank you. :D
-
Hello everybody ;
I´am new here , i hope i'm asking in the right post :( .
I have a sx510 hs and i want to know if the chdk for 1.00d is valid for a 1.00c version
firmware .
I think it should work - the main part of the firmware only differs in the version strings. Try it and report if it's working. Note that you should probably avoid using the zebra (and maybe the histogram) feature of CHDK, these may lead to crash on this cam.
-
thanks for your quick answer, if i try it i'll let you know.
:D
-
Maybe the zebra code could be modified to not write anything to
a) the cam's bitmap overlay
or
b) its internally malloc'd memory
but make boundary checks instead.
Or, does anyone have a better idea?
Using #define CAM_ZEBRA_NOBUF 1 camera has not crashed.
It is not perfect, but it is usable: https://trac.assembla.com/chdk/browser/trunk/modules/zebra.c#L150
-
Maybe the zebra code could be modified to not write anything to
a) the cam's bitmap overlay
or
b) its internally malloc'd memory
but make boundary checks instead.
Or, does anyone have a better idea?
Using #define CAM_ZEBRA_NOBUF 1 camera has not crashed.
It is not perfect, but it is usable: https://trac.assembla.com/chdk/browser/trunk/modules/zebra.c#L150
If the define prevents the crash, it should be made official.
We still should hunt down that bug someday (the behaviour change on CAM_ZEBRA_NOBUF will help to narrow down the search)...
-
#define CAM_ZEBRA_NOBUF 1 : Added to trunk in changeset 3422 (http://trac.assembla.com/chdk/changeset/3422/trunk)
-
Hi all,
I tried the CHDK for the sx510 from http://mighty-hoernsche.de/trunk/ (http://mighty-hoernsche.de/trunk/)
I found that it always reports "RAW DISABLED" / "DNG DISABLED" when I try to get the camera to record RAW images (depending on whether I turn DNG on or not). I need the raw mode for a test and it'll be fine by me if there is the optical difference to the JPEG that was discussed on page 4 of this thread.
So my question is where / how do I obtain a firmware 101a version of CHDK that does write DNG files?
-
Hi all,
I tried the CHDK for the sx510 from http://mighty-hoernsche.de/trunk/ (http://mighty-hoernsche.de/trunk/)
I found that it always reports "RAW DISABLED" / "DNG DISABLED" when I try to get the camera to record RAW images (depending on whether I turn DNG on or not). I need the raw mode for a test and it'll be fine by me if there is the optical difference to the JPEG that was discussed on page 4 of this thread.
So my question is where / how do I obtain a firmware 101a version of CHDK that does write DNG files?
This probably has to do with settings. Do you have something set in "raw exceptions" ?
There is no special build with raw enabled.
-
This probably has to do with settings. Do you have something set in "raw exceptions" ?
Thanks that was the final nudge I needed.
My reasoning had been that it should work with a clean build. I did build several trunk versions starting with 3381 where the camera/firmware combination I need was added through 3449 myself after posting this message but still to no avail.
Well, little did I know the camera was still switched to movie recording mode and there actually is a default "RAW recording off" setting for movie recording mode... It works now.
-
I'm interested in developing CHDK further using this camera as a base for my work. In particular, I'm interested in adding in some hooks to control the WiFi and to send/receive TCP/UDP packets. Applications would include shooting over WiFi, uploading images to custom servers, smart phone apps etc, and perhaps evening streaming the viewport - depending on whether it is available already compressed in H.264 etc.
A couple questions, as I'm a noob with the setup here - we have a Digic 4 processor based on an ARM instruction set, and we use GCC to cross compile the sources. When the CHDK firmware runs, how does it interact with the original firmware? are parts of the assembly from the original firmware inlined into the CHDK build?? or does CHDK load the original firmware and access it's functions like a library?
Cheers!
-
I'm interested in developing CHDK further using this camera as a base for my work. In particular, I'm interested in adding in some hooks to control the WiFi and to send/receive TCP/UDP packets. Applications would include shooting over WiFi, uploading images to custom servers, smart phone apps etc, and perhaps evening streaming the viewport - depending on whether it is available already compressed in H.264 etc.
http://chdk.wikia.com/wiki/For_Developers (http://chdk.wikia.com/wiki/For_Developers)
http://chdk.wikia.com/wiki/Adding_Firmware_Features (http://chdk.wikia.com/wiki/Adding_Firmware_Features)
When the CHDK firmware runs, how does it interact with the original firmware?
At boot, CHDK is loaded into RAM and gets control of the processor before the Canon firmware gets a chance to run. It activates the O/S in the firmware (VxWorks or DryOS depending on the camera) and hooks/replaces several tasks that the original firmware would have run. It also adds one of its own. It then lets the original firmware take control.
The hooked tasks mimick what the original tasks would have done but provide hooks for CHDK to use. The new task is essential "CHDK" at that point - doing a few simple things that would not make sense to do in the original and hooked tasks.
are parts of the assembly from the original firmware inlined into the CHDK build??
Essentially - the code for the boot process and hooked tasks is a close match to the original firmware code.
or does CHDK load the original firmware and access it's functions like a library?
No. It makes direct calls to the firmware in place.
-
I'm interested in developing CHDK further using this camera as a base for my work. In particular, I'm interested in adding in some hooks to control the WiFi and to send/receive TCP/UDP packets. Applications would include shooting over WiFi, uploading images to custom servers, smart phone apps etc, and perhaps evening streaming the viewport - depending on whether it is available already compressed in H.264 etc.
This thread may be of interest:
http://chdk.setepontos.com/index.php?topic=10724.0 (http://chdk.setepontos.com/index.php?topic=10724.0)
If you can convince the camera to go into PTP/IP mode outside of the regular menu, all of the CHDK extension stuff will be available.
Alternately, if you want to write your own socket code, most of those functions are easy to find, and I was able to start the network system (without PTP/IP) using console commands.
The magic lantern folks have also done some wireless stuff, though it's not clear how much will be applicable to P&S http://magiclantern.wikia.com/wiki/6D/Networking (http://magiclantern.wikia.com/wiki/6D/Networking)
-
Thanks for the replies guys and sorry about the delay in responding, I didn't have the notify option switched on for this thread. I have ordered this camera now and should have it within the next couple of days.
Development will be a little slow as I'm in the last year of my PhD at the moment which is a little time consuming. I will be setting up the toolchain etc over the next couple days.
Cheers!
-
Hi. I just bought an sx510hs. I tried to download the CHDK firmware using the standard tools. They recognized a firmware V 1.01A. However it did not work well.
The interface was erratic and it really did not look right.
I download the firmware from the camera using the CBASIC script documented elsewhere in the chdk site, and surprise!
The version string detected by 'strings' is the same in both cases: 1.01A, and obviously the sizes are identical: 16MB sharp.
However the firmware files are completely different.
My firmware: md5sum = 1dddbbd2e653ec90fb4266434557f9f8
The 1.01A PRIMARY.BIN from the chdk google drive site (version 1.01A): 745d70d1a79dd44f91f003f9020fb0d1
So this means that there are maybe different subversions of the 1.01A firmware. Has anyone seen this? I am happy to upload my firmware if someone is interested.
I can also contribute the porting to that subversion if it is not too out of reach for me.
Best,
-
The firmware dumps are always a little different as Canon stores a few things that change in the upper memory areas.
What does "erratic and did not look right" mean? If the CHDK version loads and runs at all it's the right version loaded.
However in shooting mode you will see the Canon firmware fight with the CHDK software for control of the LCD display. Try using CHDK in playback mode as much as possible.
-
Oh this is good news. I'll give it a second try.
I did a cmp -l which shows a first difference at 10MB from the beginning of the file (0xa00041).
Ch.
-
OK. I followed the instructions instead of relying on fully automated scripts (which wanted to create 2 partitions on the SD card) and it seems to be working as expected.
Many thanks.
-
OK. I followed the instructions instead of relying on fully automated scripts (which wanted to create 2 partitions on the SD card) and it seems to be working as expected.
I'm curious - what "fully automated scripts" ?
-
ok downloaded the build from autobuild server
seems to work ok other than a few crashes
particularly crashes everytime when i try to use
set_zoom (x) on a ptp interface
tried it even with chdkptp
zoom + or zoom - seems ok
however set_zoom (x) shuts down the camera
the same system works ok on other cameras - eg SX50hs and SX150
edit -------
ok did some more fiddling and the set_zoom(x) works consistently in the Auto mode
but fails in the M mode and P mode
-
seems
click 'video'
works intermittently
changing mode a few times to video and back makes click 'video' work
(will check more later to determine what sequence makes it work)
however....
press 'video' sleep (200) release 'video'
works consistently
- just to note tried everything from a ptp interface
same works on sx150 and sx50hs -so not a coding issue
-
Hi to all, I'm all new to CHDK.
I have a sx510, and I are very satisfied with it,along its restrictions.
So, few questions: how does the ALPHA build goes? Does it crash alot? Can I brick my camera with it? What can be done if bricked? Am I able to set ISO values what I want over 1sec shutter speed? Is it secure ti use?
Sorry for much question, it's my first camera and don't want to brick it already because I don't have the money for a new one :D
-
particularly crashes everytime when i try to use
set_zoom (x) on a ptp interface
tried it even with chdkptp
zoom + or zoom - seems ok
however set_zoom (x) shuts down the camera
Please test this version.
-
Hi to all, I'm all new to CHDK.
I have a sx510, and I are very satisfied with it,along its restrictions.
So, few questions: how does the ALPHA build goes? Does it crash alot? Can I brick my camera with it? What can be done if bricked? Am I able to set ISO values what I want over 1sec shutter speed? Is it secure ti use?
Sorry for much question, it's my first camera and don't want to brick it already because I don't have the money for a new one :D
link > SX510 HS questions - newbie around! (http://chdk.setepontos.com/index.php?topic=11863.msg116250#msg116250)
-
Dear chdk developers, could we expect to have more video settings in future releases of chdk for the sx510 hs. In particular I am interested in more settings for changing the video quality. There was such a setting for the A620 camera where the user could change the bitrate. I do not like the way the 720p movies look like compared to the 1080p movies. The 720p videos are too soft for my taste. I think that probably a setting for higher bitrate could help to solve the soft 720p videos problem.
-
Hello, I've read all ten pages and the wiki.
I'm sorry to be a noob. But we are people too. :)
I've got two days to return this camera - ANY ADVICE GREATLY APPRECIATED!
I'm pissed that:
(1) there's wifi but no remote capture or liveview... (I can do this on my watch with cellphone cam).
(2) NO usb charging and they went with some weird proprietary looking plug (mini usb seems to fit but no charging?)
(3) no HDR mode.
(4) you can view and download pictures via WIFI but NOT videos at all?
Are any of these things addressable with CHDK easily? I know C and C++ but it's been forever. How much coding do y'all think I might have to do to get any of these features working?
Thank you very much, in advance, for ANY advice whatsoever.
Best,
Franklin
-
Dear chdk developers, could we expect to have more video settings in future releases of chdk for the sx510 hs.
CHDK does not have a formal project planning systems or request mechanism. It's all volunteers who, being volunteers, get to work on what interests them. It's good that you made a request like this but please understand that if nobody responds it's because they either don't care about the feature and (usually) the feature will be a lot of work to implement for a particular camera and (usually) they don't have access to the camera model to do the work even if they are interested.
Hello, I've read all ten pages and the wiki.
I'm sorry to be a noob. But we are people too. :)
AFAIK, this forum is very newbie friendly.
I've got two days to return this camera - ANY ADVICE GREATLY APPRECIATED!
I'm pissed that:
(1) there's wifi but no remote capture or liveview... (I can do this on my watch with cellphone cam).
(2) NO usb charging and they went with some weird proprietary looking plug (mini usb seems to fit but no charging?)
(3) no HDR mode.
(4) you can view and download pictures via WIFI but NOT videos at all?
Are any of these things addressable with CHDK easily?
Easily? No - sorry.
I know C and C++ but it's been forever. How much coding do y'all think I might have to do to get any of these features working?
Number 1 will be a lot of work for an experience programmer even if they are fully immersed in CHDK development. Think in terms of man-months. Number 2 is a hardware issue - you'd have to hack circuits and solve it with solder and jumper wire. Number 3 can be done with simply CHDK scripts to create the seperate images & exposures but you will have to post process to produce a final image. Number four should not be too hard if you rename the mpg/avi file to jpg, download it, and rename it back to the original name on the PC.
-
We are testing SX510 with 1.3.0-3406 full Alpha.
1st we make connection and put it to rec. After command "luar set_zoom(60)", zoom moves but camera crashes and needs reboot.
2nd case:
We make connection and put it to rec. We use rs /tmp command to take pictures. Everything works and we can take multiple picutres in a row. But when play mode is turned on, camera crashes and needs reboot.
Everything else we need works.
(I tested also newer version 3673 of CHDK but camera crashes in firm update.)
-
2nd case:
We make connection and put it to rec. We use rs /tmp command to take pictures. Everything works and we can take multiple picutres in a row. But when play mode is turned on, camera crashes and needs reboot.
It is not a bug specific to this port, it is a remote capture known issue (http://chdk.wikia.com/wiki/User:Nafraf/RemoteShootIssues).
-
We are testing SX510 with 1.3.0-3406 full Alpha.
1st we make connection and put it to rec. After command "luar set_zoom(60)", zoom moves but camera crashes and needs reboot.
2nd case:
We make connection and put it to rec. We use rs /tmp command to take pictures. Everything works and we can take multiple picutres in a row. But when play mode is turned on, camera crashes and needs reboot.
Everything else we need works.
(I tested also newer version 3673 of CHDK but camera crashes in firm update.)
i have a little experience with the camera.
1. the camera crashes when you u zoom in the Program mode. Auto and Manual seem fine - ( This is also a problem with SX150 IS only in the ver 1.3 the problem does not occur in stable version in SX150 )
2. i have not checked this will check and report.
-
1. the camera crashes when you u zoom in the Program mode. Auto and Manual seem fine - ( This is also a problem with SX150 IS only in the ver 1.3 the problem does not occur in stable version in SX150 )
Was this reported somewhere else? If not already posted, a romlog might be helpful.
http://chdk.wikia.com/wiki/Debugging#Camera_crash_logs_.28romlog.29 (http://chdk.wikia.com/wiki/Debugging#Camera_crash_logs_.28romlog.29)
Also does this happen in all focus modes, and are you using any CHDK focus overrides or related commands like AFlock?
-
1. the camera crashes when you u zoom in the Program mode. Auto and Manual seem fine - ( This is also a problem with SX150 IS only in the ver 1.3 the problem does not occur in stable version in SX150 )
Was this reported somewhere else? If not already posted, a romlog might be helpful.
http://chdk.wikia.com/wiki/Debugging#Camera_crash_logs_.28romlog.29 (http://chdk.wikia.com/wiki/Debugging#Camera_crash_logs_.28romlog.29)
Also does this happen in all focus modes, and are you using any CHDK focus overrides or related commands like AFlock?
not using AFLock at the moment no focus overrides. just connecting thru the ptp interface and setting the Zoom using Set_zoom(x) crashes if the camera is in Program mode the workaround is that is just pass a script to save the mode switch to desired value restore the mode works for now
will provide romlog tomorrow when i have access to the camera.
EDIT : native lua calls have been turned as my only reson for getting 1.3 was aelock and manual exposure in video
-
not using AFLock at the moment no focus overrides. just connecting thru the ptp interface and setting the Zoom using Set_zoom(x) crashes if the camera is in Program mode the workaround is that is just pass a script to save the mode switch to desired value restore the mode works for now
will provide romlog tomorrow when i have access to the camera.
Is the camera in auto focus mode in the canon firmware?
Can you check in the Canon menu if Continuous AF or Servo AF is enabled? (If the camera supports either of those)
The CHDK code tries to re-focus after setting zoom, so it's possible that the SD override changes are related to this. 1.3 will be the stable branch soon, so it would be good to get this resolved.
-
Why it green when CHDK loaded? =)
sx510hs-101a-1.3.0-3837-full_ALPHA
-
Why it green when CHDK loaded? =)
sx510hs-101a-1.3.0-3837-full_ALPHA
The custom colors used in lib.c are overwriting something important in the camera's palette buffer. This will not change the colors in the resulting image JPG file - only the Canon on-screen display icons & text.
-
Why it green when CHDK loaded? =)
sx510hs-101a-1.3.0-3837-full_ALPHA
It would help us fix it if you can upload screenshots of the palette in both record and playback mode.
(CHDK Settings --> Color Settings --> Draw Palette).
Phil.
-
It would help us fix it if you can upload screenshots of the palette in both record and playback mode.
(CHDK Settings --> Color Settings --> Draw Palette).
Phil.
How to dump screenshot from device?
Anyway, here they are: playback/record
sx510hs-101a-1.3.0-3837-full_ALPHA
-
Hi, you all! I knew I already am registered on this forum, but I was wrong. I use CHDK since the beginning. I popularized CHDK firmware in my country (Romania) since the first tries... I remember GrAnd and others...
I used CHDK on my Canon A610, then recently on my SX150IS.
Now I have a new camera, SX510HS and I already installed CHDK on it. It's so exciting to see the outstanding progress of your work. CHDK works great on my cameras. Though, I have a problem. When I use ISO override (for example 6400) and camera is on A mode (aperture priority), the exposure time isn't modified accordingly (with ISO increasing) and the pictures are overexposed. In fact, the camera use the exposure time calculated for higher oficial ISO. Am I wrong something? I expected that camera adapt to the higher ISO and adjust by decreasing the exposure time.
-
When I use ISO override (for example 6400) and camera is on A mode (aperture priority), the exposure time isn't modified accordingly (with ISO increasing) and the pictures are overexposed. In fact, the camera use the exposure time calculated for higher oficial ISO. Am I wrong something? I expected that camera adapt to the higher ISO and adjust by decreasing the exposure time.
You have rediscovered one of the big limitations of CHDK exposure overrides. When you override the Tv, Av, or Sv value the camera's firmware is not aware that you have done so. It will calculate the other values ( the ones you have not overridden ) as if the value you set was not changed. And the resulting exposure will usually be incorrect.
So you either need to override all values ( "M" mode ) or use a script that recalculates the exposure values for you.
-
Why it green when CHDK loaded? =)
sx510hs-101a-1.3.0-3837-full_ALPHA
Please try the attached version.
This may not work, there does not appear to be a large enough common block of colors for CHDK to take over.
Phil.
-
You have rediscovered one of the big limitations of CHDK exposure overrides.
Ah, I understand. Thank you for the prompt reply. I use just occasionally overrides, so I can live with that. :)
Merry Christmas!
-
I noticed a strange behaviour of the battery indicator. It lasts very much between 100% and ~40%, but very, very few between ~40% and 0%. At ~40% the Canon low battery indicator starts to blink and very fast (matter of minutes) the battery come to 0% and I must plug the charger.
-
Please try the attached version.
This may not work, there does not appear to be a large enough common block of colors for CHDK to take over.
Phil.
All ok now!
sx510hs-101a-1.3.0-3851-full.zip
---
Edit: sx510hs-101a-1.3.0-3837-full_ALPHA vs sx510hs-101a-1.3.0-3855-full_ALPHA
-
I noticed a strange behaviour of the battery indicator. It lasts very much between 100% and ~40%, but very, very few between ~40% and 0%. At ~40% the Canon low battery indicator starts to blink and very fast (matter of minutes) the battery come to 0% and I must plug the charger.
I hope you'll give some attention at this battery issue, IMHO.
A question, with your permission: when I start my camera, always it starts in Play mode. Is there a setting to put it for always start in Shoot mode? Also, can I find a newer CHDK guide? I have a printed one, but it's too old and some specifications are changed.
-
All ok now!
sx510hs-101a-1.3.0-3851-full.zip
Your menu color is now a bit strange. I suspect that a full reset of CHDK is required. Either re-install cleanly to a wiped SD card or use the Reset_Options_to_Default (http://chdk.wikia.com/wiki/CHDK_1.3.0_User_Manual#Reset_Options_to_Default) option in the CHDK Settings menu.
I hope you'll give some attention at this battery issue, IMHO.
Battery code is common to all cameras - there is nothing specific to the SX510 port that could be wrong other than the default thresholds chosen. You can experiment and find better ones using the CHDK Manual - Battery (http://chdk.wikia.com/wiki/CHDK_1.3.0_User_Manual#Battery) settings.
Also, can I find a newer CHDK guide? I have a printed one, but it's too old and some specifications are changed.
http://chdk.wikia.com/wiki/CHDK_1.3.0_User_Manual (http://chdk.wikia.com/wiki/CHDK_1.3.0_User_Manual) The rest the various and sundry user guides are not maintained although I plan to release a new "for dummies" one shortly.
-
Thank you. Yes, the manual is newer than mine. :)
Well, is there a way to start camera in Shoot mode?
-
Well, is there a way to start camera in Shoot mode?
Press and hold the On/Off button until you hear the lens start to extent. Should take less than one second.
-
Your menu color is now a bit strange. I suspect that a full reset of CHDK is required. Either re-install cleanly to a wiped SD card or use the Reset_Options_to_Default (http://chdk.wikia.com/wiki/CHDK_1.3.0_User_Manual#Reset_Options_to_Default) option in the CHDK Settings menu.
After resetting CHDK settings colors back to normal.
-
Press and hold the On/Off button until you hear the lens start to extent. Should take less than one second.
Wow, so simple? Thank you!
Concerning the battery indicator: it shows long time 100% and slowly goes down to ~40%. Then the Canon low battery indicator starts to blink and the CHDK indicator goes down rapidly from ~40% to 0.
At my SX150IS there isn't such of behaviour. From the beginning of the blinking of Canon low battery indicator, there is very long time to zero battery.
Can any owner of SX510 confirm this behaviour?
-
Concerning the battery indicator: it shows long time 100% and slowly goes down to ~40%. Then the Canon low battery indicator starts to blink and the CHDK indicator goes down rapidly from ~40% to 0.
Try switching to battery voltage display and note the last voltage reading when the camera shuts down due to low battery (the camera should be in shooting mode when you do this test).
CHDK Settings -> OSD Settings -> Battery -> Show Battery Voltage [.]
If you have determined the shutdown voltage, you can enter it in the menu as Battery MIN Voltage, that will more or less correct the percent display.
-
Thank you. I'll try to do this. On the other hand, I think of the fact that my battery received only 2 charging cycles and it's not at its maximum capacity.
-
Is there a way to disable noise reduction in jpeg's? Or set the noise reduction to minimum, something like in dSLR's menu. For long exposures I checked "dark frame subtract" on "OFF", but I wonder if it's possible for short exposures, too. I ask this, because sometimes it's easier to process the jpeg's instead of RAWs.
Today, when everything is frozen at -15 Celsius, after a night with -25 C, I took several pictures. Here is one of them took at maximum tele, 720mm EFL.
(https://chdk.setepontos.com/proxy.php?request=http%3A%2F%2Fs10.postimg.org%2F5lhfiigmx%2FCRW_0239.jpg&hash=d8d140c11013911881b61fafe9c8637f)
-
Is there a way to disable noise reduction in jpeg's? Or set the noise reduction to minimum, something like in dSLR's menu. For long exposures I checked "dark frame subtract" on "OFF", but I wonder if it's possible for short exposures, too.
The canon firmware only uses dark frames for long exposures. In any case, dark frames aren't the kind of noise reduction that harms your image, they just take extra time. They are only used on long exposures because that's where the kind of problems they can fix gets significant. If the 2x shooting time isn't a problem, I would recommend leaving dark frame on for long exposures. Otherwise, you should take darks separately and subtract them later.
We don't currently know a way to control the noise reduction. It's probably something that could be found if someone is looking for a reverse engineering project. IIRC some of the higher end P&S have menu settings for it.
-
For long exposures in astronomy purposes isn't reccomended to activate DFS (dark frame subtraction). Other methods to remove hot pixels are preffered. You made me curious. I'll take some long exposure pictures by activate DFS to see how the picture is processed. Without DFS, the details are astonishing, even at higher values of ISO and long exposure time (I experimented with 1600ISO and 4-5 minutes exposure). If DFS wouldn't remove the stars, by confusing them with hot pixels, it would be extraordinary.
-
For long exposures in astronomy purposes isn't reccomended to activate DFS (dark frame subtraction)
Using dark frames is a very common technique in astrophotography.
If DFS wouldn't remove the stars, by confusing them with hot pixels, it would be extraordinary.
Canon dark frame works the essentially the same as dark frames are used in normal astrophotography: It takes an identical exposure with the shutter closed, and subtracts that from the real image. This takes care stuff like hot pixels and amp glow, and won't affect stars or details. There's no risk of hot pixels being confused with stars. The downside is that half you shooting time is taken up with the shutter closed.
It is conceivable that the variable we poke to control DFS has side effects on other parts of the Canon noise reduction process, but I haven't seen any evidence of this.
What I use for night photos is take a series of dark frames separately, average them (median is recommended, but in camera average is easy), and use that for shots with the same shutter and ISO. You do want the darks taken at approximately the same temperature, I have found that darks taken at 30-40c sensor temperature were noticeably too hot for shots taken at ~25c.
-
SX150 discussion moved to the porting thread: http://chdk.setepontos.com/index.php?topic=6953.msg119719#msg119719 (http://chdk.setepontos.com/index.php?topic=6953.msg119719#msg119719)
Thanks andrew.stephens.754365 for following up and helping keep on things topic.
-
Canon dark frame works the essentially the same as dark frames are used in normal astrophotography: It takes an identical exposure with the shutter closed, and subtracts that from the real image.
Yes, in theory is the same, but practically on my Canon 550D I take lights then darks, flats, bias frames separatelly, then combine them using astrophoto software who has far better results than in camera processing, with DFS active.
-
Maybe the zebra code could be modified to not write anything to
a) the cam's bitmap overlay
or
b) its internally malloc'd memory
but make boundary checks instead.
Or, does anyone have a better idea?
Using #define CAM_ZEBRA_NOBUF 1 camera has not crashed.
It is not perfect, but it is usable: https://trac.assembla.com/chdk/browser/trunk/modules/zebra.c#L150
The problem with the SX510 appears to be the definitions of vid_get_viewport_width() and vid_get_viewport_height().
These should return sizes in CHDK co-ordinates (360x240 or 480x240), not actual camera physical sizes - that's what the _proper() functions are for.
Compare the SX510 to the G1X to see the difference.
Because these functions are returning values much too large, the zebra code is drawing outside the memory buffer.
Phil.
-
I found a bug in the viewport related routines (at least one address is wrong).
Looking for somebody with the camera who can do some testing.
-
It looks like this camera has the same incorrect front dial code as sx160, sx170 and sx500: http://chdk.setepontos.com/index.php?topic=11164.220 (http://chdk.setepontos.com/index.php?topic=11164.220)
I've checked the fix into the 1.4 trunk, autobuild 4010 and later. If anyone can confirm it still works correctly, that would be appreciated.
-
Hello everyone!
I'm new to this forum but am using chdk for over two years now on my PS A550 camera and did over 3 million shots shooting timelapse sequences.
i was using mostly intervalometer and sometimes hdr and stacking scripts and was very pleased with the functionality that chdk gave me over my cam.
The thing is i weared the sensor badly and now im into purchasing a new cam and got my eyes on the sx510hs.
I've read allmost anything regarding this model and am concerned about the "limited features" regarding this cam fw...don't want to buy a $200 cam that doesnt fulfill my needs (i own a D800 and some mid range lens - i would rather invest in battery grip or something else...)
so the question is:
Does this build support simple intervalometer without crashing and also i use focus distance overrides and ev bracketing for hdr...that's almost everything i need from my PS Cam so if it has isues i'll move along to another model...also got my eyes on SX230HS...that would be my #2 choice....
So i would appreciate your time to offer me some info about that....
THNX!
-
also got my eyes on SX230HS...that would be my #2 choice....
So i would appreciate your time to offer me some info about that....
THNX!
Not sure what state the 510 is in.
The sx230 port has some unresolved issues, discussed in this thread http://chdk.setepontos.com/index.php?topic=12183.0 (http://chdk.setepontos.com/index.php?topic=12183.0) (I still need to find some time to work on that)
-
also got my eyes on SX230HS...that would be my #2 choice....
So i would appreciate your time to offer me some info about that....
THNX!
Not sure what state the 510 is in.
The sx230 port has some unresolved issues, discussed in this thread http://chdk.setepontos.com/index.php?topic=12183.0 (http://chdk.setepontos.com/index.php?topic=12183.0) (I still need to find some time to work on that)
thank you, not quite sure what to do, and i dont have much time either, i'm working on arboretum project and spring is coming fast and the flowering started already....will have to settle down for an older digic proc i suppose...
-
thank you, not quite sure what to do, and i dont have much time either, i'm working on arboretum project and spring is coming fast and the flowering started already....will have to settle down for an older digic proc i suppose...
FWIW, canon refurbished can be a good source:
http://chdk.setepontos.com/index.php?topic=11768.0 (http://chdk.setepontos.com/index.php?topic=11768.0)
The sx230 issue may not affect if you aren't trying to use raw while shooting rapidly.
-
Thanx for the nfo! I managed to locate and reserve the only sx230 left instock in croatia and will purchase it tomorrow so the next thing will be posting my fw and results....ill be using raw and inrervalometer script with exposure bracketing when needed...hope it will work!
Wish me luck!
-
I've checked the fix into the 1.4 trunk, autobuild 4010 and later. If anyone can confirm it still works correctly, that would be appreciated.
How to check?
-
I've checked the fix into the 1.4 trunk, autobuild 4010 and later. If anyone can confirm it still works correctly, that would be appreciated.
How to check?
I think this was already confirmed, srsa merged it to the 1.3 branch, but if you want to make sure:
Check that the jogdial (the wheel built into the direction buttons around the func set key) scrolls the CHDK menus when they are open, and works normally in the canon firmware when not in alt mode.
-
Check that the jogdial (the wheel built into the direction buttons around the func set key) scrolls the CHDK menus when they are open, and works normally in the canon firmware when not in alt mode.
All OK for me in sx510hs-101a-1.3.0-3855-full_ALPHA and sx510hs-101a-1.3.0-4043-full_ALPHA. Or it only affected on v1.4?
-
All OK for me in sx510hs-101a-1.3.0-3855-full_ALPHA and sx510hs-101a-1.3.0-4043-full_ALPHA. Or it only affected on v1.4?
Thanks for checking, the change is in 1.3 from 4035 onward, so that confirms it's OK.
-
The problem with the SX510 appears to be the definitions of vid_get_viewport_width() and vid_get_viewport_height().
These should return sizes in CHDK co-ordinates (360x240 or 480x240), not actual camera physical sizes - that's what the _proper() functions are for.
Thanks. Changes committed to trunk r4134 (https://www.assembla.com/code/chdk/subversion/commit/4134)
-
Can the CHDK of SX510 be modified in anyway so as to be run on SX520?
-
Can the CHDK of SX510 be modified in anyway so as to be run on SX520?
Unless a camera is simply a "re-badged" copy of another model (i.e. same camera, different box, case color or accessories) then the answer to this question is pretty much always "no". These cameras have different sensors, different lenses, and were released in different years. Never mind that one uses a DIGIC4 processor and the other a DIGIC4+ processor.
-
Maybe someone can make at least BETA firmware for sh510?
ALPHA bad works.
Кстати, может есть кто русский? хD
-
ALPHA bad works.
There is no formal definition of Alpha or Beta with CHDK. So there is no reason to ask for a beta release. Instead Can you tell us what does not work properly?
-
Hellow!
I've got the SX510HS 1.00A firmware dump. Link https://yadi.sk/d/ViaWCzAkkVrVh (https://yadi.sk/d/ViaWCzAkkVrVh)
-
Hellow!
I've got the SX510HS 1.00A firmware dump. Link https://yadi.sk/d/ViaWCzAkkVrVh (https://yadi.sk/d/ViaWCzAkkVrVh)
Thanks. Since this firmware is compatible with the already existing 100d port, I enabled it (https://www.assembla.com/spaces/chdk/subversion/commits/4292) for 1.4 autobuild. It will show up here (http://mighty-hoernsche.de/trunk/) soon.
-
Using CHDK 1.4.0-4291 on my SX510-HS, no major bugs at the moment, only had one issue with a user written script "TLapse1.lua" where I did get the version warning message and camera turned off, but after trying it again it runs fine now, maybe camera had to overwrite new configs for that script? One issue I do have is that using or enabling zebra it does show me the over-exposed areas but once I shoot the camera goes off, this is with any type of zebra (solid, blinking). I don't know if this happened with stable CHDK since I just started playing with the zebra mode.
Thank you all for you wonderful hard work! :)
-
OK, now I'm using commit 4293 since 4292 has a compatibility update specifically for my camera, zebra mode shoots the first shot, then powers down if taking another one.
I also noticed that stopping the script "TLapse1.lua" also powers off the camera, when using commit 4291 I would get the message "Interrupted" which I kind of liked because it stayed on, but that also happened to me in stable 1.3, it would power off (no lens retraction just like a sleep off).
The reason I use that script instead of the one that comes shipped with CHDK is because it has the option to automatically power off the display to save battery and I like the autofocus and auto ev locks in it.
Thanks
-
OK, just an update, zebra mode is working with 4293. I think I had to reboot camera after enabling it. I'll keep an eye open for this....
EDIT: No, spoke too soon, sometimes it does work and other it powers off when pressing shutter...
::)
-
Thanks for the report. I moved this to the porting thread since this seems camera specific.
Some suggestions
1: Get a romlog http://chdk.wikia.com/wiki/Debugging#Camera_crash_logs_.28romlog.29 (http://chdk.wikia.com/wiki/Debugging#Camera_crash_logs_.28romlog.29)
2: Check free memory at startup under miscellaneous -> Show memory info
3: Re-install 1.3 and see if it crashes with the same settings.
-
Oh, OK! I also just had a crash when purging orphaned DNG's, I'll do what you advise.
Thanks!
-
Oh, OK! I also just had a crash when purging orphaned DNG's, I'll do what you advise.
Thanks!
Thanks. For the romlog, note that the camera records the most recent crash, so if you save the romlog now, without triggering the zebra crash again, it will be for the purging issue. To get one for the zebra crash, make sure you trigger that and then get a romlog immediately after.
-
OK, for SVN 4293
Free Memory on Startup: 1480192 bytes
This is the romlog for zebra crash in same version:
ASSERT!! Memory.c Line 76
Occured Time 2015:11:17 16:11:33
Task ID: 7602190
Task name: _imageSensor0
SP: 0x005A27A4
StackDump:
0x00000000
0x00000000
0xFF017F0C
0x0000004C
0x00000000
0x00005FB0
0x0000DDA4
0x00005FB0
0x00000BF6
0x00000000
0x0000DE34
0x00000000
0xFF017E84
0x00000000
0x00000000
0x0000DDA4
0xFF318BF4
0x0000DDA4
0x00000000
0x005A2870
0x0000DDA4
0x00000001
0xFF318F48
0x00000001
0x00000001
0x005A2870
0xFF319144
0xFFF40658
0x00000000
0x005A2870
0xFF186C08
0x00000000
0x005A2870
0x000CAEC0
0x00007560
0x00000000
0x00000000
0x00000001
0x0000000C
0x000F55FB
0xFF186FF8
0x000CAEC0
0x0064F014
0x00640040
0x00001048
0x00000BF6
0x0000000C
0x00000001
0x00000001
0x00000000
0xFF121F74
0x00001048
0x00000BF6
0x00000040
0x0000F014
0x0000000C
0x00000001
0x00000001
0x00000000
0x00000000
0x00002134
0x00020590
0x00000000
0x00000000
0xFF02E068
0x00000001
0x00000001
0x00000001
0x00000001
0x0000000E
0x00000000
0x00000000
0xFF1C6470
0x00003480
0x000001B0
0x00000000
0x00000000
0x00002134
0x00000000
0x00000001
0x0000000E
0x00000000
0x00000000
0xFF02CCDC
0xFF02E824
0x00000863
0x19980218
0x19980218
0x000F55FB
0xFF02CBE4
0x00020584
0x0000210C
0x00000041
0x00000001
0x00590900
0x19980218
0x19980218
0x19980218
0x19980218
0x19980218
0x19980218
0x19980218
0x006B2864
0x19980218
0x19980218
0x00000408
ShootConDump:
01 02 07 08 20 0a 0c 0b 00 00
CameraConDump:
07 0a 02 0d 09 01 0f 0f 0f 0f
00018740: UI:Re ScreenUnLock
00018740: UI:Reduce ScreenUnLock
00018740: UI:DisplayPhysicalScreenCBR
00018740: UI:Re ScreenUnLock
00018740: UI:Reduce ScreenUnLock
00018740: UI:DisplayPhysicalScreenCBR
00018740: UI:Re ScreenUnLock
00018740: UI:Reduce ScreenUnLock
00018740: UI:DisplayPhysicalScreenCBR
00018740: UI:Re ScreenUnLock
00018740: UI:Reduce ScreenUnLock
00018750: UI:DisplayPhysicalScreenCBR
00018750: UI:Re ScreenUnLock
00018750: UI:ScreenUnLock
00018760: UI:DisplayPhysicalScreenCBR
00020160: UI:Button:0x000009A1:PressSwOne
00020160: UI:ScreenLock
00020160: UI:ScreenUnLock
00020160: SS:PreBuf
00020160: SS:BitR
00020160: UI:ShtCon_ResetShootingNumber
00020160: UI:ShootState:0x1
00020160: UI:ShtCon_Activate
00020160: UI:DispSw: Lock
00020160: UI:ShtCon_ShutDownRecModeMenu
00020160: UI:DSIC:61,0
00020160: UI:ScreenLock
00020160: UI:DSIC:e,0
00020160: UI:ScreenUnLock
00020170: UI:ScreenLock
00020170: UI:Reduce ScreenUnLock
00020170: UI:LogicalEvent:0x3136:adr:0,Para:0
00020170: UI:DSIC:e,0
00020170: UI:DisplayPhysicalScreenCBR
00020170: UI:Re ScreenUnLock
00020170: UI:Reduce ScreenUnLock
00020170: UI:ShtCon_PrepareCapture
00020170: SS:PreCapt
00020170: UI:ShootState:0x2
00020180: UI:ClearEventComp
00020180: UI:DisplayPhysicalScreenCBR
00020180: UI:Re ScreenUnLock
00020180: UI:ScreenUnLock
00020180: UI:LogicalEvent:0x1163:adr:0,Para:0
00020180: UI:DCIC:85,0
00020200: UI:DCIC:81,0
00020210: UI:DisplayPhysicalScreenCBR
00020520: UI:ShootSeqToUI:0x203b:adr:0,Para:0
00020530: UI:ShtCon_SetAFBeep
00020530: UI:DSIC:69,0
00020740: UI:ShootSeqToUI:0x2006:adr:0x1ddc,Para:7644
00020750: UI:ShtCon_SetPreCapt
00020750: UI:Strobe:Close
00020750: UI:ChangePopupStrobe:Close
00020760: SS:PopChg
00020760: UI:DSIC:62,1
00020760: UI:ScreenLock
00020770: SS:IsCharge=1
00020800: UI:ScreenUnLock
00020820: UI:_ResetShootingMode
00020820: UI:_EntryPrepareShoot
00020820: UI:ShootState:0x7
00020830: UI:DisplayPhysicalScreenCBR
00022310: UI:Button:0x000009A3:PressSwTwo
00022310: UI:ScreenLock
00022310: UI:ScreenUnLock
00022310: UI:ShootState:0x8
00022310: UI:ShootState:0x20
00022310: UI:ChangePopupStrobe:Close
00022320: SS:PopChg
00022320: UI:DSIC:14,0
00022320: UI:_MuteOn
00022320: UI:DSIC:43,0
00022320: UI:DispSwCon_MuteOnPhysicalScreen
00022320: UI:Window MuteOn
00022320: UI:MuteOnPhysicalScreen
00022320: SS:StartShoot
00022320: SS:SCtrl:Shoot(1/0x1)
00022320: UI:_CaptureCount->1
00022320: SS:ChkS2
00022330: UI:ShootSeqToUI:0x203f:adr:0xff3714c8,Para:-13167416
00022330: UI:DSIC:63,0
Zebra does not crash with stable 1.3 but does not draw nicely, I get sometimes the whole scene blinking red as if all was over-exposed, but draws correctly with unstable.
I'll see if I can replicate the other crashes and post them here. Will this also work for the timelapse script I'm having issues with when stopping it?
Thanks
-
OK, for SVN 4293
Free Memory on Startup: 1480192 bytes
That would look like a decent amount of memory, but...
This is the romlog for zebra crash in same version:
... the assert is due to "out of memory".
I'll see if I can replicate the other crashes and post them here. Will this also work for the timelapse script I'm having issues with when stopping it?
Yes. Just restart the cam after the crash and get a romlog.
edit:
Changeset 4292 is only about adding support for the 100a firmware revision, it doesn't change anything for this port.
-
That would look like a decent amount of memory, but...
Yes, just enabling zebra my memory went down considerably. Fooling around with the camera with it enabled but not shooting my camera's RAM went way below the 400 KB free RAM after a short while as specified in the "Testing Needed" WIKI page:
"If the Free Memory value is less than 400kb or so, there is a high risk of running out of memory. The port developer may be able to enable ARAM or EXMEM to gain additional memory. "
Even the focusing square would not appear any longer.
I'll do all the testing needed and run the included testing scripts and post my results later.
Thanks!
-
Just before anything, I want to post another romlog for a user written script that usually doesn't stop gracefully, it's this script:
http://chdk.wikia.com/wiki/Time_Lapse_Script_One (http://chdk.wikia.com/wiki/Time_Lapse_Script_One)
I use this script because I like the idea of turning off the display to save battery and the focus/ev locks it has. It runs fine, just when I stop it I never get the "Interrupted" or "Stopped" message, camera just goes off, so I think it does crashes, this is the romlog I get after running that script, I know user made scripts are "as is" but hope it helps for something...
ASSERT!! SsShootTask.c Line 268
Occured Time 2015:11:18 09:21:13
Task ID: 16449574
Task name: PhySw
SP: 0x005B137C
StackDump:
0x00000000
0x00000000
0xFF072578
0x0000010C
0x00023F5C
0x00003670
0x00003670
0x0000001A
0x19980218
0x19980218
0x19980218
0x19980218
0xFF0723DC
0x00000000
0x00000001
0x00003670
0xFF07240C
0x00000000
0x004435B8
0x00444B08
0x00000200
0x004435B8
0xFF072AC8
0x004435B8
0xFF1D7710
0x004435B8
0x00267088
0x0026706C
0x004281B1
0x004435B8
0x0042CEBB
0x00446268
0x00000048
0x00000001
0x0044D023
0x004435B8
0x00000001
0x00444B08
0x00000200
0x004435B8
0x00431C2B
0x00000002
0x005B145C
0x00444B08
0x0044D464
0x0044D348
0x0044D460
0x00444DF8
0x00000005
0x00000000
0xFF007DCC
0x0028D730
0x00000005
0x0000000C
0x004435B8
0x00000000
0x0043D01C
0x002866E8
0x0042CF25
0x004435B8
0x0042C9A3
0x004435B8
0x0042CED5
0x00444AF8
0x00000000
0x00367524
0x00000000
0x004435B8
0x00000000
0x0043D01C
0x002866E8
0x19980218
0x19980218
0x19980218
0x19980218
0x0026CA99
0x005B1470
0x0042C997
0x00000001
0x00003A2C
0x006B3BEC
0x01EA0028
0x005B14E8
0x00000000
0x000039A4
0x00000000
0x006DA688
0x0043CD74
0x00000000
0x0043D01C
0x00000000
0x0001D218
0x0042CFD1
0x00000000
0x0043CD74
0x00000000
0x004294E1
0x004294B5
0x002866E8
0x00000001
0xA32F1C9E
0x002866E8
0x00277111
0xA32F1C9E
0x00276B79
0x00003C20
0x00000000
0x60000093
0x00000019
0x00000000
0xFF088E40
0x423A4955
0x005910E0
0x00593B34
0x005B1588
0x00287D08
0x00287D94
0x00003880
0x00000000
0xFF04F448
0x00000000
0x00000000
0x005B158C
0xFF568658
0xFF04ED04
0x002859F0
0x00000000
0x19980218
ShootConDump:
0c 0b 00 00 01 02 07 08 20 0a
CameraConDump:
07 0a 02 0d 09 01 0f 0f 0f 0f
00117150: UI:ChangePopupStrobe:Close
00117160: SS:PopChg
00117160: UI:DSIC:62,1
00117160: UI:ScreenLock
00117160: SS:IsCharge=1
00117200: UI:ScreenUnLock
00117220: UI:_ResetShootingMode
00117220: UI:_EntryPrepareShoot
00117220: UI:ShootState:0x7
00117220: UI:DisplayPhysicalScreenCBR
00117690: UI:Button:0x000009A3:PressSwTwo
00117690: UI:ScreenLock
00117690: UI:ScreenUnLock
00117690: UI:ShootState:0x8
00117690: UI:ShootState:0x20
00117690: UI:ChangePopupStrobe:Close
00117690: SS:PopChg
00117690: UI:DSIC:14,0
00117690: UI:_MuteOn
00117690: UI:DSIC:43,0
00117690: UI:DispSwCon_MuteOnPhysicalScreen
00117690: UI:Window MuteOn
00117690: UI:MuteOnPhysicalScreen
00117690: SS:StartShoot
00117690: SS:SCtrl:Shoot(1/0x1)
00117720: UI:ShootSeqToUI:0x203f:adr:0xff3714c8,Para:-13167416
00117720: UI:_CaptureCount->1
00117720: SS:ChkS2
00117720: UI:DSIC:63,0
00117720: UI:ScreenLock
00117730: UI:ScreenUnLock
00117740: UI:ScreenLock
00117740: UI:ScreenUnLock
00117740: UI:ScreenLock
00117740: UI:ScreenUnLock
00117750: UI:ScreenLock
00117750: UI:ScreenUnLock
00117750: UI:DisplayPhysicalScreenCBR
00117750: UI:_MuteOff
00117750: UI:DSIC:44,0
00117750: UI:DispSwCon_MuteOffPhysicalScreen
00117750: UI:Window MuteOff
00117750: UI:MuteOffPhysicalScreen
00117750: UI:DisplayPhysicalScreenCBR
00117750: UI:DisplayPhysicalScreenCBR
00117750: UI:DisplayPhysicalScreenCBR
00117750: UI:DisplayPhysicalScreenCBR
00117890: UI:ShootSeqToUI:0x2040:adr:0x591ae0,Para:5839584
00117890: UI:DSIC:64,0
00118330: UI:ShootSeqToUI:0x203e:adr:0,Para:0
00118330: UI:ShootSeqToUI:0x2001:adr:0x19980218,Para:429392408
00118330: UI:Sht_CancelStrobeChargeTimer
00118330: UI:DSIC:4c,0
00118330: UI:ScreenLock
00118340: UI:ScreenUnLock
00118340: UI:DisplayPhysicalScreenCBR
00118340: SS:SCtrl:NextShot(1)
00118340: SS: Raw[1]
00118620: SS:SCtrl:RecReview
00118620: UI:ShootSeqToUI:0x2041:adr:0x23bf8,Para:146424
00118620: UI:ShtCon_ResetShootingNumber
00118620: UI:ShootState:0xA
00118620: UI:ShtCon_StartReview
00118620: UI:ShootState:0xC
00118620: UI:ShtCon_ResetShootingNumber
00118620: UI:_EntryPrepareRecreviewOff
00118620: UI:ShootState:0xB
00118620: UI:ShtCon_StopReview
00118710: UI:DSIC:47,0
00118710: UI:DSIC:46,0
00118710: SS:SCtrl:CompShootPic(0)
00118710: UI:ShootSeqToUI:0x2029:adr:0x23c04,Para:146436
00118720: UI:_NormalCompleteShootPictureAction
00118720: UI:_CheckNextShotAvailable
00118720: UI:_CaptureCount->0
00118720: SS:SW1L
00118720: SS:NextAvail(3),ReviewAvail(8)
00118820: UI:Button:0x000009A4:UnpressSwTwo
00118820: UI:Button:0x000009A2:UnpressSwOne
00118970: UI:DSIC:48,0
00119320: SS:AEUL
00119320: SS:_MFOff
Thanks!
-
Yes, just enabling zebra my memory went down considerably. Fooling around with the camera with it enabled but not shooting my camera's RAM went way below the 400 KB free RAM after a short while as specified in the "Testing Needed" WIKI page:
If you can narrow down what causes the free memory to go down, that would be very helpful.
For example, if you have zebra enabled, does free memory go down by a certain amount every time you half press? Does it go down if you don't have zebra enabled?
Note that the camera memory use varies on it's own so you may need to do multiple tests to be sure there's a real pattern.
It might be useful to note how much is free at
1) just after startup, in playback mode
2) after switching to rec
3) after pressing and releasing half press once
4) after shooting once
5) after shooting twice
I will try to look at the script and romlog later.
-
OK This is pretty much what I get after a few times:
Free Memory Without Zebra Enabled:
1) just after startup, in playback mode: 1480192
2) after switching to rec: 1480192
3) after pressing and releasing half press once: 1480192
4) after shooting once: 1480192
5) after shooting twice: 1480192
Free Memory With Zebra Enabled:
1) just after startup, in playback mode: 1480192
2) after switching to rec:CRASHES WHEN CHECKING MEMORY INFO
3) after pressing and releasing half press once: CRASHES WHEN CHECKING MEMORY INFO
4) after shooting once: SOMETIMES IT CRASHES & SOMETIMES IT DOESN'T BUT WILL CRASH WHEN CHECKING MEMORY INFO
5) after shooting twice: SOMETIMES IT CRASHES & SOMETIMES IT DOESN'T BUT WILL CRASH WHEN CHECKING MEMORY INFO
I was able to do steps 2 & 3 with zebra enabled and then go and disable it I could see my free Memory which was 275648 bytes, if I try replicating this routine it usually crashes
I will try to look at the script and romlog later.
Thanks! I appreciate that very much!
-
Just before anything, I want to post another romlog for a user written script that usually doesn't stop gracefully, it's this script:
http://chdk.wikia.com/wiki/Time_Lapse_Script_One (http://chdk.wikia.com/wiki/Time_Lapse_Script_One)
To help with that, it appears that there may be a problem with the fw routine set_mf is using (and it does not seem directly memory related). One option is to replace the script's lock_focus() and unlock_focus() with these:
function lock_focus()
set_aflock(1) -- fall back to AFL if set_mf fails
end
function unlock_focus()
set_aflock(0)
endMay I ask the firmware version of your camera? We may need that later.
-
To help with that, it appears that there may be a problem with the fw routine set_mf is using (and it does not seem directly memory related). One option is to replace the script's lock_focus() and unlock_focus() with these:
Hey thanks! Actually I just tried the original script without locked focus/exposure and it did stop gracefully, so I'll try those changes in the script later and test.
May I ask the firmware version of your camera? We may need that later.
according to Canon site there has not been a firmware update so I guess version 1.0.1.0 according to the CHDK firmware update if I load CHDK by that way.... ???
-
I also want to say that the jog dial (the one in the back not the mode dial) sometimes seems to be unresponsive, is this a possibility with CHDK? sometimes it's perfectly fine and others I have to dial a lot for it to respond. This did happen also with CHDK stable 1.3 but forgot to mention....
-
Free Memory With Zebra Enabled:
1) just after startup, in playback mode: 1480192
2) after switching to rec:CRASHES WHEN CHECKING MEMORY INFO
3) after pressing and releasing half press once: CRASHES WHEN CHECKING MEMORY INFO
4) after shooting once: SOMETIMES IT CRASHES & SOMETIMES IT DOESN'T BUT WILL CRASH WHEN CHECKING MEMORY INFO
5) after shooting twice: SOMETIMES IT CRASHES & SOMETIMES IT DOESN'T BUT WILL CRASH WHEN CHECKING MEMORY INFO
I was able to do steps 2 & 3 with zebra enabled and then go and disable it I could see my free Memory which was 275648 bytes, if I try replicating this routine it usually crashes
Thanks. Can you try the same procedure with 1.3?
For the firmware version, we need the canon firmware version like 100a or 101b. This will be part of the name of the CHDK build you are using. You can also see it in "build info" under the misc. menu.
-
Thanks. Can you try the same procedure with 1.3?
Sure! I'll do that in a while and post...
For the firmware version, we need the canon firmware version like 100a or 101b. This will be part of the name of the CHDK build you are using. You can also see it in "build info" under the misc. menu.
Oh, ha ha! Sorry about that, yes I have FW 101a
Thanks so much for all your help! :)
-
OK, with CHDK 1.3 these are my results:
Free Memory Without Zebra Enabled:
1) just after startup, in playback mode: 1471264
2) after switching to rec: 1471264
3) after pressing and releasing half press once: 1471264
4) after shooting once: 1471264
5) after shooting twice: 1471264
Free Memory With Zebra Enabled:
1) just after startup, in playback mode: 1237576
2) after switching to rec: 1237576
3) after pressing and releasing half press once: 1237576
4) after shooting once: 1237576
5) after shooting twice: 1237576
NOTE: I noticed that my memory dropped as soon as there were images to display, because I repeated procedure again without zebra and got same results as with zebra, when I deleted photos, it went back to 1471264 bytes, which I believe is normal since it has to load thumbnails for display
-
I also want to say that the jog dial (the one in the back not the mode dial) sometimes seems to be unresponsive, is this a possibility with CHDK? sometimes it's perfectly fine and others I have to dial a lot for it to respond. This did happen also with CHDK stable 1.3 but forgot to mention....
Does this affect the canon UI, the CHDK menus, or both?
-
Does this affect the canon UI, the CHDK menus, or both?
Usually both...
-
Regarding the crash, the 1.3 notes.txt has says
#define CAM_ZEBRA_NOBUF 1 used to prevent crash, see: http://chdk.setepontos.com/index.php?topic=10984.msg112340#msg112340 (http://chdk.setepontos.com/index.php?topic=10984.msg112340#msg112340)
It looks like no further progress was made on this issue, and the define was not added in the trunk. edit: not correct, see later posts.
I've attached a 1.4 build with this define set. To me, the symptoms like look some kind of memory corruption...
edit:
Oops, I attached the wrong build
edit 2:
Correct build attached, previous one didn't actually have the define set :-[
-
I've attached a 1.4 build with this define set. To me, the symptoms like look some kind of memory corruption...
Just tested it, it did take a shot at first or two, then crashed. Same when checking memory after half press.
Now memory when powering on on play is 1279352 bytes both zebra enabled or disabled.
About the jogwheel. I disabled CHDK to use camera normally and seems to be more responsive, I'll keep an eye on that....
-
Correct build attached, previous one didn't actually have the define set :-[
OH OK :P
Let's see...
-
Will just extracting and overwriting the whole structure in card work? Nothing will become corrupt?
-
Will just extracting and overwriting the whole structure in card work? Nothing will become corrupt?
Yes, that should be fine.
Looking further, the zebra bug was supposedly fixed trunk r4134, referencing this post http://chdk.setepontos.com/index.php?topic=10984.msg120213#msg120213 (http://chdk.setepontos.com/index.php?topic=10984.msg120213#msg120213)
Still worth trying 1.4 with the define set.
-
OK, it's working! The only issue is that it draws sometimes all over the screen blinking like it does with 1.3, but I can see the overexposed highlights, no crashes and memory seems to be stable... :D
-
Well I'm off to sleep for now! Any further testing just let me know and I'll get back to you tomorrow. I'll keep an eye open on the rest and see what else pops up...
I want to thank you so much for you hard work...
Cheers! :)
-
It looks like no further progress was made on this issue, and the define was not added in the trunk.
That define was actually removed, once nafraf found that zebra no longer crashes the camera without defining CAM_ZEBRA_NOBUF.
To me, the symptoms like look some kind of memory corruption...
FWIW, if memory right below the allocated area (base pointer - 8) gets corrupted, free() will no longer work (checked this on a r50 camera, so it can be different here).
Also, it would be possible to hook malloc and free (their low level functions actually), but I don't know how much debug data that would generate.
-
It looks like no further progress was made on this issue, and the define was not added in the trunk.
That define was actually removed, once nafraf found that zebra no longer crashes the camera without defining CAM_ZEBRA_NOBUF.
Yes, I did notice that eventually (http://chdk.setepontos.com/index.php?topic=10984.msg125541#msg125541) but apparently NOBUF stops the crashing again. :-[
I haven't had time to look at the zebra code yet to see if there are additional problems with the dimensions.
-
@joegiampaoli
Here's another test build for the zebra issue. I think the viewport height may have been incorrect before. Please check if zebra crashes, and if it doesn't, make sure it still looks correct.
-
:D
It's drawing perfectly, updates as I move camera, no full screen blinking red. Memory is stable, no crashes, tried half press and full press, memory good after that. I just have to calibrate it now with the previews of the canon.
Thank you so much! :)
-
Oh I haven't done the included tests to give you results, sorry about that, been so busy with work! I'll get to that ASAP!
Cheers!
-
:D
It's drawing perfectly, updates as I move camera, no full screen blinking red. Memory is stable, no crashes, tried half press and full press, memory good after that.
Thanks for testing, I've checked that change in, so it will be in 1.4 autobuilds 4294 and later.
I just have to calibrate it now with the previews of the canon.
You mean the threshold values?
Oh I haven't done the included tests to give you results, sorry about that, been so busy with work! I'll get to that ASAP!
No worries, you've already helped a lot :)
-
Thanks for testing, I've checked that change in, so it will be in 1.4 autobuilds 4294 and later.
Perfect! I'll later download a fresh install to run it all freshly!
You mean the threshold values?
Yes, I see I do have to raise the over-exposure values
One question, should the histogram be just the same as the one on the preview of canon's or not really since it's measuring a higher DR from the sensor and in a realtime way and not the JPEG's?
-
Perfect! I'll later download a fresh install to run it all freshly!
There shouldn't be much need to re-test stuff that's already been tested with build I posted.
One question, should the histogram be just the same as the one on the preview of canon's or not really since it's measuring a higher DR from the sensor and in a realtime way and not the JPEG's?
It won't be identical, but it should be recognizably similar. CHDK options like log vs linear, auto magnify etc. will affect how similar.
The CHDK histogram comes from the live view buffer, so it probably isn't higher DR than the Canon jpeg one.
-
Perfect! Just wanted to make sure if it was OK if histogram wasn't identical to what I saw in jpeg previews, but it does look similar as you say
Thanks again!
-
OK, I had some free time today to do some of the test scripts included in 1.4
isobase didn't create a log but this is the result I got from screen:
isobase.lua
BASE=200
I have a question about that isobase, does that mean that's the camera's "native true ISO"? like NIKON's that have 200 as base also? Or nothing to do with that? And do you know what is the true basic ISO in Powershots? 80? 100? ???
Attaching one file with the logs, help that helps if needed for something and thanks for this awesome freedom! :)
-
OK, I had some free time today to do some of the test scripts included in 1.4
isobase didn't create a log but this is the result I got from screen:
isobase.lua
BASE=200
Thanks. This is set correctly in the port.
I have a question about that isobase, does that mean that's the camera's "native true ISO"? like NIKON's that have 200 as base also? Or nothing to do with that?
From a CHDK POV, it's an arbitrary constant that is require to correctly override the ISO setting. The Canon auto ISO works by adding a (positive or negative) offset to a base value. CHDK (ab)uses this for ISO overrides.
And do you know what is the true basic ISO in Powershots? 80? 100? ???
It almost certainly varies between cameras, Canon users many different sensors, and the minimum ISO available in the UI varies between models. ISO override is a complicated subject, the Canon firmware uses two different units (which we refer to as "real" and "market") http://chdk.setepontos.com/index.php?topic=10341.0 (http://chdk.setepontos.com/index.php?topic=10341.0)
See also http://chdk.setepontos.com/index.php?topic=12165.50 (http://chdk.setepontos.com/index.php?topic=12165.50)
-
Today I noticed a strange behavior with the histogram and higher ISO's. If I set my ISO from 80 to 400 the histogram seems to show true results compared to the preview in playback mode. If I raise my ISO above 400 (800,1600 and 3200) and adjust my ET I see the histogram shows a lower value than the true value written in the file, photos can come overexposed, even the live preview shows a brighter image, but:
I then configured histogram to show all the time for further testing, so when not half pressing at the higher ISO's it seems to show the real value but when I half press it goes down lower and if I shoot the recorded preview shows me what the histogram originally showed without half pressing.
But the thing here is that I started camera without CHDK to see if something similar happens at these high ISO's, I don't have a live histogram from the Canon FW but I did notice that the live preview becomes slightly darker when I do the half press in those ISO's, doesn't do it in ISO 400 below, so it's really not a CHDK issue, it's something to do with the ISO's in the camera. Could this be the result of expanded or not true ISO's? I can live with it if I use the histogram all the time and rely on it only before half pressing the shutter, but I wanted just to let you know.
Thanks!
-
Today I had a few crashes using ND filter state "IN" with 1.4, here's the ROMLOG I got. This did not happen in previous 1.3 since the ND filter was something I have used a lot.
Thanks :)
-
Today I had a few crashes using ND filter state "IN" with 1.4, here's the ROMLOG I got. This did not happen in previous 1.3 since the ND filter was something I have used a lot.
Thanks :)
I'm thinking maybe it has probably something to do with "Manual bad pixel removal" I was able to add my sensor size to the program and compile it, it's working great but maybe extra memory going to use with that function that might cause this crash? I disabled it and it's enabled again no crashes so far with ND filter for now, memory seems pretty good with and without ND filter states and with bad pixel removal on, I'll keep testing and see....
-
I'm thinking maybe it has probably something to do with "Manual bad pixel removal" I was able to add my sensor size to the program and compile it, it's working great but maybe extra memory going to use with that function that might cause this crash?
How large is your badpixel file?
I disabled it and it's enabled again no crashes so far with ND filter for now, memory seems pretty good with and without ND filter states and with bad pixel removal on, I'll keep testing and see....
The ND override shouldn't take any noticeable amount of memory.
The romlog shows a crash in BrtMsrTask. CHDK does not modify this task, but I suspect this task has something to do with exposure calculation, so ND override might have some effect on it.
I would be somewhat surprised if any of this was related to 1.4.
-
How large is your badpixel file?
It's 130.7 Kb over 10,000 lines, is there actually a way to trim it if it's too large? I understand that only the first 80 Kb's of it are used, it takes out the most noticeable stuck bad pixels (about five or six) I see in my JPEGS, I'm not sure if all those too many lines are overkill for the memory or is this a normal size? I'll attach it if you are interested in seeing it
The romlog shows a crash in BrtMsrTask. CHDK does not modify this task, but I suspect this task has something to do with exposure calculation, so ND override might have some effect on it.
Correct. I assume this has something to do with the other issue I was having with the histogram and ISO I posted above in reply #181, something quirky with ISO's above 400 and the way the display shows me the exposure...
Thanks as usual! :)
-
How large is your badpixel file?
It's 130.7 Kb over 10,000 lines, is there actually a way to trim it if it's too large? I understand that only the first 80 Kb's of it are used, it takes out the most noticeable stuck bad pixels (about five or six) I see in my JPEGS, I'm not sure if all those too many lines are overkill for the memory or is this a normal size? I'll attach it if you are interested in seeing it
That seems like a very large number, especially if you only see handful of hot pixels in normal images. I'd guess there was something wrong with the way it was created.
If you post the modified code and image you used, I may be able to tell what went wrong.
You can also use chdkptp to make a hotpixel list from a DNG, see https://www.assembla.com/spaces/chdkptp/wiki/DNG_Processing (https://www.assembla.com/spaces/chdkptp/wiki/DNG_Processing) at the end of "Generating badpixel lists"
I assume this has something to do with the other issue I was having with the histogram and ISO I posted above in reply #181, something quirky with ISO's above 400 and the way the display shows me the exposure...
I don't have much idea about this issue. It's normal for the firmware to brighten up the live view display in low light when you are not half pressing. When you half press, it should preview the actual exposure. The CHDK histogram just reads the buffer used for the LCD display.
-
That seems like a very large number, especially if you only see handful of hot pixels in normal images. I'd guess there was something wrong with the way it was created.
If you post the modified code and image you used, I may be able to tell what went wrong.
You can also use chdkptp to make a hotpixel list from a DNG, see https://www.assembla.com/spaces/chdkptp/wiki/DNG_Processing (https://www.assembla.com/spaces/chdkptp/wiki/DNG_Processing) at the end of "Generating badpixel lists"
Well, I deleted the original RAW I used but just created a new one with new badpixel file, I think I previously used ISO 400, this time it was done with ISO 200 and both were 10sec exposures, so badpixel file is much smaller and still is functional at removing the visible ones. Here's a link to the files I used now and my edition of the source, line 32 would be the one I added, I tried before without the
black_level<<=2; threshold<<=2;
values but it didn't remove anything so I based it on the one on line 35 since it's also a 12 bit sensor, I'm not sure if that was correct to do or not.
Here's the link to dropbox:
https://www.dropbox.com/sh/blkrgjki0fuwfhl/AACajL7T8xPxkvu7xkqLkZgDa?dl=0 (https://www.dropbox.com/sh/blkrgjki0fuwfhl/AACajL7T8xPxkvu7xkqLkZgDa?dl=0)
I really appreciate your help on that!
You can also use chdkptp to make a hotpixel list from a DNG, see https://www.assembla.com/spaces/chdkptp/wiki/DNG_Processing (https://www.assembla.com/spaces/chdkptp/wiki/DNG_Processing) at the end of "Generating badpixel lists"
This sounds cool! I wasn't aware of chdkptp! I see I can even specify the crop sensor area with this,will give it a try later and see, really helpful!
Thanks so much! :)
-
Sorry that link wasn't right!
https://www.dropbox.com/sh/blkrgjki0fuwfhl/AACajL7T8xPxkvu7xkqLkZgDa?dl=0 (https://www.dropbox.com/sh/blkrgjki0fuwfhl/AACajL7T8xPxkvu7xkqLkZgDa?dl=0)
Updated in original post also...
-
values but it didn't remove anything so I based it on the one on line 35 since it's also a 12 bit sensor, I'm not sure if that was correct to do or not.
Thanks, that part looks right to me.
In your sample raw, it looks like there is a column of bright pixels on the left from x=80 to 88 roughly. This is responsible for most of the pixels in your file. This is outside of the active area, which starts at x=96 according to platform_camera.h, so you could just delete everything with a lower X value.
This sounds cool! I wasn't aware of chdkptp! I see I can even specify the crop sensor area with this,will give it a try later and see, really helpful!
Yes, it can give you just the active area, which ought to give you a reasonable size file.
Note my example in that link sets the threshold to 4095 which would only catch pixels at the brightest possible values. You might want to use something lower. You can use the dnglistpixels -fmt=count option or the dnghist command to see how many pixels are in a given range of values.
-
This is outside of the active area, which starts at x=96 according to platform_camera.h, so you could just delete everything with a lower X value.
:D Yes, of course! I didn't think of that!
Thanks again! :)
-
I was trying to compile from SVN but got errors although I seem to have my liblua installation right with all headers, seems it's a mess in Debian (Jessie8-64), anyway, no worries, I saw the precompiled binaries and was able to run it and see the whole sensor in GIMP, it's amazing, yes, a huge darker vertical line between 80 and 88, really cool, so now I understand! Thank you so much, I am attaching you the output when I tried to compile chdkptp in case it helps you, but for me I'm cool now that I was able to run it.
Thanks again! :)
-
I was trying to compile from SVN but got errors although I seem to have my liblua installation right with all headers, seems it's a mess in Debian (Jessie8-64), anyway, no worries, I saw the precompiled binaries and was able to run it and see the whole sensor in GIMP, it's amazing, yes, a huge darker vertical line between 80 and 88, really cool, so now I understand! Thank you so much, I am attaching you the output when I tried to compile chdkptp in case it helps you, but for me I'm cool now that I was able to run it.
The relevant errors are
chdkptp.c: In function ‘chdkptp_registerlibs’:
chdkptp.c:2192:2: warning: implicit declaration of function ‘luaL_register’ [-Wimplicit-function-declaration]
...
chdkptp.c:(.text.startup+0x7f): undefined reference to `luaL_register'
Given that only 'register' is causing problems, I'm guessing you haven't set USE_LUA_52=1 in config.mk or the command line.
Rather than specifying LUA_LIB etc on the command line, the suggested way to build chkdptp is to copy config-sample-linux.mk to config.mk and edit the settings as needed for your particular system.
-
I just downloaded and installed last 1.4 version (27.05.2016). I hoped that this last version eliminated a bug found in other older release (don't remember date, but no older than 1 month). In Miniature mode I get pics like those attached. Both affected jpg and dng. Curiously, recording movies in Miniature mode doesn't affect image.
SX510HS
A test version for fw 101a is available here (http://www.filedropper.com/sx510hs-101a-150-4635-taskdevelophook). It uses task_developseq() hook. Please test if dng works in miniature mode, auto mode, P, etc..
-
Yes, works great in miniature mode with this version. I hope that this version it's "other bugs" free.
Thank you very much!
For the traceability, the pictures attached on the other topic are these:
(https://chdk.setepontos.com/proxy.php?request=http%3A%2F%2Fs5.postimg.org%2Fpz3l4twhf%2Fcolaj.jpg&hash=3c4f730c0d8831ed2d223b0066311bac) (http://postimg.org/image/pz3l4twhf/)
PS: how can I link a message on the other topic? ???
PPS: A test version for fw 101a is available here. It uses task_developseq() hook. ???
You mean it's a full working version?
-
PS: how can I link a message on the other topic?
Copy the post's URL (should be in the right click menu when you right click on a post's title, assuming you're on a desktop and your browser supports that) and paste it as a link in your other post.
You mean it's a full working version?
That's a test version, it uses a different method to catch RAW data at the right moment.
Try shooting DNGs in as many shooting modes as you can, and check for these:
- are there missing DNGs
- are there badly numbered DNGs
- DNG/JPG corruption
- camera crash
And please report back if you find any anomalies.
-
Test version expired. Now what? :blink: I didn't notice other problems at this test version. I just installed last 1.5 and 1.4 versions and still the problem isn't solved. :( Can you correct this in the next builds?
-
:( Can you correct this in the next builds?
Did you test as srsa_4c suggest?
-
Already said: as fair as I tested it, no problems at test version. But last builds still have it.
-
Already said: as fair as I tested it, no problems at test version. But last builds still have it.
Let me explain:
I have no idea if nafraf has this camera. If not, the only person that can provide feedback is you. If we don't see a detailed report, we tend to think that testing was insufficient and the changes would potentially break the port. And we don't make potentially untested changes official.
So, can you help us providing a bit more detailed feedback?
edit:
@nafraf
Did you remove PAUSE_FOR_FILE_COUNTER? There's a good chance that it's not needed if the raw hook is in dvlpseq task.
-
Did you remove PAUSE_FOR_FILE_COUNTER? There's a good chance that it's not needed if the raw hook is in dvlpseq task.
No. I did not remove it on previous version.
Here is a new version without PAUSE_FOR_FILE_COUNTER. Patch and compiled version for 101a.
-
Let me explain:
I have no idea if nafraf has this camera. If not, the only person that can provide feedback is you. If we don't see a detailed report, we tend to think that testing was insufficient and the changes would potentially break the port. And we don't make potentially untested changes official.
So, can you help us providing a bit more detailed feedback?
Just tell me what to do more than I did and I'll gladly do it. :)
So, using the test version:
1. the image on Miniature Mode don't have artifacts in both, DNG and JPG files.
2. no other problems concerning the images or videos on other modes. Tested it on M, P, Av, Tv and Scenes.
3. as far as I noticed, the counting of DNGs and JPGs is correct.
4. no crashes at all.
Using the official version the artifacted images appeared only in Miniature Mode. So, I suppose you must "dig" only in this part of the CHDK.
-
Here is a new version without PAUSE_FOR_FILE_COUNTER. Patch and compiled version for 101a.
Installed the version you attached at this post and works great. Thank you.
EDIT: still there is a problem. The number of correspondent DNG isn't the same with the JPEG's. It's delayed with 1 unit. It seems to skip a number. But not for all DNGs and JPEGs. Some have correct number. Weird.
-
So, using the test version:
1. the image on Miniature Mode don't have artifacts in both, DNG and JPG files.
2. no other problems concerning the images or videos on other modes. Tested it on M, P, Av, Tv and Scenes.
3. as far as I noticed, the counting of DNGs and JPGs is correct.
4. no crashes at all.
That's better. Please also test shooting in continuous drive mode(s).
Using the official version the artifacted images appeared only in Miniature Mode. So, I suppose you must "dig" only in this part of the CHDK.
The raw related part of CHDK is common to all shooting modes. That's why I'm asking for all these tests.
However, please wait with testing until the next test build is uploaded - the current one is not entirely OK (which is likely causing the numbering problems).
@nafraf: please shift the raw hook down with 2 instructions, so it's below the next subroutine call
-
Thanks for the feedback.
Here is a new version including suggested changes .
-
OK, I downloaded last attached version and I'll start to test it. I come back with the report. Thank you very much for help!
-
Tested it rapidely in all modes and in Movie Digest mode it crashed and stucked randomly (never at first shoot), so I had remove the battery. I have to admit that I didn't test it previously in movie Digest mode. I got a "memory card error" message, never got it before.
All OK in the rest of modes. Tested M, Av, Tv, P, Auto, Continuous, High speed shooting etc. No artifacts.
-
Tested it rapidely in all modes and in Movie Digest mode it crashed and stucked randomly (never at first shoot), so I had remove the battery. I have to admit that I didn't test it previously in movie Digest mode. I got a "memory card error" message, never got it before.
All OK in the rest of modes. Tested M, Av, Tv, P, Auto, Continuous, High speed shooting etc. No artifacts.
Just to confirm, are the DNGs numbered correctly now? (That should be the difference between the 2 last test builds)
About the lockup: does it also happen when using an official build?
-
I believe that the numbers of JPGs and DNGs are OK now.
The freezing in Movie Digest Mode happens even with last official version 1.4. I installed this morning last 1.4 version and made test with it.
-
I believe that the numbers of JPGs and DNGs are OK now.
The freezing in Movie Digest Mode happens even with last official version 1.4. I installed this morning last 1.4 version and made test with it.
Thanks.
@nafraf
I think you can check in your changes. I'll add code to disable RAW in movie digest mode later.
-
Changes committed to trunk, rev 4644 (https://app.assembla.com/spaces/chdk/subversion/commits/4644)
-
As for me, I installed last 1.5 version, 4644 and tested it: all it's OK (no artifacts in DNGs or JPGs, correct numbers etc.), excepting Movie Digest, where the camera still crashes.
I'll add code to disable RAW in movie digest mode later.
:) I'll wait this change, so that the camera work impeccably.
-
excepting Movie Digest, where the camera still crashes.
Should be fixed (https://app.assembla.com/spaces/chdk/subversion/commits/4649) (unless I made a mistake). Try the latest development build (1.5).
-
Indeed, 1.5 build 4649 fixed the problem (DNG disabled in Movie Digest mode). Thank you very much! :xmas
I'll make full tests today when I return home.
-
After 7 years a new ask: is there a way to control exposure in Video?
-
After 7 years a new ask: is there a way to control exposure in Video?
There's https://chdk.fandom.com/wiki/Manual_Exposure_Control_for_Video_Recording which may or may not be usable depending on your camera and needs.
-
After 7 years a new ask: is there a way to control exposure in Video?
There's https://chdk.fandom.com/wiki/Manual_Exposure_Control_for_Video_Recording (https://chdk.fandom.com/wiki/Manual_Exposure_Control_for_Video_Recording) which may or may not be usable depending on your camera and needs.
Already tested and doesn't work on my SX510HS, that's why I asked.Anyway, thanks.
Happy new year!
-
Is this version usefull for Your cam? :-[
https://chdk.setepontos.com/index.php?topic=5295.msg147344#msg147344
-
Is this version usefull for Your cam? :-[
https://chdk.setepontos.com/index.php?topic=5295.msg147344#msg147344 (https://chdk.setepontos.com/index.php?topic=5295.msg147344#msg147344)
I'll try it and I'll tell you. Thanks for help!
EDIT: no, it doesn't work.