Messages

Perhaps you could try to combine the focus stacking and focus peak features (this is just some wild idea):

Use the focus stacking feature to create a series of shots with different focusing distances. For each image in the stack, focused areas should correspond to zones in the scene that share the same distance to the camera (the focusing distance). Then, you could use the focus peak feature to grab those focused areas from each image, assign a proper grayscale color to each one, and merge them.

For a quick and dirty experiment, you do not need any modifications to ML, you can do most of the heavy work outside of the camera:

First, choose a nice scene, do a focus stack, and copy all the files to your computer. Then use enfuse to make a contrast-based fusing, and save all the masks; finally, use PS / GIMP / ... to combine those masks.

Just my two cents.

It can check and download the latest ML...

Can you expand on that please!? I am really tired of taking the card out of the camera to try each compilation...

..just wondering today.. any chance to get ML running on my plain old 350d?

I would not held my breath on that... even if it was technically feasible, I do not think there is much people interested in investing the amount of time it would need. Have a look to the CHDK's forum, there is a working hack for your camera.

I think there was a method to update the AUTOEXEC.BIN file in the card, without having to remove the card from the camera, but it was no longer functional; the link below portrays a method that could bring back something similar:

http://haxit.blogspot.ch/2013/08/hacking-transcend-wifi-sd-cards.html

Hi a1ex,

Just an idea...
would it be possible or practical to emulate a graduated ND filter in a new dual ISO mode? Let's say the top 1/3 of the image is in ISO 100, the bottom 2/3 is in ISO 800/1600, etc. You could move up and down the transition line with the joystick and the transition could be hard or soft (variable). You could emulate even a reverse ND for sunset shooting.
This would be a great advantage for landscape photographers who use filters to reach the proper results. And in this case we wouldn't have to deal with resolution loss and aliasing, etc. Only the transition area could be more problematic by using alternating lines of ISOs as today. So basically we would narrow down the usage of the current dual ISO mode with alternating lines to a small horizontal segment of the image, while the other parts of the image would be in 2 different ISOs.
I am curious about your thoughts on this.

Great work, anyway!

You can always emulate a GND from a "properly" (no highlights blown out) photograph in the computer; problem is that raising the shadows produces too much noise. But now that you can have files with a massive dynamic range, it is probably worthy trying again. At the end of the day, the results are going to be roughly the same, and much more versatile.

[I hope all Canon cameras work the same: this is what I learned from the 400D, but from my browsing of the ML source code, it seems to use the same method]

Both shutter speeds and aperture values (and even the ISO values, at least at the 400D) use the same algorithm: raw values are simply expressed in 1/8EV steps; and that means 1EV (or double exposure time) equals to increasing the value by 8, as you already know. Exposure compensation values follow the same pattern; and this is very convenient, as you can use plain arithmetics to work with exposures.

For the intermediate values, +1/2EV is naturally expressed as (base + 4), +1/3EV is (base + 3), and +2/3EV is (base + 5). Other values (base + 1, 2, 6, or 7) for exposure or aperture are just rounded to the nearest supported values; but they all work for ISO values (thus we have 7 intermediate ISO values for each EV increment in the 400D).

Hope this helps.

AFAIK, ML cannot (reliably) know the focal distance, thus I do not see how this could be implemented.

Just a comment to some suggestions posted here: if I have understood the problem correctly, this issue is not about camera movement (thus neither mirror lock-up or similar features will help), but about the air between the telescope and the sun acting as a distorting lens.

What the OP is suggesting is to monitor the sharpness of the image, using live view, and to fire a shot when a peak of maximum sharpness is reached; this would be quite similar to doing a focus trap using live view.

Hope this helps.

0xAF is probably the one who can explain this best, but I will try to throw some light here.

In 400plus, we have intercepted one of the intercommunication queues from the camera, thus our routine sees all the messages that some parts of the firmware send to other parts. One of those messages contains the information about the current exposure: shutter speed, aperture, ..., and the measured exposure compensation; the frequency of this message matches the frequency of updates to the viewfinder.

We store that value into status.measured_ec, and later use it in the AutoISO code.

Just for reference, this is how we did AutoISO + M in 400plus:

• * Only real ISO values are used (100, 200, 400, 800, 1600).
• * User sets exposure time and aperture, and 400plus chooses an ISO value to produce a perfect exposure (as close as possible to 0EV).
• * Using a combination of keys, user can define an offset value (+1EV, for example), so 400plus will select an ISO value that produces the desired exposure (+1EV), or as close as possible.
• * User can also configure a "relaxed" mode: in this mode, 400plus will let the resulting EV float to +/- 2EV before changing the current ISO value.

Hope this helps.

If time is not a constraint (their shipping is terribly slow), there are a couple of sites where these adapters are easy to find: http://dx.com/ and http://focalprice.com/; I also have several 10GB and 40GB PATA drives laying somewhere around here...

Perhaps you mean the AF-assist light? But on some (all?) cameras, AF-assist is done using the flash; however, there is the red-eye-reduction lamp, that is a separate white light.

We have something similar in 400plus: push a button, while in M mode, and the camera will change shutter speed and aperture to match the light in the scene; sometimes it's useful to get a "good enough" exposure quickly. But in our case, it is a one-time feature, you have to press it again if the light changes.

Cameras have a Bayer filter in front of the sensor (that monochrome Leicas lack), so each photosite receives only light from one part of the spectrum (color); you would need to remove such filter, and that cannot by done by software.

Perhaps you could try to explore QR codes...

Very interesting, many tanks!

Or you could use a plain intervalometer, configured with an interval just slightly larger than the machine's cycle; main problems is that your machine needs a stable speed, and you must precisely measure the cycle.

Thank's Edu,
Yes with this I have the numbers like in the screenshoot, but I wanted to have the more rounded and bigger one like Kelvin text, that's why I want to use bfnt_puts

Is there maybe a FONT_HUGE or some fontspec that works without use bfnt_puts?

that worked for me:

Code Select Expand


                        char msg[6];
                        snprintf(msg, sizeof(msg), "%d", lens_info.kelvin);
                        bfnt_puts("Kelvin", 320, 111, fc, bg);
                        bfnt_puts(msg, 300, 166, fc, bg);


Sorry, I though you where using "bmp_puts" instead of "bfnt_puts"... Anyway, "bmp_fprintf" does a "vsnprintf" and then calls "bmp_puts"; so what you do looks like the most natural thing, if there isn't a "bfnt_printf" available.

I'm having a little problem showing Kelvin values with this code:

Code Select Expand

bfnt_puts( lens_info.kelvin, 300, 166, fc, bg);
instead of numbers I got characters on screen, so probably it needs something like this:

Code Select Expand

int str = convert_to_string(lens_info.kelvin);
bfnt_puts( str, 300, 166, fc, bg);

but I don't know the correct name for convert_to_string or for the right way to do this.
Any help?

What you need is bmp_printf:

bmp_printf(uint32_t fontspec, int x, int y, const char *fmt, ...);

First parameters should be familiar to you; then comes a string with the output format, and then the values you want to print. The format follows the standard for the "printf" family. For example:

bmp_printf(FONT_SMALL, 0, 0, "%i", lens_info.kevin);

should do what you need (but I haven't tested it myself, however).

Correct, it's a common C mistake

There is a LOT of this in the code. I'm surprised ML doesn't crash instantly. Or are we missing something?

The compiler probably aligns every variable to a 4-byte boundary; so while the fourth byte is not properly reserved, it is not used, either.

I do not want to sound condescending, but side effects of those macros are well known; any developer should be aware of those effects, and code around them when necessary. Besides, I am not very versed on compilers, and do not know how exactly is translated into assembler the version you propose, but looks like it could be producing more code than strictly necessary.

Just my two cents...

Maybe in a few months I can join you at the port for the ML to 350D and 400D. For now I want to dedicate some time to my 40D. We can start this port to encourage other developers. I've seen a bit of the 350D boot. We can easily use the cache hacks, as I did in the 40D boot. After activating bootflag and have modified the boot to turn the LED's, other developers with less experience may feel encouraged to continue the work.

If you manage to make the cache hack work on the 350D, making it work on the 400D should be easy, no? That would be awesome!

What are the skills that you already have on the 350D?

Not much, in fact: I'm on the project for the 400D, and we've obtained lots of info from the hack for the 350D.

The 350D and the 400D are very similar: they share lots of addresses, constants, calls, structures, ... . When you look for info about the internals of the 350D, have a look at the 400plus project, you'll probably find lots of info there. Besides, you might want to contact user 0xAF: he owns a 400D, and is interested in porting ML to that camera.

Yes, you don't waste time building it. A self-built toolchain may compile faster on YOUR machine but the gain is really minimal

Ok, many thanks!