Coded Raw for the Camera Developer/Manufacturer

Key Benefits

• Coded Raw allows technology innovation without waiting for application upgrades;
• Cameras supporting Coded Raw will generate readable files out of the box;
• Coded Raw file structure is suited to devices with embedded recording systems;
• Applications supporting Coded Raw (even third-party applications) will generate quality renders, exactly as the algorithm designer intended;
• Reverse engineering of proprietory encodings is not necessary for cross-application support;
• Proprietary methods can be protected by licence (embedding, and parameter changes);
• Cross-platform and cross-application support;
• Rendering from devices supporting VMs (including mobile devices);
• Coded Raw API will be Open Source and openly documented;
• Photographers will choose a camera that generates images that can be archived confidently and read in the distant future;
• Multiple rendering methods from the same raw data (e.g. Sensor-Raw, or JPEG without actually storing the JPEG data) keeps the recorded files small.

The Coded Raw API will allow camera manufacturers to continue making innovations to develop leading products; their images are immediately readable by API-supporting software (proprietary and third-party), without suffering the limitations of an imposed encoding format.

A method licensing structure means that methods (algorithms) may (a) permit or forbid embedding methods into other files, and (b) permit or forbid changing of method parameters from within other applications. This means that software developers can protect their improved application algorithms from use by third-party applications, or just restrict the algorithm for use with the intended picture only.

Scenarios for using rendering methods

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.