Rockbox

The only feature that would have to be duplicated is to actually take a picture.

Yes, this is the "only" feature.

But if you thik about it, this "only" features is made of metering, reading image characteristic, focusing, face detection, driving the sensor, driving the display, reading the sensor, driving the DSP to process the image....

There is not a single byte of all the Canon's firmware that is not dedicated to "taking a picture"

To put it in another way, what parts of the features provided by Canon's firmware would you throw away?

A feature that you might find "discardable" might be important for someone else.

Even so, after all this work, we would have a camera that has some features LESS than the original Canon firmware.

Returning to the list of (sub)-features:
metering, reading image characteristic, focusing, face detection, driving the sensor, driving the display, reading the sensor, driving the DSP to process the image.

I have studied a bit the "metering" problem (apparently one of the simplest ones) and, believe me, it's bloody complex and nowhere on the web you will find a reference about it...

That's the main difference between an MP3 player and a camera: you find on the web hundreds of pages, algorithms and open source code on MP3 decompression, but I haven't found a single explanation about the metering algorithms to correctly expose a photo!

fbonomi, perhaps you missunderstood my intent.
I am not thinking about making a fully functional firmware replacement. This would be indeed very, very hard.
People that need metering, face detection (does anyone use that?), DSP processing and other features can just use the standard firmware.

What I have in mind is using the cameras for purposes that can not be done with the firmware and CHDK.

For example:
Lens removed, for microscopy or astrophotography.
WiFi, with an SD WiFi card. This can allow transforming a Canon camera into a remote webcam.
Advanced power control, such as placing the camera into a very low power state, for very long time time lapse photos.


For most of those things, only a few features are really needed:
Boot a kernel, allocate the memory, I/O and screen stuff.
Open/close the lens, operate the focus and zoom motors.
Power the sensor on/off.
Take a picture in RAW mode, no conversion/processing needed, as that can be done 'offline' on the PC.

Everything else is just 'optional'. For example the metering can be done manually.

One more advantage in having such a project is that it would be significantly easier to port it on other non Canon cameras, at least those that have an ARM CPU and have similar hardware.
Right now, CHDK is impossible to port on any non Canon camera. However, with a Linux (or even custom) kernel, a lot of the code would be the same, and only the code that needs to deal directly with the hardware would need adjustments. But even so, controlling the lens and the sensor should be similar between different camera brands, because the lenses and sensors are usually made just by a few companies, and all the cameras use similar hardware.

Quote

You are making unwarranted assumptions here.

How so?

Study the firmware until you figure it out.

Quote from: RaduP on 29 / April / 2009, 03:12:21

Quote

You are making unwarranted assumptions here.

How so?

Study the firmware until you figure it out.

Wow, that was very helpful..

For example the metering can be done manually

Ok, let's assume that.

WiFi, with an SD WiFi card. This can allow transforming a Canon camera into a remote webcam.

With manual metering?

Advanced power control, such as placing the camera into a very low power state, for very long time time lapse photos.

With manual metering?

Take a picture in RAW mode, no conversion/processing needed, as that can be done 'offline' on the PC.

Long timelapses made in RAW? there is no space on SD card.

You see, most of these "useless" features are important and required by each other. Take one away, and the camera becomes much much less useful.

I am not saying that it cannot be done, only that such a software requires a lot of work and gives benefits for very few people.

Moreover, it would be an expensive software, as it would make your camera unusable as an ordinary camera. BUT if you are really willing to throw away money for such a specific project (for example, for a very long timelapse), then there are other, simpler for the very specific project (for example, external power provided by 4 car batteries :-)

Quote

WiFi, with an SD WiFi card. This can allow transforming a Canon camera into a remote webcam.

With manual metering?

Yes, or some auto metering. It's not that complicated.

Long timelapses made in RAW? there is no space on SD card.

I totally disagree. A 16GB card can store more than 1K raws. Besides, for long time lapses, the raw to JPG conversion speed is not important, and there are algorithms that can do it pretty well.

You see, most of these "useless" features are important and required by each other. Take one away, and the camera becomes much much less useful.

As I was saying, you can still use the regular camera firmware, no?

I am not saying that it cannot be done, only that such a software requires a lot of work and gives benefits for very few people.

New features can always be added in time, and I think there would be much more developers if the cameras could run a normal OS.

Moreover, it would be an expensive software, as it would make your camera unusable as an ordinary camera. BUT if you are really willing to throw away money for such a specific project (for example, for a very long timelapse), then there are other, simpler for the very specific project (for example, external power provided by 4 car batteries :-)

Depends. Say you want to take a time lapse capture of a birds nest in a tree. Have fun putting 4 car batteries there.

Yes, or some auto metering. It's not that complicated.

It's not complicated until you try it. I tried it, and had to give up.
Find anyone that has done it, and published his results, and you will solve a problem that has been bugging me since months.

Quote

Long timelapses made in RAW? there is no space on SD card.

I totally disagree. A 16GB card can store more than 1K raws.

I am already doing timelapses with more than 1.000 frames with CHDK.
That's not what a I call a long timelapse, I am thinking of something like 10.000 frames.

Besides, for long time lapses, the raw to JPG conversion speed is not important, and there are algorithms that can do it pretty well.

Well, first you say conversion shouldn't be there, then you realize conversion should be there.
First you say metering shouldn't be there, then you realize metering should be there.
As I said before, list the features you would find acceptable to lose.
This can become a clear project to speak about.

Quote

You see, most of these "useless" features are important and required by each other. Take one away, and the camera becomes much much less useful.

As I was saying, you can still use the regular camera firmware, no?

I think it would be feasable (read: a few thousands of hours of work) to boot the camera with an OS that does basic I/O (SD, keys, display). In this case you have downgraded the camera to a very small computer.

But then, every other function must be coded.

You CANNOT call "fragments" of the original firmware without giving full control to the original software to do the start-up, like CHDK does.

Depends. Say you want to take a time lapse capture of a birds nest in a tree. Have fun putting 4 car batteries there.

Ehm... a long wire?
This is becoming surreal :-)

You see, I have started indeed working on a cabinet with two "hot-swappable" motorbyke batteries to indefinitely power a camera for very long-time timelapses.  A project like your would give me less features, not more features.

I am already doing timelapses with more than 1.000 frames with CHDK.
That's not what a I call a long timelapse, I am thinking of something like 10.000 frames.

By long, I don't mean big. I mean long. Stuff like a month or more. Long time doesn't necesarly mean many frames.

Well, first you say conversion shouldn't be there, then you realize conversion should be there.
First you say metering shouldn't be there, then you realize metering should be there.
As I said before, list the features you would find acceptable to lose.
This can become a clear project to speak about.

I didn't say no JPG conversion, I said that no need to do it in hardware.

You CANNOT call "fragments" of the original firmware without giving full control to the original software to do the start-up, like CHDK does.

I still don't think you get what I mean. Let me reiterate it: There is no need to boot Linux if you don't need Linux features.

A project like your would give me less features, not more features.

No, it would give you much more features, because you are not forced to use it, now are you?