Issue #84: do not process color conversion twice.
authorJehan <jehan@girinstud.io>
Sun, 12 Feb 2023 11:58:19 +0000 (12:58 +0100)
committerJehan <jehan@girinstud.io>
Sun, 12 Feb 2023 12:25:40 +0000 (13:25 +0100)
Until now babl_fish_lut_process_maybe() was always returning 0, even
when a LUT existed, hence a LUT-based conversion happened.

This was bad, first because it was inefficient (the point of the LUT is
that we didn't have to process through usual conversion code paths). But
worse: when the source and destination buffers were the same, we would
end up getting wrong result (since we'd have the source converted
in-place, then re-converted, hence double conversion!).

This was the reason for issue #84 (see screenshot showing very wrong
colors because of double conversion).

babl/babl-fish-path.c

index 2674c7ebd890764467bb6e2774b7a9c6530af6e6..fcf998e5245f418f4114c06271c2232169296975 100644 (file)
@@ -127,7 +127,7 @@ babl_gc (void)
 
 static float timings[256] = {0,};
 
-static inline void _do_lut (uint32_t *lut,
+static inline int _do_lut (uint32_t *lut,
                            int   source_bpp,
                            int   dest_bpp,
                            const void *__restrict__ source,
@@ -252,6 +252,11 @@ static inline void _do_lut (uint32_t *lut,
              src+=3;
           }
         }
+        else
+        {
+          return 0;
+        }
+        return 1;
 }
 
 
@@ -503,8 +508,11 @@ static inline int babl_fish_lut_process_maybe (const Babl *babl,
      }
      if (lut)
      {
-        _do_lut (lut, source_bpp, dest_bpp, source, destination, n);
-        BABL(babl)->fish_path.last_lut_use = babl_ticks ();
+       if (_do_lut (lut, source_bpp, dest_bpp, source, destination, n))
+       {
+         BABL(babl)->fish_path.last_lut_use = babl_ticks ();
+         return 1;
+       }
      }
      return 0;
 }