| Summary: | Broken EXR and TIFF when exporting from some color spaces | ||
|---|---|---|---|
| Product: | [Applications] krita | Reporter: | Geekley <mrgeekley> |
| Component: | File formats | Assignee: | Krita Bugs <krita-bugs-null> |
| Status: | REOPENED --- | ||
| Severity: | normal | CC: | amy |
| Priority: | NOR | ||
| Version: | 5.1.3 | ||
| Target Milestone: | --- | ||
| Platform: | Flatpak | ||
| OS: | Linux | ||
| Latest Commit: | https://invent.kde.org/graphics/krita/commit/132211ddd13a34a56ab46c5c89282b63a955f4fc | Version Fixed In: | |
| Sentry Crash Report: | |||
| Bug Depends on: | 462799, 462925 | ||
| Bug Blocks: | |||
| Attachments: |
Test files - source images, broken files and exportation script
Dolphin previews of original sent files from "broken" folder Dolphin previews of "broken", retrying script now to ensure flatten image Exported files after retrying script now to ensure flatten image Example file that Krita reads incorrectly (fully white issue) |
||
|
Description
Geekley
2022-11-18 04:46:39 UTC
I've started triaging this bug. There are some interesting insights on the characteristics of the broken TIFF files, I'll write back when I have a fuller picture. Ok, I've tested this and have a few observations. > OBSERVED RESULT > The source KRA files use paint and vector layers. > - Sometimes vector layers aren't exported. [BUG] I was able to consistently reproduce the latter error with your files, but only when not flattening the files. Something's failing inside LibTiff and not in our code. I'll try and debug it on my end. > However, even if you convert all layers to paint layers, they'll still be broken because of other problems: > - No files export alpha channel correctly (result often has opaque background, sometimes image is totally empty). This is correct and consistent with `Store Alpha Channel (transparency)` being unset by default on your end. The latter is actually consequence of the error above (as we never checked the return value of LibTiff when writing each layer). > - Most files in Gray/Alpha color space export Gray channel incorrectly (often file is green). [BUG] Can confirm this with the Tev viewer. All GrayA images store as green, will check the code in light of https://lists.aswf.io/g/openexr-dev/topic/82133584?p=Created,,,20,2,0,0::,,,0,0,0,82133584 . > - Some files appear broken in other viewers (in addition to the problems above when opening in Krita), e.g. some TIFF previews are all messed up in Dolphin. I don't have Dolphin, but all files (when flattened) show correctly in macOS Preview and the Windows 10 Photo Viewer (except for the CMYK 32f whose depth seems to be unsupported). It'd be great if you could send the affected files here plus previews of each, to understand what the graphical glitches are. > - Files in "encodedBadly" folder have incorrect colors because the result expects linear colors but they didn't convert from sRGB, so they're lighter than the original. This can be seen by inspecting the "0.5" gray in the middle. Triangle was sRGB gray (should be close to #808080) and circle was linear gray (should be 0.5f in linear space, equivalent to #bcbcbc); tertiary colors also use the same logic. [BUG] Can confirm with the Tev viewer. Will dig deeper into this. > > - Sometimes vector layers aren't exported. > [BUG] I was able to consistently reproduce the latter error with your files, but only when not flattening the files. Did you test both GUI and command line? I ran a quick test here: `flatpak run org.kde.krita --export CMYK-8-cp.tif.kra --export-filename CMYK-8-cp.tif` and I got the inconsistency I said before: > 6. Sometimes exporting from Krita GUI gives a different result from the command-line (bug!), but this result is still broken for one reason or another. > This is correct and consistent with `Store Alpha Channel (transparency)` being unset by default on your end. I'm a bit confused because I thought I always enable alpha. So I just tested TIFF exportation and I found something really weird in the GUI. "Flatten the image" was checked and "Store alpha" was unchecked and disabled/locked. When I uncheck flatten, alpha becomes checked and still locked. When I check flatten again, alpha becomes checked and UNLOCKED! This has to be a bug and might have caused either the issue itself or some confusion in my testing. I don't know if it's always like this or if it happens on some specific case. > It'd be great if you could send the affected files here plus previews of each, to understand what the graphical glitches are. I'll add just the screenshots for now (little time). The "broken" folder is from the original files I sent. The "broken-retry" is what I tried again now, double-checking that it should use flatten image (in case it didn't do that the first time); both were generated from that command line script. Created attachment 154449 [details]
Dolphin previews of original sent files from "broken" folder
Created attachment 154450 [details]
Dolphin previews of "broken", retrying script now to ensure flatten image
Created attachment 154452 [details]
Exported files after retrying script now to ensure flatten image
I kept them in the same folder as the originals. I hope I did it right.
> This has to be a bug and might have caused either the issue itself or some confusion in my testing. I don't know if it's always like this or if it happens on some specific case.
Yes, that's a bug I found first hand when trying your files here. I'll try and commit the first set of patches (this issue and the EXR grayscale import/export) today so you can try with the nightlies of tonight.
(In reply to amyspark from comment #2) > [BUG] I was able to consistently reproduce the latter error with your files, > but only when not flattening the files. Something's failing inside LibTiff > and not in our code. I'll try and debug it on my end. We recently changed the code so that all file accesses went through Qt, in order to support Android's content URLs. We had not noticed that LibTiff actually requires simultaneously read and write mode to save multi-page TIFFs, so we set it as write-only. I'll clean up the code while at it, as it'll help be more maintainable long-term. A possibly relevant merge request was started @ https://invent.kde.org/graphics/krita/-/merge_requests/1671 Git commit 179a85f477627256aa2db22ac6ef8f7b6cb54b63 by L. E. Segovia. Committed on 12/12/2022 at 15:23. Pushed by lsegovia into branch 'master'. TIFF: fix LibTiff requiring read/write access to write multi-page files M +4 -3 plugins/impex/tiff/kis_tiff_export.cc https://invent.kde.org/graphics/krita/commit/179a85f477627256aa2db22ac6ef8f7b6cb54b63 Git commit 229cca731c977cbbc2914da45f3d3a4eb4edbccc by L. E. Segovia. Committed on 12/12/2022 at 15:27. Pushed by lsegovia into branch 'krita/5.1'. TIFF: fix LibTiff requiring read/write access to write multi-page files (cherry picked from commit 179a85f477627256aa2db22ac6ef8f7b6cb54b63) M +4 -3 plugins/impex/tiff/kis_tiff_export.cc https://invent.kde.org/graphics/krita/commit/229cca731c977cbbc2914da45f3d3a4eb4edbccc > I'll try and commit the first set of patches (this issue and the EXR grayscale import/export) today so you can try with the nightlies of tonight.
Cool! I've tried 5.1.4 and I can see the checkbox issue was fixed and the green issue too. Files are still broken (mostly because of the vector layers), but there has been improvements.
Some EXR files (e.g. GrayA-16-linear.exr) that were opening as fully transparent in Krita before (when preview was green), now at least show something, but colors that should be grayscale currently appear as fully white in Krita (but are grayscale in Gwenview, GIMP, Dolphin previews). So, it's not just writing, there must be some additional issue in reading EXR files too.
Created attachment 154718 [details]
Example file that Krita reads incorrectly (fully white issue)
Git commit ee625a5f0dc63eb23f5a9e913837d01e76921d0e by L. E. Segovia. Committed on 27/12/2022 at 02:52. Pushed by lsegovia into branch 'master'. EXR: fix opening files with only luma channel M +23 -5 plugins/impex/exr/exr_converter.cc https://invent.kde.org/graphics/krita/commit/ee625a5f0dc63eb23f5a9e913837d01e76921d0e Git commit 132211ddd13a34a56ab46c5c89282b63a955f4fc by L. E. Segovia. Committed on 27/12/2022 at 02:53. Pushed by lsegovia into branch 'krita/5.1'. EXR: fix opening files with only luma channel (cherry picked from commit ee625a5f0dc63eb23f5a9e913837d01e76921d0e) M +23 -5 plugins/impex/exr/exr_converter.cc https://invent.kde.org/graphics/krita/commit/132211ddd13a34a56ab46c5c89282b63a955f4fc I'm working on supporting vector layers, at least by converting them to bitmaps. The code is, however, so old that it'll take me a while before I can show some reliable results. I'll CC this bug once I have news; but as this bit is specifically a wishlist one, I've marked this bug as resolved. Thanks for your testing and the heads up! I've tested with 5.1.5 and, just a reminder, some issues here (other than the vector layer thing) still persist.
TIFF exportation is weirdly behaving differently when the file exists - it's not deterministic. Each time the file is overwritten, file size keeps increasing. This issue happens on both GUI and command-line exportation (I tested on this file RGBA-8-sRGB). I didn't test this before, but it seems plausible to assume this was introduced with the read-write mode thing (it doesn't happen on EXR). Though minor, I'd say it's still a bug.
It's still having inconsistent results between command-line and GUI exportation of the same file with (presumably*) same settings.
I tested RGBA-8-sRGB.tif.kra and when exporting from GUI, the file is perfect, even vector layers are OK.
When I had tested command-line though, at first on batch exportation (all-kra-convert.sh), I got broken files.
Then I tested again, exporting only this file:
flatpak run org.kde.krita --export RGBA-8-sRGB.tif.kra --export-filename RGBA-8-sRGB-sh.tif
And the file wasn't broken this time, though it wasn't perfect like from GUI (some text** isn't shown). So, unless it has something to do with settings, there's inconsistency between GUI and command-line exports. I tried batch again but they weren't broken this time, so who knows what happened...
* (I say presumably because unfortunately there's no way to enforce/ensure specific exportation settings, so I expect it to use last used settings; a feature to set those via command-line/json would be great and also significantly help testing).
** May be related to this warning - though it's strange that the issue is only via command-line:
krita.file: WARNING: 'font-size-adjust' SVG attribute is not supported!
First issue: Maybe it's easy to solve by just deleting the file before re-creating it on read-write mode or something like that. Second issue: Actually, it might not be related to that warning after all; on closer inspection, this font-size-adjust attribute is on the text that's being shown correctly (imported/pasted from Inkscape svg), not on the one that is not rendered (Legend vector layer made in Krita). In any case, if this is more related to the vector layer support feature and out-of-scope, then ignore this part I guess. > First issue: Maybe it's easy to solve by just deleting the file before re-creating it on read-write mode or something like that.
This is because libtiff's one of the few libraries that need to go through Qt's QIODevice to work in Android. IIRC, libtiff does not reuse IFDs on rewrite, so we'll have to open the file with truncation mode to keep it from ballooning.
|