Ok, I can tell you that the flash chips themselves:

* There are two layouts, small and large.
* Have 512 byte pages, or 2048 byte pages
* Each page has "out-of-band" data of 16 bytes or 64 bytes. The OOB data is used for error correction, filesystem info etc.
* Pages are written individually - you should write a whole chunk of 512 or 2048 bytes.
* A set of pages are arranged in a block. A block is 2k or 128k. Only the whole block can be erased.
* The number of pages is always a power of 2.

So, your differences can be accounted in two ways:

1. Bad blocks. Can't remember the figures, but I think a max of 5% or 10% bad blocks is the max.

2. Reserved blocks. These are "set aside" for when a good block fails. The controller can copy the data out into a reserved block and ditch the bad block. It will do this without you knowing at all - and to do that it needs these reserved out of the set.

So, maybe a manufacturer may use the HDD term for a gigabyte, but use the extra 2.4% for reserved blocks.

And, as I mentioned, different manufacturers have different qualities and capabilities of controller (the bit that glues the SD interface to the NAND flash chips). Some controllers are dumb and will corrupt your file when a bad block occurs, other controllers will copy it to a reserved block and preserve the file.

The trouble is, there's never much information on extactly what the controller chips can manage...

Hope that explains a bit
Matt

Not 100% true for flash memory. It is true for HDDs.
But you are right about the bad blocks. However, some manufacturers reserve some of the good blocks ready to swap out an acquired ad block, so that you'll have a consistent amount of space. The bad block management and error tolerance does vary, depending on the quality of the controller. That was definitely the case with CF, but I'll have to double-check SD.

I use the raw chips in our electronic products, and have been writing firmware to use them for many years. xD-card and MMC are raw NAND flash chips (ie no controller chip)

Matt

Ok, so I've had a little time (insomnia again!) to look at the RAW formats. Interesting results!

I took the SD-CF adapter, put a brand new Kingston 133x 1Gb card into each camera:
*ist-D = 67 RAW shots
*ist-DS = 90 RAW shots

Next I take almost the same shot on both cameras onto the one card. What's interesting is that both cameras can preview each other's image. The newer camera (the *ist-DS) can view the EXIF data for both, whereas the older (*ist-D) cannot view the EXIF data for the newer.

I then take a look at dcRAW, extract the embedded thumbnail and find the thumbnail is pretty tiny in each case - about 1.1Mb and no difference to write home about (1.10Mb vs 1.08Mb).

Finally I resort to viewing the files in a hex editor and I find the main cause of difference:
The *ist-D uses 16-bits of storage per CCD pixel
The *ist-D uses 12-bits of storage per CCD pixel

Which is really obvious when you think about it. The CCD has a bit depth of 12-bits, and the *ist-D is just wasting storage space (filling the extra four bits with zero). That calculation would make the *ist-D use 11.5Mb (12,080,128 bytes) for the CCD RAW, and the *ist-DS use 8.6Mb (9,060,096 bytes). Taking into account the 1.1Mb embedded JPG, and other tables and data those values pretty much tally.

So, actually neither camera is using compression... it's just that the *ist-D stores the extra zero bits to make it 16-bits wide.

Could it be changed in the *ist-D? Probably. Will it be changed? I doubt it, given firmware development costs (mostly in terms of time).
I suspect that the RAW convertors just read the TIFF header within the RAW file (because that's largely what these RAW files are) and decode appropriately. There's certainly nothing "hard coded" regarding image file format within dcRAW.

So I hope that explains everything!!
(And, by the way, the adapter seems to work very well in the *ist-D - a RAW file takes roughly 8.5 seconds. However there is a slight pause when you power up, almost as if the adapter is "booting up" and working out the SD card. I think I'll buy SD cards from now on )
Matt

It's already been answered:
https://www.pentaxuser.com/forum/viewtopic.php?t=2513&highlight=4gb

The answer's no

But if they did work they would not drain the power any more quickly
In some ways you are better off spreading your images across a few cards - just in case a card goes bad (which they can do from time to time).

Hope that helps!
Matt

The D motor is much more powerful. I just checked with an SMC-F 50/1.7 and the D really whips it round. The DS is infinitely more leisurely and can be stopped fairly easily.
They probably expected you to be using huge lenses on the D.

Let's hope they put the power AF motor on the new D replacement...

Incidentally, getting back on track - I received an SD-CF adapter from DigitalEra in the UK. Speedy delivery, and works exactly as it says. I shoved a 256Mb SD card in the adapter and put it in the *ist-D. No problems.

Can't give you any timing tests... will have to wait until I get the faster SD cards delivered.

Matt

Daniel,
I'll check out the DS vs D format in dcRAW when Iget half a chance.

Yes, the DS is achingly slow at focus compared to the D. I don't think it's the lens at all, but the body. The grip is mire 'positive', and the shutter is 'softer'. Still prefer the D overall

Matt

As far as I am aware, none of the current Pentax cameras have any form of compression in the RAW format (I know because I've looked through the source code of dcRAW). Lossless compression, like the Huffman encoding in DNG, is something I've been hoping Pentax will produce for the next run of DSLRs, and that should give something like 50%.

For RAW it could be: a) a difference in the way the thumbnails are created, b) differences in the CF & SD technologies.

I'll let you know about the differences - have a D already, and a DS arriving today. I'll try and set something up.

I do know that CF and SD technologies are very different. It might be down to how the spare data is used in the flash blocks. You see each page of 512 bytes (or 204 has an extra chunk of information that's used for the filesystem linking, ECC (error correction), and the like. I'd have to double check the details as I mainly work with bare NAND-flash chips (which is what xD and SmartMedia cards are).

In addition, all flash media has bad blocks (either shipped, or acquired). Normally you don't know about those blocks, except perhaps that when you check the exact size of the card it isn't quite what you expect

Edit: Have tried a few shots with the *ist-DS. My guess is that the thumbnail JPG isn't as large in the DS PEF, compared to the D PEF.
And also - what a completely different shutter sound they have! I thought they'd be the same. Even the grip is a bit more "definite" on the DS, though the grip part at the rear is a bit "sharp".

Matt

You could preempt the situation:
http://cgi.ebay.co.uk/CF-Compact-Flash-Adapter-for-SD-MMC-Card-512MB-1GB-2GB_W0Q...

In the UK: http://www.digitalera.co.uk/detail.html?productref=89 (SD card does not protrude!) Type II CF (suitable for the *ist-D)

Note: Maplins in the UK sell one where the SD card does protrude, so won't fit in the *ist-D.

Matt

I have some fine dust particles on the inside front element of my SMC-FA 24-90. It's annoying, but doesn't affect the images.
I was going to try the suggestion of using an anti-stat gun (as for vinyl LPs) which should dislodge it... I'll let you know if I succeed.
Matt

For me I reckon lugging around a background would be a real pain. I don't even bother with a tripod - I prefer to move quickly.
I'd much rather use the f1.4 lens.

But then it depends what kind of shots you (and the B&G) want. Whatever you do just make sure it's quick so you don't overload the B&G, or keep anyone waiting.

Matt