[MJKoski]

Uhm. Well, no, the current buffering sucks. It is "machine gun" until end is reached and then continues with sloppy speed when trigger is held. It could be so that it would begin filling the again the buffer slots which are already written to the card and continue at maximum speed much longer. You see, the "end" of the buffer reaches the "head" of the buffer. It just rolls and rolls until battery dies or shutter fails (this would require very fast writing speeds though).

Maybe they are using optimal buffering already but in this case the buffer memory is very small when taking into account 36MP sensor. Not that Nikon variants are any faster...or Sony (horrible waiting times).

---

Last edited by MJKoski; 10-11-2016 at 07:26 AM.

[interested_observer]

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.

Here is an example of a real time sequence of continuous shooting, where the buffer becomes filled, image capture stops while the buffer is reset, then shooting continues. It is intuitively obvious to the casual observer - the point within the sequence where the plane makes an abrupt drop - well, this is the point where the buffering/shooting is discontinued while the buffer is being reset.

• Lightroom Export - Sendvid

What prolonged wait? .....

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

---------- Post added 10-11-2016 at 08:24 AM ----------

This was intended to be posted before the one above. Unfortunately, I forgot to post it before I went down to the other end of the house - to my other PC storing my files to retrieve an example of the problem....

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.

Excuse me, but I have run in to this in terms of some work that I have done. I do know what I am talking about - thank you very much. I have the documentation - consisting of a series real time action image sequence of a plane landing on a runway that just happens to be time stamped in the EXIF, that clearly show to the eye what is occurring. Here is a similar link with a discussion. I have other landing sequences, where the continuous shooting is used, where you have a smooth series of images - for example a plane landing, where upon the buffer becomes completely filled, followed by the buffer being cleared and reset no images are captured, then once the buffer is reset, image capture is then continued (I guess I'll have to go dig this out). The "stop action" sequence shows the plane making a smooth landing up to the point where the buffer becomes filled then a pause, followed by additional images - with the plane farther down its landing process. This sequence below, just happens to have the pause at touchdown. This sequence was taken not specifically to show the buffer problem.

• https://www.pentaxforums.com/forums/38-photographic-technique/318924-sky-harb...ime-lapse.html

[joergens.mi]

I'm not shure that I get, what you are talking about - maybe that I'm misinterpreting some text, I'm not a native speaker.
The sequence I know, is the following for pure raw and FF-mode.

• For 17 pictures the camera is working at 4.5 pictures a second (roundabout 4 seconds) during that time the camera is starting to write to the sd-card
• Now the speed of taking pictures drops immediately to roundabout a picture every 2 seconds - the next picture is taken when a buffer is free.
• When you stop triggering the camera will continue to write to the card for roundabout 34 seconds (there are 850 MB to write)
• If you start triggering during this write time, the camera gets full speed until the buffer is filled up again, and than goes down to 1 picture every two seconds

One possibilty to get a longer sequence is to change to the jpg mode with best quality or to reduce the speed of continuous shooting to medium or low.

[interested_observer]

Well, my German is non-existent. Even though my grandparents immigrated from Germany (clipper ship around Cape Horn) and spoke German, my father thought that Spanish was a better choice while growing up in California.

The examples above were taken quite by accident. Rather than try to time the best shot (really going for stills), I just put the camera body (K5IIs) in continuous shooting mode and locked down the external shutter release as the planes flew overhead on their landing approach, in order to capture a large amount of shot so I could select the best one later while post processing them. While post processing them, I noticed that they made a really nice "stop action" video - so I processed them using Picassa into a video sequence. When viewing the video in real time, it was very apparent that, as the plane as it was making its decent for touchdown, the sequence of individual stills was interrupted for a period of time, and then subsequently resumed. The interruption does not show as an "interruption" in the video sequence, but shows the plane suddenly "dropping" in its flight path. This "drop", is when the buffer is full, and no additional images are captured while the buffer is being cleared and reset, followed by the resumption of image capturing.

While shooting sequences a couple of days later, you could hear the shutter click off at about 7 frames per second, a string of 20+ images and pause, then subsequently resume. The real aim was to collect RAW stills as opposed to JPGs. Also, the "video" is just a fortunate happenstance from sequencing through the individual single images, and seeing the "discontinuity" of the plane's travel trajectory. What I found was that - from memory, that the K5IIs holds about 22 full size raw, but with the lossless compression, and depending the individual shots (and how they compress), I can get about 29 +/- before the buffer fills.

I have quite a number of image sequences from several outings at the end of the runway over the last year or so. It's pretty evident that the buffer is just linear, and when filled does a clear & reset, prior to resuming. Imaging Resources has observed the same performance characteristic.

• Pentax K-5 II Review - Performance

Also the characteristics of the continuous shooting buffer performance is illustrated in the Forum's review too. This link notes differences between the K3 and K5IIs in terms of the buffer processing times. It also notes differences when different performance levels of SD cards are used.

• Pentax K-3 Review - Performance and Burst Mode | PentaxForums.com Reviews

The K5IIs writes at 30Mb/s. The initial SD card I was using (Transend SD HC 32GB), had a write speed of about 20 MB/s. I picked up a couple of faster SD cards (both SanDisk Extreme PLUS) - one with a write speed of 45 MB/s (32GB HC I) and the other with a write speed of up to 60 MB/s (64GB XC I) - as I needed a couple of new cards anyway. I was expecting the potential of a larger number of images written to the card before the buffer was cleared.

Both of these cards performed somewhat differently. Actually, I was able to have fewer images written to the card before the buffer was cleared (makes little sense - but it is what it is). Each was freshly formatted.

This is what leads me to conclude that the continuous shooting buffer management is very "linear", followed by clearing/reset, rather than circular, where the buffer management is done with pointers when an image is both inserted into the buffer, and when an image is removed after being written to the card. A circular buffer by its very design would have a very uniform performance, along with being able to temporally cycle through a substantially larger number of images before having to limit/curtail insertions due to being full. Also, by significantly increasing the rate of the SD card to accept data, beyond the rate that the buffer was being filled at. If the buffer was circular, then we would never encounter a buffer full condition (given that everything else being equal).

---

Last edited by interested_observer; 10-11-2016 at 12:18 PM.

[MJKoski]

Yes circular buffer is very nice. But we are hitting the wall with writing speed here as well. XQD interface would solve it for good and provide unlimited buffer when circular buffer is used.

[joergens.mi]

I think I understand the difference in our understanding.
You think, the camera gets it n-pictures until the buffer is full, stops taking pictures, save the pictures to sdcard and restarting after that.
I think (know), the camera gets is n-pictures, but it starts immediately after the first picture to save to sdcard and the two processes are running in parallel.
The problem is there are much more data coming in (350 MBytes a second) than going out to (25-30 MBytes a second) sd-cards. At one point the buffer is full (780 MB) the camera must stop taking pictures until one picture (50 MB) is saved. This takes roundabout 2 seconds, than the next picture is taken.

I think a pause of 30 Seconds would lead to a different type of video.

[interested_observer]

Normally, I would agree with you. And actually, that was my thinking until I tried it again with the faster cards. The thought that about 29 images +/- with the 20MB/s card should increase when using either a 45 MB/s or the 60 MB/s card. The problem was, when using the faster SD cards, that was not the case. If the output was rate limited to 30 MB/s then going from a 20MB/s to something over 30MB/s - would still yield an noticeable improvement. Simple but straight forward analysis.

Now, it does appear that Pentax has been tuning their buffering approach since the K5 model (the K5IIs and the K3). Both the Imaging Resources and PF's links above show this. What the limitations are within their design is not known - other than the obvious implied input and output transfer rates.

I think a pause of 30 Seconds would lead to a different type of video.

The 30 seconds came from the PF link that measured the pause - clearing of the buffer under a series of conditions (right hand table, mid page), with 33 seconds being the maximum measured pause.

I have been going for the highest possible image quality, hence using RAW. When strung together in full resolution running at 24 fps, you have a stunning (but very short) 5K video. For Internet posted video, just doing everything in say ** jpg mode, should certainly yield a couple of hundred images that would capture the entire landing sequence. But, at the beginning - that is not what I started out to capture. It just so happened that this particular "end of the runway" shooting setup, is very good at visually capturing the various buffering characteristics being employed.

I might just trundle down to the airport later this afternoon/evening and give it another try. I have not been down there for quite a while. At 6pm the daily BA 747ER flight arrives from London followed by a rush hour of landings, stacked up at one per minute.

[Des]

A modest firmware suggestion: the option to name folders and image files to start with date of shooting. Dates should allow for selection of a chosen format (e.g. YYYY-MM-DD or just YY-MM or MM-DD, or in the case of files, YYYY-MM-DD-hhmmss). Recent venting of frustration about this shortcoming here: https://www.pentaxforums.com/forums/6-pentax-dslr-discussion/331599-folder-naming.html

[joergens.mi]

Thats a problem with the DCIM ( Design rule for Camera File system - Wikipedia, the free encyclopedia ) a JEITA specification (CP-3461) that defines the filenaming convention - it define the names to a length of eight. Nowadays I would prefer a 5 digit file numbering. even longer names would be fine. The definition is set to 4 digit filenumbers and to 3 chars followed by '_' for sRGB and an '_' and tree chars for an Adobe RGB picture. There is also a restriction to 500 pictures with the same extension in one folder (raw+ has 500 pef and 500 jpg in a folder)

I would like a camera option to set the file naming not Jeita conform.

This filenaming would be insufficient; YYYY-MM-DD-hhmmss cameras can make more than 1 shoot per second Pentax up to eight some other above 10. I think a YYYYMMDD_ followed bei an upcounting 5 digit number (as we are used to, with 4 digits) would be fine and fit most purposes i.

[Gimbal]

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.

I agree, they are obviously already using a circular buffer. Which isn't surprising really as that would be the first idea that comes to mind to any programmer. As soon as the buffer is full you can't shoot faster than the hardware can write to the memory card, which is exactly what happens, and there is no trick around that less then throwing data away.

Unless they somehow could write to both cards at the same time, odd numbered pictures to the first card and even numbers to the second card, and thus doubling the speed. But there is probably some hardware limit putting a stop for that.

[joergens.mi]

Unless they somehow could write to both cards at the same time, odd numbered pictures to the first card and even numbers to the second card, and thus doubling the speed. But there is probably some hardware limit putting a stop for that.

There have been some experiments about that, described in discussions, writing to both cards reduces the speed below the 25 Mb/second. It can be tested when writing the same picture to both cards (one of the options). There is only one hw-bus to the sd-cards and this is the limiting element. The change in hw must be another controller for the sd-card devices, this costs more current (especially the higher writing speed modes of UHS I or UHS II) and a lot more interrupts. This may be one of the reasons for the slow interface - the total power budget especially the maximum current that can be drawn at a time.
A series photography with 4.5 pictures needs a lot of power, getting the picture from the sensor, processing it writing it to the card and there is wifi, gps Display and focussing. All these actions at the same time generates a maximum of current drawn - this must be delivered by the accu without a voltage drop (== pictures loss) and overheating any parts in the camera

[LightBug]

Can we please request to add option to configure TAv mode to set "minimum" shutter speed instead of "fixed" shutter speed? This will make TAv more useful in outdoor conditions when plenty of light available could cause pictures to overexpose.

[serothis]

I haven't read the whole thread but there are my suggestions (that haven't been mentioned...that I could find. sorry if they have) But these are the things I can think of off the top of my head.

Request #1: a quick "Info" on/off function. This is mentioned in the OP but I would like to offer another alternative setup to achieve the same thing.

Have a user selected default screen that can be quickly accessed with a single press of the info button. And then the screen turned off (and stay off) with a half press of the shutter button.

Request #2 - FAT32 Support.

Request #3 - Exif info editor and auto fill

I have a couple of manual lenses. Being able to auto fill/quickly edit exif info on the spot would be invaluable to me. Auto fill could either be done with a set parameter in one of the USER modes or have a profile list that could be selected in the preview screen. Batch auto-fill would also be appreciated.

[krazykat]

Here is an example of a real time sequence of continuous shooting, where the buffer becomes filled, image capture stops while the buffer is reset, then shooting continues. It is intuitively obvious to the casual observer - the point within the sequence where the plane makes an abrupt drop - well, this is the point where the buffering/shooting is discontinued while the buffer is being reset

Hi,


I'm finding hard to see exactly where this point is in the video, could you tell me?


Cheers.

[interested_observer]

Hi,

I'm finding hard to see exactly where this point is in the video, could you tell me?

Cheers.

The initial reason for the image sequence was to capture the landing and find the best single individual still image. In post processing I was looking for that one single image and I saw the stop action sequence and though that it looked pretty good - thus the video. And that was the reason for the initial posting - some time ago.

In this thread, I reused the video sequence because near the end you can see a something of a stop/pause in the somewhat smooth descent. I have a number of other sequences - other landings that show a much more distinct - be it a longer gap where the buffer is being reset. And, that is the point of the initial suggestion here - some better buffering in this series of posts. In RAW (I was shooting in RAW to get the best image quality for the stills I was shooting), I noticed that the way the buffering was being handled - I think could be handled better.

Across a number of instances, the buffer which is 22 RAW frames in length - according to reviews and the documentation, was filling up at around 27 to 29 frames, then stopping, pausing and then restarting. The duration of the stoppage was somewhat arbitrary. I was also using a slow SD card. This perked my interest, and since I needed a new SD card anyway, and they were on sale, I picked one up that was substantially faster (on the write - 95MB/s if I remember), than what the camera could write. I expected to see a difference in performance. I did - the stoppage or gap in the action sequence was earlier and was a bit longer (i.e., worse performance). Now, there is the potential of some variability here, in that the size of each individual RAW frame is going to vary to a degree, and that is going to be based on the scene being shot, etc.

You can pretty easily replicate this. Just pick a road where cars are going to be zooming by. Set the camera up on a tripod, during the day with good lighting works just fine. Focus on infinity, and put the camera in to manual focus - as this is not a focusing test. I would use a small aperture for a good depth of field so that you can have some good definition and sharpness, to see what is occurring. Put the camera into high burst mode. So, as a car passes by depress and hold the shutter down (well I used an external shutter release) and just let it shoot continuously (the K5 runs at about 7 frames per second), so after a bit more than 3 seconds - and keep holding the shutter down, you will hear the shutter stop for a bit - sometimes longer, and then start up taking images again at a somewhat slower rate. That is what my set of posts here was about. I would think that the buffering could be handled a bit better. Yes, I could do a rate analysis - but for me what is the point - as I can't change anything in the software. I understand software - I have been a software systems engineer for over 40 years (embedded real time systems). The way the buffering was handled was not, as I would have expected.

Going back to doing your own experiment - then load the images into the PC and using your post processing utility (I was using lightroom 5.5), just slew from one image to the next - and you start to see a stop action image sequence - similar to a cartoon. After slewing through about 20 to 30 images you will see the somewhat smooth cadence of the image sequence stutter- a break in the continuous motion, and then startup again in terms of the continuous motion. This is the break, stoppage, the pausing, the gapping, the stuttering - what ever you wish to call it. I then took the sequence and loaded it into Picassa (which makes movies) and turned it into a movie, so that I could see it a bit better.