GNOME Bugzilla – Bug 760348
Child layers in exported OpenRaster (ORA) files have the wrong offsets in MyPaint
Last modified: 2016-03-28 22:03:35 UTC
Created attachment 318564 [details] Example XCF file being exported When exporting layer groups to ORA files both the group and their children get (x,y) values relative to image space (0,0). This results in everything being shifted when loading in MyPaint because it expects children to be relative to the parent's (x,y) values. Changing this will probably impact the ORA loader too, because Gimp exported ORAs look correct when loaded again in Gimp. MyPaint files look fine in Gimp because it never sets (x,y) for it's layer groups.
Created attachment 318565 [details] Exported ora when loaded in Gimp
Created attachment 318566 [details] Exported ora when loaded in MyPaint (git-master 1/8/2016)
Is there anything about this in the spec?
https://wiki.freedesktop.org/www/Specifications/OpenRaster/Draft/LayersStack/#stackelement It just says that the stack element is allowed to have an x and y value, it doesn't say what the effect of setting them is. I would be inclined to assume "what MyPaint does" is the one true specification but CCing someone in here who could fix the wiki would be good too.
(In reply to Daniel Sabo from comment #1) > Created attachment 318565 [details] > Exported ora when loaded in Gimp Exporting GroupTest.xcf.gz as GroupTest.ora and loading it in krita shows the two squares overlapping though
Krita appears to ignore x & y on layer groups: https://github.com/KDE/krita/blob/a046e33b71aa179c0899fd82006b822a8a4f6659/krita/ui/ora/kis_open_raster_stack_load_visitor.cpp#L179
Created attachment 318637 [details] [review] plug-ins: openraster: Ignore the x,y values of layer groups So given the conflicting interpretations I think the best compromise value is to not set x,y on <stack> elements. Group offsets don't seem to do anything significant in Gimp and any non-zero value will confuse some existing software.
Hi there. Michael Schumacher asked me to have a look in this thread. MyPaint doesn't save offsets for groups because all its layers use the same reference coords internally. Groups don't really have an offset. When saving, we transform data layer offsets to those of the data bbox or the user-defined frame, since MyPaint is an infinite canvas monster. https://github.com/mypaint/mypaint/blob/41c49b0cb892ac496465e706735240a5991aa1f2/lib/layer/core.py#L764 https://github.com/mypaint/mypaint/blob/41c49b0cb892ac496465e706735240a5991aa1f2/lib/layer/data.py#L404 https://github.com/mypaint/mypaint/blob/41c49b0cb892ac496465e706735240a5991aa1f2/lib/layer/data.py#L411 https://github.com/mypaint/mypaint/blob/41c49b0cb892ac496465e706735240a5991aa1f2/lib/layer/group.py#L471 So MyPaint does that, and software that doesn't really have group offsets can do something similar. But the spec allows groups other than the root to have offsets, and I think it always has. IMO the only correct loading interpretation should be that offsets are summed all the way back up the stack. And that's what MyPaint does: Layer group ORA load method, note summation and recursion: https://github.com/mypaint/mypaint/blob/41c49b0cb892ac496465e706735240a5991aa1f2/lib/layer/group.py#L76 Surface-backed layer ORA load method, note summation: https://github.com/mypaint/mypaint/blob/41c49b0cb892ac496465e706735240a5991aa1f2/lib/layer/data.py#L127 Krita should probably not be ignoring offsets on layer groups when loading just because MyPaint doesn't write them. I can update the Openraster spec to make this clearer.
CREATE list thread for discussing a clarification to the OpenRaster specification: http://lists.freedesktop.org/archives/create/2016-January/005162.html
Thanks for coming to clarify. I agree that MyPaint's interpretation of the values is correct, but I do have some doubts that groups should ever have x,y values. In terms of Gimp's output I don't see any benefit to exporting layers with offsets when it will confuse existing software. Possibly Gimp should read layers with offsets, but I don't like having code that no existing software will test. Is there an official repository of sample ORA files to test against?
My understanding is that this is underspecified in the current standard - but I do not know how OpenRaster is supposed to evolve, maybe it is expected to be shaped by implementation details of software implementing it?
(In reply to Daniel Sabo from comment #10) > Thanks for coming to clarify. I agree that MyPaint's interpretation of the > values is correct, but I do have some doubts that groups should ever have > x,y values. > > In terms of Gimp's output I don't see any benefit to exporting layers with > offsets when it will confuse existing software. Same decision we made for GIMP-compatibility, in fact ☺ > Possibly Gimp should read > layers with offsets, but I don't like having code that no existing software > will test. Is there an official repository of sample ORA files to test > against? This is a thing that should exist, heck I want one for MyPaint too. But my time is limited right now. These days I'd be inclined to dump specification documents, the old reference implementation that nobody's had time to maintain *coughcough*, and a new repo of official test ORA files onto github. Define "official" for OpenRaster! ☺ Current workflow is entirely based around a low-traffic mailing list and a wiki that's hard to edit. Perhaps it's time to migrate?
Are there any objections to going with this patch for now? From the Create mailing list discussion it seems like the closes thing to consensus is that offsets on groups are undefined behavior. An ORA saved with this patch would be compatible with any future version of OpenRaster that can open existing MyPaint and Krita files.
I think some systems could plausibly store and use them, so we should thrash out that aspect of the spec at LGM. MyPaint will continue to treat * Group1 (x=100, y=700) * Group2 (x=-25, y=0) * Layer1 (x=0, y=50) as identical in appearance to * Group1 * Group2 * Layer1 (x=75, y=750) That's a reasonable interpretation in my book ☺ It'll save them out in the latter format though, because that's safest.
So zeros at least for now: commit f10067e560fd5b33104bdb680be1a9a1c7458d65 Author: Daniel Sabo <DanielSabo@gmail.com> Date: Sat Jan 9 21:56:06 2016 -0800 plug-ins: openraster: Ignore the x,y values of layer groups (bug 760348) Neither MyPaint or Krita sets these values when saving, and when loading they have conflicting interpretations such that the only universally valid value will be zero. plug-ins/pygimp/plug-ins/file-openraster.py | 12 +++--------- 1 file changed, 3 insertions(+), 9 deletions(-)