CHDK firmware hack discussion (19)

[jonquil]

Hi GrAnd, rossig,

I have uploaded the firmware dump in
http://www.zshare.net/download/4295284cd838ba/
I have dumped it twice and the results were the same.

I've looked into the dump and it seems that it is a little bit
broken, at least in the beginning: a lot of bytes with code 0x00 were
replaced by code 0x20.
What the program did you use for dumping/editing/concatenating two
parts? Maybe one of these programs did these changes?

Umm.. I will retry the dumping as soon as possible.. maybe these are the problems I am having with the porting... but, strangely.. I downloaded twice each part, and they were the same....

I sum up both parts in windows in a usual way:

copy b a1.bin + a2.bin a.bin

(I do constantly this for other things).

I could try a similar thing in the linux box.

Thanks for the point

 

[microfunguy]

waiting for comments....

Before commenting on that I will take the opportunity to repeat some questions that I think you missed from an earlier post :-

void vid_get_viewport_live_fb()

Does 'fb' stand for frame-buffer ?

What do each of these functions do ? :-

vid_get_viewport_live_fb()
vid_get_bitmap_fb()
vid_get_viewport_fb()
vid_get_viewport_fb_d()

Thanks.

David

 

[mx32]

Before commenting on that I will take the opportunity to repeat some
questions that I think you missed from an earlier post :-

void vid_get_viewport_live_fb()

Does 'fb' stand for frame-buffer ?

What do each of these functions do ? :-

vid_get_viewport_live_fb()
vid_get_bitmap_fb()
vid_get_viewport_fb()
vid_get_viewport_fb_d()

I have joined this project not so long ago.
I don't have all answers to your questions.

i think (sure) "fb" stands for frame bufer

vid_get_viewport_fb_d() - seems returns address of frame for Display mode

vid_get_viewport_live_fb() - dont know for sure ( it seems name is self descriptive but port implementers could place there addresses which are not logical

vid_get_viewport_fb() - it returns one of three buffers in shot mode (as I stated in prev message)

vid_get_bitmap_fb() - dont have any guess

 

[microfunguy]

waiting for comments....

Before commenting on that I will take the opportunity to repeat some questions that I think you missed from an earlier post :-

void vid_get_viewport_live_fb()

Does 'fb' stand for frame-buffer ?

What do each of these functions do ? :-

vid_get_viewport_live_fb()
vid_get_bitmap_fb()
vid_get_viewport_fb()
vid_get_viewport_fb_d()

Thanks.

David

 

[GrAnd]

vid_get_bitmap_fb() - dont have any guess

The address of buffer which contain all OSD texts, icons, etc. It hardware overlays to the image.

 

[microfunguy]

Sorry !

Accidental repeat of post.

 

[Divalent]

For a brief moment us script/property case guys thought we found a reliable indicator of when the camera was ready to take another image (property 205). However, it seems that that is not the case.

The idea is that, in scripts where you'd like to take a sequence of shots as rapidly as possible, you need to know when it is ok to shoot the next one, under all conditions. (Currently, we just Sleep for some interval that "seems" to work and hope for the best).

It would be great to find a more reliable indicator that would work under all conditions but would be as fast as the current conditions allow.

So, in seeking further, I wonder...

1. Do you know of any flag set in the camera somewhere that may indicate this information? (And if so, how can a script access it?)

Of there is not one (or not one known), how about:

2. A flag that indicates "writing to memory"?

or:

3. A flag, or LED control, that shows the state of the red LED?

On my camera, the red LED flashes when writing to memory.

It may be that we can use #2 or #3 as a surrogate for #1: when it stops writing to memory (or the LED stops flashing) we know (do we?) that is is ready to go again (or will be in a very short time).

Any help appreciated.

FYI, I'm using Fingalo's extended build with prop_case and get_tick_count routines.

Thanks

Divalent

 

[aeropic]

For a brief moment us script/property case guys thought we found a
reliable indicator of when the camera was ready to take another image
(property 205). However, it seems that that is not the case.

Divalent,

trying to work on the 205 prop, I've the feeling that, at least in MF click shoot_full conditions, 205 is directly connected to the duration of shoot and not to the AE setting.

I made a very stupid script (see below) which writes in a file the content of 205 every 20 ms.

I set the mode in Tv and direct the lenses toward my white computer screen (constant light) ==> constant AE measurement conditions

with a 0,5sec pause I get around two 0 followed by19 occurences of 1 ==> 380 ms

while with a 1/100sec pause I get two 0 followed by only 7 occurence of 1 ==> 140 ms

==> this is not the exposure measurement duration, but rather close to the photo duration ...

I go on thinking 205 is the right indicator for shoot_full. Don't you think so ?

bye
Alain

the script (very stupid indeed !)
====================

@title 205

print_screen 1
sleep 300

click "shoot_full"

get_prop 205 s
print s
get_prop 205 s
print s
get_prop 205 s
print s
get_prop 205 s
print s
get_prop 205 s
print s
get_prop 205 s
print s
get_prop 205 s
print s
get_prop 205 s
print s
get_prop 205 s
print s
get_prop 205 s
print s
get_prop 205 s
print s
get_prop 205 s
print s
get_prop 205 s
print s
get_prop 205 s
print s
get_prop 205 s
print s
get_prop 205 s
print s
get_prop 205 s
print s
get_prop 205 s
print s
get_prop 205 s
print s
get_prop 205 s
print s
get_prop 205 s
print s
get_prop 205 s
print s
get_prop 205 s
print s
get_prop 205 s
print s
get_prop 205 s
print s
get_prop 205 s
print s
get_prop 205 s
print s
get_prop 205 s
print s
get_prop 205 s
print s
get_prop 205 s
print s
get_prop 205 s
print s
get_prop 205 s
print s
get_prop 205 s
print s
get_prop 205 s
print s
get_prop 205 s
print s
get_prop 205 s
print s
get_prop 205 s
print s
get_prop 205 s
print s
get_prop 205 s
print s
get_prop 205 s
print s
get_prop 205 s
print s
get_prop 205 s
print s
get_prop 205 s
print s
get_prop 205 s
print s
get_prop 205 s
print s
get_prop 205 s
print s
get_prop 205 s
print s
get_prop 205 s
print s
get_prop 205 s
print s
get_prop 205 s
print s
get_prop 205 s
print s
get_prop 205 s
print s
get_prop 205 s
print s
get_prop 205 s
print s
get_prop 205 s
print s
get_prop 205 s
print s
get_prop 205 s
print s
get_prop 205 s
print s
get_prop 205 s
print s
get_prop 205 s
print s
get_prop 205 s
print s
get_prop 205 s
print s
get_prop 205 s
print s
get_prop 205 s
print s
get_prop 205 s
print s
get_prop 205 s
print s
get_prop 205 s
print s
get_prop 205 s
print s
get_prop 205 s
print s
get_prop 205 s
print s
get_prop 205 s
print s
get_prop 205 s
print s
get_prop 205 s
print s
get_prop 205 s
print s
get_prop 205 s
print s

end

 

[SteveH]

I would love to be able to set the picture size on my S3 IS to a 3:2 ratio as I do a lot of album stuff in 6 x 4 inch (15 x 10 cm) size.

Can this be done?

p.s. been using the hack for some months now and very pleased with it - thanks
p.p.s just about to load a later version

--
Steve
Zurich, Switzerland
Canon 350D & S3 IS
http://www.pbase.com/steveh

 

[aeropic]

I go on thinking 205 is the right indicator for shoot_full. Don't you
think so ?

In complement, I did some more experiments. The behaviour of 205 is consistent in P Av Tv modes. I get the same durations for 205 set to 1 whatever the mode as long as the shoot condition are the same (exposure and speed).

The results (205 set to 1) are identical with or without focus locked (MF or auto focus) only the duration of 205 set to 0 before the 1 phase differ in that case.

Other findings are that in M or AUTO modes, 205 is erratic. Sometimes the one phase is present, sometimes not. Thos can be found too in the bracketing script. It works 100% in Av, Tv, P modes and often fails in M and AUTO ...

So it seems that 205 in correlated to both shoot duration AND exposure measurement ...

Strange isn't it

Alain

 

[Divalent]

For a brief moment us script/property case guys thought we found a
reliable indicator of when the camera was ready to take another image
(property 205). However, it seems that that is not the case.

trying to work on the 205 prop, I've the feeling that, at least in MF
click shoot_full conditions, 205 is directly connected to the
duration of shoot and not to the AE setting.

I go on thinking 205 is the right indicator for shoot_full. Don't you
think so ?

That may very well be the case, except it doesn't really make sense. But then who said it had to make sense?

why have a property that says "I am ready to shoot again" that is only active after a "click shoot_full", but not a "shoot". OTOH, it doesn't reliably mean "I got the exposure figured out" either, because it doesn't change at all when you do a "shoot".

Your script could work because it is telling you what you need to know ("I'm ready again"), OR whatever it is saying just happens to occur reliably at the same time the camera is ready again.

I suppose from your perspective, it doesn't really matter, as long as the script works and your photos get taken in quick succession.

It would be interesting to try your script in low light conditions where it is taking a 1-2 sec image, as well as performing a dark frame subtraction. Does 205 remain set (1) for the whole duration (or does it return to 0 after 400 msec).

Anyway, I'm convinced there must be a more general purpose signal available that would work regardless of the triggering and imaging conditions.

Thanks again for all your work on this. Hopefully we will be able to figure this 205 out (and hopefully find a more generally useful "I'm ready" signal).

Divalent

 

[Dave Ingols]

Hopefully we will be able to
figure this 205 out (and hopefully find a more generally useful "I'm
ready" signal).

Divalent

I think you're on the right track about the writing to card thing. Since many delays are also dependent on the write speed of the card. I also think these memory locations are known well by the head gurus. Like when GrAnd (or was that Vitaly?) put in the blue LED signal (on S3s) for writing the RAW files to card. It'll just take a while for them to see the plea for this "get_cam_ready x" command (may not be available by a prop ID). Or even one that doesn't need a time-consuming 10ms per line loop, just a simple "ready_go" wait and release command on one line. A shame that it wasn't as simple as the 205 one. It looked so promising. On the bright side, look at how much you are discovering in pursuit of it. That's how I try to see these things when they happen to me.

 

[Divalent]

I would love to be able to set the picture size on my S3 IS to a 3:2
ratio as I do a lot of album stuff in 6 x 4 inch (15 x 10 cm) size.

Can this be done?

FWIW, I tried setting property 24 to "16" and when I took a picture the camera crashed. (had to power down then power up). Prop 24 is 0,1,2,4,8 for the different image modes, so the pattern looks like n^2 for succesive modes; hence the reason I tried "16". I didn't try any thing else.

Feel free to play with it (at your own risk, of course

Divalent

 

[Dave Ingols]

REPOST (sorry, dpreview timed out my editing time on a re-edit, here's my post in full

Hopefully we will be able to
figure this 205 out (and hopefully find a more generally useful "I'm
ready" signal).

Divalent

I think you're on the right track about the writing to card thing. Since many delays are also dependent on the write speed of the card. I also think these memory locations are known well by the head gurus. Like when GrAnd (or was that Vitaly?) put in the blue LED signal (on S3s) for writing the RAW files to card. It'll just take a while for them to see the plea for this "get_cam_ready x" command (may not be available by a prop ID). Or even one that doesn't need a time-consuming 10ms per line loop, just a simple "ready_go" wait and release command on one line. A shame that it wasn't as simple as the 205 one. It looked so promising. On the bright side, look at how much you are discovering in pursuit of it. That's how I try to see these things when they happen to me.

p.s. MX3, It's nice to see you are still working on optimizing the motion-detect feature, especially how much that kind of thing would make lightning photography even more reliable. It might even be able to be used to trigger on pre-flash modes on banks of slave-strobes so you could get extra available light from flash units. I always see pre-flash as such a waste of valuable light going nowhere. I think since you rushed so much to get us a working version (and one that works so phenomenally too), that we are more than patient to wait for when you have more time to work on it. We were just worried you might disappear after your announcement of "I got one working!" and that's all we'd ever know about motion-detection ever existing. So yes, please do keep working on it when you have the time. I'll try to be patient to see what next neat thing you come up with.

Now if the head uBASIC gurus could just extend the variables to 2 letters, like xa, xb, ... (or letter-number format, like x(1), b(3) which might be better to use in short arrays?) instead of one character, as I requested many ages ago. The motion detect command can eat up the few variables we have really fast if you need to set all its features. I recall having to get super creative on one script just to make it work with the 26 variables allowed, and had to leave out some routines I wanted because I ran out of them. Psssssst... Fingalo? Hey buddy! Did you manage to see this?

 

[Dave Ingols]

I think the best bet for this is still going to be using a grid for composition (to make sure you're not cutting off ears or heads from your desired format ratio), and then using a batch mode in any decent editor that will allow you to design custom cropping routines. The crop routine matching your grid file that you used while taking the photos. I don't think this is even available in the new $12,000 DSLRs that are coming out. They just provide composition masks just like CHDK already has and then still relies on post-process editing to get your desired format. (The $12,000 DSLR having only 6 composition masks at that, how pathetic! )

The Great Karnak Predicts! ....Cropping/Grid coordination system: setting a filename flag (like IMGX1234.JPG, the letter X being the assigned crop grid you used, giving you 26 optional cropping formats) so a batch cropping utility will just go through all your photos and select the right crop mask to match the one you used when taking the photos.

I'm not the one that's going to write that, but sure would be nice, and so many already have demanded/NEED this so many times, it's bound to happen.

 

[emu]

From all that CHDK stuff your motion detection is the most inovative idea - I hope you make it to your goals and I'm realy looking forward to a faster motion detection. Thanks a lot for your work!

My question: I can't get the script working with display off ( to save battery power) - is it possible?

 

[Divalent]

Alain,

I did a 1 sec exposure and 205 remained "1" for about a second longer than it did when I did a 1/60sec exposure, as you would expect it to do if its telling us "i'm ready again".

BTW, total time from "click shoot_full" to reset of 205 was 1.04 sec for 1/60 sec exposure, and 2.7 sec for the 1 sec exposure (it didn't even go to 1 until more than a second after the shoot_full on the long exposure, vs 400 msec for the 1/60 shot). (all this in Av mode, with MF set as in your script).

So, regardless of what it is telling us, it looks like it is close enough for your purposes.

Cheers,

Divalent

 

[microfunguy]

1. Do you know of any flag set in the camera somewhere that may
indicate this information? (And if so, how can a script access it?)

Well, there is a 'raw data available' flag that is reset to zero as soon as the image is saved (or immediately if raw image not required).

I added a script command 'raw_available' to report the status of that flag.

I do see 0's and 1's printed but basically ... it does not work :-(

When a raw file is being saved the blue led is lit.

It is trivial to alter the code so that the blue LED is lit when you enter that code (even if you are not saving raw) and turns-off when complete.

Some simple electronics can trigger on the blue LED turning-off and and generate a pulse to switch +3V to the USB connector.

I don't have any phototransistors or photodiodes right now to try it.

If you have a camera supported by the USB remote you can alter the code or I can alter it for you to try.

David

 

[Dundee31416]

I see that there are some scripts for the G7. Are they supposed to be compatible on the G9? Or is there anything for the G9?

 

[Dave Ingols]

I see that there are some scripts for the G7. Are they supposed to be
compatible on the G9? Or is there anything for the G9?

Some of the newer Digic III cameras that Canon put out (like the G9, SX100, and S5 also) have had a particular menu item removed from these cameras. Making porting CHDK to them near impossible at this time. It could be something as simple as a filename change where it doesn't recognize the traditional firmware update files that all past cameras used. Until someone stumbles on a way to get that "firmware update" menu item to appear it doesn't look like CHDK will be portable to those models. So far I have run across postings that the G9, S5, SX100, and the S410 (Digic I), are four of the cameras that have been tested with the usual filenames and failed to have that menu item show up.

It may end up being something as simple as changing .fir to .udt (for update) to get the camera to see the files, or a particular button press sequence on startup. It's going to be winter and many people can't be out shooting photos with a lot of time on their hands. They might just stumble on the right combo one day when they have nothing better to do. Get enough people looking for the right combo and someone is bound to stumble on it by probability alone.

It's kind of a two edged sword-blade that Canon is gripping at this time. Deny people from using CHDK and they won't buy the newer cameras. Allow it and then Canon might have to come up with something even better than CHDK to encourage the next batch of sales. Personally I think they are losing sales by not allowing it. I for one would never buy a newer camera that can't use CHDK or any non-script-controlled camera, now that I've seen what can be done with it. Do you think the S6 IS will have motion detection modes in it? It better have them, or there's no reason I'd want to buy one.