[ QUOTE ]
....
A standardized file format, including such elements as a rotation tag, would prevent much of this mess. When two software products (Nikon View and Capture)from the same company can't agree on how to process identical files, something is seriously wrong.
[/ QUOTE ]
I don't see how a standardized file format would help here. Unless the problem was caused by a chnage in the Nikon file format. And if that is the case, presumably Nikon had a reason for changing the format, so the chances of a standard would be low, as this would inhibit these sorts of changes.
Steve
White Balance so easy, even our 5 year old can do it.- Melissa Strickland
The files themselves did not change formats. In each case it was the flaky Nikon software that was at fault. That said, some of the edits performed to RAW files by applications such as Nikon Capture break them so the files can no longer be read by other Nikon software. The image data are all stored in tiff format; it's the free-form junk wrapped around the tiff that is the problem. (Actually not true for all raw files - there is the recent Sony abominations of encrypted raws. That's just plain stupid.)
White Balance so easy, even our 5 year old can do it.- Melissa Strickland
In the case of Nikon (or other hw manufacturer) a std file format would not prevent these types of sw bugs. Where it might make a difference is in 3rd party sw trying to use a non-published format, but the relevant point here is if the format is published, not that it is standard. The other thing that std format would do is make some 3rd party sw (those supporting multiple file formats) cheaper, as there would be less file formats to support.
Steve
White Balance so easy, even our 5 year old can do it.- Melissa Strickland
I thought that a camera’s RAW file was specific to that camera, and was often different in specification to other RAW files from different cameras from the same manufacturer. For example, the Nikon D2H RAW format file is different to the Raw file spec from a D100.
One would expect that the RAW data coming out of the LBCAST sensor would be different from that coming out of a CCD, but maybe not.
I know that each iteration of Nikon Capture supports more recently released camera RAW files, and the same goes for ACR, iMatch, etc, etc.
So I can’t see that you could ever standardize on a RAW format. By its very nature, being specific to camera sensors and firmware options, RAW can never be standardized.
White Balance so easy, even our 5 year old can do it.- Melissa Strickland
I think that it would be wonderful if the various manufacturers could agree on a common RAW format, but I'm not holding my breath. If Adobe (or someone else) were to define a "standard" RAW format, there is no guarantee that the camera manufacturers would sign-up for it despite the "clout" that Adobe has in the industry. In fact I have heard from several sources that certain camera manufacturers are quite unhappy with Adobe for creating a RAW plug-in since it takes away sales of their own RAW software. So I wouldn't be surprised to see the opposite happen: encrypted RAW files that only the camera manufacturer's software could open. There are also technical issues with standardizing on a RAW format for all sensors (e.g. what about hexagonal sensors, dual site sensors, and sensors that receive all three colors for each pixel).
The small chance that camera manufactures would standardize on RAW doesn't mean there is no value in a standardized RAW format (SRF). If there were translators from the proprietary formats to a SRF, then software could be made to use the SRF and it would only take a translation step (e.g. during transfer from camera disk to computer) to provide the benefits (e.g. being able to open a RAW file many years in the future). Perhaps the camera manufacturers would even provide their own translation library and license it to recoup their costs, but such licensing would likely favor large software companies that could amortize such fees across huge volumes of software sales.
May I suggest another idea for a new SLF format: 16 bit linearized data (e.g. a 16 bit TIFF file would suffice - but PLEASE NOT TIFF!). This would be image data that has already been interpolated from the sensor, using whatever algorithms or tricks the camera manufacturers want to use to improve image quality over their competition (e.g. defect maps, noise cancellation, etc). This data would provide all the benefits of RAW (large dynamic range, lossless). The only drawback with this format would be the size increase of about 4x assuming no (lossless) compression (and it would compress better than compression of a Bayer CCD for example). At the rates memory and storage are increasing, I think this would be an acceptable tradeoff.
Other benefits of a SRF or SLF would be standardized handling of meta-data (e.g. captions, keywords) and image preferences (e.g. exposure compensation, color settings), and even weird stuff like linking multiple "raw" photos together.
Regards,
Dennis
White Balance so easy, even our 5 year old can do it.- Melissa Strickland
Nice joke as it shows that best jokes contain things that really could get reality.
>16 bit linearized data
Nice idea. But I also believe that there are many differences between demosaicing algorithms. The linear data would lose all the capabilities to improve demosaicing.
Uwe
White Balance so easy, even our 5 year old can do it.- Melissa Strickland
About the April Fools joke, I'm tempted to use it again (updated of course) since it is still so relevant, especially with regards to this thread. But I have some silly ideas for another one so perhaps not.
I hear you about the "demosaic" algorithms (I've just called it interpolation in the past since you are making-up data that doesn't exist by using neighboring information). I would miss this opportunity myself as I have played with several algorithms including using neural networks (which works well but still a bit too slow), and the algorithms I used for the Kodak 4xx cameras worked better than Kodak's (and then they "locked-down" their format with the DCS-520). But there can't be a "standardized RAW format" (SRF) without some fairly descriptive ways to express varying sensor layouts, and I don't know if anyone has made any suggestions about this topic. And if you did have this sophistication then you would be placing a huge burden on the reader of the format since it would have to read all possible sensor formats and have a universal algorithm for doing the interpolation based on physical layout and response properties - YIKES! It would be somewhat like JPEG - it is easy to be a JPEG writer but not so easy to read all possible variations of JPEG.
As I mentioned in my April Fools followup, it is technically possible to take a number of RAW formats and convert them into a Kodak DCS 4xx format, and then call that "a" standard, but that obviously isn't what you would want to do. Creating a less expressive SRF for, say, Bayer sensors is not to difficult, but then it wouldn't be universal.
That is why a linearized 16-bit (RGB) format (SLF) has most of the advantages of a SRF without the headaches of interpolation. And that is also one BIG reason why the camera manufacturers could fathom adopting a SLF - they can keep their own interpolation (and many other) algorithms secret.
Dennis
White Balance so easy, even our 5 year old can do it.- Melissa Strickland
Linear Mode
