Re: [Gimp-developer] A way to do 16 bits?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I would be the first to applaud when 16bit is integrated, yet this does not feel right long term, because any code written for "2 layers mode" will have to change when the data is correctly layout as a true 16bit number.

-Joseph

William Skaggs wrote:
I've been thinking about three things that are highly desired but
have been waiting for the migration to gegl: support for 16 bits,
layer groups, and procedural layers. It seems to me that all of
them can be achieved in GIMP 2 without major infrastructure changes,
not perhaps in the most ideal way, but not in a kludgy way either.
Given that the switch to gegl will probably entail a long development
cycle, it may be worth considering what can be done in the meantime
with GIMP 2.


In this email I will discuss the 16-bit-depth issue, and leave the others
for later.

The basic idea for supporting 16 bits is to treat a 16-bit layer as
two 8-bit layers, a "main" layer for the high byte and an "auxiliary"
layer for the low byte.  The auxiliary layer would never be visible,
would not appear in the Layers dialog, and would always move together
with the main layer.

The thing that makes this approach feasible is that for most purposes
the low byte of a 16-bit layer is invisible to the user.  As a starting
point, then, it can simply be ignored in computing the projection.
(Some composition modes, particularly "divide", may ultimately want
to make use of it, though.)

The program would then be to build 16-bit support gradually into tools
and filters.  It needn't be done all at once, because a lack of 16 bit
support simply means ignoring the low byte of the input, which is not
a disaster in the great majority of cases.

There are really only two things, as far as I can see, that would need
to be done right at the start:  change the Layers dialog so that auxiliary
layers don't appear, and change the layer-moving commands so that
main and auxiliary layers move together.  Everything else could be
added over time, and nothing in GIMP would be seriously broken during
the process.

I look forward to feedback :-).

Best,
-- Bill


______________ ______________ ______________ ______________
Sent via the KillerWebMail system at primate.ucdavis.edu



_______________________________________________
Gimp-developer mailing list
Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer




[Index of Archives]     [Video For Linux]     [Photo]     [Yosemite News]     [gtk]     [GIMP for Windows]     [KDE]     [GEGL]     [Gimp's Home]     [Gimp on GUI]     [Gimp on Windows]     [Steve's Art]

  Powered by Linux