[johnmflores]

So they have enough time to add memory at the last minute, but not enough time to make a simple change to the firmware to utilize it? I find that very unlikely. Do you really think the production line was only started up after the release of the D7000 to be able to get that memory in there?

Yes. The QA and testing process that Paul described above could easily take weeks. To do it right, you've got to test the camera under every possible condition and with every possible combination of settings. Just look at all the different possible combinations of camera modes, drive modes, AF modes, etc... and you've got a lot of testing.

If they didn't do that, it would be just a matter of time before someone in the forum would find the bug and declare that Pentax is doomed!

[Gimbal]

In an embedded system (such as a camera) where the user can't change the memory size you don't waste time scanning for the amount of installed memory each and every time the user switch it on (as a PC do during boot up) since it will never ever change. You state the amount available in the firmware and start running from there. So it is plausible (as they say in Mythbusters) from a technical point of view that you need a new firmware to take advantage of any extra memory installed.

But did they have time to change it? Or where they sneaky enough to use the larger memory from the beginning to have the option of enabling it (if the competition demands it) or switch to a smaller memory after a month should they not need it?

[falconeye]

Larger buffer might actually be HW?

No nonono

[Gimbal]

Because...

[johnmflores]

I'm in the "it's hardware" camp. If it's software and a more efficient way of fitting things in the buffer, then might we also see firmware upgrades to the K-r and other recent cameras that can take advantage of the new trick?

[jolepp]

In an ideal case having the option for doubling the memory would just mean one more trace for an extra address line to a pad that was there, but was NC with the lower capacity chips. Then again, usually the parts are sourced, production lines reserved etc. months in advance, so I'd consider it more likely that any increase in raw capacity is due to more efficient use of memory by the new firmware (*). Also, if the amount of memory was doubled, it should also mean getting more jpegs before it runs out. A change to support more memory in the FW could be simple, but they might also have stringent QA (testing) requirements which could have prevented any last minute changes making it to initial production.

(*) A likely thing would seem to be optimizing the raw compression for much greater speed, or maybe using a quick-but-not-so-efficient algorithm initially and leaving the final compression phase with a slower-but-more-efficient one for later.

[Col]

Speaking to Pentax at PhotoPlus Expo in New York | Enticing the Light
In the link provided by Peter Zack. It appears Ned Bunnell lays the blame for the initial 8 frame limit entirely on the software engineers in Japan messing up. He's really getting a bit blunt ATM with Japan HQ

[jolepp]

Speaking to Pentax at PhotoPlus Expo in New York | Enticing the Light
In the link provided by Peter Zack. It appears Ned Bunnell lays the blame for the initial 8 frame limit entirely on the software engineers in Japan messing up. He's really getting a bit blunt ATM with Japan HQ

Then it could be something as "simple" as [originally] compressing the images as they are being written to the SD card, having to wait for the slow write operations (which are the underlying cause of the limitation). Now [with the new firmware], maybe, they compress as they buffer (to RAM), or maybe compress the images in the queue waiting to be written on SD thereby freeing memory. Incidently, the latter would seem to require a much more complex data structure for efficient memory use which might be why it was left as we-do-it-later and didn't make it to the initial production firmware. (They might have had the modification ready, but not trough QA yet, which would actually be to their credit, IMHO :-)

[falconeye]

Then it could be something as "simple" as compressing the images as they are being written to the SD card

Nothing is simple here.

The engineers had to squeeze out the last bit of performance out of a processor introduced with the K-m and made for the 1.1 fps 645D. I.e., they all of a sudden had to fully process and then compress 16.4 MP 14 Bit raw data at 7fps in real time. I can very well understand how they missed this performance goal on the first deadline.

The entire processing, device capture to ready 16MP DNG (or JPG) file, takes less than 140ms. This is less than the blink of an eye. With a 100MHz processor or so.

Try to do this at home, e.g., with your trusted Lightroom.

And then come back and talk about "simple". Sometimes, I really wished the few excellent software engineers out there earned a bit more credit, respect and money

[Col]

Nothing is simple here.

edit

And then come back and talk about "simple". Sometimes, I really wished the few excellent software engineers out there earned a bit more credit, respect and money

Totally agree I used to enjoy the published interviews with the Pentax engineers as to product development. Something that appears to have stopped under the new ownership. I was very surprised that Ned allowed himself to be quoted on blaming the engineers directly.

[sjwaldron]

It appears Ned Bunnell lays the blame for the initial 8 frame limit entirely on the software engineers in Japan messing up. He's really getting a bit blunt ATM with Japan HQ

I highly doubt the engineers forgot or messed up. It's just some marketing speak for a release date that didn't give the engineers enough time to make efficient use of camera resources. I think we will see quite a few improvements in firmware as the months move by. The nice thing is Pentax does bother to dedicate some of their people to keep improving on a product in software once it is released.

Nothing is simple here.
The engineers had to squeeze out the last bit of performance out of a processor introduced with the K-m and made for the 1.1 fps 645D. I.e., they all of a sudden had to fully process and then compress 16.4 MP 14 Bit raw data at 7fps in real time. I can very well understand how they missed this performance goal on the first deadline.

Thanks for the reality check falconeye. I agree with you.

I also think it's likely that the K-5 is using a lot of the same electronics as the K-7 to save on production costs, which would explain the processing speed bumps compared to the K-7. The board with CPU, RAM, and support components are probably exactly the same. The money pinchers probably told the engineers to work with what they had CPU/RAM wise as they were spending a lot on other parts of the camera (AF sensor, integrating the Sony CMOS sensor).

For example, I can set the K-7 to ISO 6400 with high noise reduction and get 13 full speed RAW DNG frames before the buffer gets saturated and the camera slows down. Add an extra 2MP, 14-bit raw, and more noise reduction without modifying the underlying code nets us about what the K-5 is currently able to do.

It also explains why this firmware update will at least initially only work with PEF format as the engineers probably are better able to extract speed out of that full pipeline to the SD card than DNG. If it had a physically larger buffer I don't see why PEF would be the only format to get a speed increase.

flash.

I highly doubt it has flash memory for the buffer, especially since using it for a buffer would be questionable given that it has limited lifespan. It's most likely DDR2 SDRAM and most likely the same exact amount the K-7 has. Firmware and custom setting storage on the other hand is flash or some other variant that can store data without power.

[Gimbal]

Nothing is simple here.

The entire processing, device capture to ready 16MP DNG (or JPG) file, takes less than 140ms. This is less than the blink of an eye. With a 100MHz processor or so.

That does sound a little bit to hard. 100 (million cycles) times 0,14 gives 14 million instructions per picture. Each picture made of 16.3 million 14 bits words. So less then one instruction per word (assuming risc µp). I would say that requires some special hardware to pull that one off.

And of course they do have special hardware so it is not undoable, although it is impossible to tell how hard it is since we don't know what the "special" hardware can do.

[jolepp]

That does sound a little bit to hard. 100 (million cycles) times 0,14 gives 14 million instructions per picture. Each picture made of 16.3 million 14 bits words. So less then one instruction per word (assuming risc µp). I would say that requires some special hardware to pull that one off.
...

Quite. Then again there might be no point using a faster CPU as the SD write speed bottleneck would still be there. Also, a lower clock speed CPU gets more done / energy used, so this would be good for conserving batteries as well as development costs.

[JamieP]

It appears Ned Bunnell lays the blame for the initial 8 frame limit entirely on the software engineers in Japan messing up.

I was very surprised that Ned allowed himself to be quoted on blaming the engineers directly.

I don't think the comments in the blog article are that direct and the article clearly says that all comments are paraphrased. It is not accurate to make such conclusions from this type of article. I can see getting that impression from the article, but don't want this to spin into "Ned at war with Pentax Japan" like many other internet tall tales.

Maybe Miserere can provide some more context around this part of his discussion with Ned.

[jolepp]

...
And then come back and talk about "simple". Sometimes, I really wished the few excellent software engineers out there earned a bit more credit, respect and money

The quotes around "simple" were to convey the idea that this isn't in fact so simple: I'm all for more appreciation for SW engineers like myself .