I'm still very new to iOS development, so bear with me. 

I've got a TableView using static cells to contain options (click to check), I am able to select the cells fine. I'd like to assign a value (identifier) to each cell, so that when a cell is selected or de-selected I can add/remove it from an array. Then, once the editing has finished, use the references stored in the array to update the respective CoreData attributes.

My google skills have failed me today, so a push in the right direction would be very much appreciated.

Thanks. 


Question: Does the Canon *.CR2/CRW format contain "truly RAW" data?
Answer: I think you are most definitely missing something. Consider: JPG is used to store (and usually compress, lossy) images. Any image. What is an image? It is a great big bundle of pixels, when all is said and done.

The output from the camera sensor is a great big bundle of pixels, too. They just happen not to be full-colour RGB pixels, they are monochrome pixels - whether any individual pixel represents R G or B depends on its location on the image sensor, which is known. But their monochrome, colour-given-by-position nature does not mean that they cannot be usefully stored in the JPG way. A bundle of pixels is a bundle of pixels, and why reinvent the wheel?

Look more closely at the document. "So with a BAYER grid of RG/GB, the even rows has interleaved HuffCode/Diff data for ...RGRGRG..., while the odd rows it is ...GBGBGB...". So, the raw Bayer output is stored in a JPG format. Lossless, it is stated (otherwise we'd have a problem!) and presumably in more than 8 bits' depth. You have too cook this quite a lot to get a useful photo from it. 

The other JPG images are used for in-camera preview, histogram and such. It makes good sense to cook these once and for all as the image is taken, rather than having to do it on the fly each and every time you want to look at them. This also means that the computer can fish these out for thumbnail purposes once you unload the camera into the PC.

* I can't add a comment for some reason, so this goes here:
Goldenmean, what makes you think that there is a problem that you don't have full RGB info for each pixel? Assuming that you are creating a RAW format and have a measurement of 128 from a "red" sensor cell; you can either choose to store this as 128,0,0 or 128,128,128 or, of you are feeling clever, 128,"data from next cell", "data from the cell after that" to save some space. Doesn't matter really. It's the RAW converter's job to keep track of this (though I'm sure the programmers would appreciate it if you documented how you chose to store your sensor data) and make an actual picture from it.