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

Hi,

"William Skaggs" writes:

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.

Let's see. We have GIMP 2.2 done and are preparing to switch to GEGL. At this point you are trying to propose a kludge? Sorry, but I am not going to read any further...

Sven

William Skaggs wrote:

Sven wrote:

Let's see. We have GIMP 2.2 done and are preparing to switch to GEGL. At this point you are trying to propose a kludge? Sorry, but I am not going to read any further...

Well, the most recent ChangeLog entry for gegl is dated 3-25-04, and if it is nearly ready to use, then the CVS archive and the gegl web page are very misleading. Am I missing something?

You're missing all the brainpower Øyvind Kolås has put into gggl and oxide while evaluating concepts that will get into GEGL and XCF2. See http://pippin.gimp.org for more information.

Michael

Hi,

William Skaggs wrote:

Well, the most recent ChangeLog entry for gegl is dated 3-25-04, and if it is nearly ready to use, then the CVS archive and the gegl web page are very misleading. Am I missing something?

No. Step 1 to using gegl is working on gegl. The needs for gegl before we can start using it are:

1) at least one concrete implementation of all of the abstract interfaces

2) An application that uses gegl. Something that just does a file load and file save (something like convert) would be enough - it just needs to work :)

Once we have both of those, the GIMP can start migrating to those interfaces (even if they change regularly), and we can get more people working on alternative back-ends for the abstract stuff. For example, there were several people interested in optimising images in memory - that's a research project for gegl, but it's not a requirement for us before we start using it (nor, honestly, is a tile-based model - a flat big block of memory would do to start off with).

Nor do we need a CMYK data model to start with - RGB8 is fine. We just need something behind those interfaces we're going to migrate to.

It would be great to let people loose on gegl and that was the plan 6 months ago - get 2.2 out the door, and then put the GIMP into maintenance mode (feature chill or whetever you want to call it) until gegl had reached a stage where it could be used. That means all the people currently putting code into the GIMP would be putting code into GEGL.

It may not work like that - there were a couple of features I would really have liked to see in 2.2 that didn't get in there, things like text boxes and text on a path, color management. So perhaps there will be a GIMP 2.4 after all. But we should get as many as people as possible working on gegl as soon as possible. And we need an updated design doc to do that. The unit tests and the template code that's there is a good start, but what we could do with is someone writing an update to the 1998 design docs.

I've CCed gegl-developer, since that's where this belongs.

Cheers, Dave.

On 15.12.2004, at 20:16, 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.

Why do you want to have 16 bits per channel when most if not all tools will only work with the MSBs?

It would probably be the same amount of work to DTRT and simply extend the core to work with 16 bit values instead of 8 bit. A big start would be to replace all implicitely coded pixel composites by arrays containing a unioned datatype representing a pixel which for your purpose could be dynamically modified to supply a higher color resolution and later be more easily replaced by GEGL types, no?

Servus,
Daniel

Hi,

"William Skaggs" writes:

Sven wrote:

Let's see. We have GIMP 2.2 done and are preparing to switch to GEGL. At this point you are trying to propose a kludge? Sorry, but I am not going to read any further...

Well, the most recent ChangeLog entry for gegl is dated 3-25-04, and if it is nearly ready to use, then the CVS archive and the gegl web page are very misleading. Am I missing something?

The point you are missing is that we can't expect GEGL to mature into anything useable if we continue to not using it. The only way to make things happen is to do them. I am certainly not going to accept any such kludges in GIMP since we should finally get around to do the right thing (TM). We've been waiting for this too long already.

That said, perhaps it's about time that we try to come up with a roadmap for the time after the 2.2 release...

Sven

* Daniel Egger :

--Apple-Mail-35-297443358
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; format=flowed

On 15.12.2004, at 20:16, 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.

Why do you want to have 16 bits per channel when most if not all tools will only work with the MSBs?

Hey, I'd have 80% of my 16bit usage if only Layers and Curves supported this 16bit ability.

Having said that, extra 8bit as integer is nothing but an band-aid, as most of more-than-8bit-depth fun is anything but 16bit integer.

On 16.12.2004, at 02:13, Sven Neumann wrote:

The point you are missing is that we can't expect GEGL to mature into anything useable if we continue to not using it. The only way to make things happen is to do them. I am certainly not going to accept any such kludges in GIMP since we should finally get around to do the right thing (TM). We've been waiting for this too long already.

I would say that any subproject paving the way for GEGL integration is worthwhile, especially if that lightens the way for the integration. If someone like Bill wants to make the current code more generic so that a more dynamic system can be more easily integrated later, that'd be a big plus.

Servus,
Daniel