[CREATE] ORA fullscreen viewers

[Luka Čehovin]

Hello,

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

Yes ... it is a start. The goal of ORA is a really big one and it does
not look (at the moment) that we have the coding-power to accomplish
everything right away.


> 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:

Those are all valid concerns. Of course I do not expect everyone to
use this library (lets call it libora) the same way as some people
write their own decoders for png. The important thing is that there is
some standard way of specifying the baseline that the community stands
behind and calls it the implementation of the X.X version of the
standard.

>
> 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.

Well this is a problem of standardization and it's enforcement. I do
not have experience with such things but in my opinion these
procedures are always tedious and full of compromises. At the end we
can make some tests that work and use them to maintain a compatibility
list ... I do not think there is any other way.

>
> 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.

Yes ... we do not want to go that way. Of course with all the planned
features for ORA (vector layers, text layers and such) it is hard to
imagine that a simple library would be able to render all that ...

>
> 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.

Yes ... that was my idea as well. But first we need the low level
reading of layers and metadata and attributes ... then we can create a
pure software based compositor ... of course in many cases using
external library will be faster ... but you could get something out of

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

Thank you for your thoughts ... as you can see we should talk even a
bit more to sort out the details ... but at the end we will also have
to get to work and actually code things :)

cheers,

-- 
Luka Čehovin
http://luka.tnode.com