Features:

• API and associated file format that allows embedding of plug-in VM byte-code (e.g. Java).
• Methods embedded within a raw file can describe the associated raw data, without the application needing to know how to interpret the raw file.
• Object-oriented approach, where the methods may also be overridden by applications, so that improved algorithms can be used in future, and the embedded algorithm is then regarded as an archival fallback.
• The architecture is extensible, and may be periodically ratified.
• Supporting standards may be created, both for source raw files, and for the version of API support. Thus, updated methods can be matched to files.
• Locally enumerated and named embedded resource chunks, which may be accessed by the API.
• Enumerated and named published embedded properties are optionally supported by implementors, which may be queried through the API. Initially, this will query the EXIF data elements, but may be expanded to query other locally-enumerated or named resources. Property implementation remains with the embedded code.

Benefits:

• Cross-platform interpretation of raw images.
• Cross-application interpretation of raw images, and also of subsequent workflow processing, such that the original applications are not required to perform the intended rendering.
• Standard outputs can be obtained without the use of proprietary software; the image knows how to render itself, and query its raw data.
• Manufacturers and software developers can write methods to suit new technologies, without necessarily upgrading the API. For example, where a CCD uses a new interleaving technique during encoding, the embedded method knows how to de-interleave the image. Consider this API support on a parallel with graphics card manufacturers writing OpenGL drivers for their new cards.
• When a manufacturer ceases support for the image format, the existing method, embedded in the file, knows how to express itself in a standard format, compliant with an API revision.
• Storage burden is lower, while keeping the ability to offer multiple renderings from the same raw data.
• The original raw file may be extracted, using one of the required methods.
• Where standards allow, a pre-rendered low-level stream of raw sensor data can be extracted.
• Manufacturers can still protect their intellectual property rights while developers can access their raw files, because their own proprietary raw formats do not need to be 'reverse engineered' to be interpreted correctly; the API and the embedded methods do the work.
• Versioning and certification of the methods and the API would give the workflow a 'quality assured' interpretation.
• The API would allow published parameters for renderings. These parameters carry defaults, but may be adjusted through the API. This gives the possibility of alternate renderigs, e.g. of different exposure, colour balance, sharpening, noise reduction, etc. Decisions on the degree of flexibility offered by the parameters remain with the manufacturer or developer.

• While Java has many features that make it the ideal choice for the embedded byte-code and interface (mature, documented, standardised, recognised, archived, object-oriented, open, portable, technically competent, current and continuing), is it the correct choice for the API? A custom VM would be difficult to perfect, and an unwelcome distraction.
• Will manufacturers support the API by writing methods?
• Will manufacturers support the API direct from camera?
• Will software developers use the API?
• How much support can the API give to extending the workflow, e.g. embedding application-specific image processing methods.
• Who can do the feasibility and specification work?
• Will we need to write the first raw interpreters ourselves, before manufacturers give their full support?
• Does this API meet the requirements of all workflow users, e.g. press photographers, landscape artists, designers and pre-press, office users, astronomers, television studios, unskilled amateurs, medical imagers, document archivists and historians. Should we be looking at such a large scope?

• Initially, this API will serve as a wrapper for proprietary raw files.
• This API still allows for a forthcoming open raw format to be embedded as the raw file, just as any proprietary file may be embedded; it will just require that the API methods be implemented for the embedded raw data.

Legal licensing intent

In accordance with OpenRaw principles, where a solution is viable, I require that this API be developed, ratified and versioned under the auspices of a responsible organisation (for example, OpenRaw). IP rights are respected, and acknowledged, but the products and sources are to remain open. I consider this vital to the API's success.