[Eruditass]

In theory, the camera could decouple the mirror and aperture travel between exposures. Shutters might also be designed to operate in both directions so that there is no need to "cock" the shutter between exposures.



Steve

It'd be hard to follow the action without the mirror flipping back, but this would be a great 2nd option.

[interested_observer]

Actually, it starts way before any of these - at the time of the initial system architecture and design. Using market analysis to define the overall functionality of the camera, you would start off with what you want it to actually be when completed.

The mirror and shutter assembly would only be the front end and mechanical assemblies, and yes there would be a physical limitation on how fast they can operate. But the real concerns are the sensor, sensor design, and the image processing pipeline software run in the processor. All of this is of course battery dependent, since you want to maintain the life of the battery charge over a reasonable number of images. So you start off with your battery budget and sensor size. Every component has a power budget that needs to be maintained. You also need to have a reasonable idea as to the amount of software processing that needs to be done (worst case, high resolution, high sharpening, high noise reduction, etc.) in order to correctly size your processor in terms of processor speed (the higher the speed, the more power it will consume per image) which maintains the image thruput processing. Also, you need to determine your buffer size in terms of buffering up a number of shots waiting to be written to the SD card (and this is SD card dependent), and also the amount of time required for either RAW, JPG or both.

Then in parallel with all of that, is the cost factors, along with parts availability. System architecture and design are refined and modeled, requirements written and refined, which flow into hardware and software being design and then developed and module tested on parallel tracks. Each of these activities are brought together in system integration and test, where the results are compared to the requirements/specification and the modeling results. There will be obvious problems - both functional and performance. These will be identified and reworked to varying extents in order to meet functional and performance requirements.

I tried to make it easy, but there are also custom FPGAs and or ASICs that are very custom parts that contain specialized hardware that is programmable is such a way as to speed the processing in ways that a general purpose processing chip could never compete with. This way you can speed up the processing and pull down the power requirements to a certain extent.

This is the general process for a reasonable new product development. To the extent existing designs are available and appropriate they are reused - which generally speeds the process along. Also, existing prototypes would also assist and accelerate the overall process too.

hope that helps...

[Glen_S]

I'd like my K10's continuous fire a lot better if I could somehow stop it from trying to fine tune the AF between frames (without going to complete MF). This surely has to be doable through the software/firmware I would think.

I was sitting out on the lake in a canoe last year getting pictures of Osprey's diving after fish, I was shooting with my 18-250 and getting some pretty good frames (thinking about investing in long fast prime glass just for this purpose), but I found I missed a lot of shots because the camera was trying to fine tune the focus between frames, which resulted in 1.? fps a lot of the time. When the target is >150 meters away I don't think this is really neccessary.

I switched to mf for awhile, but as soon as I did that a big bird would hit the water at 1/2 the distance of the previous shot and I'd be fumbling with the focus and barely get a shot or two off.

My wife(s) Kx seems to pick the focus for the first frame and keep it, resulting in anywhere from 5-10 frames to choose from when the K10 might give me 2-5 in the same time period. She has managed to get some spectacular shots of birds in flight around our many feeders, and she is a very neophyte SLR user.

I'm looking forward to trying her Kx out on the lake when I can catch a time where several Osprey's are hitting the water for fish.

[Marc Sabatella]

I'd like my K10's continuous fire a lot better if I could somehow stop it from trying to fine tune the AF between frames (without going to complete MF). This surely has to be doable through the software/firmware I would think.

It's already done. Prefocus however you like - auto or manual, then stick your thumb on the AF button (OK button on some models) to temporarily cancel AF. Assuming you've configured the button to work this way in your custom options.

Actually, though, is this even necessary if you're using AF-S? I never use continuous shooting so I'm not up on the ins and outs of it. But I am a heavy user of the OK button on my K200D to temporarily cancel AF and thus avoid the need for refocus between shots, even when in single shot mode.

[Lowell Goudge]

Actually, it starts way before any of these - at the time of the initial system architecture and design. Using market analysis to define the overall functionality of the camera, you would start off with what you want it to actually be when completed.

The mirror and shutter assembly would only be the front end and mechanical assemblies, and yes there would be a physical limitation on how fast they can operate. But the real concerns are the sensor, sensor design, and the image processing pipeline software run in the processor. All of this is of course battery dependent, since you want to maintain the life of the battery charge over a reasonable number of images. So you start off with your battery budget and sensor size. Every component has a power budget that needs to be maintained. You also need to have a reasonable idea as to the amount of software processing that needs to be done (worst case, high resolution, high sharpening, high noise reduction, etc.) in order to correctly size your processor in terms of processor speed (the higher the speed, the more power it will consume per image) which maintains the image thruput processing. Also, you need to determine your buffer size in terms of buffering up a number of shots waiting to be written to the SD card (and this is SD card dependent), and also the amount of time required for either RAW, JPG or both.

Then in parallel with all of that, is the cost factors, along with parts availability. System architecture and design are refined and modeled, requirements written and refined, which flow into hardware and software being design and then developed and module tested on parallel tracks. Each of these activities are brought together in system integration and test, where the results are compared to the requirements/specification and the modeling results. There will be obvious problems - both functional and performance. These will be identified and reworked to varying extents in order to meet functional and performance requirements.

I tried to make it easy, but there are also custom FPGAs and or ASICs that are very custom parts that contain specialized hardware that is programmable is such a way as to speed the processing in ways that a general purpose processing chip could never compete with. This way you can speed up the processing and pull down the power requirements to a certain extent.

This is the general process for a reasonable new product development. To the extent existing designs are available and appropriate they are reused - which generally speeds the process along. Also, existing prototypes would also assist and accelerate the overall process too.

hope that helps...

while all of this is true and reasonable, at the end of the day the aperture and mirror are the short term limitations in burst mode.

Data pipeline, buffer size and all the other stuff is then designed to meet the maximum the mechanics will allow, not the other way around.

there is no point having a data pipeline, etc, that can run 20FPS when the shutter / mirror / aperture can't, it is wasted performance. the bottom line is that while there is perhaps a lot of other limiting things designed into the camera because of the mechanical limitations, redesigning the electronics without fixing the mechanics achieves nothing.

[simico]

the bottom line is that while there is perhaps a lot of other limiting things designed into the camera because of the mechanical limitations, redesigning the electronics without fixing the mechanics achieves nothing.

Unless liveview or video is used where mechanics and their limitations doesn't play

[Zav]

If the buffer needed to be larger why couldn't a high speed grip be offered with a additional RAM buffer in the grip?, maybe even offering an addiional processer and SD chip? Just a thought.

Shu

This is how the Nikon D700 grip works.

[Lowell Goudge]

Unless liveview or video is used where mechanics and their limitations doesn't play

true


An electronic shutter and a electronic fiew finder would eliminate all the mechanical delay issues, with the exception that after initial activation, you would be viewing in stopped down mode not open aperture. this would make AF difficult if not impossible if you were stopped down below F6.7, and image quality while viewing would be poor

Let's go back to the design concept of an SLR. AN SLR is an optical preview through the lens system, with open aperture viewing and metering.

we need to retain all these functions. so to do all of this needs the following if speeds increase

- replace the mirror with an electronically alterable reflective surface, so that the mirror is turned on/off with logic not mechanics, the challenge here is distortion of the light path.
- in the lens electronic aperture control.
- bi directional shutter, with no re cocking between frames
- faster electronics to deal with the higher data rate from the sensor

[shuie]

sounds similar to the fixed pelical mirror in the old cannons