Thoughts on Krita + OpenToonz merge - theoretically speaking?

[m1karii]

This is a repost from Krita forum: https://forum.kde.org/viewtopic.php?f=137&t=177120

Krita is one of the best digital painting programs out there (I'd dare say only challenged by CSP). OpenToonz is professional 2D animation software based on Studio Ghibli's fork of Toonz, currently maintained by Dwango.

Both apps are written in C++ with Qt front-end so the merge should be theoretically possible. I don't know about the licenses however. Krita uses GPL and OpenToonz uses modified BSD license.

Reasons for this proposed merge can be summed up as: Krita's animation features are nowhere near those of OpenToonz and OpenToonz' painting / drawing features are nowhere near those of Krita therefore even ommiting everything else one software has, that other does not, and only focusing on these main features (painting + animating) both apps have a lot to gain from each other. The merge would probably also result in more fluid workflow (especially for animation).

First step would be for OpenToonz to join the Krita Foundation. By doing this it would probably also benefit in the development coordination because afaik Dwango is "the maintainer" of OpenToonz, but no longer taking an active part in it's development. (* https://github.com/opentoonz/opentoonz/issues/2746 )

Of course it'd be a lot of work. I tried to keep it short.

I'd like to know opinions of both Krita and OpenToonz community members and devs.

[RodneyBaker]

My surface thought without diving two deeply beyond the theoretical idea that such a thing could happen:

The two programs are so different it is difficult to imagine how Opentoonz and Krita could ever merge. It seems considerably more likely the two communities would work together to develop the applications to be more efficient and optimized for their respective workflows in support of a (also theoretical) optimized animation production pipeline.** This also to allow other applications (both free and paid depending on preferences of individuals and studios) to also fit into the pipeline to the benefit of all.***

You mention the differences in licensing and that is certainly an important consideration; if not deal breaker. It is also one which, in my admittedly uniformed opinion and for the time being, limits this theoretical thinking exercise to the point of near certain disappointment. This might not be the case if a new licensing construct was adopted by both Krita and Opentoonz but that seems unlikely as Krita likely won't change licensing and Opentoonz basically (theoretically?) cannot.

Having said all this... and since we are inside of theoretical space... I see no 'real' obstacles to prevent the two applications from merging. I might thefefore ask, "What does success look like?" A follow up question then might be, "Why not create an entirely new program to replace both applications?"

And just in case it isn't obvious, no, I don't believe we want an entirely new application that replaces both applications. But that is the most likely outcome if such a merging the two programs were to happen.

** This is something of a holy grail for both individuals and studios... to have a 'perfect' production pipeline/workflow. As such well worth exploring as everyone is exploring it already. Of course duplication of effort (often wasteful but occasionally innovative) can certainly be problematic.

*** All programs should be striving to share data; both with input and output. Building bridges between workflows and applications is a much more likely outcome in my estimation. WIth this approach licensing is also considerably less of a problem.

-- Rodney

[JParks123]

we recently added OCA (Open Cel Animation) Export format to OpenToonz this is also available for Krita and it will soon have an import function also hopefully OpenToonz will as well.
OCA supports the most common features of all drawing/animation software:

Layers Layer Groups (and pass through mode if any) Layer Labels Layer Visibility Blending Modes Layer Alpha options (inherit alpha) Keyframes and their duration (animation exposure) Opacity Keyframes Layer Sizes and Coordinates Document background color Document color depth Duration Framerate All these properties are stored in a simple JSON file, and the images are stored in standard image file formats: PNG, EXR, SVG…

Everything is assembled in a folder which name ends with .oca. The JSON file is at the root, while the images are stored in subfolders corresponding to layers and groups so far OCA is available for After Effects Blender and Fusion (Import) also Krita, OpenToonz, Animation Paper (export) and soon TVPaint and Photoshop. for more info on OCA format https://rxlaboratory.org/tools/oca/

[Bracket-H]

Opentoonz, as crusty as it can be, is superior to Krita for animation as a workspace and source.

Anti aliasing tools and vector improvements are the only thing I wish for on the functionality side, and Krita is bereft of those, as well. Just doesn't seem to be like that cause Krita doesn't use 'aliased drawing' 'by default', because it's a painting program.

And there's interoperability already, the composition abilities is, IIRC, the reason why Ghibli went for it initially. Also, I think Krita should not have gone for animation in itself...and I worked on Krita myself, before. Had it not done that then this wish would not be necessary.

I see it like Jack Audio, Pipewire and Pulseaudio for Linux. Only Jack Audio should exist of these because 'wiring together sources' was its whole idea behind it. Pipewire should never have been invented. Pulseaudio should have never been invented.

For classic, audio behavior, there's Alsa. For advanced audio with routing and stuff, there should be jack audio.

For animation there should be Opentoonz. For painting there should be Krita. For photomanipulation there should be Gimp, for three dee stuff there should be Blender (which also tries to do it all, these days)

Gimp is not really relevant for this topic (I just brought it up cause Krita also dabbles in photomanipulation, and some use Gimp for painting, too, but it has almost no real usage for animation, aside from perhaps cleaning up scans) But maybe you get the idea.

If you want painterly animation like TvPaintAnimation, then do the layouts, the timing, the pencilling in OT, then do the paintwork in Krita, and if need be, put it back into OT, or A video editor, or a compositor that isn't OT.

That way, all programs can play their strengths. And in fact, now that I bring it up. Compositing ... Would be nice if there was a badass composing library equivalent to the mypaint brush library system. Imagine being able to have the same exquisite compositor engine in any application you want.

That would be sweet.

Anyway, to reiterate...I'm firmly on team 'unix' do one thing well.

---

Edit: Oh, right, to perhaps give this a bit more 'gravitas'. Consider the old RETAS suite. It was split up so much that even painting had its own environment, and many a great works have been produced with it.

I understand, though, it would be more convenient to merge but...here's something to remind oneself of:

People are, and were flocking to opentoonz because it (really) is a professional tool. Thing is, professional tool is sort of synonymous with "studio" or "team", where you have dedicated sections to things.

Just consider the fact that OT has render farm support. That's not something the average 'private' person has.

What I'm getting at is: The more we squish things together, the less 'pro' it actually becomes. This is not to say that "pro" means awkward and painful to use, but it's like with audio stuff and DAWs, digital audio workstations used by private people.

Where they then become producer, writer, editor, mixer and mastering section of the entire thing. Now, that's a pretty good thing actually, because it enables the everyman to do something cool.

But ...it ain't a dedicated studio with hardware synths, with hardware equalizers, mixing, recording booths, sound technicians, dedicated pros who do little else than deal with mixing, mastering, etc.

And the more of that is crammed in one place, the less powerful it can become because..there's hardware constraints, etc.

Now...I'm gonna be real. Opentoonz is not THAT big of a deal compared to an entire audio studios worth of equipment, or an animation studios equipment. But the more aspects you add, the more demand for excellence in these parts is requested, and even a single bad component can sour the entire view of the program.

Both from a workhorse perspective, like: If you only have so much ram, so much cpu power, then loading in all the suite pieces at once takes up those resources. And if you unload the parts that are used and only use them when changing to a mode...then you've deluded yourself into thinking that you're not actually using different parts, because it's all under one interface. But in reality, you are using different parts at that point.

And from a 'feeling' perspective,like: Let's say you hear that Krita has animation support, so you get krita and you want to animate. But it's not that good, while the painting is excellent. You might just go "Well, this is crap" and toss Krita aside wholesale. Not guaranteed, but it's possible.

But if all you can do is paint really really well, then there is less room for 'misunderstanding' and 'communication of intent'.

I'm sure you get the idea now though...and I have to say. Opentoonz could use some drawing improvements, but ...at the end of the day, OT would become less pro if it's going to turn into a jack of all trades.

It already has too much compositing for my taste. I mean, its necessary because for proper layouts, etc you need to be able to move 'cels' around. But I'd rather have the final compositing elsewhere.

That's why I'd wish for a mypaint like compositor library, and it would be 'steered' by an equivalent of the OSC

Where clients to the library 'program' the compositor engine underneath with messages, without implementing the compositing itself. A bit like PureData~ which is a 'sound' programming language.

Then a blur compositing bit would just send messages that pertain to blurring to the underlying library, trading in image data and getting out image data, which is then cached until it needs changing.

That would be sweet, but yea. It's also a bit off topic (heh, OT...)

But consider the power behind specialization. OT has many opportunities for improvement, but it should not be leaning into other 'genres' too much.

A little bit of diligence is better than half assed feature. Like, if OT had a sound editing part because it happens to have audio tracks to playback. Just do the diligent thing and prepare the sound diligently in a diligently used separate program and treat your work like a planned production.

That's what the pros do, after all. I'm not a pro, but that's what they do. And OT is 'alluring' because it's pro.

tl, dr; Interoperability of separate components > squishing everything into everything, having weaknesses in one aspect, that a previous tool did better, switch to that tool, see that it has less capabilities of something else, implement the weakness there, realize it's not as good as something else still, go to THAT new tool which does both, add a third thing, but that's not as good as another.

If that was kept up long enough then every media tool would slowly accumulate every type of production. gimp would have animation, because it has image editing and image editing is useful for animation. krita has animation and image editing and painting, because image editing is useful for painting. etc.

[RodneyBaker]

Transferring this report over to Opentoonz-docs where additional discussion can continue.