GNOME Bugzilla – Bug 592106
Missing fast paths for rotation by multiples of 90 degrees
Last modified: 2018-05-22 12:04:23 UTC
Multiple of 90 degrees rotate and axis aligned reflect do not have fast paths.
Created attachment 151298 [details] Proposed fix
Created attachment 151301 [details] Make the workaround more generic
Created attachment 151646 [details] [review] Some fixes to the fast path code + Do not use the fast paths for non-integral transformations. + Remove the matrix comparison code for fast paths from the public API. + Increment the src_rect.y by 1 for reflections about the X axis and src_rect.x by 1 for reflections about the Y axis.
Applying patch, leaving bug open as we still lack fast paths for rotation by multiples of 90 degrees. commit 520d69ab8a78e38af2c557d69323e9f9c4158aac Author: Debarshi Ray <debarshir@src.gnome.org> Date: Tue Jan 12 23:53:25 2010 +0200 affine: Add fast paths for axis aligned reflect Fixing bug 592106
Comment on attachment 151646 [details] [review] Some fixes to the fast path code [Setting "patch" flag and correcting mime type so this can actually be queried for.]
Massimo Valentini and I agree that fast paths are a really bad idea. Summary of why: I am pretty sure the "GIMP geometry convention" broke it <- bad reason I am not sure it speeds things up much, given that it introduces additional branching <- wishy washy reason Such shortcuts will bring you untold grief when you actually do transformations which are far from affine, and even then, it's not desirable. Better reasons: When you transformation happens to go through a reflection, the result will jump unless a) the sampler is interpolatory (sometimes called cardinal); and b) the geometry computation manically takes floating point errors into account (I am far from sure that the manic standard holds in GEGL now) Cristy of ImageMagick agreed enough that now ImageMagick does not use such shortcuts unless you do something with the plainest of calls (so as not to break old stuff). It's not only in the interior that things matter: Near the borders, not perfectly symmetrical (no choice, unfortunately, that's why there are a million ways to round in C99) stuff happens, and I would think that making sure things don't break is going to be a pain in the neck, not even dealing with the fact that deciding that something is a "perfect reflection" is a yes/no question which round off turns into a fuzzy one. Finally: I think that it was broken even before I moved GEGL to using the same geometry convention as GEGL.
After discussing things with Oyvind, it is clear that SOME fast paths are necessary, because GEGL now does the rendering heavy lifting when you scroll in GIMP. So, some form of integer translation fast path is necessary. Unfortunately, a filter like the popular Mitchell-Netravali cubic cannot use such fast paths without side effects, because it is not interpolatory. This means that unless the fast paths cache a filtered version and integer translate or rotate or reflect the filtered version when appropriate, the fast paths will make things "jump" if they are taken with a filter like Mitchell-Netravali (or the current GEGL cubic).
FYI, like gimp, gnome-photos directly rearranges the GeglBuffer instead of using gegl:rotate* to apply the embedded orientation of images. See: https://gitlab.gnome.org/GNOME/gnome-photos/commit/b4e7b56f9863654f07de61d444ccbc947b6c0838 It makes the entire decoding, including the time taken to read the bytes off the disk, 10 times faster.
-- 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/gegl/issues/8.