|
1. Coded Raw files can be read by any API-supporting application.
The API does the rendering, using the code embedded within the file, regardless of the application requesting the render. This means that applications can value-add by providing workflow options, upgraded methods, or intelligent use of parameters for the renders.

2. All applications supporting Coded Raw can immediately take advantage of BIOS upgrades and hardware innovations.
This scenario has a raw file generated by an old BIOS (top), and a raw file generated by the same camera with a BIOS upgrade which writes images in a different format (bottom).

In the conventional workflow, a new raw file format would be a problem to photographers, because the application software updates need to reach all users who need to use the new format. Software updates take considerable resource for each software developer, so it could take a long time before third-party applications can use raw images from a new camera, which would make some photographers reluctant to buy the product.
The Coded Raw workflow has the advantage, because any application supporting the Coded Raw API may read the new file. As the technology matures and software algorithms improve, updates to rendering algorithms can be provided without upgrading the BIOS (see diagram 4, below).
3. Legacy proprietary raw files can be 'converted' into a Coded Raw format.
Here, an old file is encapsulated using the Coded Raw file format, by an application that contains methods written for the original proprietory raw file format. The generated Coded Raw file can then be rendered from any application that supports the Coded Raw API (shown here as Application B). Again, Application A contributed a method that was stored in the Coded Raw file, and Application B called the Coded Raw API to render the raw data.

4. Upgraded methods can easily be used to render a raw file.
An upgraded method (decoding algorithm) is downloaded, and the Coded Raw API uses the upgraded method to interpret the Camera-Native Coded Raw file, overriding the original file's method. The application chooses the method (by looking at versions and preferences), specifies this to the Coded Raw API when rendering or extracting data.
In this case, the workflow progresses no further, because the Interpreter Code v1.01 has its licence set to 'forbid embedding', which means that the code can not be embedded in a saved Coded Raw file.

This example covers a number of scenarios: (a) improving existing algorithms, (b) releasing software updates after BIOS updates (not ideal situation, but at least it is possible to reactively correct methods provided in the BIOS updates), (c) providing the user with choices of renderer for a proprietary raw file format.
In the interests of providing the best possible rendering of a raw file, it is generally recommended that updated methods are given a licence to 'permit embedding'. It is understood that intellectual property of workflow methods (e.g. effects image-processing methods) might need to be protected, so a licensing option is provided to permit or forbid changing a method's parameters (forbidding still allows a render to be called by a third party application, but denies the flexibility of the source application to the third-party application).
5. Where licence permits, upgraded methods can be embedded in Coded Raw files.
Here, the upgraded algorithm has been embedded into the Coded Raw file by the Proprietary Raw Application. Other applications supporting the Coded Raw API may then use the updated method to render the image.

Again, the application can choose the rendering method from those embedded in the Coded Raw file.
|