[CREATE] Status of libora?

[Jon Nordby]

On 24 September 2012 05:19, Jehan Pagès <jehan.marmottard at gmail.com> wrote:
> Hi,
>
> On Mon, Sep 24, 2012 at 5:18 AM, Jon Nordby <jononor at gmail.com> wrote:
>> On 23 September 2012 20:06, Jehan Pagès <jehan.marmottard at gmail.com> wrote:
>>> Hello,
>>>
>>> I am new to this list, so I present myself. I am Jehan, developer, and
>>> lately working with an animator for an animation project.
>>> In this context, I have recently been interested into OpenRaster and
>>> decided to search if a library did already exist. I found libora, and
>>> actually already made my first patch there, as I could not compile it
>>> (bug 55246).
>>
>> Hi Jehan,
>> thanks for your interest and the patch. I've pushed it to master now.
>>
>
> Thanks for both answer (Jon and Luka) and especially the reactivity.
>
>>> But what striked me was that the repository has not been touched since
>>> November of 2010, so nearly for 2 years, and I see 5 other bugs,
>>> apparently untouched since their creation in 2011. But what scares me
>>> even more is that someone has even provided a patch on one of these
>>> report (more a feature, for a command line tool), and there has been
>>> no answer for a year and a half.
>>>
>>> Has the development been somewhat abandoned? What is the status?
>>> I would be interested into looking more into this library, and even
>>> fix what I can in it if I know that it will be integrated.
>>
>> At the moment no-one is using libora, hence its lack of development.
>> All the applications that have read/write support of OpenRaster have
>> their own implementations, often written in more high-level languages
>> (Python, C#, C++). As simple as OpenRaster is at the moment, this is
>> often just as easy as using a C library like libora.
>>
>
> I was kind of scared by the lack of activity, but your fast answers
> "un-scare" me. :-)
> I completely understand interest fading or other activities taking
> over, as long as you still maintain by at least checking new patches
> in. And apparently you do. That's good.
>
>> The only consumer I know is a very basic, and not really distributed
>> QImageIOLoader plugin (repo: qopenraster) that uses libora to attempt
>> to provide preview/render support for Qt based applications. The
>> problem is that libora can only render a very very small subset of
>> OpenRaster files correctly. Fixing that would require to do a lot more
>> work on the compositing in libora to support the various blending
>> modes that are specified. This is also the reason why it was not a
>> high priority to merge Davids patch on the bugtracker (we discussed it
>> on IRC, bad us). We should probably just put it in.
>>
>> If you are interested in continuing to work on libora I'll review and
>> integrate the patches you provide, and give you commit access when
>> you've completed a couple.
>
> Cool. I don't know if I'll clone the repo, or maybe simply send some
> patches, if ever I have any to send.

Either works fine by me, as long as you create a bugreport or send an
email when you want it merged (I don't have email subscriptions in
gitorious, too spammy). A separate repo is of course a bit easier for
bigger amounts of work.

> While I am at it, I have a generic question about OpenRaster: what is
> the "status of acceptance"? I know mypaint already has it as its
> default format. But Gimp still has it as a very basic plugin
> lacking features (I think you wrote it, so know that's not a critics
> of the nice work done :p).
> First test I did, I used groups of layers, and they disappeared in the ora
> (though, after skimming through the spec, ora has group of layers:
> stack element).
> Do you know if Gimp developers plan to switch to ora some day to
> replace xcf? That would be awesome.

OpenRaster can be used to exchange basic raster documents between the
applications listed here:
http://www.freedesktop.org/wiki/Specifications/OpenRaster/ApplicationSupport

The GIMP plugin is lacking support for the active layer marker and the
non-separable layer modes that where specified recently,
but is otherwise on-par with what exists in MyPaint or Krita.

The Krita guys did at some point plan to use OpenRaster as the native
file format (don't know the current viewpoint), but I don't think this
has ever been the plan for GIMP. In my opinion OpenRaster has value as
an interchange format. For simple applications like MyPaint using it
as a native format is useful, but for advanced applications like GIMP
I think it would be more pain than gain. It might even break the
exchange promise as simpler applications rarely are able to implement
everything more advanced applications would want in a native format.

> What about the proprietary softwares (we all think of Adobe with
> Photoshop, of course!). They will obviously not make it their default,
> but do you know of anyone interested in the spec other than Free
> Softwares, at least for secondary export format?
> After all, you based on OpenDocument spec and mouvement, and it is now
> even supported in Microsoft Word (and most proprietary text processor
> softwares).
I have not seen any interest from proprietary companies. But then
again, they rarely communicate with open source projects, so it could
be they are paying close attention for all I know. Realistically
though, if anyone wants OpenRaster support for Adobe Photoshop I think
it is best to just do it yourself. I believe it would be possible with
the Photoshop SDK.

> Also is the standards still evolving?
> I would personally be interested into an animation extension. I see
> there has been a "proposal" of just a few approximative lines. In the
> context of our project, I would be happy to discuss it, extend this
> and add a support to libora.
Yes, some things were agreed on this year, so it is still in
development. I don't expect any changes to the base standard at this
point, but the things that noone has implemented yet may still change,
and additions are of couse possible. Sadly it is not so easy from the
spec which aspects has been widely implemented and agreed on and which
are still a bit in the air.

In the end, like in any open source project, development is up to the
involvement of the various developers making use of OpenRaster.


-- 
Jon Nordby - www.jonnor.com