Image -> Properties, Depth: 8-bit integer/channel The image consists of 3 bands of solid R, G and B. due to the 0/255 values when I export to a format such as PNG, optimization appears to happen where Krita knows it could use 1-bit channels instead to represent the image. There is no option listed in the export dialog to prevent this. While I'd like the image to retain the 0 and 255 channel values, this optimization prevents it being able to work with FreeImage(which a program I am trying to use the image with relies on) as it does not support the bit depth. Can the ability to prevent this during export be made available? ImageMagick's `identify -verbose /path/to/image.png` is what helped me realize Krita was providing false information on bit depth of the image(probably because it could be edited as 8-bit in Krita and thus wasn't locked to 1-bit per channel like the stored format?). identify output snippet: Depth: 8/1-bit Channel depth: red: 1-bit green: 1-bit blue: 1-bit alpha: 1-bit ...... png:IHDR.bit-depth-orig: 8 png:IHDR.bit_depth: 8 png:IHDR.color-type-orig: 6 png:IHDR.color_type: 6 (RGBA) png:IHDR.interlace_method: 0 (Not interlaced) png:IHDR.width,height: 9, 9
Krita cannot work with indexed images nternally. There is an option to save png images as indexed, if possible. Please attach your original .kra file and the .png file your talking about to the bug report so I can check what's up.
Created attachment 105987 [details] .kra file
Created attachment 105988 [details] .png 1-bit per channel
(In reply to Boudewijn Rempt from comment #1) > There is an option to save png images as indexed I've seen that option and I had it unchecked.
I think that it's libpng that does that automatically... Or maybe the standard forces this. I converted the file to psd and saved the image with gimp and photoshop and identify gives exactly the same results: Image: rgb_gimp.png Format: PNG (Portable Network Graphics) Mime type: image/png Class: DirectClass Geometry: 9x9+0+0 Resolution: 37.4x37.4 Print size: 0.240642x0.240642 Units: PixelsPerCentimeter Type: Palette Endianess: Undefined Colorspace: sRGB Depth: 8/1-bit Channel depth: red: 1-bit green: 1-bit blue: 1-bit Channel statistics: Red: min: 0 (0) max: 255 (1) mean: 103.889 (0.407407) standard deviation: 125.295 (0.491352) kurtosis: -1.85795 skewness: 0.376889 Green: min: 0 (0) max: 255 (1) mean: 103.889 (0.407407) standard deviation: 125.295 (0.491352) kurtosis: -1.85795 skewness: 0.376889 Blue: min: 0 (0) max: 255 (1) mean: 103.889 (0.407407) standard deviation: 125.295 (0.491352) kurtosis: -1.85795 skewness: 0.376889 Image statistics: Overall: min: 0 (0) max: 255 (1) mean: 103.889 (0.407407) standard deviation: 125.295 (0.491352) kurtosis: -1.85795 skewness: 0.376889 Format: PNG (Portable Network Graphics) Mime type: image/png Class: DirectClass Geometry: 9x9+0+0 Resolution: 37.4x37.4 Print size: 0.240642x0.240642 Units: PixelsPerCentimeter Type: Palette Endianess: Undefined Colorspace: sRGB Depth: 8/1-bit Channel depth: red: 1-bit green: 1-bit blue: 1-bit Channel statistics: Red: min: 0 (0) max: 255 (1) mean: 103.889 (0.407407) standard deviation: 125.295 (0.491352) kurtosis: -1.85795 skewness: 0.376889 Green: min: 0 (0) max: 255 (1) mean: 103.889 (0.407407) standard deviation: 125.295 (0.491352) kurtosis: -1.85795 skewness: 0.376889 Blue: min: 0 (0) max: 255 (1) mean: 103.889 (0.407407) standard deviation: 125.295 (0.491352) kurtosis: -1.85795 skewness: 0.376889 Image statistics: Overall: min: 0 (0) max: 255 (1) mean: 103.889 (0.407407) standard deviation: 125.295 (0.491352) kurtosis: -1.85795 skewness: 0.376889 Colors: 4 Heck, identify gives the same results on the psd file: Image: rgb.psd Format: PSD (Adobe Photoshop bitmap) Class: DirectClass Geometry: 9x9+0+0 Resolution: 95x95 Print size: 0.0947368x0.0947368 Units: PixelsPerInch Type: Palette Endianess: Undefined Colorspace: sRGB Depth: 8/1-bit Channel depth: red: 1-bit green: 1-bit blue: 1-bit Channel statistics: Red: min: 0 (0) max: 255 (1) mean: 103.889 (0.407407) standard deviation: 125.295 (0.491352) kurtosis: -1.85795 skewness: 0.376889 Green: min: 0 (0) max: 255 (1) mean: 103.889 (0.407407) standard deviation: 125.295 (0.491352) kurtosis: -1.85795 skewness: 0.376889 Blue: min: 0 (0) max: 255 (1) mean: 103.889 (0.407407) standard deviation: 125.295 (0.491352) kurtosis: -1.85795 skewness: 0.376889 Image statistics: Overall: min: 0 (0) max: 255 (1) mean: 103.889 (0.407407) standard deviation: 125.295 (0.491352) kurtosis: -1.85795 skewness: 0.376889 So I'm not sure whether your analysis is correct. Btw, I know freeimage (http://freeimage.sourceforge.net/) only because it's a source of bugs where it's used in deepin's qimageio plugins. Or did you mean a different freeimage? How are you using freeimage with these png's?
> How are you using freeimage with these png's? A library called ArrayFire that allows you to load images onto the GPU. I wanted to work with the values of 0 and 255 but it threw an error about FreeImage not being happy with the bitdepth. I wasn't aware that was an issue with other popular image programs as well or due to a standard. In that case I guess this isn't a bug for Krita. The outcome of the export being optimized like that was just unexpected.
Maybe use one of the formats that really are just the channel values concatenated?
It's not an issue for me with the library anymore as it was only for understanding how the data was presented via the API ArrayFire has. I had used jpg prior with max quality settings and from memory some 0 became 1 and some 255 became 254, which I guess is expected of a lossy format. Thanks for clarifying everything :)