Thread to collect easy firmware improvement suggestions (software feature requests)

**interested_observer** · 10-03-2016, 01:26 AM

Originally posted by Gimbal

That cannot be fixed in firmware, it’s a problem that occurs due to the wide rectilinear lenses distorting the image. Objects at the corners are stretched out by the lens compared to similar objects in the center of the image. If we are shooting stars that is not a problem as long as the stars in the corner stays in the corner, as they do if you use a barn door tracker, or equatorial mount.

But if the lens and camera doesn’t rotate as when using the built in astro tracker, the stars will move from the corners into the center and then out again. And while dong so they will appear to change speed due to the distortion that enlarge them in the corners. In other words, they will appear to move faster in the corners.

You get the same thing if you do a long exposure without using the astro tracker, the trails will be longer in the corners.

Gimbal - I guess we are just going to agree to disagree on this topic. Pentax designed their system, they know what the weaknesses are, however they have not disclosed any real technical information about it, hence what the problem is. They are just not saying anything. Unfortunately, AstroTracer is too nice a feature to suffer this fate.

Gimbal · 10-03-2016, 03:42 AM

Originally posted by interested_observer

Gimbal - I guess we are just going to agree to disagree on this topic. Pentax designed their system, they know what the weaknesses are, however they have not disclosed any real technical information about it, hence what the problem is. They are just not saying anything. Unfortunately, AstroTracer is too nice a feature to suffer this fate.

I guess so.
But you do realize that wide rectilinear lenses distort the image? A star that appears to move say 4mm in the center of the frame during a certain shutter speed, will move 6mm if you reframe so that star sits in the corner for the same time. (The numbers are of course just examples taken out of the blue to illustrate the problem.)

**interested_observer** · 10-03-2016, 07:13 AM

Originally posted by Gimbal

I guess so.
But you do realize that wide rectilinear lenses distort the image? A star that appears to move say 4mm in the center of the frame during a certain shutter speed, will move 6mm if you reframe so that star sits in the corner for the same time. (The numbers are of course just examples taken out of the blue to illustrate the problem.)

Yes, a wide rectilinear lenses will distort the image. However, the real question here is to Pentax. Please identify your sources of error, to what extent do they contribute to the overall problem and for each source - how is the error manifest/realized in the resultant image. AstroTracer is a closed black box system. We know the generic inputs, we just do not know the quality (accuracy and precision) of the inputs (for instance the compass). Are there limitations to the system? - absolutely! We know that exposure time is one (Pentax has limited that to a maximum of 5 minutes based on focal length), and that times of less than a minute minimize star trailing. That is a substantial difference. Through observation (actual use) elevation angles beyond 45 degrees produce degraded results, and Pentax should acknowledge and quantify that. Your position is that wide rectilinear lenses is a major contributing factor - OK, Pentax needs to characterize and quantify that aspect (what focal lengths minimize trailing). My position has been that the compass has limitations and needs to be characterize and quantify - and potentially address how an extended calibration process may help to control this.

Once sources of error have been identified, characterize and quantify and their effect/how they will be manifested in the resulting image - Pentax should be able to advise possible approaches to reduce or to minimize their effects. They have done this in one area - fine calibration should not be done near large metal objects - cars. They can also update the system - either in firmware (to the extent possible) or with new hardware (camera bodies - for instance the K1 and its new 5 axis stabilized sensor).

Pentax can also publish a technical paper addressing their overall system in a more technical environment than what they currently have. A several page paper addressing the system, inputs, characterized errors, what and how users can assist in their minimization, etc. For instance - a discussion on exposure time, focal length, are a couple - and there are several more.

Pentax has modeled the GPS system. Addressing the model (to the extent possible) along with its implementation within the actual device (O-GPS1/K3II/K1) utilization would do a great deal in addressing this topic.

Quite frankly - I don't want to do it. Users should not have to reverse engineer a system in order to use it effectively. I retired several weeks ago and just want to go take pictures and improve my composition. My days of system architecture and engineering to a large extent are in my past. I have done several star tracking systems - across a wide range of uses - (hybrid combinations of GPS, inertial and celestial) from sub-orbital navigation, orbit insertion, station keeping and re-entry, to even a little telescope down in Texas.

Right now, I am trying to decide if the weather is good enough to drive up to Flagstaff today to shoot the fall colors up in the alpine meadows. My only concern right now is aspen, birch, maple and oak.

Gimbal · 10-03-2016, 07:59 AM

But the problem you mention in the first post with trailing in the corners and perfect point like stars in the middle, this happens even when the astro tracker works perfectly. And that phenomenon cannot be compensated for by merely moving the sensor.

But then of course the performance is also limited by sensor input as you write, and one of the weakest sensors seems to be the compass. At least in my K-1 unit. My OGPS-1 is a lot more accurate, possible due to the sensor sitting further away from the SR unit? (which has at least four really powerful magnets built in.)

One problem which is new with the K-1 model is that the compass bearing is affected by the position of the foldable LCD. Only in some directions though, but in those directions the effect is quite strong.

**interested_observer** · 10-03-2016, 09:12 AM

As you noted, the body taken as a system as a whole - does have a number of competing technologies used for a range of applications. In terms of the astrotracer, what provides its principal enabling capability - the (magnetic field) floating sensor, is also one of the main sources of potential interference with the electronic compass, as well as the articulating screen. I am sure that there are others based on the various implementations (the o-gps1 as well as the new integrated body models).

That is why some discussions from Pentax, would certainly help. In terms of firmware and potential updates, perhaps after a successful fine calibration process, pointing the camera in the direction of its main use, and using a reading from an external compass to provide an additional input (or 2+ - say several pointing calibrations) as a base bias to the system may help. Maybe, adjusting the articulating screen in its anticipated position of use may help - who knows? All we are doing is taking some semi-educated guesses.

This approach to star tracking - essentially a reasonably pure computational design approach, has not really been implemented (well at least as consumer product) before. Folks actually doing astro (wide field, deep sky) and astrolandscaping are reasonably technical. Putting out a technical whitepaper and promoting some discussion within the community would certainly help with the results, but also be a good positive marketing approach. If done right, it would be to both Pentax's - as well as the user communities' benefit. In the end, the astrotracer is going to be judged on the results it's able to obtain. Informed users are only going to be to Ricoh/Pentax's benefit.

MJKoski · 10-03-2016, 10:00 AM

UWA Trailing is symmetrical with point stars in the middle. Miscalibration causes trails and blur in the middle as well. Just stuff UWA lens to your camera and pan around the room with live view -> images edges seem to move lot faster than the middle region.

**mattb123** · 10-03-2016, 10:13 AM

I'd like to see a 2s timer mode with bracketing that only does the 2s delay on the first shot of the bracket. I see no point in 2s before each exposure of the group. (K-5, K-3, 645D, K-1)

TheOneAndOnlyJH · 10-09-2016, 08:23 AM

Originally posted by mattb123

I'd like to see a 2s timer mode with bracketing that only does the 2s delay on the first shot of the bracket. I see no point in 2s before each exposure of the group. (K-5, K-3, 645D, K-1)

Best would be to set both custom initial delay and interval between shots separately. For example, 10s so you could get in position and then 1s between exposures so you don't have to wait.

**interested_observer** · 10-09-2016, 04:08 PM

Buffering - Right now Pentax implements a linear FIFO (first in first out), that holds on the order of 20 something images (both model and image format(RAW/JPG) dependent). When you fill it up, it then takes 30 seconds for it to be cleared. Then its ready to wash and rise again.

Modifying the buffering to a circular buffer would be straight forward and easy. It is just a case of pointer management - which is extremely quick and straight forward to perform. There really is no real reason to take time to clear the buffer. It would essentially be endless if the SD card's write speed was similar to the burst speed of the camera ~ 7 frames per second. There are SD cards that are substantially faster.

joergens.mi · 10-10-2016, 06:41 AM

Originally posted by interested_observer

Buffering - Right now Pentax implements a linear FIFO (first in first out), that holds on the order of 20 something images (both model and image format(RAW/JPG) dependent). When you fill it up, it then takes 30 seconds for it to be cleared. Then its ready to wash and rise again.

Modifying the buffering to a circular buffer would be straight forward and easy. It is just a case of pointer management - which is extremely quick and straight forward to perform. There really is no real reason to take time to clear the buffer. It would essentially be endless if the SD card's write speed was similar to the burst speed of the camera ~ 7 frames per second. There are SD cards that are substantially faster.

That may be a possible solution. But the write speed of the camera hardware is limited to something between 25 and 30 MBytes per second, therefore the buffer will fill up with 6.5 pictures a second. The question is not the maximal possible write speed of the cards but the maximum write speed of the camera.

Your suggestion may be right if the buffer is static in size, but i assume that it will be dynamic and the pictures are stored in a compressed format (because pef/dng stores lossless compressed) to make maximal usage of the buffer.

**interested_observer** · 10-10-2016, 10:24 AM

Originally posted by joergens.mi

That may be a possible solution. But the write speed of the camera hardware is limited to something between 25 and 30 MBytes per second, therefore the buffer will fill up with 6.5 pictures a second. The question is not the maximal possible write speed of the cards but the maximum write speed of the camera.

Your suggestion may be right if the buffer is static in size, but i assume that it will be dynamic and the pictures are stored in a compressed format (because pef/dng stores lossless compressed) to make maximal usage of the buffer.

It's not only a possible solution - it's the best solution and optimal. In terms of write speed, all the card has to do is to keep up with the camera. Most cards today, can meet the 30 MB/s thruput. If they can't, it will take a few trips around the queue until you run in to the pointer overrun condition, in which case, your queue emptying rate will be regulated by the card's write speed - which is OK. You are still going to get, probably 2x to 3x the queue size (number of images) out as an initial burst, before slowing down. The absolute worst case for a glaicerly slow card, would be 1x the size of the queue - but would not suffer the 30 second cleaning and reset delay, as is the current case.

In terms of the sizing of the individual cells, all you need to do is to size them to the maximum of a PEF/DNG image (plus the size of a pointer), then have a pointer at the top of the cell that points to the end of the variable length image (essentially a single unit linked list - another classic optimal solution). You will not be using all of the cell for each image, there will be a bit of wastage, however this will yield about the same number of images, and more importantly - be quicker to both fill and empty, again with out the prolonged delay.

A circular buffer is a classic solution, both well known and understood - Knuth, Volume 1 (anyone with a Computer Science or Software Engineering degree will understand the citation). Actually, I am willing to send my own personal set to Pentax if necessary. Heck, since my set is the original 1st edition (3 volumes), I'll spring for the brand spanking new 4 volume, 3rd edition.

One possible reason why they haven't implemented this (or a similar) solution, is that it may increase the wear on the shutter, since theoretically you could put a million+ actuations with a single shutter click (well actually the capacity of the mounted SD Card). If this is a concern, just put an artificial limit of say 3 continuous trips around the buffer or 100 bursted images.

joergens.mi · 10-10-2016, 02:30 PM

4.5 Pictures a second is roundabout 230 MB of data (RAW-files are 50 MB typically in my experience), write speed is maximum 30 MB/sec. You need roundabout 7-8 seconds to clear the pictures of one second.
Pentax manages to keep roundabout 17 pictures (870 MB) in the buffer, and they manages - after buffer filling - a picture every 1.5 seconds.

If you look at the numbers you'll see the writing of the data is the limit, the only thing to improve is a hardware change to increase the write speed to the sd-cards. Even a circular buffer - as described by Donald E. wouldn't help. You can not even determine if they use a circular buffer already.

**interested_observer** · 10-10-2016, 07:53 PM

The primary point of the suggestion is to eliminate the prolonged wait at the end of the initial burst of continuous shooting. The specific rates are going to vary with the individual body model, along with the SD card's performance, and with the image format in use. A better handling approach can be employed.

Simen1 · 10-11-2016, 12:38 AM

Originally posted by interested_observer

A better handling approach can be employed.

I'm not sure I understand the suggestion fully, but any way the buffer is filled up, it has to be emptied before its ready for a new burst. The emptying will take time. 17 images * 50 MB / 30 MB/s max write speed from the camera = 28 seconds. The emptying has to be done regardless of linear buffer filling followed by linear emptying or continuously circular filling/emptying.

I also do think the raw data currently are compressed before buffering. The size of 17 images suggests that the buffer is a 1 GB ram chip with some space occupied by the running firmware.

I think the only way to increase speeds are to wait for a new model with new hardware. The K-1 is a mighty fine camera, but it also got some deserved critics of hardware speed. A new sensor, processor, and buffer could improve a lot, including the usability of pixel shift, at least with a mirror up burst.

joergens.mi · 10-11-2016, 12:41 AM

Originally posted by interested_observer

The primary point of the suggestion is to eliminate the prolonged wait at the end of the initial burst of continuous shooting. A better handling approach can be employed.

What prolonged wait? There is no prolonged wait at the end. The camera starts to fire and to write immediately, at the end of the typically 17 shots (raw only) the buffer is filled up to the very end - and the first pictures already written -, the camera continues writing and shoots the next picture asap a buffer is free.

You should make some experiments with the real camera to get the the base data.

10-10-2016, 10:24 AM	#71
interested_observer Loyal Site Supporter Join Date: Jun 2009 Location: Tumbleweed, Arizona Photos: Gallery \| Albums Posts: 5,707	Originally posted by joergens.mi That may be a possible solution. But the write speed of the camera hardware is limited to something between 25 and 30 MBytes per second, therefore the buffer will fill up with 6.5 pictures a second. The question is not the maximal possible write speed of the cards but the maximum write speed of the camera. Your suggestion may be right if the buffer is static in size, but i assume that it will be dynamic and the pictures are stored in a compressed format (because pef/dng stores lossless compressed) to make maximal usage of the buffer. It's not only a possible solution - it's the best solution and optimal. In terms of write speed, all the card has to do is to keep up with the camera. Most cards today, can meet the 30 MB/s thruput. If they can't, it will take a few trips around the queue until you run in to the pointer overrun condition, in which case, your queue emptying rate will be regulated by the card's write speed - which is OK. You are still going to get, probably 2x to 3x the queue size (number of images) out as an initial burst, before slowing down. The absolute worst case for a glaicerly slow card, would be 1x the size of the queue - but would not suffer the 30 second cleaning and reset delay, as is the current case. In terms of the sizing of the individual cells, all you need to do is to size them to the maximum of a PEF/DNG image (plus the size of a pointer), then have a pointer at the top of the cell that points to the end of the variable length image (essentially a single unit linked list - another classic optimal solution). You will not be using all of the cell for each image, there will be a bit of wastage, however this will yield about the same number of images, and more importantly - be quicker to both fill and empty, again with out the prolonged delay. A circular buffer is a classic solution, both well known and understood - Knuth, Volume 1 (anyone with a Computer Science or Software Engineering degree will understand the citation). Actually, I am willing to send my own personal set to Pentax if necessary. Heck, since my set is the original 1st edition (3 volumes), I'll spring for the brand spanking new 4 volume, 3rd edition. One possible reason why they haven't implemented this (or a similar) solution, is that it may increase the wear on the shutter, since theoretically you could put a million+ actuations with a single shutter click (well actually the capacity of the mounted SD Card). If this is a concern, just put an artificial limit of say 3 continuous trips around the buffer or 100 bursted images. Last edited by interested_observer; 10-10-2016 at 10:32 AM.

10-11-2016, 12:38 AM	#74
Simen1 Veteran Member Join Date: Jul 2009 Location: Tromsø, Norway Photos: Albums Posts: 1,031	Originally posted by interested_observer A better handling approach can be employed. I'm not sure I understand the suggestion fully, but any way the buffer is filled up, it has to be emptied before its ready for a new burst. The emptying will take time. 17 images * 50 MB / 30 MB/s max write speed from the camera = 28 seconds. The emptying has to be done regardless of linear buffer filling followed by linear emptying or continuously circular filling/emptying. I also do think the raw data currently are compressed before buffering. The size of 17 images suggests that the buffer is a 1 GB ram chip with some space occupied by the running firmware. I think the only way to increase speeds are to wait for a new model with new hardware. The K-1 is a mighty fine camera, but it also got some deserved critics of hardware speed. A new sensor, processor, and buffer could improve a lot, including the usability of pixel shift, at least with a mirror up burst. Last edited by Simen1; 10-11-2016 at 12:46 AM.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
An analysis of Pentax AF compared to competitors and suggestions for improvement	bwDraco	Pentax DSLR Discussion	20	08-23-2015 03:07 PM
Easy to use panorama software	badtux	Digital Processing, Software, and Printing	18	08-17-2014 06:56 PM
An easy-to-do small improvement to AE-L button confusion	jon404	Pentax K-01	4	10-21-2013 08:27 AM
Firmware feature requests	Thingo	Pentax K-01	4	03-04-2013 07:09 PM
K20D Firmware ONLY Fix & Feature Requests	Cedar	Pentax DSLR Discussion	18	04-24-2008 08:17 PM

10-03-2016, 01:26 AM	#61
interested_observer Loyal Site Supporter Join Date: Jun 2009 Location: Tumbleweed, Arizona Photos: Gallery \| Albums Posts: 5,707	Originally posted by Gimbal That cannot be fixed in firmware, it’s a problem that occurs due to the wide rectilinear lenses distorting the image. Objects at the corners are stretched out by the lens compared to similar objects in the center of the image. If we are shooting stars that is not a problem as long as the stars in the corner stays in the corner, as they do if you use a barn door tracker, or equatorial mount. But if the lens and camera doesn’t rotate as when using the built in astro tracker, the stars will move from the corners into the center and then out again. And while dong so they will appear to change speed due to the distortion that enlarge them in the corners. In other words, they will appear to move faster in the corners. You get the same thing if you do a long exposure without using the astro tracker, the trails will be longer in the corners. Gimbal - I guess we are just going to agree to disagree on this topic. Pentax designed their system, they know what the weaknesses are, however they have not disclosed any real technical information about it, hence what the problem is. They are just not saying anything. Unfortunately, AstroTracer is too nice a feature to suffer this fate.

10-03-2016, 03:42 AM	#62
Gimbal Pentaxian Join Date: Apr 2007 Location: Sweden Posts: 2,106	Originally posted by interested_observer Gimbal - I guess we are just going to agree to disagree on this topic. Pentax designed their system, they know what the weaknesses are, however they have not disclosed any real technical information about it, hence what the problem is. They are just not saying anything. Unfortunately, AstroTracer is too nice a feature to suffer this fate. I guess so. But you do realize that wide rectilinear lenses distort the image? A star that appears to move say 4mm in the center of the frame during a certain shutter speed, will move 6mm if you reframe so that star sits in the corner for the same time. (The numbers are of course just examples taken out of the blue to illustrate the problem.)

10-03-2016, 07:13 AM	#63
interested_observer Loyal Site Supporter Join Date: Jun 2009 Location: Tumbleweed, Arizona Photos: Gallery \| Albums Posts: 5,707	Originally posted by Gimbal I guess so. But you do realize that wide rectilinear lenses distort the image? A star that appears to move say 4mm in the center of the frame during a certain shutter speed, will move 6mm if you reframe so that star sits in the corner for the same time. (The numbers are of course just examples taken out of the blue to illustrate the problem.) Yes, a wide rectilinear lenses will distort the image. However, the real question here is to Pentax. Please identify your sources of error, to what extent do they contribute to the overall problem and for each source - how is the error manifest/realized in the resultant image. AstroTracer is a closed black box system. We know the generic inputs, we just do not know the quality (accuracy and precision) of the inputs (for instance the compass). Are there limitations to the system? - absolutely! We know that exposure time is one (Pentax has limited that to a maximum of 5 minutes based on focal length), and that times of less than a minute minimize star trailing. That is a substantial difference. Through observation (actual use) elevation angles beyond 45 degrees produce degraded results, and Pentax should acknowledge and quantify that. Your position is that wide rectilinear lenses is a major contributing factor - OK, Pentax needs to characterize and quantify that aspect (what focal lengths minimize trailing). My position has been that the compass has limitations and needs to be characterize and quantify - and potentially address how an extended calibration process may help to control this. Once sources of error have been identified, characterize and quantify and their effect/how they will be manifested in the resulting image - Pentax should be able to advise possible approaches to reduce or to minimize their effects. They have done this in one area - fine calibration should not be done near large metal objects - cars. They can also update the system - either in firmware (to the extent possible) or with new hardware (camera bodies - for instance the K1 and its new 5 axis stabilized sensor). Pentax can also publish a technical paper addressing their overall system in a more technical environment than what they currently have. A several page paper addressing the system, inputs, characterized errors, what and how users can assist in their minimization, etc. For instance - a discussion on exposure time, focal length, are a couple - and there are several more. Pentax has modeled the GPS system. Addressing the model (to the extent possible) along with its implementation within the actual device (O-GPS1/K3II/K1) utilization would do a great deal in addressing this topic. Quite frankly - I don't want to do it. Users should not have to reverse engineer a system in order to use it effectively. I retired several weeks ago and just want to go take pictures and improve my composition. My days of system architecture and engineering to a large extent are in my past. I have done several star tracking systems - across a wide range of uses - (hybrid combinations of GPS, inertial and celestial) from sub-orbital navigation, orbit insertion, station keeping and re-entry, to even a little telescope down in Texas. Right now, I am trying to decide if the weather is good enough to drive up to Flagstaff today to shoot the fall colors up in the alpine meadows. My only concern right now is aspen, birch, maple and oak.

10-03-2016, 07:59 AM	#64
Gimbal Pentaxian Join Date: Apr 2007 Location: Sweden Posts: 2,106	But the problem you mention in the first post with trailing in the corners and perfect point like stars in the middle, this happens even when the astro tracker works perfectly. And that phenomenon cannot be compensated for by merely moving the sensor. But then of course the performance is also limited by sensor input as you write, and one of the weakest sensors seems to be the compass. At least in my K-1 unit. My OGPS-1 is a lot more accurate, possible due to the sensor sitting further away from the SR unit? (which has at least four really powerful magnets built in.) One problem which is new with the K-1 model is that the compass bearing is affected by the position of the foldable LCD. Only in some directions though, but in those directions the effect is quite strong.

10-03-2016, 09:12 AM	#65
interested_observer Loyal Site Supporter Join Date: Jun 2009 Location: Tumbleweed, Arizona Photos: Gallery \| Albums Posts: 5,707	As you noted, the body taken as a system as a whole - does have a number of competing technologies used for a range of applications. In terms of the astrotracer, what provides its principal enabling capability - the (magnetic field) floating sensor, is also one of the main sources of potential interference with the electronic compass, as well as the articulating screen. I am sure that there are others based on the various implementations (the o-gps1 as well as the new integrated body models). That is why some discussions from Pentax, would certainly help. In terms of firmware and potential updates, perhaps after a successful fine calibration process, pointing the camera in the direction of its main use, and using a reading from an external compass to provide an additional input (or 2+ - say several pointing calibrations) as a base bias to the system may help. Maybe, adjusting the articulating screen in its anticipated position of use may help - who knows? All we are doing is taking some semi-educated guesses. This approach to star tracking - essentially a reasonably pure computational design approach, has not really been implemented (well at least as consumer product) before. Folks actually doing astro (wide field, deep sky) and astrolandscaping are reasonably technical. Putting out a technical whitepaper and promoting some discussion within the community would certainly help with the results, but also be a good positive marketing approach. If done right, it would be to both Pentax's - as well as the user communities' benefit. In the end, the astrotracer is going to be judged on the results it's able to obtain. Informed users are only going to be to Ricoh/Pentax's benefit.

10-03-2016, 10:00 AM	#66
MJKoski Veteran Member Join Date: Aug 2016 Posts: 1,784	UWA Trailing is symmetrical with point stars in the middle. Miscalibration causes trails and blur in the middle as well. Just stuff UWA lens to your camera and pan around the room with live view -> images edges seem to move lot faster than the middle region.

10-03-2016, 10:13 AM	#67
mattb123 Site Supporter Join Date: Apr 2010 Location: Colorado High Country Photos: Gallery Posts: 10,873	I'd like to see a 2s timer mode with bracketing that only does the 2s delay on the first shot of the bracket. I see no point in 2s before each exposure of the group. (K-5, K-3, 645D, K-1)

10-09-2016, 08:23 AM	#68
TheOneAndOnlyJH Veteran Member Join Date: Dec 2013 Location: Buffalo, NY Posts: 351	Originally posted by mattb123 I'd like to see a 2s timer mode with bracketing that only does the 2s delay on the first shot of the bracket. I see no point in 2s before each exposure of the group. (K-5, K-3, 645D, K-1) Best would be to set both custom initial delay and interval between shots separately. For example, 10s so you could get in position and then 1s between exposures so you don't have to wait.

10-09-2016, 04:08 PM	#69
interested_observer Loyal Site Supporter Join Date: Jun 2009 Location: Tumbleweed, Arizona Photos: Gallery \| Albums Posts: 5,707	Buffering - Right now Pentax implements a linear FIFO (first in first out), that holds on the order of 20 something images (both model and image format(RAW/JPG) dependent). When you fill it up, it then takes 30 seconds for it to be cleared. Then its ready to wash and rise again. Modifying the buffering to a circular buffer would be straight forward and easy. It is just a case of pointer management - which is extremely quick and straight forward to perform. There really is no real reason to take time to clear the buffer. It would essentially be endless if the SD card's write speed was similar to the burst speed of the camera ~ 7 frames per second. There are SD cards that are substantially faster.

10-10-2016, 06:41 AM	#70
joergens.mi Veteran Member Join Date: Jan 2012 Posts: 408	Originally posted by interested_observer Buffering - Right now Pentax implements a linear FIFO (first in first out), that holds on the order of 20 something images (both model and image format(RAW/JPG) dependent). When you fill it up, it then takes 30 seconds for it to be cleared. Then its ready to wash and rise again. Modifying the buffering to a circular buffer would be straight forward and easy. It is just a case of pointer management - which is extremely quick and straight forward to perform. There really is no real reason to take time to clear the buffer. It would essentially be endless if the SD card's write speed was similar to the burst speed of the camera ~ 7 frames per second. There are SD cards that are substantially faster. That may be a possible solution. But the write speed of the camera hardware is limited to something between 25 and 30 MBytes per second, therefore the buffer will fill up with 6.5 pictures a second. The question is not the maximal possible write speed of the cards but the maximum write speed of the camera. Your suggestion may be right if the buffer is static in size, but i assume that it will be dynamic and the pictures are stored in a compressed format (because pef/dng stores lossless compressed) to make maximal usage of the buffer.

10-10-2016, 02:30 PM	#72
joergens.mi Veteran Member Join Date: Jan 2012 Posts: 408	4.5 Pictures a second is roundabout 230 MB of data (RAW-files are 50 MB typically in my experience), write speed is maximum 30 MB/sec. You need roundabout 7-8 seconds to clear the pictures of one second. Pentax manages to keep roundabout 17 pictures (870 MB) in the buffer, and they manages - after buffer filling - a picture every 1.5 seconds. If you look at the numbers you'll see the writing of the data is the limit, the only thing to improve is a hardware change to increase the write speed to the sd-cards. Even a circular buffer - as described by Donald E. wouldn't help. You can not even determine if they use a circular buffer already.

10-10-2016, 07:53 PM	#73
interested_observer Loyal Site Supporter Join Date: Jun 2009 Location: Tumbleweed, Arizona Photos: Gallery \| Albums Posts: 5,707	The primary point of the suggestion is to eliminate the prolonged wait at the end of the initial burst of continuous shooting. The specific rates are going to vary with the individual body model, along with the SD card's performance, and with the image format in use. A better handling approach can be employed.

10-11-2016, 12:41 AM	#75
joergens.mi Veteran Member Join Date: Jan 2012 Posts: 408	Originally posted by interested_observer The primary point of the suggestion is to eliminate the prolonged wait at the end of the initial burst of continuous shooting. A better handling approach can be employed. What prolonged wait? There is no prolonged wait at the end. The camera starts to fire and to write immediately, at the end of the typically 17 shots (raw only) the buffer is filled up to the very end - and the first pictures already written -, the camera continues writing and shoots the next picture asap a buffer is free. You should make some experiments with the real camera to get the the base data.