[CREATE] ORA topic presentation for Online LGM 2020

Alexandre Prokoudine alexandre.prokoudine at gmail.com
Sat May 16 18:09:26 UTC 2020


пт, 15 мая 2020 г., 18:56 InkLab App <inklabapp at gmail.com>:

>
> For 'layer effects' : do you mean, non destructive filters? If so, this
> was a very interesting problem that I have been considering for a while,
> that is, implementing arbitrary functions into a file format. IT seems very
> difficult to do safely, but I did have a few ideas. I would love to hear
> your thoughts on this. The same idea could be applied, in a more limited
> scope, to define generalized layer filters.
>

By the way, I think we missed an important stage here: (re)defining the
goals of ORA.

It used to be a long-term archival file format. Then suddenly it turned out
to be a somewhat convenient file format for basic multi-layer project data
exchange between applications (Krita, GIMP, and MyPaint were first to
implement support for it, I think).

At some point, Krita started pushing it forward with new features in their
own namespace (extra blending modes). Other projects haven't followed suit
yet, as far as I can tell.

So what do we actually want ORA to be and why? If we want it to become a
lingua franca multilayer project file format w/ basic vector graphics, a
kinda libre PSD, then it makes sense to list certain expectations based on
real-life use cases _before_ jumping to features implementation.

Also, if/when we add features like layer effects, how much
(many?) roundtripping errors can we realistically live with? Because you
_will_ get those unless you standardize a fixed set of effects
between applications (settings and semantics, rendering model etc.).

P.S. As for speed etc., here you go:
https://blender.stackexchange.com/a/148466/213 (pointed out by Troy).

Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/create/attachments/20200516/2d123872/attachment.htm>


More information about the CREATE mailing list