Originally posted by DeadJohn .......Yeah, give us that, and make it a non-encrypted file so we can edit our settings on a computer and also share settings with each other. Rather than scroll through everything on the small rear LCD, see it all on a big screen. Music synthesizers have been doing that for decades.
Well, since I made the suggestion, let me pour some cold water on it now, as to why it probably will not happen any time soon, if at all. However, there is a smidgen of hope - in that Pentax did release the recent set of API SDKs for the USB interface. That actually is a very positive step, that could possible hold out some hope here. Especially, since the same set/type of problems would occur within the USB interface.
First, let me say, obviously I don't work for Ricoh/Pentax and have no absolute direct or indirect knowledge, but I would have to guess that their software engineers already have such an application on both their desktops/laptops and on their smartphones that they use to troubleshoot problems and extract/analyze/modify/upload data both in the lab and out in the field. I too, use to be an embedded real time software engineer - and this would be among the first tools, I would have created.
So, what's the problem? In a word, data checking as in content, range, size of, type, bounds along with other similar maladies. If they were to dump/reload an encrypted file, then the problems / concerns would be substantially reduced - as Ricoh/Pentax would have absolute control of the content (based on camera body type and firmware version). The main problems arise when users try to mix and match, and especially when third parties can create, modify and update the file.
- Mix and Match - use a file from model X with firmware version Y to update to model X with firmware version Z. Or model A with firmware version B to model X with firmware version Y, etc. You get the idea. In order to bridge the firmware version problem, you then need to go to the concept of labeled data, and the dump or writer functionality, takes on additional intelligence and complexity.
- Third Party utilities - This would be the main area of risk. The newly created/modified file may not have checked or correctly checked the data for goodness/correctness. This could cause all types of problems, both direct and indirect.
- What if there is a problem? - When you go to reload the file, and there is a problem - how do you go about communicating it back to the user in a useful and descriptive way - other than "load failed". Especially with third party support, you need failure information in a way that the user may/can successfully correct the problem. The loader then takes on additional intelligence and complexity.
- $upport Co$t - The co$t of the additional $upport in terms of the added intelligence for both the read/write functions across the camera models and firmware versions would be probably at least 1 FTE engineer. Then you need to balance this against offering this "free" capability will result in any meaningful additional $ale$. These support costs also wash in to the overall camera design - especially the firmware. How much additional memory is this going to take? On the newer models that can be factored in. Also, how do you introduce it into the field - older and current models will not be supported (causing disappointment), while newer models going forward will. Considerations will also need to be made in the maintenance area, where it could both assist and potentially in other area be a detriment.
Overall, I do believe it would be a net plus, but I think I was posting almost 10 years ago that a USB API SDK would be an excellent addition when the tethering capability disappeared after the K20D. So, time will tell.