I am having to backtrack to Krita version 2.8 to open certain files that have imported layers that originated from .TIF files. I have a comic book template that I have been working off of in version 2.8 of Krita, when I updated to version 2.9 these files are unable to open due to "Could not load pixel data". The error is below. (Note: I removed the whole file paths for confidentiality reasons). ----- Could not open /Issue 1/Pages/pg_3/pg_3_pencil.kra Reason: Could not load pixel data: /Issue 1/Pages/single_page_template.tif/layers/layer6.. Could not load pixel data: /Issue 1/Pages/single_page_template.tif/layers/layer5.. Could not load pixel data: /Issue 1/Pages/single_page_template.tif/layers/layer4.. Could not load pixel data: /Issue 1/Pages/single_page_template.tif/layers/layer3.. Could not load pixel data: /Issue 1/Pages/single_page_template.tif/layers/layer2. ----- (Tried running through the terminal for some additional info, just got the same error message outside the terminal with no additional info inside the terminal). Other files that I originally made in 2.8 open and work fine. The only difference I have been able to find is that I imported a template .TIF image into one file, and the others I didn't. This reason doesn't make complete sense to me though, as there is only one layer that was created from an imported .TIF file, but the error makes it seem like it is linking to the .TIF file that I originally imported into "pg_3_pencil.kra". Reproducible: Always Steps to Reproduce: 1.Make a .TIF file with some image data 2.Create a .KRA file in Krita 2.8 3.Import .TIF as a later in the .KRA file 4.Save 5.Uninstall Krita 2.8 6.Install Krita 2.9 7.Open the .KRA file with the imported .TIF layer Actual Results: In Krita 2.9, .KRA file doesn't load and throws error about original imported .TIF file and all layers inside the .KRA file not being able to load their pixel data. Expected Results: In Krita 2.9, .KRA file loads regardless if it has layers created from imported .TIF images. Kubuntu 14.10 64-bit Krita 2.9.0 through dimula73/krita PPA
Hi William, Thanks for your report. Could you share the actual .kra file with us? If it's confidential, feel free to mail it directly to me.
File sent. Thank you Boudewijn!
Hi William, A krita .kra file is a plain old zip file, so I unzipped it and took a look. There are two issues with the file you sent me: the internal path to the layer data starts with a /, which means the zip code is getting confused and thinks that the layer data is outside the zip file, because this means an absolute path. The second problem is the the long path to the layer data, which has spaces inside. I'm not sure why that's a problem, and I'll look into it, but I'll mail you a fixed file so you can at least access your data. If you have more files like this, you can fix them by: * make a temporary directory * enter the temporary directory * unzip the .kra file * make a directory called 'image' * move the layer and annotation folders at the end of the long path to 'image' * open the xml files and replace the long path with image * zip the result up again.
Krita using .zip compression to create it's files is an interesting fact. I wonder if this might have something to do with with the bug I recently filed for the Ark file compression utility used in Kubuntu. Here https://bugs.kde.org/show_bug.cgi?id=344923 Recently Ark has been creating bad .zip files for me. But this doesn't make too much sense that these Krita files work just fine with Krita 2.8.6. Unless Krita uses a bugged version of Ark internally to create the .kra files? Sounds like a long shot though. Thank you for looking into this Boudewijn. Also, thank you for the information on changing the files so they work with the latest version of Krita. I have had to backtrack to 2.8 in order to do my work until now. But with the process to manually fix the files, I can enjoy all the new features 2.9 has to offer :)
It's actually possible, ark and krita use the same library for reading and writing zip files, and there's been a bit of development in those libraries recently. On the other hand: if 2.8 works for you and if you haven't had to change your version of the kde libraries, then the bug really must be in Krita. So that's what I will assume for now -- and I'll try to find a fix asap.
Oh dear, now I know what's up. It isn't the spaces, it isn't the leading /, it's the part of the folder tree that was just a number. Prior to 2.9, the calligra libraries had a bug where there's be a string 'part' prepended to any folder that started with a number. So... We'd store this in maindoc.xml: name="media/lachoneus/Wills External Hardrive/Thor_Media/2014/Company Work/Art/Project Ark/Issue 1/Pages/single_page_template.tif" And then we'd use this path in the zip file: name="media/lachoneus/Wills External Hardrive/Thor_Media/part2014/Company Work/Art/Project Ark/Issue 1/Pages/single_page_template.tif" Let's see what I can do to patch this up...
Git commit c1f1a85c7ff6bb0108b162043db33d35f1c0c95d by Boudewijn Rempt. Committed on 20/03/2015 at 09:45. Pushed by rempt into branch 'calligra/2.9'. Related: bug 2, bug 9 If a part of a path started with a number, KoStore pre 2.9 would prepend 'part'. We don't do that anymore, but there are files out there with that weirdness, so check whether the path can be opened, and if it can't, fix it up. M +26 -1 krita/ui/kra/kis_kra_load_visitor.cpp http://commits.kde.org/calligra/c1f1a85c7ff6bb0108b162043db33d35f1c0c95d