350d boot from cf card

a1ex

If the 350D uses intercom for changing camera settings, 400plus is a great choice.

If it doesn't, but it has prop_request_change (pRequestChange) and similar property stuff, you may consider porting the 5D classic ML.

Either way, high level stuff is similar in many cases, we are exchanging code with them. FIO, GUI, task API, properties, state objects and most other low level things are identical or very similar from 5Dc (digic II) to 5D3 (digic V).

GUI stuff shouldn't be a big problem, bitmap buffer should be easy to find (Coutts can help here).

If you need to restore the hack after formatting the card from the camera, ML does that, look in bootflags.c and debug.c. FAT16/32 code included, you only need to find how to do low-level I/O on the card and a place where to copy the files temporarily. You can't just write the RAM copy of autoexec, as it contains some variables too, not just read-only code.

We couldn't trigger bulb exposures in 5Dc.

Hope this helps.

zestoi

a1ex
If the 350D uses intercom for changing camera settings, 400plus is a great choice.

yep, we have a function called SendToIntercom() that 400plus also uses.

GUI stuff shouldn't be a big problem, bitmap buffer should be easy to find (Coutts can help here)

cool. i may give it a go then. he's on this forum? i really don't know how many people are still using 350d's but it'd be an interesting project anyway.

If you need to restore the hack after formatting the card from the camera, ML does that, look in bootflags.c and debug.c. FAT16/32 code included, you only need to find how to do low-level I/O on the card and a place where to copy the files temporarily. You can't just write the RAM copy of autoexec, as it contains some variables too, not just read-only code.

cheers - i'll grab the ML code then and have a dig...

We couldn't trigger bulb exposures in 5Dc.

ah ok... i've seen that 400plus has defined a shutter_release_bulb() function that ends up calling IntercomHandlerButton() in the firmware. we have a PressButtonHandler() defined in funclist.txt. how would i go about seeing what it does etc or what the function signature may be? name sounds similar to the 400plus one. don't mind too much if i brick my 350d tho would mean an end to my hacking fun with it...

Hope this helps.

indeed it does 😉 are there tools that help with the creation of the funclist.txt file? i presume people don't manually look for functions in each firmware dump?

a1ex

I use this to browse the firmware: http://magiclantern.wikia.com/wiki/GPL_Tools/ARM_console

Most functions can be found from strings. Others can be found by similarity with other firmwares (e.g. called from the same place), or just... you figure out what it does. Small ones can be decompiled. The firmwares from different cameras are very similar in many places, so you can find them just by comparing 350D with 400D firmwares, for example.

Coutts is more active on the ML forum, he has a 5Dc now, but he inspired a lot from the 350D hack, especially with the boot process. I have yet to look inside the 350D firmware.

There's lots of info floating around, feel free to browse and try things. Be careful with changing camera settings, they are persistent and there's no easy way to reset them if something goes wrong. Many things can be ported from compacts or from newer DSLRs.

I think you can use the 5Dc graphics routines for drawing on the screen. I remember 400plus guys also tried them, but I'm not sure if they are present in the main source tree.

About bulb exposure, once you figure out how to trigger it, should be easy to do some manual ramping. And even if the timing won't be perfect, you can solve that in post. I'm writing a deflickering script here: http://www.magiclantern.fm/forum/index.php?topic=2553

eduperez

a1ex
I think you can use the 5Dc graphics routines for drawing on the screen. I remember 400plus guys also tried them, but I'm not sure if they are present in the main source tree.

Yes, it is in out main source tree; we have only used it experimentally so far, but it seems to work as expected.

xbrav

Thanks for the amazing updates! How difficult would it be to add an option to control exposure time?

crazyklaus

xbrav
Thanks for the amazing updates! How difficult would it be to add an option to control exposure time?

what exactly do you mean with that?

I'm back from vacation and while there I've played a bit with the timelapse function for the first time.
It's much nicer than I thought. I can remember that the code is not nearly as elegant as I would have liked when I wrote it, but it works quite reliably.

It's especially nice for self shots/group shots with a tripod - a very convenient and practical alternative.

I didn't have any problems with the relatively high power consumption because I run my camera from an external battery pack that gives me A LOT of shots.

xbrav

crazyklaus
what exactly do you mean with that?

I didn't get a chance to dig into the code, but is it possible to code in an exposure control beyond 30 seconds?

Sergei

zestoi
ah ok... i've seen that 400plus has defined a shutter_release_bulb() function that ends up calling IntercomHandlerButton() in the firmware. we have a PressButtonHandler() defined in funclist.txt. how would i go about seeing what it does etc or what the function signature may be? name sounds similar to the 400plus one. don't mind too much if i brick my 350d tho would mean an end to my hacking fun with it...

I think you can use SendToIntercom(0xB6,0,0); In 400d 0xB6 and 0xB7 are codes for remote control buttons.
Camera must be in Tv or M mode and shutter set to "Bulb".
SendToIntercom(0xB6,0,0); // to open a shutter
SleepTask(long_exposure_time); // exposure time
SendToIntercom(0xB6,0,0); // to close a shutter

cobarcore

I'm back after a month reporting that, thanks to a friend, my 350D is working again. 🧑‍🎄 He substituted the broken shutter with one of another dead 350d. CHDK is still working and I'll try to update to the last version.

I've also made some testing, measuring gain and read noise from 100 to 3200 ISO. I remember to have read that 3200 ISO is not a true sensitivity, since the amplifier gain is the same of 1600 ISO and only the values are doubled via internal software. But from the measurements, the gain at 3200 is a factor 2 different from 1600, so it seems that 3200 ISO is a real sensitivity. Any comment?

cobarcore

I'm trying the new version, very nice the EAEB function with a large number of frames!

But I've found that it does not work very well:
- not working with "M" mode.
- working with AV, but this imply that if the subject changes brightness, the sequence will not be correct.

Any idea to get a continuous sequence of increasing exposure times?

cobarcore

crazyklaus
the 3200 is software pushed, so there shouldn't be a difference.

According to my measurements of gain, 3200 ISO should be real. Do you have any source for your statement?

eduperez

cobarcore
According to my measurements of gain, 3200 ISO should be real. Do you have any source for your statement?

According to my investigations with the 400D, internal codes for ISO values follow a 1/8 EV sequence, and the highest code accepted by the camera is 1600 + 7/8 EV; trying to set ISO to 3200 (using the code that really corresponds to ISO-3200) produces broken images. Then, if you have a look at 16-bit histograms of the resulting images, you'll notice gaps in all extended / intermediate ISOs; these gaps indicate that the image was pushed by software. And the pattern of those gaps in a (supposed) ISO-3200 image do not correspond to a ISO-3200 image.

cobarcore

eduperezAccording to my investigations with the 400D, internal codes for ISO values follow a 1/8 EV sequence, and the highest code accepted by the camera is 1600 + 7/8 EV; trying to set ISO to 3200 (using the code that really corresponds to ISO-3200) produces broken images. Then, if you have a look at 16-bit histograms of the resulting images, you'll notice gaps in all extended / intermediate ISOs; these gaps indicate that the image was pushed by software. And the pattern of those gaps in a (supposed) ISO-3200 image do not correspond to a ISO-3200 image.

Thanks for your reply Eduperez! Your point is very good, and now I've verified on my images the presence of the gaps in the histogram at 3200 ISO, as you wrote.
So the conclusion should be that the image at 3200 ISO is obtained from an image at 1600 ISO that is multiplied by 2.
Ok, this was also my thought, but I'm wondering why the measured gain at 3200 ISO is not the one at 1600 ISO. Here are my gain measurements on a 350D: http://www.astrosurf.com/comolli/strum154.png

crazyklaus

cobarcore
I'm back after a month reporting that, thanks to a friend, my 350D is working again. 🧑‍🎄 He substituted the broken shutter with one of another dead 350d.

good to hear you have a working cam again 😀
was this the first time that you had to replace the shutter?

cobarcore

crazyklausgood to hear you have a working cam again 😀
was this the first time that you had to replace the shutter?

Thanks! Yes, first time. At 158k shots I cannot ask more...

crazyklaus

definitely not, the rating for the 350D is 50k

cobarcore

@ eduperez: in addition to my other reply, I've looked at the histograms of:
350D: 3200 and all intermediate 1/3 stops have gaps in the histogram
5D (old): 3200 has gaps, but all intermediate 1/3 stops no. (3200 is extended sensitivity, enabled by standard custom funtions)
60D: all sensitivities have no gaps, also the extended one at 12800 ISO.

So it seems to be no rule for understanding what is true and what is software. Any idea?

crazyklaus

since the 350D's 3200 is enabled by a hidden custom function, and the 20D goes to true 1600, and extended 3200 with custom function I've always assumed the 350d would be the same.

if the 350d had true iso 3200 that would be quite an anachronism. even the 450D and the 40D only go to 1600.

eduperez

My findings on the 400d (and I very much doubt the 350D is different about this):

* Only "official" ISOs (100, 200, 400, 800, 1600) are "real" (hardware-based); all other intermediate / extended ISOs are software-based. This can be noticed easily in high-resolution histogram.

* ISOs increment in 1/8 EV values, but the camera displays only 1/3 increments (the same goes for the value recoded in the EXIF tags inside the image). If you make a sequence of images, going from ISO 100 to ISO 200 for example, you'll see how the light increases constantly [this makes a lot of sense, by the way, because multiplying by 1/8 can be done quite easily, using only fast integer arithmetic (and the hardware does not support floating point)].

* Working values go from ISO 100 to ISO 3000; any value below ISO 100 or above ISO 3000 produce broken images. Notice that ISO 3000 is displayed as ISO 3200, and there is little difference in the result; thus some people assumed ISO 3200 was working, when in fact it was ISO 3000.

Hope this helps.

cobarcore

eduperez
* ISOs increment in 1/8 EV values, but the camera displays only 1/3 increments (the same goes for the value recoded in the EXIF tags inside the image).

And so the intermediate iso settings in 350D chdk, such as 1000 and 1250 ISO, not only are software computations from an acquisition with gain set to 800 ISO, but they are also not 1000 and 1250 (not rounded value are 1008 and 1270 ISO), but maybe 800+3/8EV(=1037) and 800+5/8EV(=1234ISO). Is this correct? Is +3/8 and +5/8 EV the numbers programmed in CHDK?
The numbers above are also very similar to the one I've found from the gain measurements (see http://www.astrosurf.com/comolli/strum154.png ).

eduperez If you make a sequence of images, going from ISO 100 to ISO 200 for example, you'll see how the light increases constantly

I'm not able to try this since in the CHDK only 1/3 EV increments are possible in the ISO setting.

eduperez* Working values go from ISO 100 to ISO 3000; any value below ISO 100 or above ISO 3000 produce broken images. Notice that ISO 3000 is displayed as ISO 3200, and there is little difference in the result; thus some people assumed ISO 3200 was working, when in fact it was ISO 3000.

Very interesting, so 3200 is instead 2934 ISO. This also explains the gain measurement in the linked graph, that is a little above the interpolating line.

Thank you very much for your very helpful post!

« Previous Page Next Page »