GNOME Bugzilla – Bug 690265
libgimp/gimptilebackendplugin.c provides no pyramid
Last modified: 2018-05-24 13:25:48 UTC
If the scale value is <= 0.5, the buffer is not scaled as expected. I have a piece of code which works as expected for any scale > 0.5 (scale down or up), but as soon as I try scale <= 0.5, the resulting image in the destination buffer is bigger than expected. In gegl/buffer/gegl-buffer-access.c : gegl_buffer_get_unlocked(), there is this piece of code: while (scale <= 0.5) { scale *= 2; factor *= 2; level++; } If I simply comment it out, the scaling under 0.5 suddenly works as expected. So this level thing is broken somewhere. But I guess it must have been done this way for a reason (more efficient way to scale up by factors of 2, I imagine?) so removing this part is not the right fix. I don't know if this fails in every case. Here is the flow I followed for mine: This computed level is used in gegl_buffer_iterate_read_dispatch() > gegl_buffer_iterate_read_abyss_none() > gegl_tile_source_get_tile (). I see at some point it calls get_tile() from gegl/buffer/gegl-tile-handler-zoom.c. But as it get the tile from the source (cache in my case), it returned directly and did not do anything with z. Considering the name of this tile source (GeglTileHandlerZoom), does it mean the scale to half should happen at this point? I wanted to fix, but I definitely don't know well enough yet GEGL code and logics to understand where the level value is supposed to be handled (because right now, it seems it never is). If I could get some pointer, would be nice (or of course, you can fix, but I'd like to understand GEGL code better too).
Created attachment 231655 [details] Animation play with zoom Hey Mitch, I know that gegl_buffer_get() works on GIMP, but maybe I am in a special case (?) that we don't encounter on GIMP code; yet I am very happy if you can prove me wrong here. But really I have a very basic piece of code that I am going to show you (attached). You can simply replace plug-ins/common/animation-play.c in your tree by this version, which has many more features than what is currently on the repo (I am actually waiting for several patches to be reviewed by yourself before I can submit the ones to arrive to this very nice version! :p). And in particular, it has a zoom/scaling feature (and now the attached version of the display is in a scroll window, which allows to play even very detailed parts without breaking window usability. Of course the detached version has no scrolling on the other hand). If you play with it, you can see that bigger zooms work, smaller zooms work, but when you select 50 % or below, suddenly you get the 100% drawing in the smaller drawing area. I have left 2 printf in the code, only for the debugging purpose of displaying the parameter values just before the gegl_buffer_get(). As you will see, the width, height and scale are correct, but not the result. Check the render_frame() function for the appropriate call. Finally as I said before, if you were to comment out the part which compute the factor/level in GEGL code, it suddenly works as expected.
This seems to be a problem in gimp, see http://git.gnome.org/browse/gimp/tree/libgimp/gimptilebackendplugin.c#n135 probably the transfer between GIMP-core and a plug-in of tiles from upper levels of the mip-map is not yet implemented.
Ah of course, the GIMP core had the same problem when we used to have the TileManager buffer backend. You can't have a backend without a mipmap, and have a pyramid at the same time. Sigh.
This one seems to be fixed now (purely from empirical tests. What used to not work does now). Is there something else I am missing, or has it been fixed? :-)
Nope, I was wrong. That one is still there. Not sure what I did in my last test which made me think it was fixed. But it's definitely not fixed. Please disregard my previous comment. :-P
Perhaps GEGL should support meta-data for the tile backend about whether it suppot z coordinate for tile indices; and do something a little bit more reasonable if there is no mipmap levels?
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gimp/issues/440.