I just noticed that MyPaint 2.0 was recently released.
It seems to use a slightly different version of the ora format that Krita shares due to the addition of spectral colour mixing.
So now we have two applications with different forms of the same format. Oh well…
On the plus side, MyPaint is quite nice for sketching.
Just to let you know, ora format may be changing a lot in the close future. Krita, GIMP will be more interchangeable though there are issues that prevents them from being fully interchangeable.
Thanks for letting me know. Will MyPaint also get the changes?
Ping for @InkLab 
@Kirtai if ORA format will contain features MyPaint doesn’t have, it will just either need to implement it - which can take a lot of time - or ignore (load files only partially). That’s how Krita treats PSD files.
Ah. I was wondering since I’m pretty sure that ORA is MyPaints native file format which they have already extended for the spectral colour mixing.
I foresee a lot of confusion if both groups extend it differently and incompatibly.
Maybe it would be worth talking with the MyPaint devs to coordinate things?
Also, if it changes a lot, what will become of old ORA files? Will there be an upgrade path?
Yeah, well, last time I checked, it was @wolthera and @halla (both from Krita project obviously) being official maintainers of ORA format, so… 
But when @InkLab started to be involved recently in extending ORA format we suggested that we need to wait until LGM (libre Graphics Meeting) where a lot of other projects will be available in one lace to discuss it.
Ah, that’s good. I was worried about the unpleasant prospect of having multiple, incompatible versions of ORA floating around. Also, I somehow missed the main thread about it. >_<
Hey @Kirtai,
Appreciate the conversation starter. I am fine discussing these things early as it provide more insight I can use to prepare for LGM.
In general, my understanding is that ORA was created as a general replacement for PSD, that was designed as a libre format, after adobe created licensing /
maintainability issues with PSD:
“The Adobe Photoshop PSD file format was widely used as a cross-application file format for layered images. Adobe allowed this by releasing the format’s specifications publicly. In 2006 Adobe changed this license to only grant access to and use of the specifications and documentation “for the purposes of internally developing Developer Programs in connection with Adobe Software products and incorporating portions or all of the Sample Code into Developer Programs.”[4] In response to these restrictions, the OpenRaster format was proposed” (OpenRaster - Wikipedia)
While it is fine that mypaint chooses to use ORA as a native file format, in general I believe the goal should be maximum compatibility across raster editors,
both closed and open source.
In my first iteration, I have been trying to go over features of Krita, mypaint, gimp, Photoshop, and Procreate to determine the union of all features and consider the most practical ones to propose for the standard. Here are some initial things I noted just while looking at the open source programs:
Non destructive layer masks: Things like gimp’s opacity mask and Krita’s Transform mask, are very important for correctly rendering the intended image.
Blend Modes: While ORA currently supports a good amount of ‘named’ blend modes proposed by the w3c spec, there are a number of different modes available in gimp and Krita. There are two possible solutions; either the standardized list of named modes could be expanded, or the blend mode support could be expanded by allowing embedding of the source / dest pixel mixing formula into the ORA standard (using LUA or some other scripting lang?)
Composite modes: Some of Gimp’s composite modes, like “Clip to Layer” seem to work differently than the porter-duff composite modes represented in ORA. These modes actually composite the alpha channel too instead of just overlaying it. We need to decide if we would like to support this in general. (either additional porter-duff modes, or non porter-duff modes)
Vector Layers: This is a big one. Lot’s of use cases for a layered image interchange format involve some use of text of general vector layers. (Despite the fact that it ruins the format name, haha) I don’t at all expect a program like MyPaint to ever implement general support for vector layers (I would not want these features anyway - MyPaint is supposed to be a simpler painting program). For maximum compatibility, one possibility would be to provide both a vector and raster layer when writing ORA files, so that opening them with a program like MyPaint would still be able to render the whole image, even if the vector information was lost.
Composite + Blend modes: In some cases we want to both clip to the underlying layer, and also multiply for example. This should be fairly straightforward to support.
I am still going to need to investigate some of the closed-source programs to find even more quirky things to support. I will get back to you once I have some updated news about that. In the meantime I am welcome to some early discussion / feedback on the other points here. :3
Anything about non-destructive layer style? Krita, Photoshop, Affinity Photo supports it.
Hey, thanks for the information. Part of my concern was that MyPaint might get left out since it was seeming dead for a while, leading to incompatibilities.
Speaking of incompatibilities, I believe that both MyPaint and Krita have each changed the way at least one blending mode work from one version to another. So ORA might need multiple versions of a mode, or maybe a separate colour mixing or other settings.
Regarding embedding of the formula, the gettext internationalization tool uses a simplified C expression to describe language plurals. It might be a good inspiration
Be careful you don’t make it overly complex. Does an interchange format really need to support everything all the native formats allow?
Hey @Kirtai,
Appreciate any suggestions you provide.
For the scope of the format, the only reason that I want to investigate as many programs as possible is to help to achieve my understanding of the original goal of this standard: to be a viable replacement for adobe PSD. There are currently no other alternatives I am aware of. I agree that if a feature is too specific it will have to be disregarded or considered an extension. I am interested to know if there are any specific other software that you can think of that I should investigate.
I looked at the page you linked regarding the simplified C expression. I don’t think it directly covered what I needed to consider. The problem of storing code that is easily parasble and executable in any program, without potential for abuse / exploitation, is non trivial to solve. However, I do think it would be a very nice generalization if I can find some appropriate standard with parser libraries available for most popular programming languages.
Looking at PSD significant missing feature is the volume of non-destructive filters available. As I imagine these would be much too complicated to store as a formula, so likely they would just have to be exported as the base layer with the masked-result layer on top of it, and the base layer hidden by default. Exporting general filters as formulas would be very cool in general but I think it would likely be too big of a stepping stone for this update.
Anyway I am planning to make a matrix of supported modes and related features across these software projects as a quick comparison and I will post it here when I have something assembled. It looks like right now that Krita has more than 2x the blend modes of all of the other programs I have looked at. =P
More questions: What about color space and profile? Affinity, Photoshop, and Krita all supports 32F, LAB, CMYK, Gray, RGB.
Hi @Reptorian,
Again, I really appreciate the ideas, as there are obviously many aspects that I didn’t think of!
I took a shallow look into some of these formats. At a high level, it seems that, while they may have different representations inside of the editing program or specific exported file types, the actual image data should always technically be able to be handled by ORA’s current png file containers. There is also the Grayscale color space, which has the advantage of requiring less space and is natively supported by the png container. I think we could theoretically support exporting grayscale pngs to save space, as any good png library should be able to handle this without issue. For the other color spaces, we could provide an optional attribute in raster layer elements to indicate the intended color space to the program reading the file, it they support it, but I would consider this to be lower priority. Perhaps you could help to elucidate manually or with a link, what the advantages of storing the layer as a different color space provide?
Perhaps you could help to elucidate manually or with a link, what the advantages of storing the layer as a different color space provide?
In context of Krita, you can use LAB layer in RGB color document to gain access to filter options you normally wouldn’t have. For example, you can use two different layers where they are the same and one of them is essentially converted into LAB, and then you can use LAB color adjustment curves as a filter mask or modify alpha based on LAB as a filter mask. I used it a bit for editing pictures. The only program I know that can does it without workaround is literally Krita and Photoflow. That is it. So, I don’t think it should be implemented into ora, but throwing this out there.
I think in general optional attributes to ORA elements/layers (such as color space) could be registered as used for a certain purpose by certain programs (similar to how there are blend modes only supported by Krita, like the “kra:***” optional values for the “composite-op” attribute. Because adding XML attributes does not really change the standard in a significant way. While I can’t find it in the official layer-stack specification right now, I think it should be the case in general that programs which read and later save a layer element in the stack, should not modify any additional attributes which they do not understand. In this way, color space could continue to be used by only Krita and Photoflow.
If there is a reason we should not use arbitrary (free) attributes as extensions, please feel free to contribute a situation where this would prove problematic.
Just to be on the clear, color space is universally supported by GIMP, Krita, Photoshop, Affinity Photo though some do support LAB, and CMYK. Layer color space is a different thing though, and as far as I know, only Krita, and I think Scribus and InDesign supports it though not quite in the same way as Krita. I’m not too sure about Photoflow, but it seems that they do universal modification g’mic style, so I don’t think it supports it similar to Krita. I guess layer color space shouldn’t be supported at all in ora as Krita is the only raster editor that can do it.
@Reptorian after talking to Tiar for a few days on IRC, I am generally convinced that if we want to support different color space storage in general (either per layer, or for all layers) the image container for those formats could need to support that color space naively. (For example, if we want to use CMYK, we should not be using png containers) This is not only due to the performance issues of converting everything from one format to another for saving / loading, but even more because rounding errors due to repeated conversions could slowly degrade these images.
If we would like different color space support we need to decide on another container in addition to, or besides PNG which has wide enough support for popular programming languages, and the color spaces we had in mind to support.
Let me know if anything in particular comes to mind!
I would recommend using .tiff either separate or layered instead of .png when not compliant with RGB-8I/Gray-8I.
I think using layered tiffs would confuse the format even more, but afaik tiff is quite capable in terms of color spaces:
so it might be just the good choice.
Ill start on my comparison of supported formats on various raster editors this weekend so we can make a more informed decision about exactly how wide a range of formats would actually get used. When deciding on these updates it is difficult to decide between covering all the bases for future proofing, or being more conservative to make integration easier for developers. I tend to lean more to the former but it would be best to get input from a wider audience.
