GNOME Bugzilla – Bug 787222
Can't convert from 16 bit to 16 bit floating point
Last modified: 2017-12-26 22:59:47 UTC
Created attachment 359042 [details] shredded picture (screenshot) Hello, sorry for my weak possibility to report bugs. My english is really poor and so are my abilities with all this technical stuff... When I tried to open a 16 bit floating point xcf file wich I had made with Gimp 2.9.4, the whole picture opened with shredded vertical bars. (I made a screenshot.)When I export it to jpg it comes out correctly. After this I tried to convert another file from 16 bit to 16 bit floating point. And at this point it became also shredded. I hope I did this bug report stuff correctly. Best regards, Susi
Created attachment 359044 [details] viewport bug at different zoom levels I can confirm this behavior on Windows 10, Gimp 2.9.6 Windows build by Ell, based on commit 5afea2f. Multithreading is disabled. Converting from whatever other precision to 16 bit floating point will create the distortion effect, that can be seen in the original report. Although it does look like a simple offset at first, it is in fact not, as illustrated in my attachment. The black lines should have the same opacity all over the image, since they are drawn with the pencil tool. The distortion depends on the current zoom factor of the viewport (getting more extreme the more you zoom out) and disappears at around 51% (so everything from 51%++ will be not distorted. Everything that is added to the distorted canvas will have the same kind of distortion (Pencil drawings, Filter results, ...) at the affected zoom levels.
I can't reproduce this on Linux, latest git of everything as of today.
Confirming. Happens on Windows, but not on Linux. How weird is that? :)
Could be a compiler issue, maybe some flags need to be passed in order to get working half float?
Turns out this is a (pretty scary) compiler bug, affecting GCC 7.2, which was used for the Windows build. This has nothing to do with Windows vs. Linux, or half-precision floats. Using 16-bit float just happens to trigger a GEGL code path that's affected by this bug. In particular, 16-bit float tiles are downscaled using gegl_downscale_2x2_generic(), which converts the data to 32-bit float, and uses gegl_downscale_2x2_float() to do the actual work. Since the BPP of the temporary buffers used by gegl_downscale_2x2_generic() is known at compile time, GCC is able to inline the call to gegl_downscale_2x2_float(), and generate vectorized code for it... Only that the code it generates is wrong, resulting in these artifacts.
Is there a corresponding gcc bug report?
There is now :) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82108
Is there a way to work around the compiler bug in our code (and should we even do this)? If not, I'd suggest a configure test which outputs a warning when using affected GCC versions because that's a pretty bad issue.
Adding 2.10 milestone.
This isn't really worth working around. For all we know, this bug may affect other code as well. I think a configure/sanity warning is the most we should do, if anything. Regardless, it would be a good idea to add compiler version info to $ gimp -v.
Totally +1 on the compiler info in gimp -v
Adding a configure test: commit 9b4382614be46468c3fbe384e7ffc73c9cb2bb43 Author: Jehan <jehan@girinstud.io> Date: Sat Sep 9 23:21:42 2017 +0200 Bug 787222 - Can't convert from 16 bit to 16 bit floating point. This comes from a bug in GCC itself. Comparing with GCC's revision dates (bug introduced in revision 250312 in 18th of July 2017), this bug apparently affects only GCC 7.2. Let's just add a configure warning so that builders are made aware of the issue when they use this compiler. See also: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82108 configure.ac | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) Will add compiler info to `gimp -v` as well.
commit 2c19ea21457b5e79b1c8621ed79337f07c273143 Author: Jehan <jehan@girinstud.io> Date: Sun Sep 10 01:20:13 2017 +0200 app: add compiler info in `gimp -v`. app/Makefile.am | 1 + app/version.c | 1 + configure.ac | 16 ++++++++++++++++ 3 files changed, 18 insertions(+)
Aaaand, the GCC bug is fixed :)
I'd hoped we'd have a new GCC release by 2.9.8, but since that didn't happen, I used GCC 6.3 for the windows binaries. Either way, this should be fixed in 2.9.8.
I don't see this with the current gcc 7.2.0 in Debian Testing. $ gcc --version gcc (Debian 7.2.0-18) 7.2.0 They likely included a fix.