PIX 2015

K5: Testing RAW Continuous Shooting

Started Oct 20, 2010 | Discussions
Shop cameras & lenses ▾
Dale108
Dale108 OP
Veteran MemberPosts: 5,987
Like?
Re: K5 vs Kr: Testing JPEG Continuous Shooting
In reply to Dale108, Oct 23, 2010

I set the K5 at 4 star JPEG and Kr at 3 star JPEG (it doesn't have 4 star), put on manual focus and fired away. The result was almost a tie, with both the K5 and Kr firing off 20 pics without slowing; the difference was that the Kr seemed to clear buffer a little quicker to continue shooting. Of course, with the K5 you have 16 MP vs 12 MP JPEGs, so true winner would be K5. What is surprising me is how good the Kr performs.

Dale
--
http://www.pbase.com/abundant108

http://www.pentaxphotogallery.com/home#section=ARTIST&subSection=272176&subSubSection=1787360&language=EN

Reply   Reply with quote   Complain
GordonBGood
Veteran MemberPosts: 6,286
Like?
Re: 2 x 128mb 'ping-pong' buffer ?
In reply to GordonBGood, Oct 24, 2010

GordonBGood wrote:

Kerusker wrote:

GordonBGood wrote:

As has already been discussed with Mike, the reason that the K-5 has this amount of memory, whatever it should be, is that the K-7 had it, but also with twice the memory there would be twice the buffer clearing time of about 20 seconds, which might well be unacceptable.

Why can't PENTAX use two 128MB buffers to read/write in parallel (often called 'ping-pong' buffer). While ping-buffer is filled by CPU, pong-buffer is read out and written to card. Then ping and pong buffers are switched.

Then burst would not be limited by write speeds (using sufficiently fast buffers and cards).
Heating up the sensor with long bursts might be the problem then.

I don't think that dividing say the hypothetical 256 MByte raw buffer into two alternating buffers would actually help that much, even for a new model camera as it obviously isn't possible for the current design of the K-5 which mostly uses the K-7 basic design with a new sensor. Let's analyse this as follows:

4) As long as the flash write speed is only about 22.5 MBytes per second, your alternating page scheme isn't going to make any difference to the buffer depth of four images per side, nor the buffer full rate of about 1.1 fps, nor the time to clear the buffer (both) of something just over eight seconds (longer for larger raw files of higher detail or noise). In fact, the camera will be waiting to switch memory "sides" for the files to be written out from the last side as the output rate is slower than the acquisition rate.

In fact, the alternating buffer scheme is going to make the continuous shooting mode work worse in some ways in that the camera will shoot eight frames, then pause a few seconds while the other page is still being cleared, then shoot a fast four frames, then pause, etc.

Alternating pages is a benefit when the acquisition time is quite a bit greater than the processing and write time so that the alternate page is always clear in time. In the case of Pentax DSLR's, acquisition time is negligible as it is likely done by a Direct Memory Access (DMA) mode as fast as the sensor can be scanned, so the limit is the processing but even more the actual flash memory write time.

Regards, GordonBGood

Reply   Reply with quote   Complain
GordonBGood
Veteran MemberPosts: 6,286
Like?
Re: 2 x 128mb 'ping-pong' buffer ?
In reply to Jeff Charles, Oct 24, 2010

Jeff Charles wrote:

GordonBGood wrote:

...My temporary or alternate solution proposed above may be practical for the current design of the K-5, where neither can the amount of memory nor the flash memory write speed be increased , thus the proposal is to reduce the average size of the files that need to be written by having an optional 12-bit mode.

Makes sense. Why there isn't a 12-bit mode already is unclear.

Well, one reason that there may not be an optional 12 bit mode is that it appears the way the Pentax have implemented it, it would take a completely separate processing chain for each of the 12 bit and 14 bit modes. The 12 bit mode as used with previous cameras including the K-7, K-x, and K-r appear to be dealing with a byte packed raw buffer and thus would have to process by reversing the byte packing for alternate photosites in turning three bytes into readings from two photosites where it appears that the 14-bit mode uses two bytes per photosite so that this unpacking wouldn't need to be done. I don't say that both options couldn't be offered if there is enough space in the firmware EEPROM's but there could be a fair amount of extra code.

The advantages that 14 bit brings may not be important in many cases, and I think I read that there is little benefit at high ISOs. So, the "price" of 14 bit has to be paid with every raw, whether you need it or not.

You are correct that there is no advantage to 14-bit raw in many cases, as in all ISO's above 200, in all the brighter tones above about 9.7 stops below the full bright clipping level at even the lowest ISO and even less for higher ISO's (11 stops below at ISO 200), and even in the best of cases only provides a few extra very dark graduations as in less than four extra distinct levels even if one boosts the very dark levels up to where we can actually see these. It would seem to be a bit price to pay for a benefit of very few underexposed or truly wide scene Dynamic Range (DR) images.

Also, one issue with K-5 buffer clearing seems to be that you can't review any images until the buffer is fully cleared. A couple of other DSLRs I own (Olympus and Nikon) both allow review will data is being written to the card. Could Pentax make a firmware change to support this?

Anything is possible, but I would think if the Pentax cameras did allow this, it would have a negative impact on buffer clearing times. I guess that wouldn't matter much when the photographer was busy "chimping" anyway if it were implemented in such a way that the buffer clearing was interrupted only if the operator hit the Play button to start "chimpling". It would be much harder to start Live View (LV) up again before the buffer was clear, as it likely needs some of the same raw buffer space that is being used and the processing required to display the LV image would come out of the processing time currently used to clear the buffer.

Regards, GordonBGood

Reply   Reply with quote   Complain
jeanphilippe Goube
Senior MemberPosts: 1,495Gear list
Like?
Parrallel write on 2 sd cards
In reply to GordonBGood, Oct 24, 2010

Hi,

to avoid waiting a technological breaktrough is SD card, Pentax may better add support of 2 SD slots with parallel writes - just as disk units that allows RAID 0 (parallel writes). Then 2 raw images/s will be achieved.
--
jpgoube

 jeanphilippe Goube's gear list:jeanphilippe Goube's gear list
HD Pentax DA 15mm F4 ED AL Limited Pentax Q Pentax K-3 Nikon D810 Pentax smc FA 43mm F1.9 Limited +8 more
Reply   Reply with quote   Complain
gDaniel
Regular MemberPosts: 167Gear list
Like?
Re: 128mb buffer in my estimation
In reply to Dale108, Oct 24, 2010

Dale108 wrote:

Hi Mike:

Some good ideas. I haven't checked in to what the Canon 7D or Nikon D300s buffers are like but i would expect them to be larger. If the focus tracking is better then the K7 (haven't tried out in field), then this could work well enough.

in case you need some data:

D300 +Sandisk Extreme 3 CF 8 GB(30MB/S listed, but it's more like 25)

17 frames at 6fps - raw only
15 frames - raw + jpeg
67 jpegs

With a Sandisk Extreme 4, you can get more frames ( around 25 raws) until the camera will slow down and fps will be uneven.

Number of frames does not decrease if you change iso ( tried ISO 200 and 6400)

 gDaniel's gear list:gDaniel's gear list
Nikon D800 Nikon AF-S Nikkor 16-35mm f/4G ED VR Nikon AF-S Nikkor 50mm f/1.4G Nikon AF-S Nikkor 70-200mm f/2.8G ED VR II Sigma 85mm F1.4 EX DG HSM +6 more
Reply   Reply with quote   Complain
Alex Sarbu
Veteran MemberPosts: 4,449Gear list
Like?
Re: Parrallel write on 2 sd cards
In reply to jeanphilippe Goube, Oct 24, 2010

jeanphilippe Goube wrote:

Hi,

to avoid waiting a technological breaktrough is SD card, Pentax may better add support of 2 SD slots with parallel writes - just as disk units that allows RAID 0 (parallel writes). Then 2 raw images/s will be achieved.
--
jpgoube

Risky - if one card fails, you'd lose everything. Complicated. And you'd need special software to read the data on your computer (unless you'd use the camera, via USB).

But there is a better solution: alternative writing, e.g. odd-numbered files on SD1 and even ones on SD2. Maybe this is what you had in mind?

We'll have to wait the next body, to see if Pentax made room for dual SD slots (that would be a good idea, IMO - for the K-5's replacement). 2012?

Alex S.

 Alex Sarbu's gear list:Alex Sarbu's gear list
Pentax K20D Pentax K-5 Pentax smc DA* 60-250mm F4.0 ED (IF) SDM Pentax smc DA 21mm F3.2 AL Limited Pentax smc DA 70mm F2.4 AL Limited +4 more
Reply   Reply with quote   Complain
falconeyes
Senior MemberPosts: 1,200
Like?
Re: 128mb buffer in my estimation...
In reply to GordonBGood, Oct 24, 2010

GordonBGood wrote:

I am starting to take an alternate approach, as follows

I reply to your combined responses. I just wanted to chime in and agree that the DRAM size in the K-5/7 is 256MB, 512MB or 1024MB.

The following chart shows the base K-7 architecture (although "PRIME II" consists of the Fujitsu Milbeaut M5 + Pentax-made ASIC labelled PRIME-II, K-5 has no external A/D converter anymore):

It shows 2 DDR2 chips and a 1GB/s memory bandwidth.

A 1024MB DDR2 DRAM module with 8 chips is about $24, so a 128MB DDR2 chip is about $3. Therefore, 256MB, 512MB or 1024MB would cost $6, $12 or $24 resp. I assume that the printed Prime II board didn't include an option for larger capacity DDR2 chips as otherwise, just doubling the capacity would have been an option.

Of the available DRAM, a part is reserved as a writing buffer to SD card. There is no reason to believe it is a power of 2. I guess the buffer is around 150MB, leaving 100MB or more to the processing.

Reply   Reply with quote   Complain
GordonBGood
Veteran MemberPosts: 6,286
Like?
Re: 128mb buffer in my estimation...
In reply to falconeyes, Oct 24, 2010

falconeyes wrote:

GordonBGood wrote:

I am starting to take an alternate approach, as follows

I reply to your combined responses. I just wanted to chime in and agree that the DRAM size in the K-5/7 is 256MB, 512MB or 1024MB.

The following chart shows the base K-7 architecture (although "PRIME II" consists of the Fujitsu Milbeaut M5 + Pentax-made ASIC labelled PRIME-II, K-5 has no external A/D converter anymore):

It shows 2 DDR2 chips and a 1GB/s memory bandwidth.

A 1024MB DDR2 DRAM module with 8 chips is about $24, so a 128MB DDR2 chip is about $3. Therefore, 256MB, 512MB or 1024MB would cost $6, $12 or $24 resp. I assume that the printed Prime II board didn't include an option for larger capacity DDR2 chips as otherwise, just doubling the capacity would have been an option.

Of the available DRAM, a part is reserved as a writing buffer to SD card. There is no reason to believe it is a power of 2. I guess the buffer is around 150MB, leaving 100MB or more to the processing.

Falk, as you see from my current thinking, it is more likely that the total DDR RAM memory size is 512 MBytes for both the K-7 and the K-5, with about 270 MBytes used for the raw buffer and the rest (242 MBytes) used for other purposes as in the RGB buffer for developing images, etc. You are right that there is now need for the area of memory used for buffer to be exactly a power of two.

Regards, GordonBGood

Reply   Reply with quote   Complain
falconeyes
Senior MemberPosts: 1,200
Like?
Re: 128mb buffer in my estimation...
In reply to GordonBGood, Oct 24, 2010

GordonBGood wrote:

Falk, as you see from my current thinking, it is more likely that the total DDR RAM memory size is 512 MBytes for both the K-7 and the K-5, with about 270 MBytes used for the raw buffer and the rest (242 MBytes) used for other purposes as in the RGB buffer for developing images, etc. You are right that there is now need for the area of memory used for buffer to be exactly a power of two.

Regards, GordonBGood

Yes, I saw this and you may be right. However, it seems like the area reserved for the write buffer about stayed the same. Which means that the area used for general processing remained about the same too. And that other area's size should be at least proportional to the MP count. And if it didn't change much eating from the buffer, then it must not be large. Therefore, my bet would be like a 150+100 MB memory layout.

Reply   Reply with quote   Complain
glanglois
Contributing MemberPosts: 987Gear list
Like?
Re: 128mb buffer in my estimation...
In reply to GordonBGood, Oct 25, 2010

Thanks for responding, Gordon.

I'm afraid I didn't make myself clear, though. I understand that testing was done without special processing options.

I was suggesting that the image processor may have too much to do even without the options invoked - that "business as usual" is becoming too much for it.

Or did I miss something in your response?

Cheers,

Geoffrey

GordonBGood wrote:

glanglois wrote:

Are we certain that the bottleneck is found in the physical size of the buffer and/or electrical characteristics of the card interface?

I have this suspicion, based upon burst speed when certain auto corrections are enabled, that at some point the image processor may be unable to keep up with developing, compressing, bit shifting, as well as various personal hygiene activities (protocol handling, error checking, self-diagnostics, etc.).

Could it be we're asking the PRIME II and its hardware implementation to do entirely too many thing to too many bits?

If you've kicked this around, Gordon, I'm afraid I didn't find it.

We've had our testers turn off all JPEG processing that can be turned off, including distortion and aberration correction, and JPEG noise reduction, with the results as to to raw buffer depth as posted and as specified by Pentax Japan: about eight frames to buffer full (actually should be specified as "for ISO sensitivities below ISO 6400"). No doubt turning on some of those things reduces the buffer depth from this.

Regards, GordonBGood

Reply   Reply with quote   Complain
GordonBGood
Veteran MemberPosts: 6,286
Like?
Re: 128mb buffer in my estimation...
In reply to glanglois, Oct 25, 2010

glanglois wrote:

Thanks for responding, Gordon.

I'm afraid I didn't make myself clear, though. I understand that testing was done without special processing options.

I was suggesting that the image processor may have too much to do even without the options invoked - that "business as usual" is becoming too much for it.

Or did I miss something in your response?

Geoffrey, I think that you are under the common misconception of how much that the CPU actually has to do with image processing for a modern digital camra as do many who are used to desktop computers where the processor does everything. Typical camera CPU's (even for current designs) only operate at 100's of MHz rather than GHz and have very little to do with image acquisition, image processing pipeline, or image output compression as it would take much too long; thus, these types of task are performed by the hardware image processing engine. In fact, it is because "add-on" processing such as the lens corrections, HDR image alignment, or perhaps some new types of noise reduction, are not already designed into the PRIME II imaging engine that they are slow.

In order for the K-5 to acquire full size images at up to seven frames per second (fps) for a throughput of over 200 MBytes per second, it is quite certain that the transfer process is set up by the CPU but that the actual data is streamed directly to the RAM buffer. In a similar way, for the camera to be able to shoot JPEG's, including developing such JPEG's, continuously at quite high rates also requires processing speeds far above the capabilities of the camera CPU. Finally, as a modern 2 GHz plus desktop CPU takes in the order of a second to compress JPEG's or raw data of this number of MP, there is no way that the camera CPU could maintain the throughput it does without help from the dedicated imaging engine.

I think that you will find that the actual CPU of a modern camera doesn't actually do that much other than setting up the above options other than for the cases where the camera does something that the imaging engine was not designed to help; in those cases such as lens correction, HDR alignment, and new types of noise reduction, the operations are slow.

Regards, GordonBGood

Reply   Reply with quote   Complain
GordonBGood
Veteran MemberPosts: 6,286
Like?
K-5 RAM size
In reply to falconeyes, Oct 25, 2010

falconeyes wrote:

GordonBGood wrote:

Falk, as you see from my current thinking, it is more likely that the total DDR RAM memory size is 512 MBytes for both the K-7 and the K-5, with about 270 MBytes used for the raw buffer and the rest (242 MBytes) used for other purposes as in the RGB buffer for developing images, etc. You are right that there is now need for the area of memory used for buffer to be exactly a power of two.

Yes, I saw this and you may be right. However, it seems like the area reserved for the write buffer about stayed the same. Which means that the area used for general processing remained about the same too. And that other area's size should be at least proportional to the MP count. And if it didn't change much eating from the buffer, then it must not be large. Therefore, my bet would be like a 150+100 MB memory layout.

Proportionally, the increase in buffers may not be that big. Given one buffer to do all RGB image processing (other than noise reduction, which requires both an input and output buffer) and given that the RGB buffer needs to have a 16 bit depth, also given that the raw compression buffer needs to be large enough for the "capped" output raw size, I estimate the RAM use as follows:

K-7

RGB processing buffer: 15 raw MP by 6 bytes per pixel = 90 MBytes.
Another same size buffer for Lens Correction and NR computations: 90 MBytes
Raw compression buffer (12-bit) = 15 MP by 1.5 = 22.5 MBytes
Raw capture buffer: 12 images by 22.5 MBytes per image = 270 MBytes.

Total: 475.5 MBytes, which leaves about 30 MBytes for other unknown purposes if used at all and if the actual RAM size is 512 MBytes.

K-5

RGB processing buffer: 16.4 raw MP by 6 bytes per pixel = 98.4 MBytes.
Another same size buffer for Lens Correction and NR computations: 98.4 MBytes
Raw compression buffer (14-bit = 16-bit) = 16.4 MP by 2 = 32.8 MBytes
Raw capture buffer: 8 images by 32.8 MBytes per image = 262.4 MBytes.

Total: 492.0 MBytes, which leaves about 20 MBytes for other unknown purposes if used at all and if the actual RAM size is 512 MBytes.

Using similar computations:

K-x

RGB processing buffer: 12.5 raw MP by 6 bytes per pixel = 75 MBytes.
Another same size buffer for Lens Correction and NR computations: 75 MBytes
Raw compression buffer (12-bit) = 12.5 MP by 1.5 = 18.75 MBytes
Raw capture buffer: 4 images by 18.5 MBytes per image = 74.0 MBytes.

Total: 242.5 MBytes, which leaves about 13.5 MBytes for other unknown purposes if used at all and if the actual RAM size is 256 MBytes.

K-r

RGB processing buffer: 12.5 raw MP by 6 bytes per pixel = 75 MBytes.
Another same size buffer for Lens Correction and NR computations: 75 MBytes
Raw compression buffer (12-bit) = 12.5 MP by 1.5 = 18.75 MBytes
Raw capture buffer: 9 images by 18.5 MBytes per image = 74.0 MBytes.

Total: 335.25 MBytes, which doesn't work out to an even binary RAM size.

Alternatively, the two raw buffers may be two bytes per photosite, which may save time during acquisition and speed continuous frame rates just as for the K-5, which will make them 25 and 225 MBytes, respectively, in which case the total memory use would be 425 MBytes, so for a 512 MByte RAM space there would be all sorts of room for an extra "special" raw noise reduction buffer used for high ISO chroma noise reduction without reduction of the raw buffer size.

Note that I have reduced the expected raw buffer size from what is actually seen by the computed number of images written out during the time until the buffer is full.

Regards, GordonBGood

Reply   Reply with quote   Complain
glanglois
Contributing MemberPosts: 987Gear list
Like?
Thank you, Gordon
In reply to GordonBGood, Oct 25, 2010

I was, in fact, assuming that the "imaging engine" was software run by a GP processor. It seemed reasonable that there were ASICs involved at some point but I had no idea which roles they may play. You've helped there.

Of course, even ASICs and other special purpose processors have finite throughput limits. I think I've just shifted the question and made it more general: are we seeing a processing limit or a buffer size limit?

As an aside, I'm entirely too familiar with a case in which the ASICs in a device could handle a great deal of work as long as the demand upon it wasn't unusually lumpy. The demand was, in this case, rather lumpy and the result undesirable.

After a series of conversations with the device vendor about queuing and buffering, it appeared that a larger input buffer had been tried and actually reduced throughput. The only solution was a different (read: "more expensive") model with new ASICs.

Perhaps I'm reading too much of that situation into this one?

PS: I just noticed the conversation you and Falk had yesterday around noon my time. Perhaps all of the above was entirely unnecessary and I'm sorry if I created a distraction rather than an elaboration.

Reply   Reply with quote   Complain
ET2
ET2
Veteran MemberPosts: 3,840Gear list
Like?
Bigger Buffer is better
In reply to GordonBGood, Oct 25, 2010

GordonBGood wrote:

1) Adding the option of 12-bit raw output bit depth, which would make raw buffer depth a more competitive about 12 frames at 7 frames per second (fps) with about a 1.4 fps buffer full rate and about 10 seconds buffer clear time. Competing cameras may have a deeper raw buffer, but they also have a corresponding longer buffer clear time so the above might be considered optimal. Some Nikon D7000 raw modes will have faster buffer full fps and buffer clearing times for the size of buffer due to the files being about two thirds the size of those of the Pentax compressed formats ("virtually lossless" Nikon NEF format).

Bigger buffer is always better. Yes, the buffer clear time maybe longer but you are never even going to fill the buffer in normal use anyway, so that won't even be an issue.

Bigger buffer is better.

Reply   Reply with quote   Complain
RonHendriks
Regular MemberPosts: 108Gear list
Like?
K-7, up to 17 RAW in Hi-shooting burst!
In reply to GordonBGood, Oct 25, 2010

Just did a test with my K-7.

Settings:

M-mode; 1/500th second; f5.6; iso100; Manual Focus; lenscap on; Hi-continuous shooting.

With this I could make a varius of numbers in a burst from 14 to 17. Only in Live-View I could get past the 14 and even had one burst of 17 shots. The size of the DNG-files where just under 10 MB.

I used a class 10 32 GB card wich I tested on read/write speed and it's topwritespeed is about 16 MB/s. The cardtest you can find: http://www.flashmemorytoolkit.com/

So how would this test run on a K-5???????????????????????????

 RonHendriks's gear list:RonHendriks's gear list
Pentax K-01 +2 more
Reply   Reply with quote   Complain
telfish
Junior MemberPosts: 46
Like?
Re: K-7, up to 17 RAW in Hi-shooting burst!
In reply to RonHendriks, Oct 25, 2010

RonHendriks wrote:

Just did a test with my K-7.

Settings:

M-mode; 1/500th second; f5.6; iso100; Manual Focus; lenscap on; Hi-continuous shooting.

With this I could make a varius of numbers in a burst from 14 to 17. Only in Live-View I could get past the 14 and even had one burst of 17 shots. The size of the DNG-files where just under 10 MB.

I used a class 10 32 GB card wich I tested on read/write speed and it's topwritespeed is about 16 MB/s. The cardtest you can find: http://www.flashmemorytoolkit.com/

So how would this test run on a K-5???????????????????????????

I get 9 frames at 9.92 MB with a K5 which is interesting, as the file sizes are the same yet I get less frames?

Terry

Reply   Reply with quote   Complain
Dale108
Dale108 OP
Veteran MemberPosts: 5,987
Like?
Re: K-7, up to 17 RAW in Hi-shooting burst!
In reply to telfish, Oct 25, 2010
Reply   Reply with quote   Complain
telfish
Junior MemberPosts: 46
Like?
Re: K-7, up to 17 RAW in Hi-shooting burst!
In reply to Dale108, Oct 25, 2010

Dale108 wrote:

Hi Terry:

So was your result with a K5 or K7?

Dale
--
http://www.pbase.com/abundant108

http://www.pentaxphotogallery.com/home#section=ARTIST&subSection=272176&subSubSection=1787360&language=EN

With a K5 Dale, not really sure why it should be so different!

Reply   Reply with quote   Complain
GordonBGood
Veteran MemberPosts: 6,286
Like?
Re: K-7, up to 17 RAW in Hi-shooting burst!
In reply to telfish, Oct 26, 2010

telfish wrote:

Dale108 wrote:

Hi Terry:

So was your result with a K5 or K7?

Dale
--
http://www.pbase.com/abundant108

http://www.pentaxphotogallery.com/home#section=ARTIST&subSection=272176&subSubSection=1787360&language=EN

With a K5 Dale, not really sure why it should be so different!

The K-5 is different than the K-7 because of how it uses the raw buffer in that the actual raw output file sizes aren't so important other than flash memory card write speeds, which allow the camera to clear more images before the buffer is filled up. For the K-7, the raw buffer is being stored as three bytes per two photosites (byte packed), whereas the K-5 is storing two bytes per photosite to better support the eventual compression to 14-bit output raw files (and maybe to help increase the acquisition speed from 5.3 frames per second (fps) to 7 fps.

Regards, GordonBGood

Reply   Reply with quote   Complain
falconeyes
Senior MemberPosts: 1,200
Like?
Re: K-5 RAM size
In reply to GordonBGood, Oct 26, 2010

GordonBGood wrote:

falconeyes wrote:

GordonBGood wrote:

Falk, as you see from my current thinking, it is more likely that the total DDR RAM memory size is 512 MBytes for both the K-7 and the K-5 [...]

Proportionally, the increase in buffers may not be that big. Given one buffer to do all RGB image processing (other than noise reduction, which requires both an input and output buffer) and given that the RGB buffer needs to have a 16 bit depth, also given that the raw compression buffer needs to be large enough for the "capped" output raw size, I estimate the RAM use as follows:

K-7

RGB processing buffer: 15 raw MP by 6 bytes per pixel = 90 MBytes.
Another same size buffer for Lens Correction and NR computations: 90 MBytes
Raw compression buffer (12-bit) = 15 MP by 1.5 = 22.5 MBytes
Raw capture buffer: 12 images by 22.5 MBytes per image = 270 MBytes.

Total: 475.5 MBytes, which leaves about 30 MBytes for other unknown purposes if used at all and if the actual RAM size is 512 MBytes.

K-5

RGB processing buffer: 16.4 raw MP by 6 bytes per pixel = 98.4 MBytes.
Another same size buffer for Lens Correction and NR computations: 98.4 MBytes
Raw compression buffer (14-bit = 16-bit) = 16.4 MP by 2 = 32.8 MBytes
Raw capture buffer: 8 images by 32.8 MBytes per image = 262.4 MBytes.

Total: 492.0 MBytes, which leaves about 20 MBytes for other unknown purposes if used at all and if the actual RAM size is 512 MBytes.

Hi Gordon,

You make a number of assumptions here, like that image processing is done by full frame buffers rather than in an image pipeline. I'm not sure I have enough information to go that far in my speculations. Image pipelines are more memory efficient, faster and teached to imaging engineers. It may also explain why some operations which can only be done efficiently on a buffer level (robust alignment, state-of-the-art NR, auto-expose a JPG after the shot etc.) aren't available in the firmware. Moreover, I don't think the K-5 writes anything but fully processed raw images into the write buffer. E.g., I tried and the K-7 can maintain full 5.2fps forever if you make the JPGs small enough (1 star quality at 14.6MP). This means that the RAW processing pipeline is fast enough to write (the smaller) fully processed and compressed raw files into the buffer. And because High ISO raws are larger, the buffer holds less of them. Also, enabling RAW+JPG should make the buffer smaller then which I guess it does.

I know it is reported that the K-5 raw buffer doesn't get deeper with 10MB lens cap raws (still only 9 or 90MB total). But we don't know the reason for this. The write buffer being in frames rather than files would just be one possible explaination.

If I must speculate (I don't), then I would assume an image processing pipeline starting from two 32MB A/B image buffers where buffer A is processed while buffer B is read from sensor. Plus an image pipeline and a write buffer. I don't say the memory isn't 512MB. I only say that it can be done in 256MB too. The memory layout then would be like 150MB buffer + 100MB processing.

The topic is fascinating. Because a change from a 100% pipeline architecture (if this is what is used now) to a partial buffer architecture (requiring more on board memory and more memory bandwidth) allows new opportunities. Like in-camera panorama stitching, more robust auto alignment (the one in the K-5 can be fooled), image stacking for reduced noise/increased depth of field (macro) moving subject removal/simulated low iso, focus/SR bracketing and keep sharpest, and many more. I wonder how the HDR is implemented. However, it disables burst mode and may simply reuse the write buffer. So, there may already be limited use of a buffered images architecture when pipeline processing is not active.

Reply   Reply with quote   Complain
Keyboard shortcuts:
FForum MMy threads