Version: 1.5.1 (using KDE KDE 3.5.2) Installed from: Debian testing/unstable Packages OS: Linux As reported in Debian #354804, krita generates empty files when exporting CMYK images to PNG. I'm getting the same results as the downstream bug submitter with 1.5.1 on i386. TIFF export also generates invalid files. Since I don't know if this is due to the same bug, this bug report should be closed when the PNG issue is solved. If the issue with TIFF is different, I'll open a new one for that then. GIF export worked (more or less). When exporting to PNG, the error message "Could not save /home/chealer/Desktop/cmyk.png" appeared. This seems to be reproducible using any CMYK image. If anyone fails to reproduce, feel free to request me to attach an example one.
Zut! You're right -- I tested this some time during the 1.5.0 development cycle, but we've got a regression here. I'm assigning this bug to Cyrille, since he's the export guru. Cyrille, do you think we can fix this before 1.5.2 is released (i.e., in a month)?
for me it's a close to be a duplicate of #115433, that's not that png is failling to save the file, it's that png can't save to CMYK and that krita should either tell it, or maybe offer a conversion dialog, but I would prefer something generic to all krita's filter than something coded for each filter. And no matter what, it can't be fixed in the 1.5.x series. As for tiff, cmyk is supported by the file format, and should work, but no need to open a bug report I will investigate it today.
SVN commit 544617 by berger: bug fix: saving cmyk tiff CCBUG: 127992 M +1 -1 kis_tiff_writer_visitor.cpp --- branches/koffice/1.5/koffice/filters/krita/tiff/kis_tiff_writer_visitor.cpp #544616:544617 @@ -41,7 +41,7 @@ color_type = PHOTOMETRIC_RGB; return true; } - if ( cs->id() == KisID("CMYKA") || cs->id() == KisID("CMYKA16") ) + if ( cs->id() == KisID("CMYK") || cs->id() == KisID("CMYKA16") ) { color_type = PHOTOMETRIC_SEPARATED; TIFFSetField(image, TIFFTAG_INKSET, INKSET_CMYK);
SVN commit 544625 by berger: ugly hack to warn user when the colorspace can't be used for export BUG:127992 M +4 -1 jpeg/kis_jpeg_converter.cc M +4 -1 png/kis_png_converter.cc M +4 -1 tiff/kis_tiff_writer_visitor.cpp --- branches/koffice/1.5/koffice/filters/krita/jpeg/kis_jpeg_converter.cc #544624:544625 @@ -28,6 +28,9 @@ #include <qfile.h> #include <kapplication.h> +#include <kmessagebox.h> +#include <klocale.h> + #include <KoDocumentInfo.h> #include <kio/netaccess.h> @@ -70,7 +73,7 @@ { return JCS_CMYK; } - kdDebug(41008) << "Cannot export images in " + cs->id().name() + " yet.\n"; + KMessageBox::error(0, i18n("Cannot export images in %1.\n").arg(cs->id().name()) ) ; return JCS_UNKNOWN; } --- branches/koffice/1.5/koffice/filters/krita/png/kis_png_converter.cc #544624:544625 @@ -25,6 +25,9 @@ #include <qfile.h> #include <kapplication.h> +#include <kmessagebox.h> +#include <klocale.h> + #include <KoDocumentInfo.h> #include <kio/netaccess.h> @@ -59,7 +62,7 @@ return alpha ? PNG_COLOR_TYPE_RGB_ALPHA : PNG_COLOR_TYPE_RGB; } - kdDebug(41008) << "Cannot export images in " + cs->id().name() + " yet.\n"; + KMessageBox::error(0, i18n("Cannot export images in %1.\n").arg(cs->id().name()) ) ; return -1; } --- branches/koffice/1.5/koffice/filters/krita/tiff/kis_tiff_writer_visitor.cpp #544624:544625 @@ -19,6 +19,9 @@ #include "kis_tiff_writer_visitor.h" +#include <kmessagebox.h> +#include <klocale.h> + #include <kis_annotation.h> #include <kis_colorspace.h> #include <kis_group_layer.h> @@ -53,7 +56,7 @@ return true; } - kdDebug(41008) << "Cannot export images in " + cs->id().name() + " yet.\n"; + KMessageBox::error(0, i18n("Cannot export images in %1.\n").arg(cs->id().name()) ) ; return false; }
Cyrille, thanks for the quick TIFF fix and PNG/* workaround. About your comment "for me it's a close to be a duplicate of #115433, that's not that png is failling to save the file, it's that png can't save to CMYK and that krita should either tell it, or maybe offer a conversion dialog,", I agree that this looks like a variant of 115433, but note that this is not just about interface issues, but also about the generation of an empty file. The generation of an empty file could still be added to 115433's scope. Thanks again for your quick reaction