CHDK Forum
CHDK Development => General Discussion and Assistance => DryOS Development => Topic started by: alsarp on 25 / September / 2014, 12:55:15
-
Mod note: A CHDK port for sx700 firmware 100e is available from the unstable autobuilds (http://chdk.wikia.com/wiki/Downloads), thanks to @ftm
Hi,
pursuing a master degree in computer science i'm starting this thread to call for motivated person to port our firmware to the good sx700. So whenever so you are hot to help waise your hand dso that the work coudl begin. I think the first step for the beginners who are already able to code in C is the for developpers page: http://chdk.wikia.com/wiki/For_Developers (http://chdk.wikia.com/wiki/For_Developers).
Canonly
-
I've just get one, so I can do some testing.
-
ok it's noticed. Aren't you able to particpate to the building? I've the code already dissambled in you can help.
-
Unfortunatelly I can not do programming, just testing.
-
Hello,
here you may find my csv file noting the address of the functions mapped comparing the sx280.102b dump to the sx700.100d dump. I tried to double-check the addresses.
Starting from the sx280.102b, I have tried to modify the stubs_entry_2.S and the boot.c in order to do a minimal compilation, but I had some undefined references errors. So I tried to modify also the stubs_min.S to add def (fakedef) of some variables, and that eliminated some of this undefined references.
I still have some undefined references, because some of the modified functions in boot.c (and other files) are not found...other attached file.
I guess:
1) I have to define these functions somewhere else.
2) For now I can keep the fakedefs, just to compile, but I have to find them afterwards.
3) I am starting the modification from the code of srsa_4c in the sx280.102b, but I guess this has more tasks, functions and variables needed for the first trial. Right?
4) Of course, I can easily compile the sx280.102b and I have used the PRIMARY.bin correct for the sx700.100d (or so I guess).
-
You can get lots of "undefined reference to ..." errors when the stubs_auto files do not get re-generated during the build process. Try erasing them manually before re-building.
If you're using the sx280 102b port to start, your port is going to need the same stubs and firmware variables (you need to correct all the addresses of course to match your firmware).
Can you share the source in some form (zipped files or svn diff)?
If you want something that can boot without finishing all details, disable task replacements in the port's boot.c (CreateTask_my).
-
Well, I had forgot a line commented in the Makefile:
STUBS_AUTO_DEPS=boot.c capt_seq.c movie_rec.c filewrite.c
, and rebuilding after uncommenting produced sensibly less undefined references (see attached output). I also tried to recompile after cleaning manually, with the same results.
Also, find attached the changed files in sx700\sub\100d.
Edit: for the moment I commented the part of the boot.c with the CreateTask_my and the CreateTask_my function. I noticed I really need to correct the stubs_min.S, finding variables and tables.
-
Well, I had forgot a line commented in the Makefile:
STUBS_AUTO_DEPS=boot.c capt_seq.c movie_rec.c filewrite.c
, and rebuilding after uncommenting produced sensibly less undefined references (see attached output). I also tried to recompile after cleaning manually, with the same results.
Attached is a 100d subdir that allows build to succeed. It's based on your version, I added the rest of files from sx280 102b. I slightly changed boot.c (commenting out all task replacements). I also changed stubs_entry_2.S: rearranged most stubs to (sort of) alphabetical order, added the missing ones. Please fill in the addresses for all NULL_SUB entries (except for those two at the bottom). Your included stubs_min.S was from a pre-DIGIC 6 port, I added the sx280 102b file instead (unchanged).
I did not make other changes. I'd like to note that you likely want to copy routines from your sx700 disassembly and change them where needed instead of trying to fix up the sx280 routines.
-
seems you got further than me i'll put support in a couple of days i'm the exam period that's why i disappeared but it finished this friday
-
Hola srsa_4c,
thanks for all your support!!!
Attached is a 100d subdir that allows build to succeed. It's based on your version, I added the rest of files from sx280 102b.
Great! Actually, I may have missed to say that I just zipped and shared the different files respect to the sx280.102b files, but I think you got that.
Yesterday, modifing the boot.c according to your suggestion to temporarily bypass the CreateTask_my, adding the missing stubs to stubs_entry_2.S, and modifing the stubs_min.S with the missing variables(I also tried to find the sx700 addresses/value for all of them), I still had 5/6 undefined references... so, of course, I still have something missing and, above all, a bit of order to make... merging your good work and the variables found should be my next reach point, for now. Still, I have to find the tables and do double checks, but I will come to this after a bit of needed order.
I did not make other changes. I'd like to note that you likely want to copy routines from your sx700 disassembly and change them where needed instead of trying to fix up the sx280 routines.
You are absolutely right, actually some routines are very similar from sx700 to sx280, so I had to do few changes respect to yours, others were much more different, so you have a good point there.
-
Antwa may i know what have you done so far in order to help if possible?
-
Hi I am a embedded software engineer. Let me know if you people need any support in the development.
-
Hi I am a embedded software engineer. Let me know if you people need any support in the development.
Hi,
if you're serious with your offer, I'm sure you could help with porting. Do you have this camera? If so, which firmware (http://chdk.wikia.com/wiki/Canon_Basic/Scripts/Dumper) version (search for the "GM1." string in the dump)? Do you have some experience in CHDK as user (or perhaps more)?
-
Hi srsa_4c,
Yes i bought one 3 days back. Firmware version is GM1:00E(1.0.0.0), Adj Ver.010.002.
Unfortunately I am new to CHDK. Just started studying things...
Just for your information I took a dump today. As f now collecting other softwares..
-
Hi guys,
I have really my hands full with a work project until december, so my plans to align everything had to shift... anyway, I will try during this week to align and post an updated version of the previous zip, in order to have a something ordered and compilable.
As I said, find an update attacched. Here is the repo where I stored the code :
https://subversion.assembla.com/svn/tna-repo/trunk/ (https://subversion.assembla.com/svn/tna-repo/trunk/)
-
Please, friends, go ahead with this. SX700 is a good cam and it deserves his own chdk.
Unfortunately, my knowledge is not enough for this kind of work. I just can appreciate your effort.
-
So... no progress so far? Seems like DIGIC 6 is a bit of a dead end. RAW on this camera would really set it apart from its competitors. Can anyone give an elaborate status update?
-
Hi Everyone
just joined CHDK as new owner of SX700.
I'm not developer so not help you on this side but happy to help in testing.
If there are any beta version I'm in.
Gio
-
Unfortunatelly there are only testers and no contributors so far.
-
Hi everyone,
I am also a new buyer of the SX700HS and I really wish to be able to activate the RAW mode.
As I understand there is not enough programmers to create a full build for this camera but at least is it possible that anybody just post a way to allow the camera to take pictures in RAW mode? Thanks for your replies.
-
I am also a new buyer of the SX700HS and I really wish to be able to activate the RAW mode.
As I understand there is not enough programmers to create a full build for this camera but at least is it possible that anybody just post a way to allow the camera to take pictures in RAW mode?
For the most part, the amount of work (coding & testing) necessary to get CHDK running well enough to enable RAW images is pretty much the same amount of work needed to make a complete port. There are no worthwhile shortcuts.
A SX700 port will get done when somebody with the necessary software skills, time, desire, and access to the camera volunteers to perform the port.
-
To give a status update: my last conversation with antwtna was almost 2 months ago.
The work he has done so far:
- almost all so-called firmware stubs are identified (for the 100d fw version)
- a test diskboot.bin was successfully tested (this only means a few startup routines, just enough to boot the original firmware)
However, this is still true:
A SX700 port will get done when somebody with the necessary software skills, time, desire, and access to the camera volunteers to perform the port.
-
Where to get the newest version of this port? I know, that is only an alpha.
-
Where to get the newest version of this port?
The source repo was linked (http://chdk.setepontos.com/index.php?topic=11927.msg118493#msg118493) on the 2nd page of this thread.
I know, that is only an alpha.
Not alpha, the current code doesn't even start CHDK.
-
Is it possible to promote, donate this project to achieve at least a working alpha version?
-
Hi,
I just want to give an update about the situation of this porting.
Thanks to a bit of free time and the help and suggestions of srsa_4c, the repo at this link (https://subversion.assembla.com/svn/tna-repo/trunk/) has been updated and the last revision 9, the languages files should be aligned to build 1.4.0 now.8 is now aligned to build 1.4.0 of chdk. The only folder that is not aligned to this build is the <trunk>\CHDK\LANG, so if anyone tries to compile it will get an error due to language files not being aligned. I will align them in the next revision, just taking them from official repo, so if anyone tries to compile just keep this in mind.
Reported a correction in the loader that could cause issues, taken from sx280 repo.
The port is still far from being working, but at least the actual code starts the minimal spytask and physw_task. The actual behaviour is that the diskboot.bin is loaded using a locked SD card and playback mode, chdk logo is shown and the memory card is not locked.
Loading of minimal binary using firmware update worked before, now it does not seem to work (file update error!).
I tried and I am trying to connect with chdkptp on windows, and I am able to, but most of the functions does not seem to work properly. Chdkptp is able to read memory (rmem), but file listing is not working (i see a camera folder and a dummy folder inside), any kind of pushbutton I press on the interface gives me a "Compile error" in the console.
Also I tried to upload a newer diskboot.bin (u <mypath>\bin\DISKBOOT.BIN) respect to the one present in the SD card, and I got in the console something like "<mypath>\bin\DISKBOOT.BIN->A/DISKBOOT.BIN". So apparently no problem, but when I tried to reboot I could see the build was always the old one (the build number and date is shown into the chdk logo), so the upload did not effectively work.
So, if anyone more experienced has any suggestion it's gladly accepted :)
Updates about debugging:
- tried open-write-close sequence of little text file, writing return values in unused RAM and retrieving them using chdkptp and rmem. I see open seems to work, while write and close both give 0xFFFFFFFF (-1), so error.
- tried in the same way fopen-fwrite-fclose sequence. fopen and fwrite seem to work properly, while fclose alway returns 0xFFFFFFFF (-1). Verified that the fwrite effectively writes the file buffer.
- tried to bypass semaphore in wrappers.c, but the behaviour is the same, so the issue seems to be different.
- tried to add the startupchecks substitution, but still same behaviour as before...
-
Hi,
an update of the situation. Yesterday I tried to re-compile from a clean repository and I realized the behavior was different from what I saw from my main repository :(
I realized I had some local files and folders that had been removed from the tools folder (edit: the main diff seemed to be in gui_osd.c in the core folder) in svn when I aligned the repository to the build 1.4.0, but remained in the local repository.
The behavior now is that the camera starts, the chdk logo is shown. Afterward as soon as I try to connect with chdkptp, after a little bit of time, the camera display flashes white and the camera shuts off. I retrieved two romlogs from two similar crashes, and I share them with you here (http://filebin.net/bj5d8c2clc).
I would try to solve this issue, before of going on.
-
Unfortunately I don't have technical expertise to offer, but I would happily make a donation to someone to get CHDK up and running on the SX700HS.
The camera allows long exposures and high ISO, but in incredibly annoying fashion it does not allow both simultaneously - any exposure time above 1" is constrained to ISO 100. Why have a manual mode and then pointlessly restrict settings?
Thank you!
-
Unfortunately I don't have technical expertise to offer, but I would happily make a donation to someone to get CHDK up and running on the SX700HS.
As nobody has responded to your offer, I guess I'll point out that doing a complete CHDK port can take at least 16 hours if really you know what you are doing and there are no surprises. A more normal amount of time for someone new is probably over 40 hours - but that's just my guess.
So in general, nobody usually does a port for money as not many people are willing to come up with the one to five thousand dollars that would make doing the port worthwhile. Although I think some people may have been willing to do a port for less in the past. To make it harder, I think I can almost count on one hand the number of people who still follow this forum that have done more than one port themselves.
I also know of several ports that have been done in simple in exchange for supplying the person doing the port with the camera being ported (which they then keep).
Sorry - in most cases getting a port done is a question of luck and being in the right place with the right camera at the right time.
-
Unfortunately I don't have technical expertise to offer, but I would happily make a donation to someone to get CHDK up and running on the SX700HS.
I will donate for the port too. So we are two. :)
-
I will donate for the port too. So we are two. :)
Crowdfunding is a good solution for new ports :)
-
Unfortunately I don't have technical expertise to offer, but I would happily make a donation to someone to get CHDK up and running on the SX700HS.
As nobody has responded to your offer, I guess I'll point out that doing a complete CHDK port can take at least 16 hours if really you know what you are doing and there are no surprises. A more normal amount of time for someone new is probably over 40 hours - but that's just my guess.
Note the above estimates are reasonable for pre-digic 6. For a d6 camera like SX700, a lot more work will be required.
This cam has shown up in the canon refurb site, but not at a really good discount yet.
-
Hi,
as you may have read in previous post I own a sx700hs and I am trying to do this port "for free", meaning I am more interested in acquiring knowledge about chdk and the digic system, offering my little spare time and a little bit of programming knowledge.
I don't know if I will succeed and I can confirm what reyalp said, the digic6 cameras seem to take more effort than pre-digic6 ones, or at least this seems to me.
Of course, if anyone is interested in your offer and has the knowledge and the camera (having it is necessary to test the developments) I am willing to help and there is a repository linked in the 2nd page where I put the code ported until now.
In the meanwhile, I am continuing (with my little spare time) debugging the issues I have found. At the moment my camera crashes when I connect with chdk_ptp, and after a bit of investigation I have found out that this is some way linked to the "send_resp" call in core/ptp.c:
data->send_resp( data->handle, &ptp, 0 );
When I commented this, the camera did not crash anymore when connecting with chdk_ptp, and I am able to execute simple commands as "ls", that gets me the list of files and directories effectively present in the camera (and so the memory does not seem corrupted).
Of course, this needs more investigation and a resolution in order to send responses to ptp commands.
-
Hi,
an update of the status of the porting, thanks to the great help of srsa_4c, the problem that made the camera crash has been found out and the solution is committed in the revision 11 of the repo linked on 2nd page.
Substantially, the original size of the PhySw task stack is 0x800 bytes, and it seems not enough, leading to stack overflow and various side effects, for example the crash I reported before when connecting with chdkptp.
I don't know if similar porting of other digic 6 camera have the same issue, I think it's worth noting this down, and keep in mind that different builds may present different side effects respect to mines.
So enlarging it to 0x2000 bytes seems to solve the issue with the crash, there may be other problems, but at least the camera buttons seem responsive... and the porting can continue :)
-
Good to know that port continues. 8)
If some of the users who offered donations, send me a camera I will help with the port. I have done blind ports, but I don't want to do that with a Digic6 camera
-
I can't afford to donate very much, the only reason I have this camera is because I was lucky enough to get it very cheaply second hand, but could put £20 GBP into a communal pot if others could add to it and it was any use to anyone. I appreciate that completing a port can be a communal effort with multiple coders and testers involved, so this may be of limited use and is a small amount, but just wanted to extend the offer.
Thank you to the people involved across this site, your efforts are much appreciated.
-
Hi,
just to inform you, I have been a lot busy with work and apart from doing the keys mapping I did not progress very much.
I also had an issue with file listing on the camera, the fw saw the CHDK folder empty, most of times. I tried various things and investigated the functions related to file management, but those seemed ok.
-
I have made some JPG+RAW shot with a Canon D500 on my SD card and than loaded it in my SX 700. If I wanted to erase the image that I made with the D500 it asked if I wanted to erase RAW or JPG or JPG+RAW! So, even tha normal firmware can see the Canon raw files.
-
I have the canon powershot sx 700 hs I will test and ehelp in always possible, I have no knowledge about programing and if there is a place were I can learn proggraming to help on the development of this cameras software than I will
-
WE need everyone that can help in the creation of the port so any one that has any knowledge with programing and can help please help also I am willing to put in lots of time to help but I have no knowledge with programing so if anyone one knows were I can learn programing plz tell me and I will help out the best in my activities
-
WE need everyone that can help in the creation of the port so any one that has any knowledge with programing and can help please help
No need to start a new thread for this, I've merged it into the existing porting thread.
also I am willing to put in lots of time to help but I have no knowledge with programing so if anyone one knows were I can learn programing plz tell me and I will help out the best in my activities
Unfortunately, the level of programming knowledge you need to complete a digic 6 port is equivalent to several university courses. It's certainly possible to teach yourself (google will get you a bazillion results for "teach yourself programming" or similar), but you should expect an equivalent amount of effort. If you just want a supported camera, this would not be a good use of your time.
-
It will be a big challenge! I don'4 know anything about programming, and don't even want to learn, but I will help with testing.
-
I would help testing too if needed. My SX700 has firmware version 1.00e (ACID Info).
-
I would help testing too if needed. My SX700 has firmware version 1.00e (ACID Info).
I don't think a firmware dump of 100e has been posted yet, so if you could get one that would be good to add to our collection. See http://chdk.wikia.com/wiki/Canon_Basic/Scripts/Dumper for dumping instructions.
That said, there doesn't seem to be anyone currently working on this camera, so it's unlikely to be supported in the near future.
-
Please excuse my slow reaction. Several things prevented me from dumping the firmware immediately, but here is my 1.00e dump.
I am not able to attach files more than 1.5MB, so I uploaded the 32MB bin file to sendspace. If I went wrong because I have missed the right place for firmware dumps please tell me.
Firmware 1.00e for SX700
https://www.sendspace.com/file/9vnhw7 (https://www.sendspace.com/file/9vnhw7)
-
I am not able to attach files more than 1.5MB, so I uploaded the 32MB bin file to sendspace. If I went wrong because I have missed the right place for firmware dumps please tell me.
Thanks. That's the right way to do it. The dump looks OK, and confirms that 100e would need a different port from 100d.
-
Added the
full 32MB dump by 8schpi from this forum post (https://chdk.setepontos.com/index.php?topic=11927.msg133234#msg133234) to the CHDK P&S FW dumps (https://drive.google.com/folderview?id=0B08pqRtyrObjTy11Y003Sk1lYTQ#list) repository.
-
I ordered a refurb sx700hs and it should get here today. I would like to start working on porting CHDK to this over the break. I'm new to CHDK porting. I do programming mainly high level in Fotrtran, C, Python, PERL etc. Not afraid of getting into Assembler but only have the rudimentary familiarity with it. Given that Digic 6's are starting to be ported to CHDK like SX60, SX710, SX280 etc, I am hopeful that we can get something going.
Thanks very much in advance to all the CHDK fans both novices and gurus alike.
Edit to add: Just got the camera FW is 1.00E
-
Edit: Jan 2nd, 2018 -- Now in the autobuild.
Original Post:
Thanks very much to the help of reyalp, I have made a port of CHDK on the sx700hs with firmware version 100E. This build is included as an attachment. This build works and has been tested on my camera. Obviously the testing has been limited to me. I've tested the following.
Tested:
Overrides -- Av, Tv
Bracketed shooting in continuous mode (Av, Tv)
DNG shooting
Scripted shooting (Lua scripts -- isobase, llibtst, hooktest)
Connected shooting -- ptpchdk
ptpchdk camtests
Dark subtraction
Long Exposure (2 mins)
Not implemented yet:
Video -- movie rec task
Issues:
Ugly display updating (usual DIGIC 6 limitations)
I looked at code from other Digic 6 ports (sx280, sx60, sx710, g7x, g16) and adapted as needed for this camera.
Once again, I want to thank reyalp, without whose handholding, this port would not have been possible.
Any testing feedback is highly appreciated.
-
I'd like to test it, but can not made SD card bootable. I have tried STICK, that find my test100e.zip file, but after that it crashed and did not do anything. I can not install CHDK with the firmware update mode either, because I did not find the firmware update option in the menu of the camera.
How to install CHDK for SX 700? thank you
-
I'd like to test it, but can not made SD card bootable. I have tried STICK, that find my test100e.zip file, but after that it crashed and did not do anything. I can not install CHDK with the firmware update mode either, because I did not find the firmware update option in the menu of the camera.
How to install CHDK for SX 700? thank you
Have you seen the "Note For Windows Users" section in the Stick documentation? The Firmware update method does not work.
http://zenoshrdlu.com/stick/stick.html (http://zenoshrdlu.com/stick/stick.html)
Also make sure your disk is formatted as FAT32.
Edit to add: One other recommendation I have is to first format the SD card in the camera before trying to use the Stick program.
-
Thank you, it works!!! It is good to see CHDK on this camera. It is midnight at us, so I need to sleep, but I will test it soon.
-
I spent some time review the code on github. Very good work, especially for a first time port on a digic 6 camera :)
Some comments:
stubs_min.S + lib.c
current_viewport_buffer and viewport_buffers are FAKEDEF. If these aren't found, vid_get_viewport_live_fb in lib.c should just return 0 without referring to them. The rest of CHDK will then fall back to vid_get_viewport_fb. Getting these values correct will allow fast motion detection to work, and reduce latency in chdkptp live view.
lib.c
hook_raw_image_addr just returns the first raw buffer. If the camera actually uses multiple raw buffers, the image will sometimes contain the wrong data. If you tested using a static scene, it might not be obvious.
raw_buffers and active_raw_buffer are listed as "found" in stubs_min.S, so it may just be a matter of hooking them up.
The camera is probably more likely to use multiple buffers when shooting in continuous mode.
main.c
NUM_FL looks like it is ~2x the expected value. I had this mistake in an earlier version of the sx710 code. It should be the maximum zoom_pos value you get at full optical zoom. If it's too high, set_zoom(get_zoom_steps()) will crash.
screen_opened / screen_rotated are only for cameras with articulated LCD.
platform_camera.h
CAM_HOTSHOE_OVERRIDE should not be defined, camera doesn't have a hotshoe.
Have focus overrides been tested? The CAM_SD_OVER_IN* defines should be set based on testing.
If you use a color matrix from a cam with MATRIX1 and MATRIX2, it's probably a good idea to use both (I had just one in the sx710 port for a while, but I think the results with fully copy of sx60hs are better)
CAM_HAS_SPORTS_MODE should be defined if MODE_SPORTS is in the modemap
*ACTIVE_AREA can be found using the procedure at the end of https://app.assembla.com/spaces/chdkptp/wiki/DNG_Processing
platform_kbd.h
The BATTCOVER and HOTSHOE flags aren't relevant to this port.
kbd.c
KEY_FRAMING_ASSIST is commented out. From pictures it looks like this camera has one, so it should be found and included.
stubs_entry.S + shooting.c
Some modes are listed as "In firmware but not in current modemap"
If you can't find them through the canon UI, you can try setting them using set_capture_mode_canon()
Some might be internal modes that just crash or aren't settable.
notes.txt
Should be updated to reflect status of this port.
-
I have made some test:
- Menu is flickering in shooting mode (1 by sec), but if you do not press shutter button after starting the camera and you are in playback mode, it is not flickering
- the text in the upper left corner (red characters) are bit covered on the right side
- Grid works, but can not change its colour (not really a need)
- Auto ISO is great!!!!
- DNG Crop Size: Active/Full/JPEG gives the same picture area (might be not a problem)
- every second DNG file is corrupt (even with 10 second of gap), size normal, but in its upper area (about 70-80%) is only noise with bluish color
- every games loads, in Mastermind the rows are covering each other (did not try to finish any of the games)
well, something happened, it is not flickering any more, but after restarting it flickers again
-
I have made some test:
Thank you very much for your testing report. It is most appreciated.
- Menu is flickering in shooting mode (1 by sec), but if you do not press shutter button after starting the camera and you are in playback mode, it is not flickering
I could be wrong but I believe this is a common issue to Digic 6 camera CHDK ports.
- the text in the upper left corner (red characters) are bit covered on the right side
This may be adjustable with the OSD Layout editor menu. Can you post a picture of that screen?
- Grid works, but can not change its colour (not really a need)
Thanks for checking this feature out. I had not tested this. On my camera, the grid feature does not seem to be working properly. I will check it out.
- Auto ISO is great!!!!
- DNG Crop Size: Active/Full/JPEG gives the same picture area (might be not a problem)
I will check this out. There are likely settings I need to change.
- every second DNG file is corrupt (even with 10 second of gap), size normal, but in its upper area (about 70-80%) is only noise with bluish color
I am not having this problem. I shot 10 dngs in a row both on the camera as well as with chdkptp. There were no issues with any of them. Can you describe a little bit more your situation? What program are you using to view the DNG files. Maybe a different card.
- every games loads, in Mastermind the rows are covering each other (did not try to finish any of the games)
I have not tried any of the games. I think I may need to modify some settings. Maybe that will fix this issue.
well, something happened, it is not flickering any more, but after restarting it flickers again
@ mastodon -- Thanks again.
-
I spent some time review the code on github. Very good work, especially for a first time port on a digic 6 camera :)
Thanks for your kind words. could not have done it without your active help and also for the Digic 6 porters before me who worked on the sh60, sx280, g16, g7x, sx710. Just looking at their ports was illuminating.
Some comments:
stubs_min.S + lib.c
current_viewport_buffer and viewport_buffers are FAKEDEF. If these aren't found, vid_get_viewport_live_fb in lib.c should just return 0 without referring to them. The rest of CHDK will then fall back to vid_get_viewport_fb. Getting these values correct will allow fast motion detection to work, and reduce latency in chdkptp live view.
I will work on this to either find them or return 0 as you suggested.
lib.c
hook_raw_image_addr just returns the first raw buffer. If the camera actually uses multiple raw buffers, the image will sometimes contain the wrong data. If you tested using a static scene, it might not be obvious.
raw_buffers and active_raw_buffer are listed as "found" in stubs_min.S, so it may just be a matter of hooking them up.
The camera is probably more likely to use multiple buffers when shooting in continuous mode.
I will try to hook these up.
main.c
NUM_FL looks like it is ~2x the expected value. I had this mistake in an earlier version of the sx710 code. It should be the maximum zoom_pos value you get at full optical zoom. If it's too high, set_zoom(get_zoom_steps()) will crash.
screen_opened / screen_rotated are only for cameras with articulated LCD.
I have fixed these.
platform_camera.h
CAM_HOTSHOE_OVERRIDE should not be defined, camera doesn't have a hotshoe.
Have focus overrides been tested? The CAM_SD_OVER_IN* defines should be set based on testing.
If you use a color matrix from a cam with MATRIX1 and MATRIX2, it's probably a good idea to use both (I had just one in the sx710 port for a while, but I think the results with fully copy of sx60hs are better)
CAM_HAS_SPORTS_MODE should be defined if MODE_SPORTS is in the modemap
*ACTIVE_AREA can be found using the procedure at the end of https://app.assembla.com/spaces/chdkptp/wiki/DNG_Processing (https://app.assembla.com/spaces/chdkptp/wiki/DNG_Processing)
Indeed, it has exactly the same lens as the sx710. And I copied over the same values as were present in that port. I have since corrected it. I have not actively tested the focus overrides. Is there a script that tests it also in addition to using the CHDK menu? I will also check for the ACTIVE AREA as well.
platform_kbd.h
The BATTCOVER and HOTSHOE flags aren't relevant to this port.
Fixed.
kbd.c
KEY_FRAMING_ASSIST is commented out. From pictures it looks like this camera has one, so it should be found and included.
KEY_FRAMING_ASSIST was found. This is the only key that is different from the sx710. It is 0x10 at MASK1.
stubs_entry.S + shooting.
Some modes are listed as "In firmware but not in current modemap"
If you can't find them through the canon UI, you can try setting them using set_capture_mode_canon()
Some might be internal modes that just crash or aren't settable.
Was able to check for these. Some of the modes seemed identical to existing modes as as Face detect. There was a Night Portrait mode (not available in Canon menu). One of the modes crashed the camera. I have updated shooting.c
notes.txt
Should be updated to reflect status of this port.
Working on this.
Once again, thanks very much. I will push a new version to git when I've made the changes.
-
- Menu is flickering in shooting mode (1 by sec), but if you do not press shutter button after starting the camera and you are in playback mode, it is not flickering
I could be wrong but I believe this is a common issue to Digic 6 camera CHDK ports.
It's actually a problem in shooting mode with almost all CHDK ports. But it's a lot worse with Digic6 cameras.
Grid works, but can not change its colour (not really a need)
Thanks for checking this feature out. I had not tested this. On my camera, the grid feature does not seem to be working properly. I will check it out.
I think you will find the default grids are not scaled properly on the display. This is a know issue.
Grids : issues and challenges
(https://chdk.setepontos.com/index.php?topic=13239.0)
- DNG Crop Size: Active/Full/JPEG gives the same picture area (might be not a problem)
I will check this out. There are likely settings I need to change.
Yup - likely these ones in platform_camera.h :
#define CAM_RAW_ROWPIX xxxx
#define CAM_RAW_ROWS yyyy
#define CAM_JPEG_WIDTH wwww
#define CAM_JPEG_HEIGHT zzzz
#define CAM_ACTIVE_AREA_X1 nn
#define CAM_ACTIVE_AREA_Y1 mm
#define CAM_ACTIVE_AREA_X2 iiii
#define CAM_ACTIVE_AREA_Y2 kkkk
- every second DNG file is corrupt (even with 10 second of gap), size normal, but in its upper area (about 70-80%) is only noise with bluish color
I am not having this problem. I shot 10 dngs in a row both on the camera as well as with chdkptp. There were no issues with any of them. Can you describe a little bit more your situation? What program are you using to view the DNG files. Maybe a different card.
I believe reyalp predicted this would happen in his earlier post :
lib.c
hook_raw_image_addr just returns the first raw buffer. If the camera actually uses multiple raw buffers, the image will sometimes contain the wrong data. If you tested using a static scene, it might not be obvious.
-
- every second DNG file is corrupt (even with 10 second of gap), size normal, but in its upper area (about 70-80%) is only noise with bluish color
I am not having this problem. I shot 10 dngs in a row both on the camera as well as with chdkptp. There were no issues with any of them. Can you describe a little bit more your situation? What program are you using to view the DNG files. Maybe a different card.
It would be helpful in mastodon could post one of the bad images (a jpeg conversion is fine from the DNG is fine in this case). However, I'd guess this is likely caused by the hook_raw_image_addr issue mentioned in my post.
Whether the camera uses multiple buffers may depend on shooting mode (e.g, auto, P, special scene modes) continuous mode, and possibly other things like resolution, quality, ISO, SD card speed.
You can use CAPTSEQ_DEBUG_LOG with chdkptp dlstart / dlgetcam to see whether your raw_buffers/active_raw_buffer give reasonable looking results.
-
You can use CAPTSEQ_DEBUG_LOG with chdkptp dlstart / dlgetcam to see whether your raw_buffers/active_raw_buffer give reasonable looking results.
I was able to find the raw_buffers/active_raw_buffer and implement those in lib.c. I started dlstart/dlgetcam and am trying to understand the results. I took multiple raw/dng images in a row. I'm attaching the dbg.log file. Can you elaborate a little more on what would be reasonable looking results? I see lines like
01017710: UI:Capture Sequence Start: m:31 arb:1 rb:0x45782700 i:0661
01020380: UI:Capture Sequence Start: m:43 arb:0 rb:0x43f83ae0 i:0662
-
@ waterwingz -- In my case, I appear to be getting a grid which is confined only to the top left quarter of the screen. I will look at that thread regarding the grid issue.
And thanks also for the comments that you left in the G16 port. They were very useful to me. The sx700 (DryOS 54p3) had lots of similarities with the G16 as far as the asm disassembly was concerned.
-
In my case, I appear to be getting a grid which is confined only to the top left quarter of the screen.
AFAIK what your are seeing is normal for a D6 port. It's not specific to your camera - the G16 does the exact same thing too.
The thread that I linked mostly talks about general issues with grids. That code is quite old, dating back to that early days of CHDK, and has not been maintained as Canon added new display sizes.
-
waterwingz - Thanks. It looks like the grid files have hard coded values for a smaller display. 320x240. Once I made a new grid file, it worked fine.
-
waterwingz - Thanks. It looks like the grid files have hard coded values for a smaller display. 320x240. Once I made a new grid file, it worked fine.
One of the things on my "roundtuit" list is to update the grid code to scale the files to the actual display size (centered appropriately). Either that or allow CHDK to pick only appropriate grid files for the camera display size from an expanded set included with the build.
It's not a high priority as anyone who cares about this can simply edit their favorite grid file to suit their display.
-
Here are some examples.
A good dng: JPG (https://www.dropbox.com/s/fsjayurd42jgny3/IMG_0662.JPG?dl=0) - DNG (https://www.dropbox.com/s/ituh1z4nmeuqi3u/IMG_0662.DNG?dl=0)
and a bad: JPG (https://www.dropbox.com/s/pjyqsts7zvrd2vu/IMG_0661.JPG?dl=0) - DNG (https://www.dropbox.com/s/3l22yxclwqv38ac/IMG_0661.DNG?dl=0)
plus the covered text (https://www.dropbox.com/s/wkvdtz2ii3iqay3/textcovering.jpg?dl=0).
-
Here are some examples.
A good dng: JPG (https://www.dropbox.com/s/fsjayurd42jgny3/IMG_0662.JPG?dl=0) - DNG (https://www.dropbox.com/s/ituh1z4nmeuqi3u/IMG_0662.DNG?dl=0)
and a bad: JPG (https://www.dropbox.com/s/pjyqsts7zvrd2vu/IMG_0661.JPG?dl=0) - DNG (https://www.dropbox.com/s/3l22yxclwqv38ac/IMG_0661.DNG?dl=0)
plus the covered text (https://www.dropbox.com/s/wkvdtz2ii3iqay3/textcovering.jpg?dl=0).
Many thanks. It was a buffer issue. An updated version of the port is on the same post.
https://chdk.setepontos.com/index.php?topic=11927.msg135752#msg135752 (https://chdk.setepontos.com/index.php?topic=11927.msg135752#msg135752)
Please let me know if this works for you.
-
plus the covered text (https://www.dropbox.com/s/wkvdtz2ii3iqay3/textcovering.jpg?dl=0).
The "covered text" is just several CHDK OSD elements all positioned in the same place on the LCD. Go to the CHDK Settings menu, select OSD Layout Editor and move them apart.
Full instructions are here : CHDK User Manual : OSD Layout Editor (http://chdk.wikia.com/wiki/CHDK_User_Manual#OSD_Layout_Editor)
-
I can confirm that dng files are OK! Thank you for your quick improvement.
Actually I can move the covered text, but it would be much easier for the user, if this port would contain the right setting of OSD text for this camera.
And on its left side is still not perfectly visible, that is uncorrectable with the OSD layout editor. (but its just a minor cosmetic issue)
There is an option for startup sound. I can not activate. Is there any in this camera?
If I set CHDKSettings/OSD settings "Hide in ?" (don't need the SPACE) for "Don't", the text with red characters disappear on half-press. Why? Bug or feature?
And one more thing... the flickering is over! :D
-
I can confirm that dng files are OK! Thank you for your quick improvement.
Actually I can move the covered text, but it would be much easier for the user, if this port would contain the right setting of OSD text for this camera.
And on its left side is still not perfectly visible, that is uncorrectable with the OSD layout editor. (but its just a minor cosmetic issue)
There is an option for startup sound. I can not activate. Is there any in this camera?
If I set CHDKSettings/OSD settings "Hide in ?" (don't need the SPACE) for "Don't", the text with red characters disappear on half-press. Why? Bug or feature?
And one more thing... the flickering is over! :D
Thank you for your testing report. Glad that the DNG issue is fixed.
I will check on the startup sound. Check your camera Menu setting. Mine was in Mute mode.
Thanks also for confirming that the flickering is over. It is also gone on mine as well. I cleaned up some of the unidentified stubs. Maybe one of those fixed it.
Also, not sure if the OSD screen setting can be easily changed. Can you post another picture of the Left side OSD setting that is not fixable?
The OVERRIDE Display (Red characters) disappears for me as well on half-press. I do not see any menu option of keeping it on. (Edit: Other items on the OSD such as RAW state etc., also disappear on Half-press while items like Time, Battery, Space remain. Also, if you change the color of the OVERRIDE text to white, the visibility appears to be improved. I don't know if that is what you mean. )
If there are any other tests that you do please do post in this thread. It will help in improving this port and then we can include it as an autobuild.
-
SX700 100e is in the autobuild as of 4970
I made some cosmetic changes from the github code in 4969 https://app.assembla.com/spaces/chdk/subversion/commits/4969
I also removed bin_comp_fix.h in the original commit, the autogenerated one should be functionality equivalent.
Additional comments:
Modes 16943 and 16945 are probably "wink self timer" and "face self timer" (not necessarily in that order)
On SX710, these are accessed from the "smile detection" mode by pressing disp.
Has anyone tested set_led? If AF LED control is working, you should be able to check MD_Tune http://chdk.wikia.com/wiki/Testing#MD_tune.bas
If filewrite, the logging stuff should be under an ifdef, like g7x/sx710. I try not to leave these enabled by default in autobuilds because it leaves a permanent trace of CHDK if there's a romlog (OTOH, the existence of a romlog is a pretty strong clue)
The aspect ratio stuff ( vp_xo etc) in lib.c has a TODO on it. I would expect this is the same as sx710, but can be easily checked using chdkptp GUI live view and going through the available aspect ratios in the the func menu.
-
Yep, mine was in mute mode too. Sound is OK! :)
-
Yep, mine was in mute mode too. Sound is OK! :)
Thanks for confirming.
I suggest changing the text color for the Overrides to white. It looks better on the camera.
Also, you can see, the sx700 is now in the autobuild.
-
SX700 100e is in the autobuild as of 4970
I made some cosmetic changes from the github code in 4969 https://app.assembla.com/spaces/chdk/subversion/commits/4969 (https://app.assembla.com/spaces/chdk/subversion/commits/4969)
I also removed bin_comp_fix.h in the original commit, the autogenerated one should be functionality equivalent.
Thanks for putting this in the autobuild and for making the needed changes.
The aspect ratio stuff ( vp_xo etc) in lib.c has a TODO on it. I would expect this is the same as sx710, but can be easily checked using chdkptp GUI live view and going through the available aspect ratios in the the func menu.
I tried to test this using the chdkptp_gui.sh. It seems to work and I can click the FUNC button to bring up the selection and I can then use the Left/Right/Up/Down/Set buttons to change the aspect ratio as is shown on the screen. but I frequently get errors and the gui hangs. When this hangs, I unplug the camera, I get messages such as:
I/O errorlive timer update error
I have to physically disconnect and reconnect to make it work again. It seems the problems happen when UI Overlay is selected. If the UI Overlay is unselected, there are no errors and Live View works fine.
More info: Using Ubuntu VM running on a Mac OS X host via Virtual Box.
-
I tried to test this using the chdkptp_gui.sh. It seems to work and I can click the FUNC button to bring up the selection and I can then use the Left/Right/Up/Down/Set buttons to change the aspect ratio as is shown on the screen.
Thanks for testing.
The specific thing to look for with the viewport offset stuff is that the image appears in the correct place, e.g. when you choose 16:9 there it's centered vertically in the screen, not at the top. It's normal to see it briefly in the wrong location when you switch.
but I frequently get errors and the gui hangs. When this hangs, I unplug the camera, I get messages such as:
I/O errorlive timer update error
I have to physically disconnect and reconnect to make it work again. It seems the problems happen when UI Overlay is selected. If the UI Overlay is unselected, there are no errors and Live View works fine.
Interesting, I haven't seen this reported before. I wouldn't expect this to be a port issue, but it would be good to understand why it's happening.
After the error happens, you can use
!printf(errutil.last_traceback)
to get a stack trace.
If there was a USB error, the kernel logs may also show something.
You are running this in a VM, correct? This shouldn't specifically be a problem, but adds more places for things to go wrong. What VM software and Linux distro are you using?
What kind of frame rates do you get?
Does the UI overlay look OK before error happens? Meaning, the menus and OSD elements look the pretty much the same as they do on the canon screen, including transparency?
Have you tried "skip D6 opacity"? This will make the semi-transparent element look different from the camera screen, but reduce bandwidth significantly.
-
Using Ubuntu 16.04LTS VM on a MacOS X (10.13) host running VirtualBox.
The FPS starts at ~4.3 and drops to ~2.2 when UI overlay is turned on. When skip D6 opcaity is selected the fPS climbs a little bit to ~2.5.
With the Skip D6 opacity selected, it ran a little longer. Still froze eventually.
Before the hangup, everything looks good on the screen.
Here is the stack trace:
> !printf(errutil.last_traceback)
stack traceback:
[C]: in function 'chdk_connection.execlua'
[C]: in function 'pcall'
/home/ramp/develop/chdkptp-r795/lua/chdku.lua:2082: in function 'execlua_pcall'
/home/ramp/develop/chdkptp-r795/lua/chdku.lua:1014: in function 'exec'
/home/ramp/develop/chdkptp-r795/lua/gui.lua:75: in function </home/ramp/develop/chdkptp-r795/lua/gui.lua:74>
[C]: in function 'xpcall'
/home/ramp/develop/chdkptp-r795/lua/errutil.lua:97: in function 'exec'
/home/ramp/develop/chdkptp-r795/lua/gui.lua:79: in function 'execquick'
/home/ramp/develop/chdkptp-r795/lua/gui.lua:294: in function </home/ramp/develop/chdkptp-r795/lua/gui.lua:293>
(...tail calls...)
[C]: in function 'MainLoop'
/home/ramp/develop/chdkptp-r795/lua/gui.lua:758: in function </home/ramp/develop/chdkptp-r795/lua/gui.lua:731>
(...tail calls...)
/home/ramp/develop/chdkptp-r795/lua/main.lua:286: in main chunk
[C]: in function 'require'
[string "require('main')"]:1: in main chunkERROR: not connected
ERROR: not connected
There is also nothing in /var/log/syslog.
-
Here is the stack trace:
[string "require('main')"]:1: in main chunkERROR: not connected
ERROR: not connected
Hmm, that seems to be after the connection went away, not from the initial error.
I suspect this is VM related, so I wouldn't spend much time on it unless you feel like it.
using
set err_trace=always
might get the stack trace with the initial error.
There is also nothing in /var/log/syslog.
You could try the dmesg command.
-
Autobuild 4972:
- Motion.lua script works (shows grid with values, takes picture, not really fast delay seems to be 0.5 sec)
- Menu is flickering in shooting mode, after using Motion.lua script
- loading default script, flickering is over
- the default value for the battery is not good (fully loaded shows 93%) OR might my battery bit old OR one have to calibrate every battery?
-
Autobuild 4972:
- Motion.lua script works (shows grid with values, takes picture, not really fast delay seems to be 0.5 sec)
To test MD response, using MD_Tune is recommended: http://chdk.wikia.com/wiki/Testing#MD_tune.bas
- Menu is flickering in shooting mode, after using Motion.lua script
- loading default script, flickering is over
It's very unlikely this has anything to do with which script is selected. It will flicker more or less based on what the Canon firmware is doing.
- the default value for the battery is not good (fully loaded shows 93%) OR might my battery bit old OR one have to calibrate every battery?
This is just defined by min and max voltage levels, so it's not going to be perfect. Individual batteries will vary and the voltage for a battery fresh of the charger will be a bit higher than after it's been sitting for a while.
-
You should be able to get response times less than 100 msec in motion detect using md_tune.
https://chdk.setepontos.com/index.php?topic=12918.30
-
Could you please post a test version of this with the SX 700 port? (If you get there)
Build with the CHDK UI Version 3.0 (https://chdk.setepontos.com/index.php?topic=13293.0 (https://chdk.setepontos.com/index.php?topic=13293.0) waterwingz) for the SX700HS is attached.
edit: version 4975 is attached. This should have the latest waterwingz UI-3.0 (patch r6)
-
It seems to me, that this is 4 4974 with UI v 2.0.
Another experience with AutoISO, F is every time: 3,2, ISO values are different:
- In P mode: with flash 800, without flash 320
- In Tv mode (with 1/60 by default): with flash 320, without flash 1600
- In Av mode I set the light conditions let the camera set 1/60: with flash 320, without flash 1000
- In Manual mode there is no AutoISO
Why are not the ISO values the same in the various modes?
-
It seems to me, that this is 4 4974 with UI v 2.0.
I have updated to most recent CHDK (4975) and GUI patch r6 from waterwingz.
Another experience with AutoISO, F is every time: 3,2, ISO values are different:
- In P mode: with flash 800, without flash 320
- In Tv mode (with 1/60 by default): with flash 320, without flash 1600
- In Av mode I set the light conditions let the camera set 1/60: with flash 320, without flash 1000
- In Manual mode there is no AutoISO
Why are not the ISO values the same in the various modes?
What were the settings that you chose on the Custom Auto ISO page?
While, I must confess that I don't fully understand Custom Auto ISO, it seems that except for the results in the P mode that you report, the rest seem ok. Your P mode results seem reversed to me.
Priority is given to keeping the ISO within range. It seems to ignore shutter speed limits and shoots slower if it cannot get the exposure correct at Max Fallback ISO.
Also, from what I have seen of the code, the Custom Auto ISO mode will not affect the Aperture values at all. Essentially except for the M mode all modes seem to behave like mode Av when using Custom Auto ISO.
For a camera like the SX700 which has adjustable aperture, using the Custom Auto iSO in the Av mode makes the most sense (at least to me).
-
I must confess that I don't fully understand Custom Auto ISO ..
This has been an on going problem :(
The two most relevant forum posts are probably : tsvstar's patch (https://chdk.setepontos.com/index.php?topic=650.msg75555#msg75555) and Is Custom Auto ISO working for the A640 under 1.2? (https://chdk.setepontos.com/index.php?topic=10754.0)
There is also an attempt to describe its operation here : CHDK User Manual : Custom Auto ISO (http://chdk.wikia.com/wiki/CHDK_1.4.0_User_Manual#Custom_Auto_ISO). If you can edit / improve / fix that description it would be great!
-
@waterwingz — thanks for those links. I feel my understanding is more improved. I have only been using CHDK for a short while. So much to learn.
-
Hi guys. First I'd like to thank you all for creating such a great addition for my camera :)
I do have a strange issue though. I installed version (sx700hs-100e-1.5.0-4981-full_ALPHA.zip ) through the download page and used Stick to install the software.
I then locked the SD card and put it in my camera.
It seemed completely dead. However when I did a battery pull it would work.
Now every time I turn my camera off and want to use it again I must repeat the battery pull.
Any idea how I could fix this ? I tried re-formatting the card both in-camera and using Windows (10 32bit).
Also when I took a show at ISO 100 in Lightroom it was extremely noisy.
I did have DNG 1.3 enabled, could that be the issue.
When I get home I'll try switching to 1.1 and recreating the badpixel thingy.
Also, I found liveview is very different from the actual result of the images.
Is this normal ?
Sorry for all the questions....
-
Hi guys. First I'd like to thank you all for creating such a great addition for my camera :)
I do have a strange issue though. I installed version (sx700hs-100e-1.5.0-4981-full_ALPHA.zip ) through the download page and used Stick to install the software.
I then locked the SD card and put it in my camera.
It seemed completely dead. However when I did a battery pull it would work.
Now every time I turn my camera off and want to use it again I must repeat the battery pull.
Any idea how I could fix this ? I tried re-formatting the card both in-camera and using Windows (10 32bit).
Also when I took a show at ISO 100 in Lightroom it was extremely noisy.
I did have DNG 1.3 enabled, could that be the issue.
When I get home I'll try switching to 1.1 and recreating the badpixel thingy.
Also, I found liveview is very different from the actual result of the images.
Is this normal ?
Sorry for all the questions....
@WalkerOfTheDay -- Not sure what is going on. I just tested build 4981 on my Camera and it seems to work fine. I took a couple of pictures with one DNG (the default 1.3) and it looked OK.
Couple questions:
-- I suppose that it is possible that maybe your download got corrupted. Try to download it again.
-- Have you tried a different SD card?
-- I assume that firmware version is 100E. I would guess that it wouldn't have worked otherwise.
Regarding Liveview, I don't understand what you mean by liveview is different from the image that you get.
-
Hi guys. First I'd like to thank you all for creating such a great addition for my camera :)
I do have a strange issue though. I installed version (sx700hs-100e-1.5.0-4981-full_ALPHA.zip ) through the download page and used Stick to install the software.
I then locked the SD card and put it in my camera.
It seemed completely dead. However when I did a battery pull it would work.
Now every time I turn my camera off and want to use it again I must repeat the battery pull.
Any idea how I could fix this ? I tried re-formatting the card both in-camera and using Windows (10 32bit).
Also when I took a show at ISO 100 in Lightroom it was extremely noisy.
I did have DNG 1.3 enabled, could that be the issue.
When I get home I'll try switching to 1.1 and recreating the badpixel thingy.
Also, I found liveview is very different from the actual result of the images.
Is this normal ?
Sorry for all the questions....
@WalkerOfTheDay -- Not sure what is going on. I just tested build 4981 on my Camera and it seems to work fine. I took a couple of pictures with one DNG (the default 1.3) and it looked OK.
Couple questions:
-- I suppose that it is possible that maybe your download got corrupted. Try to download it again.
I tried this many times. Also formatted the card many times in camera and in Windows including a low level format.
-- Have you tried a different SD card?
-- I assume that firmware version is 100E. I would guess that it wouldn't have worked otherwise.
I have not, I don't even think I own one. But I'll buy one and try it.
Firmware is 100E, indeed.
Regarding Liveview, I don't understand what you mean by liveview is different from the image that you get.
I mean the difference between what you see on the screen and on the actual photo.
On screen it can be a perfectly clear picture while both the RAW and the Jpeg are quite dark. It would be nice if you could see the actual exposure on-screen.
The RAW also has loads of color noise in Lightroom (5.7).
When I create the badpixels file it should 0 errors.
-
In this post is a link to an earlier build (4975). https://chdk.setepontos.com/index.php?topic=11927.msg135876#msg135876 (https://chdk.setepontos.com/index.php?topic=11927.msg135876#msg135876). Can you try and see if that works better?
Regarding the dark pictures, maybe the exposure overrides are set. What does the exif of the pictures (dng/jpg) tell you about the exposure details. Tv, Av, ISO etc.
-
In this post is a link to an earlier build (4975). https://chdk.setepontos.com/index.php?topic=11927.msg135876#msg135876 (https://chdk.setepontos.com/index.php?topic=11927.msg135876#msg135876). Can you try and see if that works better?
Regarding the dark pictures, maybe the exposure overrides are set. What does the exif of the pictures (dng/jpg) tell you about the exposure details. Tv, Av, ISO etc.
Thank you. I did indeed set the exposure overrides, so this doesn't reflect on screen if I understand correctly ? That's too bad.
If I can find the time, I'll try the earlier build and let you know.
-
Thank you, it works!!! It is good to see CHDK on this camera. It is midnight at us, so I need to sleep, but I will test it soon.
Hi mastadon,
What exactly did you do to fix it ?
I seem to have the same issue, camera completely frozen.
However it does work after a battery pull and re-insert like I reported above.
By the way when I use Stick and create the test100e.zip it does not get recognized by Stick. I can only click the download button.
-
I tried ftm's suggestion, and when I put the card in the camera it seemed to work.
But after shutting the camera down, I again faced the same issue.
After switching to 1.1 the DGN are now almost noise free so that's a plus :lol
-
But after shutting the camera down, I again faced the same issue.
Sounds like the camera doesn't shut down properly. Does it drain the battery if you leave it in camera?
You could try resetting Canon settings in the Canon menu and see if that helps.
-
But after shutting the camera down, I again faced the same issue.
Sounds like the camera doesn't shut down properly. Does it drain the battery if you leave it in camera?
You could try resetting Canon settings in the Canon menu and see if that helps.
I did a test and you are right !
I charged the battery to 100% and put it back in the camera and left it
overnight. This morning the battery was completely drained.
I also tried to do a reinstall on another sd card, but the behaviour stays the same.
So it's definately some shutdown issue.
Is there anything that I can test out for you to help fix the issue ?
-
But after shutting the camera down, I again faced the same issue.
Sounds like the camera doesn't shut down properly. Does it drain the battery if you leave it in camera?
You could try resetting Canon settings in the Canon menu and see if that helps.
I did a test and you are right !
I charged the battery to 100% and put it back in the camera and left it
overnight. This morning the battery was completely drained.
I also tried to do a reinstall on another sd card, but the behaviour stays the same.
So it's definately some shutdown issue.
Is there anything that I can test out for you to help fix the issue ?
Thanks for further testing.
Which version are you running -- current autobuild version or the custom version from the earlier post in this thread.
Also, as srsa_4c suggested, did you try to reset all Canon settings in the Canon Menu.
-
But after shutting the camera down, I again faced the same issue.
Sounds like the camera doesn't shut down properly. Does it drain the battery if you leave it in camera?
You could try resetting Canon settings in the Canon menu and see if that helps.
I did a test and you are right !
I charged the battery to 100% and put it back in the camera and left it
overnight. This morning the battery was completely drained.
I also tried to do a reinstall on another sd card, but the behaviour stays the same.
So it's definately some shutdown issue.
Is there anything that I can test out for you to help fix the issue ?
Thanks for further testing.
Which version are you running -- current autobuild version or the custom version from the earlier post in this thread.
Also, as srsa_4c suggested, did you try to reset all Canon settings in the Canon Menu.
I'm not sure which version. I used stick, and it made a folder called Trunk CHDK.
I left all settings to default in stick.
But yesterday I also tried the custom version.
Forgot to mention, but I also reset all Canon settings.
-
I did a test and you are right !
I charged the battery to 100% and put it back in the camera and left it
overnight. This morning the battery was completely drained.
Does it happen if you use a card without CHDK?
I'm not sure which version. I used stick, and it made a folder called Trunk CHDK.
I left all settings to default in stick.
You can see the version in build info under the CHDK misc menu.
-
I did a test and you are right !
I charged the battery to 100% and put it back in the camera and left it
overnight. This morning the battery was completely drained.
Does it happen if you use a card without CHDK?
It does not.I can have a battery in for weeks usually.
I'm not sure which version. I used stick, and it made a folder called Trunk CHDK.
I left all settings to default in stick.
You can see the version in build info under the CHDK misc menu.
Thanks. It is showing: CHDK 1.5.0 Revision 4985.
Also when I remove DISKBOOT.BIN from the card it boots up normally (without CHDK obviously).
-
Based on your posts, this is what I gather:
1. Using Stick (v4985 from autobuild), camera does not start correctly. You have to pull the battery. Then it starts OK.
2. Using the custom version (4975), camera starts OK. However it does not now shutdown.
In Case 1. above, does the camera shut down or does it need a battery pull.
Also what mode dial is the camera in when you start up? Can you try Manual mode for example?
-
Also when I remove DISKBOOT.BIN from the card it boots up normally (without CHDK obviously).
This is pretty strange. There are two general options:
1) Something weird specific to your individual camera
2) Some difference in settings or how you use that camera that makes you have the problem while ftm and others do not.
I don't have good ideas for either.
How do you power the camera on? Using the power button, the play button or the one with the phone icon? Are you holding the button down, or just clicking?
What market was your camera sold it? US, Europe, Japan...?
-
Based on your posts, this is what I gather:
1. Using Stick (v4985 from autobuild), camera does not start correctly. You have to pull the battery. Then it starts OK.
2. Using the custom version (4975), camera starts OK. However it does not now shutdown.
In Case 1. above, does the camera shut down or does it need a battery pull.
No not exactly the behaviour between builds is exactly them same.
I need to pull the battery, sometimes multiple times before it even too boot.
Visually the camera does look to be shut down, but apparently only the screen turns off.
Also what mode dial is the camera in when you start up? Can you try Manual mode for example?
I tried M / AV / TV and P, the behaviour is all the same.
-
Do you know how to do an md5sum on the DISKBOOT.BIN file?
Alternatively, you could try to attach your DISKBOOT.BIN to a post.
-
Do you know how to do an md5sum on the DISKBOOT.BIN file?
Alternatively, you could try to attach your DISKBOOT.BIN to a post.
Not sure if I did it correctly, but I unsed onlinemd5.com and dropped DISKBOOT.BIN on it.
It gave this checksum: BF96CD829C589DEFFBB5AA292B85BCB6
Is that what you need ?
-
Thanks. That looks fine.
-
Thanks. That looks fine.
Like I said, sometimes I needed to pull the battery multiple times, but
I just found out there is a certain order I need to do.
First I need to put in the batter without SD card, and press the playback button
to turn it on.
Then I press the power button to shut it off.
Then I plug in the SD card and press the playback button.
Then it works 8 out of 10 times until powering down again.
-
You said you tried a different SD card. Was it the same or a different brand? Can you list which ones you are using?
-
You said you tried a different SD card. Was it the same or a different brand? Can you list which ones you are using?
My original card is a Sandisk Ultra 8 GB 40 MB/S SD HC i
The other one is a 2GB Integral Card it doesn't state the speed.
-
Also, as reyalp asked, which market was the camera bought in.
Can you also get a firmware dump and upload it somewhere?
-
Also, as reyalp asked, which market was the camera bought in.
Can you also get a firmware dump and upload it somewhere?
Sorry about that, I missed that posting.
It's the European Market (The Netherlands).
How do I do a firmware dump ?
edit:
Looked at the docs and I think i did it. There are now two (512 MB) CRW_0000.jpg files on my card.
Now I have to figure out where to upload them.
I'll get back to you.
-
Here you go:
https://wetransfer.com/downloads/9f74196ff8546ef21c53c2bb4520476420180126102009/4bea82f937faebd42bbdd71b9be9e0a020180126102009/d5be51
-
There are now two (512 MB) CRW_0000.jpg files on my card.
From size and filename, those are RAM dumps.
The official way to dump the firmware is detailed here: http://chdk.wikia.com/wiki/Canon_Basic/Scripts/Dumper
However, if CHDK runs on your camera, you can use the attached simple Lua script that does the same. Enable the following in CHDK menu before running the script: Miscellaneous stuff -> Enable Lua native calls
The script looks like this:
call_event_proc("System.Create")
f=call_event_proc("Fopen_Fut","A/PRIMARY.BIN","w")
call_event_proc("Fwrite_Fut",0xfc000000,0x2000000,1,f)
call_event_proc("Fclose_Fut",f)
If successful, you'll find a file named PRIMARY.BIN in the root of the card.
-
There are now two (512 MB) CRW_0000.jpg files on my card.
From size and filename, those are RAM dumps.
The official way to dump the firmware is detailed here: http://chdk.wikia.com/wiki/Canon_Basic/Scripts/Dumper
However, if CHDK runs on your camera, you can use the attached simple Lua script that does the same. Enable the following in CHDK menu before running the script: Miscellaneous stuff -> Enable Lua native calls
The script looks like this:
call_event_proc("System.Create")
f=call_event_proc("Fopen_Fut","A/PRIMARY.BIN","w")
call_event_proc("Fwrite_Fut",0xfc000000,0x2000000,1,f)
call_event_proc("Fclose_Fut",f)
If successful, you'll find a file named PRIMARY.BIN in the root of the card.
Thanks for your help. Here is the file:
https://wetransfer.com/downloads/0d266b204de1f197e3675206eaa9676f20180126174100/eb17532dc6c960d2e3779c90f70888bf20180126174100/20825c
-
Here is the file
Thanks. The dump's main part matches the 100e dump I have. The rest of the dump may or may not be ok (we can't evaluate that part as its structure is mostly unknown and camera specific).
However, I spotted a typo in the 100e CHDK source.
@ftm
The following line in boot.c is incorrect:
" ldr r0, =0x0815\n" //at fc05d340You should copy that instruction from the source, as is.
capdis -f=chdk -s=CreateTask -c=12 -stubs PRIMARY.BIN 0xfc000000
// CreateTask_FW 0x010c5075
" push.w {r1, r2, r3, r4, r5, r6, r7, r8, sb, lr}\n"
" mov r4, r0\n"
" ldr r0, =0x0000815c\n"
" mov r6, r1\n"I stopped looking here, try comparing the source to the disassembly for other unintended changes.
If 0x815 is an uninitialized part of memory, that might explain the failure on WalkerOfTheDay's camera.
-
Here is the file
Thanks. The dump's main part matches the 100e dump I have. The rest of the dump may or may not be ok (we can't evaluate that part as its structure is mostly unknown and camera specific).
However, I spotted a typo in the 100e CHDK source.
@ftm
The following line in boot.c is incorrect:
" ldr r0, =0x0815\n" //at fc05d340You should copy that instruction from the source, as is.
capdis -f=chdk -s=CreateTask -c=12 -stubs PRIMARY.BIN 0xfc000000
// CreateTask_FW 0x010c5075
" push.w {r1, r2, r3, r4, r5, r6, r7, r8, sb, lr}\n"
" mov r4, r0\n"
" ldr r0, =0x0000815c\n"
" mov r6, r1\n"I stopped looking here, try comparing the source to the disassembly for other unintended changes.
If 0x815 is an uninitialized part of memory, that might explain the failure on WalkerOfTheDay's camera.
Thank so much for reviewing the dump and spotting the error !
Hopefully the next version fixes it. Can't wait to try.
However, I'm curious to know why this would be an issue in my camera while others don't have the problem ?
-
I fixed the CreateTask typo in r4986. It should be on the autobuild within half an hour. Please report if it fixes the problem.
Normally I'd post a test build before checking in, but this unambiguously needed to be done regardless of whether it was the cause of this specific problem.
-
I fixed the CreateTask typo in r4986. It should be on the autobuild within half an hour. Please report if it fixes the problem.
Normally I'd post a test build before checking in, but this unambiguously needed to be done regardless of whether it was the cause of this specific problem.
Yes ! That did the trick. No more freezes.
One thing I did notice, when I put the camera in Auto (which I usually never do) I get distorted images, at least jpeg (haven't looked at the DNG yet).
It like halve a picture with a lot of pink.
Like this:
(https://i.imgur.com/l37MtLM.jpg)
(https://i.imgur.com/yzBuqIc.jpg)
-
Yes ! That did the trick. No more freezes.
Great :)
One thing I did notice, when I put the camera in Auto (which I usually never do) I get distorted images, at least jpeg (haven't looked at the DNG yet).
Just to be clear DNG was enabled, but you see the corruption in jpeg?
It would definitely be helpful to know what the DNG looks like in this case.
If it happens without CHDK DNG enabled, that would point to a different kind of problem.
@ftm I would guess this is means the raw buffer is incorrect (sometimes?) in auto mode, and the byte reversing for DNG corrupts it. Auto mode on modern powershots is sort of a meta-mode that tries to identify the specific type of scene, so it could behave quite differently under different conditions.
-
Yes ! That did the trick. No more freezes.
Great :)
One thing I did notice, when I put the camera in Auto (which I usually never do) I get distorted images, at least jpeg (haven't looked at the DNG yet).
Just to be clear DNG was enabled, but you see the corruption in jpeg?
It would definitely be helpful to know what the DNG looks like in this case.
If it happens without CHDK DNG enabled, that would point to a different kind of problem.
@ftm I would guess this is means the raw buffer is incorrect (sometimes?) in auto mode, and the byte reversing for DNG corrupts it. Auto mode on modern powershots is sort of a meta-mode that tries to identify the specific type of scene, so it could behave quite differently under different conditions.
Yes it happens with DNG enabled (haven't tested without though).
The DNG looks like attached image in Lightroom.
-
Sorry, I've been out of contact for the last couple days.
@srsa_4c -- thanks for finding this error and @reyalp -- thanks for updating the code.
I don't get any of the raw issues as seen by @walker. My auto mode dngs look fine.
-
I don't get any of the raw issues as seen by @walker. My auto mode dngs look fine.
It is almost certainly scene and/or setting specific.
@WalkerOfTheDay if you upload the original jpeg rather than using imgur, we can see the exif, which might help identify what triggers this. If it's too large for the forum, you can use a file hosting site like dropbox, box.com, google drive etc.
-
My auto mode dngs look fine.
IMHO, if enabling raw in certain modes corrupts pictures, raw in those modes should be disabled.
You may want to add a few CAM_DISABLE_RAW_ defines to platform_camera.h, or, implement reyalp's advanced raw buffer handling code (g7x, sx710).
-
I don't get any of the raw issues as seen by @walker. My auto mode dngs look fine.
Okay, here's the original image taken in Auto mode.
It is almost certainly scene and/or setting specific.
@WalkerOfTheDay if you upload the original jpeg rather than using imgur, we can see the exif, which might help identify what triggers this. If it's too large for the forum, you can use a file hosting site like dropbox, box.com, google drive etc.
https://drive.google.com/open?id=11LGOdnAZxB4PuoLzghlrRLueGqyz-eio
-
Hi I formatted the card in my A4000 and then copied PS.FI2, DISKBOOT.BIN and the CHDK folder into the root of the card and it worked fine. Pressing play brought up the Firmware update option and thence CHDK.
On my SX700 HS I downloaded the zip file and then all I had was the DISKBOOT.BIN and the CHDK. Is that correct?
I copied them to the card but I can't get it to start with 'Play' and offer the firmware update option. Am I missing something?
Cheers, Steve
-
On my SX700 HS I downloaded the zip file and then all I had was the DISKBOOT.BIN and the CHDK. Is that correct? I copied them to the card but I can't get it to start with 'Play' and offer the firmware update option.
Booting CHDK using the Firmware Update method is currently not supported for DIGIC6 cameras like your SX700.
-
On my SX700 HS I downloaded the zip file and then all I had was the DISKBOOT.BIN and the CHDK. Is that correct? I copied them to the card but I can't get it to start with 'Play' and offer the firmware update option.
Booting CHDK using the Firmware Update method is currently not supported for DIGIC6 cameras like your SX700.
OK. Please can you explain how I get CHDK running using the available port sx710hs-100a-1.5.0-5001-full_ALPHA.zip?
Cheers, Steve
-
OK. Please can you explain how I get CHDK running using the available port sx710hs-100a-1.5.0-5001-full_ALPHA.zip?
Cheers, Steve
http://chdk.wikia.com/wiki/Prepare_your_SD_card
I'd recommend the STICK or CHIMP utilities linked at the top of that page.
-
http://chdk.wikia.com/wiki/Prepare_your_SD_card
I'd recommend the STICK or CHIMP utilities linked at the top of that page.
STICK (I'm on Linux) won't find a Dev 1.4 image for my SX700 HS so I guess that is not an option at this stage?
-
STICK (I'm on Linux) won't find a Dev 1.4 image for my SX700 HS so I guess that is not an option at this stage?
The SX700 is only available from the 1.5 ( or unstable / development branch ). You can select that withe STICK - I did it just last night.
Or you can manually download the ZIP file from the autobuild server and follow these instructions :
http://www.zenoshrdlu.com/stick/stickx.html
-
The SX700 is only available from the 1.5 ( or unstable / development branch ). You can select that withe STICK - I did it just last night.
Or you can manually download the ZIP file from the autobuild server and follow these instructions :
http://www.zenoshrdlu.com/stick/stickx.html
OK thank you that worked with stick (although just for the record it wanted the testxxxx.zip in /home/[username] rather than the same folder as stick.jar) but the error message did point me to that.
The trouble is (and I could just be being dense here) how do I get CHDK to boot up on the camera. It just seems to go into it's normal firmware/OS?
Cheers,
Steve
-
The trouble is (and I could just be being dense here) how do I get CHDK to boot up on the camera. It just seems to go into it's normal firmware/OS?
Put your SD card lock switch into the "locked position".
-
Put your SD card lock switch into the "locked position".
I did try that but the green LED just flashes and the camera doesn't boot. As soon as I take the lock off it starts into standard Canon mode.
-
STICK (I'm on Linux) won't find a Dev 1.4 image for my SX700 HS
What does STICK's "Firmware:" box say after selecting the sx700 jpg file?
I'd guess your cam's firmware is not 100e (which is the only supported version at the moment).
I did try that but the green LED just flashes and the camera doesn't boot.
That's what happens when the compatibility check fails.
-
I'd guess your cam's firmware is not 100e (which is the only supported version at the moment)...
I did try that but the green LED just flashes and the camera doesn't boot.
That's what happens when the compatibility check fails.
Yup, that'll be it. 100d - one letter off! - can you flash a Canon up a level?
EDIT: I contacted Canon to ask!
-
Yup, that'll be it. 100d - one letter off! - can you flash a Canon up a level?
EDIT: I contacted Canon to ask!
You generally cannot upgrade the firmware unless Canon issued a public firmware update, which they generally only do in the case of major bugs.
We already have a firmware dump of 100d, adding a new sub is not a huge effort if you are willing to test.
My preference is to avoid bugging Canon about anything relating to CHDK.
-
Hello, is my first time here and sorry for my poor english.
We already have a firmware dump of 100d, adding a new sub is not a huge effort if you are willing to test.
Well, as "stevsteve", my SX700 is also in 100d, so if you need tester, I can try.
Thanks for all, (great job)
Avel
-
I'll try to do a blind port for 100d this weekend.
-
OK, thanks
-
Here's a test build for firmware 100d. If it works it should be fully functional, but I did it blind so there a fair chance something is broken.
No FI2 is included, so you will need to make your SD card bootable using a utility like Stick or CHIMP http://chdk.wikia.com/wiki/Bootable_SD_card
Code is checked in (r5003) in case anyone else wants to work on it. I had to change the loader to move the cache function inline like M3, which also affects the 100e firmware, but I'm pretty sure it's OK since I tested the equivalent change on sx710.
-
No FI2 is included, so you will need to make your SD card bootable using a utility like Stick or CHIMP
I've lost track - did dmitrys ever make CHIMP capable of installing "unofficial" builds?
-
Many Thanks, I'll try this today
-
Well, when I take a picture with flash, after the picture I have a Blank screen and nothing work, I must put the battery out and on for close. Other way, sometimes, I have the screen flashing with two thing in the same times (menu and picture or two menu).
-
Well, when I take a picture with flash, after the picture I have a Blank screen and nothing work, I must put the battery out and on for close.
Thanks for reporting. Can you check if there's a ROMLOG? http://chdk.wikia.com/wiki/Debugging#Camera_crash_logs_.28romlog.29
If you have any other details of the settings used when this happens, it would be helpful: Canon Shooting mode, ISO, CHDK raw on or off?
If anyone with a 100e camera can check (@ftm?) whether shooting with the flash works, that would also be helpful.
Other way, sometimes, I have the screen flashing with two thing in the same times (menu and picture or two menu).
Some flashing when the Canon firmware updates the screen is normal. This happens a lot in Auto or if you have continuous AF enabled.
-
If anyone with a 100e camera can check (@ftm?) whether shooting with the flash works, that would also be helpful.
reyalp -- Thanks for this. I did test this version r5003 on my SX700HS. No problems taking pictures in Flash mode. I put it in Manual as well as P mode. Also did both RAW and JPEG.
-
Sorry, I don't know in which part I was yesterday, but I have try this morning and the flash works...maybe I was in Bracketting mode ?
I must learn using before post, I think!
-
Sorry, I don't know in which part I was yesterday, but I have try this morning and the flash works...maybe I was in Bracketting mode ?
It would still be helpful if you could get a ROMLOG. Execute the following in CHDK menu: Miscellaneous stuff -> Debug Parameters -> Save ROM crash log. If you then find a file named ROMLOG.LOG in the card's root directory, upload it here.
-
Hi,
Sorry to be late but my firmware was in Ukrainian, not easy to return in english...
But at last, i have doing the romlog
-
Hi,
Sorry to be late but my firmware was in Ukrainian, not easy to return in english...
But at last, i have doing the romlog
Thanks.
Do you know if the time in the romlog matches when the problem with flash happened?
Occured Time 2018:03:19 12:40:23
It might be an hour off from the camera clock depending on the daylight saving setting.
Error 9 appears to be JPEGTimeOut http://chdk.wikia.com/wiki/Canon_error_codes (edit: see below)
I have some memory of this error being triggered by CHDK bugs in the past.
One thing that might make a difference whether the crash is triggered or not might be whether you wait for the camera to focus after half press, or just push the button quickly without waiting.
-
Error 9 appears to be JPEGTimeOut
I traced back the
"\nHARDWARE DEFECT!! ShutdownReason[%d] ErrorNo[%d]\n"string and to me it looks like the shutdownreason is a condition code evaluated in task_Bye. ErrorNo is likely the actual error code. Which, in this case, is zero (resolves to NoError).
-
Error 9 appears to be JPEGTimeOut
I traced back the
"\nHARDWARE DEFECT!! ShutdownReason[%d] ErrorNo[%d]\n"string and to me it looks like the shutdownreason is a condition code evaluated in task_Bye. ErrorNo is likely the actual error code. Which, in this case, is zero (resolves to NoError).
Hmm. That's possible. All the previous instances of HARDWARE DEFECT errors I found on the forum with a google site: search seem to ShutdownReason[9] with a variety of non-zero ErrorNo values.
For @Avel Biz and @stevesteve: Some things you could test are described on http://chdk.wikia.com/wiki/Testing
Any feedback would be appreciated.
-
Hi, and sorry for the reply time : I was in hollidays...
Well, I'll try the test this week.
Thanks for all
-
I bought my SX700 in 2014. Since I've been using CHDK on my SX100 for several years, I immediately started checking if it would be ported to my new camera. A couple of days ago (although I had given up hope after 4+ years) I checked again and to my surprise a port was available.
I tested it today (it's the untested build a couple of pages back for f/w 1.00d) and it seems to work quite well. I think the menu closed a couple of times unexpectedly but other than that it seems to be ok. I didn't do any in-depth testing, just took a couple of shots and played with the menus.
It seems the build has expired though so a fresh one is needed. :D
Anyway, thanks for your effort in porting CHDK to our camera. I hope you continue to work on it (although the last post here is in April) and I can help with testing if needed.
-
I tested it today (it's the untested build a couple of pages back for f/w 1.00d) and it seems to work quite well. I think the menu closed a couple of times unexpectedly but other than that it seems to be ok. I didn't do any in-depth testing, just took a couple of shots and played with the menus.
Thanks for reporting. I enabled sx700 100d in the autobuild. It will be available from the autobuild server shortly in trunk build 5088
It's probably as functional as the other sx700 version, but if you can use it a little bit and report back I'll take the PREALPHA label off. Running the ubtest.bas script described on https://chdk.wikia.com/wiki/Testing#ubtest.bas would probably be good enough.
Regarding the menu closing unexpectedly, I would suspect this is a drawing issue rather than the menu actually closing. Some drawing issues are expected, see https://chdk.setepontos.com/index.php?topic=12758.msg132871#msg132871 (post written about M10, but applies to other digic6 cameras too)
-
Thanks for the quick reply. The script worked without errors.
The images have different parameters (2nd one has faster speed, 3rd one lower iso).
In general it seems stable enough. The functions I tried seemed to work. There are of course a lot of options that I'm not familiar with as I haven't played much with my SX100 in the past four years (still had it on the 1.3 branch) and CHDK seems to have added even more options.
Let me know if you have more things to test.
test plat 12933 pset 6
sleep/tick test
start 371250 end 371760 dif 510
key test - set to end
up
down
left
right
menu
down
disp
set
key press test
already in rec
current mode 2
exp_count 8533
Av 330 Sv 701 Tv 412
shot - default 8534
exp_count 8534
shoot Tv+2 8535
shoot Sv-2 8536
cam has iris
ok
-
Thanks for the quick reply. The script worked without errors.
Thanks again. I switched the build status to alpha.
-
waterwingz - Thanks. It looks like the grid files have hard coded values for a smaller display. 320x240. Once I made a new grid file, it worked fine.
just discovered that the sx700hs is starting to be supported
my camera has firmware 100d
could you share a grid file you have changed for this camera please
or can someone tell me what size the screen is on these cameras
thanks
-
or can someone tell me what size the screen is on these cameras
The screen is 640x480 when using the LCD. Note that pixels are square, unlike on earlier cameras.
-
Hi,
while beeing very long time user of CHDK on my Powershots I'm very grateful to the developer team.
Testing the build CHDK_DE_sx700hs-100e-1.5.0-5596 on my SX700 I've found so far the following issues:
script command set_focus -1 (or any high value near to infinity) does not work, however this issue was discussed on different other topics already.
CHDK OSD in video mode: displayed values seem to be sensless: "0001 kbit/s" (sometimes vaues up to "0004") or permanently "00:00:01" if video time remaining should be displayed.
Override ISO value via CHDK menu: works fine if values below the minimum value of Canon standard (e.g. 50 ISO) are choosen, however it fails if the Canon standard was set to values between 400 ... 3200 ISO (all PSAM modes). In this cases the camera switches of if the shutter is pressed. If ISO should be pushed bejond the maximum standard of 3200 ISO the use case would be: setting this maximum value via the Canon menu and than use the CHDK override ISO in combination with a -1EV correction (in case of 6400 ISO) via Canon standard menu in order to obtain correct exposure. Btw, using the EV correction from the CHDK menu where values from 0 .... 4EV can be choosen, does not have any influence at all on the exposures taken.
Would be happy if one of the CHDK masters will go after this issue at one of the next builds.
But staying healthy has priority currently ....
-
CHDK OSD in video mode: :( core/gui_osd.c line 581
// D6: filesystem related info is not updated during recording
" In this cases the camera switches of if the shutter is pressed." ???
How to get Crashlog: https://chdk.setepontos.com/index.php?topic=13472.50
-
Testing the build CHDK_DE_sx700hs-100e-1.5.0-5596 on my SX700 I've found so far the following issues:
Thanks for the reports.
script command set_focus -1 (or any high value near to infinity) does not work, however this issue was discussed on different other topics already.
Different cameras have different limits and issues, so it's not clear if this is a bug or expected behavior.
This camera requires MF or AFL enabled (either with the Canon UI or set_mf or set_aflock) for set_focus to work at all. In those modes, calling set_focus should immediately update the focus distance.
You can use the DOF calculator to show the current SD value, under OSD settings->DOF Calculator
set "Show DOF Calculator" to "in misc"
check "Show Subj. Dist. in Misc."
The port is configured so that 1562414mm is largest non-infinity value that can be set. Values beyond that should result in infinity. However, at the wide end of the zoom, it will go to infinity at much lower values (my sx710, which I think has the same optics, shows infinity with set_focus(10000) at full wide). Setting -1 should set focus to "infinity" but that may actually give you the best infinity focus.
Additionally, set_focus only focus at certain steps. On my sx710 at full wide, setting 4000 to 9000 all result in SD around 5000.
CHDK OSD in video mode: displayed values seem to be sensless: "0001 kbit/s" (sometimes vaues up to "0004") or permanently "00:00:01" if video time remaining should be displayed.
Yeah, these cameras don't seem to update free disk regularly while the video is recording.
Override ISO value via CHDK menu: works fine if values below the minimum value of Canon standard (e.g. 50 ISO) are choosen, however it fails if the Canon standard was set to values between 400 ... 3200 ISO (all PSAM modes).
Do you mean 400 to 3200 in the CHDK override value, or that the Canon UI is set to those values, while a different value is in the override?
In this cases the camera switches of if the shutter is pressed.
As caefix said, a posting a romlog would be good. See https://chdk.fandom.com/wiki/Debugging#Camera_crash_logs_.28romlog.29
Note that values beyond the Canon limits may not crash, but they probably don't actually set the ISO much beyond the Canon limit. That means that ISO override is really only useful for script, or for Canon settings that restrict the ISO (for example, many cameras force low ISO for long exposures)
-
Quote
Override ISO value via CHDK menu: works fine if values below the minimum value of Canon standard (e.g. 50 ISO) are choosen, however it fails if the Canon standard was set to values between 400 ... 3200 ISO (all PSAM modes).
Do you mean 400 to 3200 in the CHDK override value, or that the Canon UI is set to those values, while a different value is in the override?
The use case is: setting e.g. ISO 3200 via Canon UI and ISO override to e.g. to ISO 6400 via CHDK, leave CHDK and press shutter. Would expect either an overexposed image or - to avoid that - would have to set a -1EV exposure compensation via Canon UI. However pessing shutter results into a camera shut down. ROMLOG.LOG attached.
-
Override ISO value via CHDK menu: works fine if values below the minimum value of Canon standard (e.g. 50 ISO) are choosen
To be more presise on this topic: setting e.g.100 ISO via the Canon UI and e.g. 50 ISO via CHDK Menu and leave CHDK. In this case the camera takes an image if the shutter ist pressed (no shut of) and the EXIF data of the image ist updated to e.g. 50 ISO. In this case I would expect either an underexposed image or would have to set a +1EV exposure compensation. However the image is NOT underexposed but exposed like 100 ISO to stay with the example.
This type of use cases work like expected on all my other Powershots with CHDK, at least as long the HW limits of this particular cams are not exeeded.
-
You can check ISO limits with ISOINC.lua
https://chdk.setepontos.com/index.php?topic=12165.0
Last Script Version
https://chdk.setepontos.com/index.php?topic=12165.msg127110#msg127110
-
To be more presise on this topic: setting e.g.100 ISO via the Canon UI and e.g. 50 ISO via CHDK Menu and leave CHDK. In this case the camera takes an image if the shutter ist pressed (no shut of) and the EXIF data of the image ist updated to e.g. 50 ISO. In this case I would expect either an underexposed image or would have to set a +1EV exposure compensation. However the image is NOT underexposed but exposed like 100 ISO to stay with the example.
This is normal. On most cameras, ISO overrides to do not work much beyond the Canon range. The exif just reflects the requested value, not the exposure. On a camera with a base ISO of 100 you might get the equivalent of 90 or something like that, but I've never seen one do 50. The script c_joerg linked is good for measuring the limits objectively. The latest version is included in the CHDK/SCRIPT/TEST directory.
There can be some weirdness at the high end, because the last steps of Canon ISO are often implemented as post processing on jpeg data, but I'd be quite surprised if you can get say, ISO 3200 equivalent in raw data on a camera that only supports 1600
I'll check if I can reproduce the crash on my cams. It's not one I've seen before:
ASSERT!! CaptureAKBAD.c Line 549
Occured Time 2020:11:04 17:27:27
Task ID: 17891368
Task name: CaptSeqTask
-
Thank's a lot to reylap and c_joerg for the hints - got a much better understanding of ISOoverride now.
However while transfering my scripts from the other cams step by step, I found some more strange things at the SX700.
e.g. get_movie_status: return "1" both for "recording" and "pause", but "4" while storing to SD card. That differs from CHDK documentation and the behavior of other cams.
Keep you updated on more findings.
-
re: script setfmode.lua
I've tested the script on my SX700 and got the following:
Use case for far SD:
- In <Alt> set Focus mode to "Ovr" and Focus dist mm to 10000
- start script
- CHDK OSD displays "SD:10000"
- leave <Alt>
- CHDK OSD sitll displays "SD:10000"
- Aim cam to a close subject e.g. at 200 mm (wide zoom lense)
- Take pic with shutter
- check pic: focus was set to an SD of 200 mm
In my point ov view the SD override ist not working as expected.
Use case for close SD:
- In <Alt> set Focus mode to "Ovr" and Focus dist mm to 100
- start script
- CHDK OSD displays "SD:100"
- leave <Alt>
- CHDK OSD sitll displays "SD:100"
- Aim cam to a far subject e.g. at 20000 mm
- Take pic with shutter
- CHDK OSD is now cleared
- check pic: focus was set to an SD of 100 mm as expected
However the focus mechanism of the cam now got stuck to this close SD while the CHDK OSD does not display any override. This only can be cleared by switching the cam off/on or changing the focus mode via Canon UI.
Most likely I've missunderstood the purpose of the script, but as far as I can see it does more or less the same as MF on the Canon UI does. So I would be happy to got more information how to use setfmode.lua correctly.
Another question would be how to use the script within a focus stacking script. Because I'm not very good at programming and scripting I will value any hints.
Thanks a lot in advance.
-
re: script setfmode.lua
...
This script is mainly intended for people using cameras without MF, so they can use CHDK SD override as a replacement. Especially for cameras that require set_mf or set_aflock for overrides to work, and do not have a way in the firmware UI to enter those states.
Since SX700 has manual focus and af lock in the normal Canon UI, there should be little reason to use the script.
I've tested the script on my SX700 and got the following:
Use case for far SD:
- In <Alt> set Focus mode to "Ovr" and Focus dist mm to 10000
- start script
- CHDK OSD displays "SD:10000"
- leave <Alt>
- CHDK OSD sitll displays "SD:10000"
- Aim cam to a close subject e.g. at 200 mm (wide zoom lense)
- Take pic with shutter
- check pic: focus was set to an SD of 200 mm
In my point ov view the SD override ist not working as expected.
This does seem incorrect. Do you have "safety MF" enabled in the Canon UI? If it's on, it might not keep the focus you set.
Does the focus seem to change when you run the script, or when you half press the shutter before shooting?
Use case for close SD:
- In <Alt> set Focus mode to "Ovr" and Focus dist mm to 100
- start script
- CHDK OSD displays "SD:100"
- leave <Alt>
- CHDK OSD sitll displays "SD:100"
- Aim cam to a far subject e.g. at 20000 mm
- Take pic with shutter
- CHDK OSD is now cleared
- check pic: focus was set to an SD of 100 mm as expected
However the focus mechanism of the cam now got stuck to this close SD while the CHDK OSD does not display any override. This only can be cleared by switching the cam off/on or changing the focus mode via Canon UI.
You should be able to return to the normal state by setting the focus mode to auto in the normal canon UI. You may need to rotate through the options if it's already on AF.
Another question would be how to use the script within a focus stacking script. Because I'm not very good at programming and scripting I will value any hints.
You shouldn't need to.
SX700 needs to be in MF or AF lock mode for focus overrides to work. If the focus stacking script does not automatically set one of those, you could either set it using the canon UI before hand, or add a line like
set_mf(1)
near the start of the script.
-
Thanks to reyalp for the clarification on setfmode.lua .
Quote
I've tested the script on my SX700 and got the following:
Use case for far SD:
- In <Alt> set Focus mode to "Ovr" and Focus dist mm to 10000
- start script
- CHDK OSD displays "SD:10000"
- leave <Alt>
- CHDK OSD sitll displays "SD:10000"
- Aim cam to a close subject e.g. at 200 mm (wide zoom lense)
- Take pic with shutter
- check pic: focus was set to an SD of 200 mm
In my point ov view the SD override ist not working as expected.
This does seem incorrect. Do you have "safety MF" enabled in the Canon UI? If it's on, it might not keep the focus you set.
No, "Safety MF" and all other focus options from the Canon UI were disabled for all the tests.
SX700 needs to be in MF or AF lock mode for focus overrides to work. If the focus stacking script does not automatically set one of those, you could either set it using the canon UI before hand, or add a line like
Quote
set_mf(1)
near the start of the script.
Quite sure, my focus bracketing script (that runs well on the other cams) uses set_mf.
But I did some more tests and belive now that I've figured out what the problem with SD override on the SX700 seems to be.
While the get_focus function gives am maximum value of approx. 350000 back on this cam (or -1), the set_focus function is obviously limitied to a maximum value of 65535. Using only a value range of 0...65535 for the set_focus fuction let work the focus stacking script well.
And btw, I've tested to set the focus override directly via the CHDK menu too (build 5623). Here seems to be a problem: regrardless of the option (On/Off/Inf) and values choosen, there will be no override displayed on the CHDK OSD and no setting of focus on the cam happens.
-
While the get_focus function gives am maximum value of approx. 350000 back on this cam (or -1), the set_focus function is obviously limitied to a maximum value of 65535. Using only a value range of 0...65535 for the set_focus fuction let work the focus stacking script well.
This is strange. There shouldn't be any such limit on this camera, and I don't see anything like that on SX710, which has similar optics and port settings.
Is your script Lua or ubasic? Can you post it here?
Note that at wide angles, the subject distance will go to -1 at quite close distances, probably before 64k.
Also, the DOF calculator setting "Use EXIF Subj. dist" also affects setting in a poorly specified way, but it doesn't seem to have a 64k limit. In any case, I'd suggest leaving that setting off.
And btw, I've tested to set the focus override directly via the CHDK menu too (build 5623). Here seems to be a problem: regrardless of the option (On/Off/Inf) and values choosen, there will be no override displayed on the CHDK OSD and no setting of focus on the cam happens.
As I mentioned, this camera must be in MF or AF lock for SD override to work. Does the override appear if you enable MF using the Canon UI?
-
Is your script Lua or ubasic? Can you post it here?FocusBrack.bas attached. German GUI and not well documented, but should be more or less selfexplaining.
As I mentioned, this camera must be in MF or AF lock for SD override to work. Does the override appear if you enable MF using the Canon UI?
Ooops, I've missed setting to MF - ist works like expected then.
-
Is your script Lua or ubasic? Can you post it here?FocusBrack.bas attached. German GUI and not well documented, but should be more or less selfexplaining.
Looking at the script, it treats 64k as infinity. Unless this is a version you modified to stay below 64k?
print "Schritt " r,"Dist.",g,"mm"
if t=0 then g=g+c
if t=1 then g=g+c*i
if t=2 then g=g+c*i*i
if g>65530 then goto "infinity"
next i
:infinity
g = 65534
set_focus g
sleep 100
It's possible this was originally written a long time ago, for old cameras that used to short for focus distance.
Assuming this isn't a modification you made to keep it below 64k, you could either use larger numbers instead of 65530 and 65534, or change the logic to just end when get_focus returns -1. The second option would be better, IMO, because the distance the camera changes to -1 depends on the zoom, so if you use a fixed number, you might get many "infinity" shots in some cases.
Something like
...
for i=1 to s
r=i
set_focus g
sleep 500
shoot
print "Schritt " r,"Dist.",g,"mm"
if get_focus = -1 then goto "done"
if t=0 then g=g+c
if t=1 then g=g+c*i
if t=2 then g=g+c*i*i
next i
:done
set_mf 0
playsound 0
end
Note that the way this script is written, it may take multiple shots at the same focus distance, because it set_focus only goes to specific positions. Example from sx710 at wide angle (using chdkptp):
con 1> =set_mf(1)
con 2> =set_focus(100) return get_focus()
3:return:100
con 3> =set_focus(1000) return get_focus()
4:return:1021
con 4> =set_focus(1500) return get_focus()
5:return:1421
con 5> =set_focus(2000) return get_focus()
6:return:1833
con 6> =set_focus(3000) return get_focus()
7:return:2586
con 7> =set_focus(4000) return get_focus()
8:return:3939
con 8> =set_focus(5000) return get_focus()
9:return:3939
con 9> =set_focus(6000) return get_focus()
10:return:-1
Notice that 4000 and 5000 both set the distance to 3939, and 6000 is "infinity" already.
-
Assuming this isn't a modification you made to keep it below 64k, you could either use larger numbers instead of 65530 and 65534, or change the logic to just end when get_focus returns -1. The second option would be better, IMO, because the distance the camera changes to -1 depends on the zoom, so if you use a fixed number, you might get many "infinity" shots in some cases.
Yes, this was the intention as it can be derived from the DHDK docu. Anyway, to use -1 from get_focus to exit the loop is much better - thanks for the hint.
Notice that 4000 and 5000 both set the distance to 3939, and 6000 is "infinity" already.
A valuable insight for me too, that get_focus can deliver a different value as set with set_focus and that the maximum values near "infinity" differs heavily from the zoom setting. Thank's again.
-
A valuable insight for me too, that get_focus can deliver a different value as set with set_focus and that the maximum values near "infinity" differs heavily from the zoom setting. Thank's again.
Yes. Focus actually works in positions of the focus mechanism, and there's some formula in the camera (original firmware, not CHDK) which converts from or to distance. As you'd expect from the optics involved, small changes in position correspond to large changes in distance as you get closer to infinity.
Forum member pigeonhill created some sophisticated focus stacking scripts here: https://chdk.setepontos.com/index.php?topic=13638.0
-
PropertyCases for Digic VI (SX700 and others)?
Hi,
has anyone newer information regarding PropertyCases https://chdk.fandom.com/wiki/PropertyCase#Digic_V_.28propset5.29 (https://chdk.fandom.com/wiki/PropertyCase#Digic_V_.28propset5.29) for this cams?
I've started some investigations on this topic using the script propdump.lua by Morris Johns (see https://chdk.fandom.com/wiki/PropertyCaseDump (https://chdk.fandom.com/wiki/PropertyCaseDump)), however I feel this to be somewhat painfull because
1. this script logs at the bottom of the logfile only one difference found even if more than one differences exist and had been displayed at script end via the UI.
2. the log files are named with file types like .1, .2., ... what makes them unable to be opend with the CHDK text viewer directly on the cam (so after each script run the SD card has to be removed to display the results). File names like PROPDUMP1.LOG and so on would help here.
Unfortunately I'm not good at LUA scripting to modify propdump.lua. But if some with more knowledge would update propdump.lua to make it more convenient, I can offer to do deeper research on PropertyCases for SX700 and probably other Digic VI cams (if this might be valuable for other CHDK users).
Best regards
-
PropertyCases for Digic VI (SX700 and others)?
Generally, propsetN.h in the source (or CHDK/LUALIB/GEN/propsetN.lua) is the more comprehensive source these days. That wiki page isn't updated much, although there's probably some items that don't appear in the propset files.
sx700 is propset 6 http://tools.assembla.com/svn/chdk/trunk/include/propset6.h
For a completed port, the propset file should have all the commonly used props verified already, so additional research is only need if you want to do something unusual, or research for its own sake.
Note that propsets don't really correspond to digic version, there are digic 4 cameras, and most digic 6 cameras use other propsets.
2. the log files are named with file types like .1, .2., ... what makes them unable to be opend with the CHDK text viewer directly on the cam (so after each script run the SD card has to be removed to display the results). File names like PROPDUMP1.LOG and so on would help here.
I'm not familiar with that script, but FWIW, if you use the "text file reader" -> "open new file" menu item instead of going from the file browser, you should be able to open any file.
That said, my preferred to way to investigate propcases is the chdkptp (https://app.assembla.com/spaces/chdkptp/wiki) devutil extension. See https://chdk.setepontos.com/index.php?topic=13569.msg138496#msg138496 for a brief explanation.
-
Thank's - that helps much!
-
PropCase # 167: Direct timelaps video recording in (Full)HD with SX700 (and some others?)
Hi,
I have'nt found something about this feature on this forum so I've checked some PropCases from http://tools.assembla.com/svn/chdk/trunk/include/propset6.h (http://tools.assembla.com/svn/chdk/trunk/include/propset6.h), in particular
PROPCASE_VIDEO_FRAMERATE [167]
This PropCase is RW and has (at least for the SX700) the following additional values:
3 = 240 fps
4 = 120 fps
5 = 60 fps
9 = 6 fps *)
10 = 3 fps *)
11 = 1.5 fps *)
*) like used in MINIATURE mode (but this mode is HD only and blures top and bottom of the video).
I do not belive that video recording may be driven beyond the HW limits with this, but setting PropCase # 167 allows direct timelaps recording in (Full)HD. So the usual CHDK process to take a series of still pictures and generate the TL video in post is much easier now for this series of cams. To do TL video without any blur (like in MINIATURE mode) I've done the small script TL_FHDe.bas attached.
Have fun and share Your experience.
In addition setting PropCase # 167 via an override option from the CHDK menu may be a topic developers can hook on.
-
CHDK OSD: Show Remaining Videotime
The CHDK menu on the SX700 provides an option to display Remaining Videotime [ Don’t, hh:mm:ss, KB/s, both ].
However this display is not updated correctly during video recording - pls see attached screen shoot. Is there a chance to fix that at one of the next builds?
-
CHDK OSD: Show Remaining Videotime
The CHDK menu on the SX700 provides an option to display Remaining Videotime [ Don’t, hh:mm:ss, KB/s, both ].
However this display is not updated correctly during video recording - pls see attached screen shoot. Is there a chance to fix that at one of the next builds?
Probably not, at least not without significant reverse engineering. Digic 6 cameras don't appear to update the free disk space while recording.
-
Digic 6 cameras don't appear to update the free disk space while recording.
I believe I found a version of GetDrive_FreeClusters that updates during recording. I mis-identified it as GetDrive_TotalClusters in the M10 port, only corrected it in changeset 5633. You could try identifying it in your cams, it's the first routine with an AvailClusters.c assert.
If my guess is correct, the stub for sx700 is 0xFC0668E7 (100d and 100e).
-
I believe I found a version of GetDrive_FreeClusters that updates during recording. I mis-identified it as GetDrive_TotalClusters in the M10 port, only corrected it in changeset 5633. You could try identifying it in your cams, it's the first routine with an AvailClusters.c assert.
If my guess is correct, the stub for sx700 is 0xFC0668E7 (100d and 100e).
Hmm, on G7X, the equivalent of that function (100d fc06e693) appears to return exactly the same value as the current GetDrive_FreeClusters, including not updating while recording video.
@CanonUser9000 if you want to test, here's a build for sx700 100e using the function srsa_4c mentioned
-
@reyalp:
Thank's a lot for the testbuild.
Unfortunately there is no change regarding the OSD during video recording - display ist still "0000 KB/s -00:00:01" on the SX700.
-
Hmm, on G7X, the equivalent of that function (100d fc06e693) appears to return exactly the same value as the current GetDrive_FreeClusters, including not updating while recording video.
Yeah, I'm getting the same result on the sx280. Newer models, such as g5x and sx730, have a function that looks identical to the one in m10. I guess it's possible that those cams behave like the m10.
-
I think I found a possible source for the free cluster count. This value seems to be the one that gets copied to the other similar firmware variables. On the sx280, it is updated during video record.
@CanonUser9000
Attached is a test build. Does the CHDK free card space display and the movie bitrate display look reasonable?
Index: platform/sx700hs/lib.c
===================================================================
--- platform/sx700hs/lib.c (revision 5708)
+++ platform/sx700hs/lib.c (working copy)
@@ -267,3 +267,11 @@
extern char jpeg_count_str[];
return jpeg_count_str;
}
+
+// get free cluster info directly
+// also updated during video recording
+unsigned long _GetDrive_FreeClusters(int drive)
+{
+ extern unsigned long live_free_cluster_count;
+ return live_free_cluster_count;
+}
Index: platform/sx700hs/sub/100d/stubs_entry.S
===================================================================
--- platform/sx700hs/sub/100d/stubs_entry.S (revision 5708)
+++ platform/sx700hs/sub/100d/stubs_entry.S (working copy)
@@ -211,7 +211,7 @@
NHSTUB(GetUsableMaxAv ,0xfc1a2d47) // 0
NHSTUB(GetUsableMinAv ,0xfc1a2d35) // 0
NHSTUB(GetDrive_ClusterSize ,0xfc3075a3) // 0
-NHSTUB(GetDrive_FreeClusters ,0xfc307ad1) // 0
+//NHSTUB(GetDrive_FreeClusters ,0xfc307ad1) // 0 Overridden
NHSTUB(GetFocusLensSubjectDistance ,0xfc2dcd43) // 0
NHSTUB(GetKbdState ,0xfc06e207) // 0
NHSTUB(GetMemInfo ,0xfc3d4e4d) // 0
Index: platform/sx700hs/sub/100d/stubs_entry_2.S
===================================================================
--- platform/sx700hs/sub/100d/stubs_entry_2.S (revision 5708)
+++ platform/sx700hs/sub/100d/stubs_entry_2.S (working copy)
@@ -26,6 +26,7 @@
NHSTUB(apex2us, 0xfc31375f) // sx700v100e Shutter.c asserts @ fc1499d0 for line 0x16e, same as 100e fw
NHSTUB(GetDrive_TotalClusters, 0xfc307aad) // sx700v100d found function immediately before GetDrive_FreeClusters in ROM
+IGNORE(GetDrive_FreeClusters) // replacement in lib.c
NHSTUB(LogCameraEvent, 0xfc306c97) // sx700v100d debugging, from func csv
Index: platform/sx700hs/sub/100d/stubs_min.S
===================================================================
--- platform/sx700hs/sub/100d/stubs_min.S (revision 5708)
+++ platform/sx700hs/sub/100d/stubs_min.S (working copy)
@@ -35,6 +35,8 @@
DEF(displaytype, 0x8f98)
+DEF(live_free_cluster_count, 0x15f270) // 0x15F238 + 0x38 @ 0xFC05ECEC
+
// *** Not Found ***
FAKEDEF(video_compression_rate, 1)
Index: platform/sx700hs/sub/100e/stubs_entry.S
===================================================================
--- platform/sx700hs/sub/100e/stubs_entry.S (revision 5708)
+++ platform/sx700hs/sub/100e/stubs_entry.S (working copy)
@@ -211,7 +211,7 @@
NHSTUB(GetUsableMaxAv ,0xfc1a2c7b) // 0
NHSTUB(GetUsableMinAv ,0xfc1a2c69) // 0
NHSTUB(GetDrive_ClusterSize ,0xfc30747b) // 0
-NHSTUB(GetDrive_FreeClusters ,0xfc3079a9) // 0
+//NHSTUB(GetDrive_FreeClusters ,0xfc3079a9) // 0 Overridden
NHSTUB(GetFocusLensSubjectDistance ,0xfc2dcc47) // 0
NHSTUB(GetKbdState ,0xfc06e207) // 0
NHSTUB(GetMemInfo ,0xfc3d4cdd) // 0
Index: platform/sx700hs/sub/100e/stubs_entry_2.S
===================================================================
--- platform/sx700hs/sub/100e/stubs_entry_2.S (revision 5708)
+++ platform/sx700hs/sub/100e/stubs_entry_2.S (working copy)
@@ -28,6 +28,7 @@
NHSTUB(apex2us, 0xfc313637) // sx700v100e Shutter.c asserts @ fc1495ca -> fc149620 instructions similar to g7x fc3826c4
NHSTUB(GetDrive_TotalClusters, 0xfc307985) // sx700v100e found function immediately before GetDrive_FreeClusters in ROM
+IGNORE(GetDrive_FreeClusters) // replacement in lib.c
NHSTUB(LogCameraEvent, 0xfc306b6f) // sx700v100e found debugging, from func csv
Index: platform/sx700hs/sub/100e/stubs_min.S
===================================================================
--- platform/sx700hs/sub/100e/stubs_min.S (revision 5708)
+++ platform/sx700hs/sub/100e/stubs_min.S (working copy)
@@ -44,6 +44,8 @@
// Search for ActionStopRecordMovie, then go till next branchtable
DEF(displaytype, 0x8f98) // sx700v100e Similar to sx280 0x8f54 + 0x44 found @0xfc120a38 (GetDisplayType)
+DEF(live_free_cluster_count, 0x15f270) // 0x15F238 + 0x38 @ 0xFC05ECEC
+
// *** Not Found ***
FAKEDEF(video_compression_rate, 1)
-
Hi,
congratulations!
With this build the OSD now displays both free card space and movie bitrates. The values seem to be feasible to me (the value box is flickering, but I understood so far that this can be avoided).
-
SX700: Custom Auto ISO
I've tested Costom Auto ISO on the SX700 withe the following settings (e.g.) in P-Mode:
Minimum Shutter Speed: Auto
User Factor (1/FL/factor): 6
IS Factor (Tv*factor): 4
Min ISO: 200
Max ISO Auto: 1600
Fallback Min. Shutter Speed: 1/60
Fallback Max ISO: 3200
Overexp Compensation: Off
With this setting I would expect the cam in any case (even in brighter light as long as the shortes shutter speed is not required) to set 200 ISO if Custom Auto ISO ist set ON. Under lower light conditions I would expect the cam to set ISO 3200 as soon as a shutter speed of longer than 1/60 is required and Custom Auto ISO is set ON.
However in any test cases exposure values are fully identical regardless if Custom Auto ISO is set ON oder OFF.
So please help me if I'd missunderstood the meaning of Custom Auto ISO as described above. Otherwise please verfiy if this feature is working corrrect on the SX700.
Thank's in advance!
-
So please help me if I'd missunderstood the meaning of Custom Auto ISO as described above. Otherwise please verfiy if this feature is working corrrect on the SX700.
The Custom Auto ISO code has an interesting history. I beleive the current code was added by this patch : https://chdk.setepontos.com/index.php?topic=650.msg75555#msg75555
I tried to describe how it works here : CHDK User Manual : Custom Auto ISO (https://chdk.fandom.com/wiki/CHDK_1.5_User_Manual#Custom_Auto_ISO)
-
Hi waterwingz,
thank's for the two links (that I've consulted anyway prior posting).
However from my point of view this does not explain the behavior of the SX700.
Given the use case "bright light" the cam exposes with ISO 100 both with Custom Auto ISO on ON or OFF (and the same shutter speed).
At the use case with "low light" the cam sets always ISO 1600 (even in more or less complete darkness) if Custom Auto ISO ist set ON with the settings mentioned above.
Note: the SX700 allows to set ISO 3200 via the Canon menu. For the tests ISO was set to AUTO on the canon menu.
This all would lead me to the conclusion that Custom Auto ISO is not working on the SX700.
Or are other explanations feasible?