Bug 423088 - Exporting to ora format produces blank file
Summary: Exporting to ora format produces blank file
Status: RESOLVED FIXED
Alias: None
Product: krita
Classification: Applications
Component: File formats (show other bugs)
Version: 4.3.0-beta2
Platform: Appimage Linux
: NOR normal
Target Milestone: ---
Assignee: Krita Bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-06-17 07:10 UTC by notfood.dev
Modified: 2020-07-04 22:09 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
Input file, merely export to ORA to reproduce the issue. (621.87 KB, application/x-krita)
2020-06-17 07:10 UTC, notfood.dev
Details
ORA file to reproduce the issue (85.64 KB, image/openraster)
2020-06-17 17:30 UTC, notfood.dev
Details

Note You need to log in before you can comment on or make changes to this bug.
Description notfood.dev 2020-06-17 07:10:03 UTC
Created attachment 129439 [details]
Input file, merely export to ORA to reproduce the issue.

### Issue
- Moving a selected grouped area breaks ORA exporting.

### Enviroment
- OS: Linux
- Arch: x86_64
- Krita Versions: 4.2.9-6 (native), 4.3.0-beta2 (appimage)

### Steps to reproduce
- Group several layers
- Select rectangular area
- Select the group layer
- Use transform tool to move selection (all grouped layers) somewhere else
- Export as ORA

### Details
- Saving it as KRA format produces the right file, even after re-loading this file, exporting it to ORA will produce a wrong blank file.
- It's always reproducible. You need to restart Krita after saving.
- If you inspect the ORA file with a zip archiver, the layers are all blank, the stack.xml offsets are messed up.
- I suspect the ORA format exporter is trying to use the image offset extension wrong as the resulting file has strange x and y offsets together with blank pngs.

### Workaround
- Inserting a new layer then merging down the offending layer, effectively re-creating it, allows the exporter to produce the right ORA file.
Comment 1 notfood.dev 2020-06-17 17:30:21 UTC
Created attachment 129461 [details]
ORA file to reproduce the issue

I managed to reproduce it with a single layer.

### Steps to reproduice
- Open input.ora
- Move the Tiger
- Export to output.ora
- Load output.ora (is blank)

Made a video about it: https://streamable.com/z5571c
Comment 2 Ahab Greybeard 2020-06-18 01:03:36 UTC
This bug was initially reported and discussed at:
https://krita-artists.org/t/bug-exporting-to-ora-produces-blank-file/8431

It seems this is caused by drag-dropping a layer from a .ora file produced by MyPaint or from other sources.

I can't reproduce the bug from scratch using only krita generated content.

There may be an incompatibility/mismatch between krita and other applications involving .ora files.
Comment 3 notfood.dev 2020-06-18 01:35:53 UTC
I managed to reproduce it with pure Krita.
Steps:
- Create new image
- Scribble
- Crop to selection
- Resize canvas to a bigger area, you don’t even need to use transform tool, just stick to a corner. If you use the transform tool, it’s even more noticeable.
- Export to ORA. (broken offsets)

Video: https://streamable.com/6jp8y0
Comment 4 Ahab Greybeard 2020-06-18 11:30:11 UTC
I can Confirm this for the situation in Comment 3 with the 4.3.0 appimage

It looks like a visible layer size problem in the .ora file as well
Comment 5 Halla Rempt 2020-06-22 13:15:32 UTC
Git commit 87f72b5c02c6e61fac7bbc171f0abba6919c5c99 by Boudewijn Rempt, on behalf of InkLab App.
Committed on 22/06/2020 at 13:15.
Pushed by rempt into branch 'master'.

Fix exporting ORA files

While gathering the x + y offsets, and bounds for saved layers in ORA, now use the
layer->exactBounds() method instead of the plain layer->x() and layer->y().
This seems to correctly capture transformations outside of the original layer bounds
when using transform tools.

M  +5    -5    plugins/impex/ora/kis_open_raster_stack_save_visitor.cpp

https://invent.kde.org/graphics/krita/commit/87f72b5c02c6e61fac7bbc171f0abba6919c5c99
Comment 6 Halla Rempt 2020-06-22 13:15:54 UTC
Git commit 41d481852428cb4658ad13c458b1d47582cb4d48 by Boudewijn Rempt, on behalf of InkLab App.
Committed on 22/06/2020 at 13:15.
Pushed by rempt into branch 'krita/4.3'.

Fix exporting ORA files

While gathering the x + y offsets, and bounds for saved layers in ORA, now use the
layer->exactBounds() method instead of the plain layer->x() and layer->y().
This seems to correctly capture transformations outside of the original layer bounds
when using transform tools.
(cherry picked from commit 87f72b5c02c6e61fac7bbc171f0abba6919c5c99)

M  +5    -5    plugins/impex/ora/kis_open_raster_stack_save_visitor.cpp

https://invent.kde.org/graphics/krita/commit/41d481852428cb4658ad13c458b1d47582cb4d48
Comment 7 Tiar 2020-07-04 20:06:58 UTC
Git commit 74c10b9577ccea4dec573b5a5be204acb5fad1df by Agata Cacko.
Committed on 04/07/2020 at 17:33.
Pushed by tymond into branch 'master'.

Don't save x and y of groups in .ora files

Before this commit Krita would save position attributes for
group layers. However Krita and Gimp's handling of those attributes
differs from the behaviour MyPaint has. For the layer inside the group,
the position attributes are considered relative to the group layer
position (they are summed). In Krita and Gimp, the position of the layer
inside the group is considered absolute.

For example this layer structure:
> group layer x=100 y=100
>> paint layer x=100 y=100

In Krita and Gimp, the paint layer will appear in x=100 y=100
on the canvas, while in MyPaint it will appear in x=200 y=200.

This commit always saves group layers with x=0 and y=0 to avoid this
issue.

M  +14   -2    plugins/impex/ora/kis_open_raster_stack_save_visitor.cpp

https://invent.kde.org/graphics/krita/commit/74c10b9577ccea4dec573b5a5be204acb5fad1df
Comment 8 Tiar 2020-07-04 20:16:38 UTC
Git commit 8adf54c9d91d7ed9b04e09177ff623a80d6e0c18 by Agata Cacko.
Committed on 04/07/2020 at 20:16.
Pushed by tymond into branch 'krita/4.3'.

Don't save x and y of groups in .ora files

Before this commit Krita would save position attributes for
group layers. However Krita and Gimp's handling of those attributes
differs from the behaviour MyPaint has. For the layer inside the group,
the position attributes are considered relative to the group layer
position (they are summed). In Krita and Gimp, the position of the layer
inside the group is considered absolute.

For example this layer structure:
> group layer x=100 y=100
>> paint layer x=100 y=100

In Krita and Gimp, the paint layer will appear in x=100 y=100
on the canvas, while in MyPaint it will appear in x=200 y=200.

This commit always saves group layers with x=0 and y=0 to avoid this
issue.


(cherry picked from commit 74c10b9577ccea4dec573b5a5be204acb5fad1df)

M  +14   -2    plugins/impex/ora/kis_open_raster_stack_save_visitor.cpp

https://invent.kde.org/graphics/krita/commit/8adf54c9d91d7ed9b04e09177ff623a80d6e0c18
Comment 9 Tiar 2020-07-04 22:09:16 UTC
Git commit 9c115719730281d50322abe3467d54616a292bbe by Agata Cacko.
Committed on 04/07/2020 at 21:33.
Pushed by tymond into branch 'krita/4.3.0'.

Don't save x and y of groups in .ora files

Before this commit Krita would save position attributes for
group layers. However Krita and Gimp's handling of those attributes
differs from the behaviour MyPaint has. For the layer inside the group,
the position attributes are considered relative to the group layer
position (they are summed). In Krita and Gimp, the position of the layer
inside the group is considered absolute.

For example this layer structure:
> group layer x=100 y=100
>> paint layer x=100 y=100

In Krita and Gimp, the paint layer will appear in x=100 y=100
on the canvas, while in MyPaint it will appear in x=200 y=200.

This commit always saves group layers with x=0 and y=0 to avoid this
issue.

M  +14   -2    plugins/impex/ora/kis_open_raster_stack_save_visitor.cpp

https://invent.kde.org/graphics/krita/commit/9c115719730281d50322abe3467d54616a292bbe
Comment 10 Tiar 2020-07-04 22:09:16 UTC
Git commit 9d39b8d395082fcdc4c549cd206f51e89fa58f84 by Agata Cacko, on behalf of InkLab App.
Committed on 04/07/2020 at 21:32.
Pushed by tymond into branch 'krita/4.3.0'.

Fix exporting ORA files

While gathering the x + y offsets, and bounds for saved layers in ORA, now use the
layer->exactBounds() method instead of the plain layer->x() and layer->y().
This seems to correctly capture transformations outside of the original layer bounds
when using transform tools.

M  +5    -5    plugins/impex/ora/kis_open_raster_stack_save_visitor.cpp

https://invent.kde.org/graphics/krita/commit/9d39b8d395082fcdc4c549cd206f51e89fa58f84