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.
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.
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.
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.
Even weirder, saving a file under another name when the file was loaded incorrectly results in a correct file.
In any case, it's not like loading files with group layers is completely broken...
I can reproduce a fail to load with the 4.0.0 appimage
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
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
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">
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
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
I guess we can close this issue now.
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
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
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
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
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