[CREATE] ORA fullscreen viewers

[Alastair M. Robinson]

Hi :)

On 10/09/10 19:28, Luka Čehovin wrote:

> I think we should start working on the solution for this problem step
> by step. First we need a baseline/reference for storing and loading
> ora files that is capable of accessing all the data elements in some
> platform independent manner.

So a separation of storage and interpretation?  Probaby a good idea, 
given the ambitious goals of ORA.

> After that a viewer can be built for a
> specific platform using this library and some graphics library that
> actually handles rendering. Putting all this functionality in one
> library and expecting it to render a single raster for you would be
> either a lot of work and a lot of code to maintain or would require
> using a lot of external dependencies (in my vision the basic library
> should be similar to libpng in terms of external dependencies).

Well by all means have a low-level library analogous to libpng - just 
bear in mind that if using such a library is too burdensome for 
application developers it won't be used.  I don't want to sound 
pessimistic here, because ORA's a great idea - but there are two ways it 
could go horribly wrong:

1. The reference library doesn't provide enough functionality, and 
leaves the application developer to implement various filters, blends 
and colourspace conversions.  As you rightly point out, this is a lot of 
work, which in this scenario has to be duplicated in each application 
that suports ORA.  As a result, support for ORA remains patchy, and 
those applications which do support it have incomplete or bug-ridden 
implementations.  End users find that using ORA causes them problems, so 
avoid the format.

2. The reference library provides application developers with a way of 
getting a flat pixel buffer from an ORA file, but doesn't support all 
the blend modes and filters.  In this case, many applications will 
rapidly gain ORA support, but end users will once again find that their 
images don't appear correctly, and again get the impression that the 
format can't be "trusted" and should be avoided.

To my mind the best solution would be to have both a high-level and 
low-level interface - so apps which can handle layers, blend modes, etc, 
would use, say, libora_lowlevel, and apps that don't care about the 
composition of the image but just want to display or print it can use 
libora_highlevel to get a flat pixel buffer.  If the high-level library 
doesn't support all blend modes, etc, then fair enough - that can be 
improved over time.  What is vital, however, and I cannot emphasize this 
enough, is that if a user attempts to open an ORA file that makes use of 
unsupported features, the user *must* be informed that the flat pixel 
buffer is only a best-effort rendition.

Wow - I'm in blowhard mode tonight - hope someone finds these thoughts 
useful anyway. :)

All the best
--
Alastair M. Robinson