On Tue, Dec 03, 2002 at 06:39:16PM -0800, Jonathan Cohen wrote:

We are seriously considering ripping out all modes except for 32-bit floating point. This would drastically simplify the internal rendering engine and allow us to optimize it significantly. Since we don't see any real reasons why high-end paint work could not be done entirely in 32-bit float, this is a reasonable thing.

I'm just curious: What do you get by using 32-bit _float_? Why not use 1.31-Bit Fixed Point? It should have a higher precision than 32-bit float - at least, it's precision is steady.

Bye, Tino.

On 04-Dec-2002, Tino Schwarze wrote:

On Tue, Dec 03, 2002 at 06:39:16PM -0800, Jonathan Cohen wrote:

We are seriously considering ripping out all modes except for 32-bit floating point. This would drastically simplify the internal rendering engine and allow us to optimize it significantly. Since we don't see any real reasons why high-end paint work could not be done entirely in 32-bit float, this is a reasonable thing.

I'm just curious: What do you get by using 32-bit _float_? Why not use 1.31-Bit Fixed Point? It should have a higher precision than 32-bit float - at least, it's precision is steady.

It should still have a 16-bit floating point because you cant use sse acceleration with double floats unless you have sse2 (which is like no one.)

On Wed, Dec 04, 2002 at 05:05:13AM -0500, Patrick McFarland wrote:

It should still have a 16-bit floating point because you cant use sse acceleration with double floats unless you have sse2 (which is like no one.)

Single floats are 32 bits each. Double floats are 64 bits each.

/* Steinar */

On Wed, Dec 04, 2002 at 10:49:05AM +0100, Tino Schwarze wrote:

I'm just curious: What do you get by using 32-bit _float_? Why not use 1.31-Bit Fixed Point? It should have a higher precision than 32-bit float - at least, it's precision is steady.

The point is probably to be allowed to go below 0 or over 1 -- you might not always want to work in a clamped range, like fixed point does.

/* Steinar */

On 04-Dec-2002, Steinar H. Gunderson wrote:

On Wed, Dec 04, 2002 at 05:05:13AM -0500, Patrick McFarland wrote:

It should still have a 16-bit floating point because you cant use sse acceleration with double floats unless you have sse2 (which is like no one.)

Single floats are 32 bits each. Double floats are 64 bits each.

I knew that. Really, I did.

On 04-Dec-2002, Steinar H. Gunderson wrote:

On Wed, Dec 04, 2002 at 10:49:05AM +0100, Tino Schwarze wrote:

I'm just curious: What do you get by using 32-bit _float_? Why not use 1.31-Bit Fixed Point? It should have a higher precision than 32-bit float - at least, it's precision is steady.

The point is probably to be allowed to go below 0 or over 1 -- you might not always want to work in a clamped range, like fixed point does.

Yes, that would be very nice.

On Tue, 3 Dec 2002 18:39:16 -0800 (PST), Jonathan Cohen wrote:

I am one of the R&H engineers working on film gimp. I have previously posted a message describing our short term plans for film gimp development. Unfortunately, we have not really had time to begin on any of these issues yet, but we are planning on starting within the next few weeks to a month.

Thanks a lot for these explanations. I also have to apologize for not being able to reply yet to some of the interesting messages in the discussion that I started last Friday, but I will try to send some replies later today.

[...]

Programmer manpower is an expensive thing, and R&H allocates resources (Calvin, Caroline Dahllof, and myself) to gimp because it is a cost effective way of getting a suitable high-end paint tool. If filmgimp went in the direction of becoming a more general painting tool, it is entirely possibly that we would branch yet again and maintain our own "r&h" branch so that we can customize it as needed to meet our immediate day-to-day needs. This is not any kind of veiled threat-- it is the reality of r&h's relationship with gimp. gimp is a tool we will support to the extent that it meets our production needs.

I fully agree with this. You have your own needs and your are certainly allowed to customize the software in such a way that it suits you. Of course, this is even better if some of these changes can be contributed to a larger community, but private changes are OK.

That said, the software engineer in me is slightly saddened by the fact that we are duplicating (some) efforts from the gimp programmers. I'm sure most of what is on our todo list is on the gimp's todo list as well (or has already been done).

Yes, and this is the part that I was worried about. For instance, here are the things that I am planning to work on personally (once I buy my new PC):
1) Better support for metadata: EXIF (bug #56443) and XMP/IPTC (bug #94416).
2) Offer an optional MDI interface and menubar on top of the window (bug #7379 and bug #52305).
3) Implement a macro recorder (bug #51937). This is only my personal list of goals and I do not know when these will be implemented or whether some other GIMP contributors are interested in these things. But this is what I am interested in, and I certainly see a large overlap with some of the things that are mentioned on the FilmGimp goals list. Point (1) is probably useful for the GIMP only, but points (2) and (3) could be shared if there was a more common codebase. These are the parts that I am the most worried about and that encouraged me to start this discussion. This, and the other features that are already part of GIMP-1.3.x and are being implemented slightly differently in FilmGimp (Windows and Mac ports, Python, etc.).

However, some of things on our list definately are *not* the same. For example, we are eager to remove the color & index modes we do not need for performance and cleanliness reasons. We are seriously considering ripping out all modes except for 32-bit floating point. This would drastically simplify the internal rendering engine and allow us to optimize it significantly. Since we don't see any real reasons why high-end paint work could not be done entirely in 32-bit float, this is a reasonable thing. Obviously, for a general paint tool like gimp, there is no question of maintaining 8-bit support. For us, the need to maintain this kind of flexibility with the code and independence from non-high end feature requirements far outweigh any software engineering ideals.

Yes, this makes sense. It would be nice if this could still be achieved by keeping a common codebase and linking a different library for the rendering engine and/or having suitable #ifdef's in the code. If this would be too difficult or if the resulting code would not be clean enough, then you can of course strip out all the parts that you do not need.

Anyway, I do not expect the GIMP and FilmGimp to be merged in the next few weeks (or months?). But I hope that there will be some efforts from both development teams to converge rather than diverge, at least for the parts of the code for which this makes sense. Even if some FilmGimp developers prefer to keep a separate branch for the code, it would be nice if more parts of the code could be shared so that any improvements done on one branch can also benefit the other branch. I think that the first step is to communicate more and exchange more ideas between the development teams. I am glad that this has started.

I hope this clarifies our position and bit and explains the current state of r&h's gimp plans.

Yes, thanks!

If you are curious, here are some direct links to the bug reports mentioned in this message:
- http://bugzilla.gnome.org/show_bug.cgi?id=51937 (macro recorder) - http://bugzilla.gnome.org/show_bug.cgi?id=7379 (MDI model) - http://bugzilla.gnome.org/show_bug.cgi?id=52305 (menubar in image window) - http://bugzilla.gnome.org/show_bug.cgi?id=56443 (EXIF metadata) - http://bugzilla.gnome.org/show_bug.cgi?id=94416 (XMP and IPTC metadata)

-Raphaël

On Wed, Dec 04, 2002 at 10:49:05AM +0100, Tino Schwarze wrote:

I'm just curious: What do you get by using 32-bit _float_? Why not use 1.31-Bit Fixed Point? It should have a higher precision than 32-bit float - at least, it's precision is steady.

as was mentioned already, 1.31 bit fixed point (which probably means sign + 31 bits mantissa) has a limited range compared to 32 bit fp.

On 2002-12-03 at 1839.16 -0800, Jonathan Cohen typed this:

Hi,

That said, the software engineer in me is slightly saddened by the fact that we are duplicating (some) efforts from the gimp programmers. I'm sure most of what is on our todo list is on the gimp's todo list as well (or has already been done). However, some of things on our list definately are *not* the same. For example, we are eager to remove the color & index modes we do not need for performance and cleanliness reasons. We are seriously considering ripping out all modes except for 32-bit floating point. This would drastically simplify the internal rendering engine and allow us to optimize it significantly. Since we don't see any real reasons why high-end paint work could not be done entirely in 32-bit float, this is a reasonable thing. Obviously, for a general paint tool like gimp, there is no question of maintaining 8-bit support. For us, the need to maintain this kind of flexibility with the code and independence from non-high end feature requirements far outweigh any software engineering ideals.

i have been watching Sven gently break it to the artists that newer gimps might not be able to index until time to save. and truly, indexing is a terrible thing to do to an image, except the GIMP index changes and reduces the number of colors so nicely. that is just one mode. i use the other modes (grayscale i guess is left) as plug-ins demand them. it seems like the plans for the gimp i use has been to strip many many of the plug-ins from it, which is fine by me. overdue even. could the image modes be stripped also and made into plug-ins?

i am trying to make sense of this paragraph of the R&H post. i think it says that if many of the things in the gimp core were split off, into plug-ins say, then development could continue in many camps and work not be duplicated.

carol

On Wed, 4 Dec 2002, Tino Schwarze wrote:

On Tue, Dec 03, 2002 at 06:39:16PM -0800, Jonathan Cohen wrote:

We are seriously considering ripping out all modes except for 32-bit floating point. This would drastically simplify the internal rendering engine and allow us to optimize it significantly. Since we don't see any real reasons why high-end paint work could not be done entirely in 32-bit float, this is a reasonable thing.

I'm just curious: What do you get by using 32-bit _float_? Why not use 1.31-Bit Fixed Point? It should have a higher precision than 32-bit float - at least, it's precision is steady.

For high dynamic range rendering.

The sun is like a billion times brighter than a candle - and a candle is a thousand times brighter than the dimmest thing a human eye can see.

Taking a 'true' rendition of the world needs more dynamic range than even a 32 bit integer.

However, we don't need to measure the brightness of the sun to the precision of the dimmest thing we can see. So we DON'T need the precision of a 32 bit integer.

Hence a 32 bit float is a more reasonable format.

It's also the format that modern graphics cards are beginning to support (and will increasingly support in the future).

---- Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation & Training (817)619-2466 (Fax) Work: sjbaker@link.com http://www.link.com Home: sjbaker1@airmail.net http://www.sjbaker.org

On 09-Dec-2002, Stephen J Baker wrote:

On Wed, 4 Dec 2002, Tino Schwarze wrote:

On Tue, Dec 03, 2002 at 06:39:16PM -0800, Jonathan Cohen wrote:

We are seriously considering ripping out all modes except for 32-bit floating point. This would drastically simplify the internal rendering engine and allow us to optimize it significantly. Since we don't see any real reasons why high-end paint work could not be done entirely in 32-bit float, this is a reasonable thing.

I'm just curious: What do you get by using 32-bit _float_? Why not use 1.31-Bit Fixed Point? It should have a higher precision than 32-bit float - at least, it's precision is steady.

For high dynamic range rendering.

The sun is like a billion times brighter than a candle - and a candle is a thousand times brighter than the dimmest thing a human eye can see.

Taking a 'true' rendition of the world needs more dynamic range than even a 32 bit integer.

However, we don't need to measure the brightness of the sun to the precision of the dimmest thing we can see. So we DON'T need the precision of a 32 bit integer.

Hence a 32 bit float is a more reasonable format.

It's also the format that modern graphics cards are beginning to support (and will increasingly support in the future).

First, maybe can you guys _slow down?_ I can only respond so fast =)

Seriously though, yeah, 32-bit floats do dynamic range so much better (and with the way I abuse Gimp, I need the dynamic range.) But (as I've said about four times already) the speed boost on archs that can do spfp math (aka sse enabled archs) is more than worth it.