simply opening png doesn't work Reproducible: Always Steps to Reproduce: 1. open a simple png 2. 3. Actual Results: png image load in layer stack, but I can't work on it because krita give a blank screen I'm using last beta version (http://files.kde.org/krita/3/windows/devbuilds/krita-3.0-Beta-master-d330a4a-x64.zip) on Win 10
Is the screen black or blank? If black, your graphics card/driver combination might have bug and you might have to disable opengl in the settings/configure Krita dialog. If you see the transparency squares, something else is up.
Created attachment 98944 [details] this is what I obtain
Is that with 2.9 or 3.0? And does it change if you disable opengl?
As in first post, it's the last beta version (http://files.kde.org/krita/3/windows/devbuilds/krita-3.0-Beta-master-d330a4a-x64.zip). Disable opengl doesn't change.
Hm, that's strange, I just tried the same build on my win7 desktop and my test png file loaded correctly.
On linux I can open any png just fine i am on arch linux nvidia 750 ti (proprietary drivers) with opengl 'on' @ n1k0l4 if possible can you upload the png that doesn't open for you?
@Raghavendra kamath sure.. But I can't open any kind of png...
Created attachment 98945 [details] png
one test: I try to open the attached png with gimp, and then exported... it works :) So, is this kind of png the problem?
@ n1k0l4 thank you for sharing the file. I can reproduce the bug with your file I logged in on a spare windows 10 machine and i could open pngs in my system , i also tried with png downloaded from internet ( ex: this one -> https://en.wikipedia.org/wiki/Portable_Network_Graphics#/media/File:PNG_transparency_demonstration_1.png) you can try it too. However when I open the png provided by you I get the same screen as you , so in a way I can reproduce the bug on windows 10 as stated by you but only with your file. Thank you for sharing the file once again , i'll try to open it in linux version of krita
Yes, I can confirm with this png image.
How was this PNG created? The gama block is extremely weird: cHRM: 6.94525e-310 6.95262e-310 6.94525e-310 4.94066e-324 6.94525e-310 0 0 6.94508e-310 gAMA 4.94066e-324 sRGB 78
A normal png has: cHRM: 6.53249e-316 6.46603e-316 6.95218e-310 6.95265e-310 7.21377e-317 7.13487e-316 6.95218e-310 6.95217e-310 gAMA 0 sRGB 2077215784
And imagemagick identifies it as grayscale, we load as rgb.
Not a regression: 2.9 loads the image the same way.
I don't know how it was created because it was downloaded from an italian manga site (http://animeprodestiny.forumcommunity.net/?t=55738497) as a test for editor. this is the mirror for all png http://www.mediafire.com/download/pyp6h8w4wsfwyiv/%5BAPD%5D+Test+Editor.rar
So, basically, this is a grayscale png that says it's got a palette: we don't handle that yet. It's definitely a bug, but not a regression, so I'm first going to move on to the next regression.
Git commit 259d2ed6610fd60e863f14bde79a3295950ffc16 by Boudewijn Rempt. Committed on 02/11/2016 at 10:54. Pushed by rempt into branch 'krita/3.1'. The sample PNG has a resolution of 0,0 set, and PNG_RESOLUTION_METER as unit type, which is invalid and wrong, but now we can at least handle it. M +4 -4 libs/ui/kis_png_converter.cpp http://commits.kde.org/krita/259d2ed6610fd60e863f14bde79a3295950ffc16
There was even more wrong with this png: it had a resolution set of 0 ppi...
Git commit 3f03b830b40ad2d953c386d9507f0696069dd20f by Boudewijn Rempt. Committed on 03/11/2016 at 10:31. Pushed by rempt into branch 'rempt/impex-refactoring'. The sample PNG has a resolution of 0,0 set, and PNG_RESOLUTION_METER as unit type, which is invalid and wrong, but now we can at least handle it. M +1 -1 libs/ui/kis_png_converter.cpp http://commits.kde.org/krita/3f03b830b40ad2d953c386d9507f0696069dd20f