On Fri, Jun 27, 2008 at 11:32 PM, <[EMAIL PROTECTED]> wrote:
> On Fri, 27 Jun 2008 03:02:01 +0200, David Gowers <[EMAIL PROTECTED]> wrote:
>> and is no longer required in today's
>> world of fast CPUs with fast FSBs, large memory, and huge hard drives.
> Easy on the sweeping assumptions here. Embedded systems are in exponential
> growth right now and correspond in performance to what you are quickly
> writing off as old and decrepid hardware that is best ignored.
> Many embedded systems are reaching a power that allows them to be used for
> image and even video (CCTV) applications. It's unlikely, though not
> impossible, that you'd use such a system for GUI image manipulation but Gimp
> could conceivably be useful here for batch processing images or other tasks.
> Be careful not to assume all target systems are like your average desktop
GIMP doesn't run on embedded systems AFAIK (mainly because of its
minimum screen resolution requirements.)
In any case, what you said above is true and unrelated. GEGL seems a
much better choice for batch manip generally, however even if you
would use GIMP, nothing would force you to use high bitdepths.. GEGL
allows you to make different versions of an operation for different
data types / colorspaces, so you would perhaps need to make
8bit-optimized versions (more likely, GIMP would implement these
itself already, since it's a common data type). The difference is that
GIMP needn't make that assumption, and thus the overall application is
more flexible, accommodating different color spaces and color depths
in the one application transparently.
In short: optimization reflects an underlying assumption, and the
assumption that 8bit is the only efficient choice is no longer true,
therefore the optimization of assuming 8bit is no longer appropriate.
Gimp-developer mailing list