Bug 395378 - A file with animation enabled by accident does not load consistently
Summary: A file with animation enabled by accident does not load consistently
Status: RESOLVED FIXED
Alias: None
Product: krita
Classification: Applications
Component: General (show other bugs)
Version: 4.0.4
Platform: Appimage Linux
: NOR normal
Target Milestone: ---
Assignee: Krita Bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-06-14 16:14 UTC by razvanc87
Modified: 2018-09-07 14:16 UTC (History)
2 users (show)

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


Attachments
Show loading status of original and incremental version (477.20 KB, image/png)
2018-06-14 21:49 UTC, vanyossi
Details

Note You need to log in before you can comment on or make changes to this bug.
Description razvanc87 2018-06-14 16:14:18 UTC
In Ubuntu 18.04

In v4.0.4 the attached file opens with no strokes (only the background page texture - bottom layer), all other layers are empty but they do contain strokes.

In v4.0.3 the file opens correctly.

Can't attach the file that's not loading in v4.0.4 cause it's over size limit, I've already reverted to v4.0.3, I'll keep the krita file here: https://mega.nz/#!vR4TCAQK!ulplAkgzTlWqLO_t4QOPGxkkR189gKIJPmFixdMQ8uE for a while.
Comment 1 Halla Rempt 2018-06-14 18:18:29 UTC
I can confirm the issue. It is not present in git master, so we must be missing an important commit that we didn't backport.
Comment 2 vanyossi 2018-06-14 21:49:29 UTC
Created attachment 113330 [details]
Show loading status of original and incremental version

I can reproduce this bug in master

When it happens the file never shows the content during that session. It happens apparently randomly but only with the file provided. The screen shot shows the original file on the right. any attempt to open that file will result in a solo background.

Saving an incremental version, closing the file and opening the new incremented version makes the strokes show up normally.

To try and reproduce on master:
1. Open Krita
2. Open file
3. if file opened correcly
4.   close krita inmediatly with Ctrl+Q
5.   repeat from step 1

NOTES: If the new file dialog is shown it is less likely to occur (but since is random its not a given)

If the bug is triggered and the incremental version was generated. Opening the incremental version in the same session will always show. But the original file fails always

When creating the incremental version console ouputs
krita.lib.store: KoStore: Duplicate filename "unnamed/layers/"
krita.lib.store: KoStore: Duplicate filename "unnamed/layers/.defaultpixel"

It might or not be related, but saving another incremental version, does not produce those messagess.
Comment 3 Halla Rempt 2018-06-15 07:37:20 UTC
Yes, this really seems specfic to just this file. Once the file has loaded correctly, I saved it to another file. The copy never showed the problem.
Comment 4 Halla Rempt 2018-06-15 07:43:04 UTC
Even weirder, saving a file under another name when the file was loaded incorrectly results in a correct file.
Comment 5 Halla Rempt 2018-06-15 07:46:56 UTC
In any case, it's not like loading files with group layers is completely broken...
Comment 6 Halla Rempt 2018-06-15 07:53:33 UTC
I can reproduce a fail to load with the 4.0.0 appimage
Comment 7 Halla Rempt 2018-06-15 07:58:53 UTC
And with 3.0.1... This is also interesting: in the original file, the layer3 and layer4 files have the same md5sum:

boud@linux-u0cn:~/bla/unnamed/layers> md5sum layer3 layer4 layer5
bec0b3db1869660646ddfabb559ccb62  layer3
bec0b3db1869660646ddfabb559ccb62  layer4
c583ee6685abb23e6e9a5cdd6c6cf29c  layer5

Which is not the case in the resaved image:

boud@linux-u0cn:~/bla2/unnamed/layers> md5sum layer3 layer4 layer5
c113750bbedb48b11086af817c688759  layer3
71bf308f2c41ead8e107ed7039aed9a3  layer4
c583ee6685abb23e6e9a5cdd6c6cf29c  layer5
Comment 8 Halla Rempt 2018-06-15 08:00:37 UTC
But in the original image, the layer data is in frame 1:

-rw-r--r-- 1 boud users       56 Jun 14 17:58 layer3
-rw-r--r-- 1 boud users        4 Jun 14 17:58 layer3.defaultpixel
-rw-r--r-- 1 boud users   725662 Jun 14 17:58 layer3.f1
-rw-r--r-- 1 boud users        4 Jun 14 17:58 layer3.f1.defaultpixel
-rw-r--r-- 1 boud users      588 Jun 14 17:58 layer3.icc
-rw-r--r-- 1 boud users      497 Jun 14 17:58 layer3.keyframes.xml
-rw-r--r-- 1 boud users       56 Jun 14 17:58 layer4
-rw-r--r-- 1 boud users        4 Jun 14 17:58 layer4.defaultpixel
-rw-r--r-- 1 boud users  1068096 Jun 14 17:58 layer4.f1
-rw-r--r-- 1 boud users        4 Jun 14 17:58 layer4.f1.defaultpixel
-rw-r--r-- 1 boud users      588 Jun 14 17:58 layer4.icc
-rw-r--r-- 1 boud users      500 Jun 14 17:58 layer4.keyframes.xml
-rw-r--r-- 1 boud users 25217393 Jun 14 17:58 layer5
-rw-r--r-- 1 boud users        4 Jun 14 17:58 layer5.defaultpixel
-rw-r--r-- 1 boud users      588 Jun 14 17:58 layer5.icc
Comment 9 Halla Rempt 2018-06-15 08:12:15 UTC
Okay, so what happened is that the reporter accidentally pressed the shortcut for New Frame instead of New Layer. There is still a bug: the file loads inconsistently, probably because the time is not initialized correctly:

10:11:38 < tyyppi> this certainly looks weird: <keyframe color-label="0" frame="layer3" time="-2147483647">
Comment 10 joupent 2018-06-15 09:25:32 UTC
Git commit b6fe6c10617021c179df056bb2fbe9baaaffd095 by Jouni Pentikäinen.
Committed on 15/06/2018 at 09:24.
Pushed by jounip into branch 'master'.

Fix creating invalid keyframe times when pasting

Also added some safeguards against using infinite time ranges in
inappropriate places.

M  +2    -0    libs/image/kis_image_animation_interface.cpp
M  +1    -0    libs/image/kis_time_range.h
M  +4    -1    libs/ui/actions/KisPasteActionFactory.cpp

https://commits.kde.org/krita/b6fe6c10617021c179df056bb2fbe9baaaffd095
Comment 11 Dmitry Kazakov 2018-06-15 18:13:54 UTC
Git commit 47b3cab9f82ba4591a484727a865edc57c44eef8 by Dmitry Kazakov.
Committed on 15/06/2018 at 18:13.
Pushed by dkazakov into branch 'master'.

Remove an assert that breaks some code

Some code expects end() to return raw value for saving/loading

M  +5    -6    libs/image/kis_time_range.h
M  +2    -0    libs/ui/kis_animation_frame_cache.cpp

https://commits.kde.org/krita/47b3cab9f82ba4591a484727a865edc57c44eef8
Comment 12 Halla Rempt 2018-06-16 09:00:16 UTC
I guess we can close this issue now.
Comment 13 Dmitry Kazakov 2018-06-25 17:58:07 UTC
Git commit 5b76f0f7aa834a91e0e201476333f5690eecbcc2 by Dmitry Kazakov.
Committed on 25/06/2018 at 17:18.
Pushed by dkazakov into branch 'krita/4.1'.

Remove an assert that breaks some code

Some code expects end() to return raw value for saving/loading

M  +5    -5    libs/image/kis_time_range.h
M  +2    -0    libs/ui/kis_animation_frame_cache.cpp

https://commits.kde.org/krita/5b76f0f7aa834a91e0e201476333f5690eecbcc2
Comment 14 Andrey 2018-06-26 15:11:41 UTC
Git commit ea5b0d1dd2f3c17c02bfaef8bbbf9f164294415e by Andrey Kamakin, on behalf of Dmitry Kazakov.
Committed on 26/06/2018 at 14:18.
Pushed by akamakin into branch 'akamakin/T8628-multithreading-optimization'.

Remove an assert that breaks some code

Some code expects end() to return raw value for saving/loading

M  +5    -6    libs/image/kis_time_range.h
M  +2    -0    libs/ui/kis_animation_frame_cache.cpp

https://commits.kde.org/krita/ea5b0d1dd2f3c17c02bfaef8bbbf9f164294415e
Comment 15 Andrey 2018-06-26 15:13:41 UTC
Git commit 2505e8821d524bf136caa861056c6f802d784cad by Andrey Kamakin, on behalf of Jouni Pentikäinen.
Committed on 26/06/2018 at 14:18.
Pushed by akamakin into branch 'akamakin/T8628-multithreading-optimization'.

Fix creating invalid keyframe times when pasting

Also added some safeguards against using infinite time ranges in
inappropriate places.

M  +2    -0    libs/image/kis_image_animation_interface.cpp
M  +1    -0    libs/image/kis_time_range.h
M  +4    -1    libs/ui/actions/KisPasteActionFactory.cpp

https://commits.kde.org/krita/2505e8821d524bf136caa861056c6f802d784cad
Comment 16 Dmitry Kazakov 2018-08-13 15:21:45 UTC
Git commit f1452472b9448acad20665eabfe75813c5e4af44 by Dmitry Kazakov.
Committed on 13/08/2018 at 15:21.
Pushed by dkazakov into branch 'master'.

Add a workaround for loading broken files with negative frame ids

Summary: CCBUG:395378

Test Plan:
Try to load the file attached to this bugreport:
https://bugs.kde.org/show_bug.cgi?id=395378

Every layer in the file should have two frames (in random order). At least one
of the frames should have sane pixel data

Reviewers: #krita, rempt, jounip

Tags: #krita

Differential Revision: https://phabricator.kde.org/D13562

M  +30   -0    libs/image/kis_keyframe_channel.cpp
M  +1    -0    libs/image/kis_keyframe_channel.h
M  +3    -2    libs/image/kis_raster_keyframe_channel.cpp
M  +3    -1    libs/image/kis_scalar_keyframe_channel.cpp
M  +3    -1    plugins/tools/tool_transform2/kis_transform_args_keyframe_channel.cpp

https://commits.kde.org/krita/f1452472b9448acad20665eabfe75813c5e4af44
Comment 17 Halla Rempt 2018-09-07 14:16:03 UTC
Git commit 7bcfd862e1e7b4e36b28811d36febb603e656e4d by Boudewijn Rempt, on behalf of Dmitry Kazakov.
Committed on 07/09/2018 at 12:36.
Pushed by rempt into branch 'krita/4.1'.

Add a workaround for loading broken files with negative frame ids

Summary: CCBUG:395378

Test Plan:
Try to load the file attached to this bugreport:
https://bugs.kde.org/show_bug.cgi?id=395378

Every layer in the file should have two frames (in random order). At least one
of the frames should have sane pixel data

Reviewers: #krita, rempt, jounip

Tags: #krita

Differential Revision: https://phabricator.kde.org/D13562

M  +30   -0    libs/image/kis_keyframe_channel.cpp
M  +1    -0    libs/image/kis_keyframe_channel.h
M  +3    -2    libs/image/kis_raster_keyframe_channel.cpp
M  +3    -1    libs/image/kis_scalar_keyframe_channel.cpp
M  +3    -1    plugins/tools/tool_transform2/kis_transform_args_keyframe_channel.cpp

https://commits.kde.org/krita/7bcfd862e1e7b4e36b28811d36febb603e656e4d