I think it best that Filmgimp do its own thing for the time being I
personally use both... If there where any merging I would suggest the
1.3.x branch than the 1.2.x branch simply because the code in the 1.3
branch is so much easier to work with (I say that as someone who is
almost completely
Hi,
Stephen J Baker [EMAIL PROTECTED] writes:
So, I was pointing out that floating point imagery is soon going to
be important to many other user communities outside of the film industry
and it follows that floating point images ought to be loadable, editable
and save-able from within
On 10-Dec-2002, Sven Neumann wrote:
the plan is not to have 16 bit or 32 bit or floats but to offer a
framework that allows to handle image data more or less independently
of its representation. GEGL is the framework and it already supports
floating point, 8bit and 16bit integer. Adding more
On Fri, 29 Nov 2002, Sam Richards wrote:
I would like to stress that some of the film-industry interest in
filmgimp is as much for the floating point as the 16 bit. The need for
floating point is for High Dynamic Range imagery which is used as a
lighting tool, and not for final delivery. So
On 09-Dec-2002, Stephen J Baker wrote:
On Fri, 29 Nov 2002, Sam Richards wrote:
I would like to stress that some of the film-industry interest in
filmgimp is as much for the floating point as the 16 bit. The need for
floating point is for High Dynamic Range imagery which is used as a
On 09-Dec-2002, Stephen J Baker wrote:
I'm not suggesting that this would be useful to GIMP - but that other
developers who are working in 3D using modern rendering hardware will
soon need support for 32 bit floating point texture maps.
So, I was pointing out that floating point imagery is
Branko,
... I would like to compliment you and your team on following The Right
Way.
The Film Gimp team deserves more credit than I for what's been accomplished.
Others toiled in secret for years on Film Gimp before I joined the project
this summer. Since going public, new developers have
Hi,
Sam Richards [EMAIL PROTECTED] writes:
I would like to know what the roadmap for gimp is after 1.4? When is
the merge for GEGL? Are you planning 16 bit support as a separate
thing to GEGL? Are there any design docs for 1.3? How much work was
it porting to GTK2.0?
This document is
Hi,
Patrick McFarland [EMAIL PROTECTED] writes:
To cut this all short, how long will it be until I can do higher
precision rendering in any gimp whatsoever? FG's xcf plugin is
broke, gegl isnt done yet insert stock rant here
GEGL is being worked on and it has already come a long way.
Thus spoke Patrick McFarland
because the development teams dont communicate enough. I agree with a lot of
what you said, but in the end, its silly to have two branches like this.
Maybe not. Consider that having competing branches can push the advancement
of both. This is true of any research
On 01-Dec-2002, Michael J. Hammel wrote:
Maybe not. Consider that having competing branches can push the advancement
of both. This is true of any research or commercial development. In this
case, the discussion on 16bit support has been nudged yet again - perhaps
enough to make real
Wow. Sure is hot in here.
Some comments, from a gimp _and_ filmgimp developer:
I also regret any duplication of effort between the two. However,
I'm not personally convinced that merging them is a good idea.
My feeling is that Filmgimp should be a tool specifically (or
at least, primarily) for
On Sat, 30 Nov 2002 00:40:52 +1100, David Hodson [EMAIL PROTECTED] wrote:
Wow. Sure is hot in here.
Ouch! ;-)
Some comments, from a gimp _and_ filmgimp developer:
Thanks! I am glad that such a person exists. ;-) And I prefer to
have a serious discussion rather than a flame war.
I also
On 29-Nov-2002, David Neary wrote:
Hi all,
David Hodson wrote:
My feeling is that Filmgimp should be a tool specifically (or
at least, primarily) for the film industry. It is very likely
to develop along lines that are (at best) not useful to, or
(quite possibly) totally unwanted by,
Merging both does not require the removal of features from either
tool. The added value of Film Gimp comes primarily from its 16-bits
support and its frame manager (and specialized plug-ins). But
unfortunately, it is based on an old core, which lacks many features
that are present in the
Hi,
I am one of the developers of filmgimp, although really I am mostly
bug-fixing and packaging it at the moment. While I'm not going to
comment on accuracies of the web site, thats Robins area, but I would
like to address some of the other issues raised...
Firstly, like everybody else, I
On 28-Nov-2002, Sven Neumann wrote:
the point is that the new film-gimp maintainer or any of the people
working on film-gimp don't communicate with us at all. The project
somehow came back to life without any notification on this
mailing-list. We had to hear about it in the news. Among
On 27-Nov-2002, Raphaël Quinet wrote:
I have the feeling that the gap between GIMP and Film Gimp is widening
more and more, instead of shrinking until the two versions can be
merged in the same codebase. I understand that the development on the
HOLLYWOOD branch has different constraints than
18 matches
Mail list logo
