> 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 current GIMP (not to mention the plug-ins). > If GEGL and the frame manager were merged into the current GIMP, then > everybody would win because any new feature or bug fix would be > immediately available to everybody. Currently, everything since the > original HOLLYWOOD fork has to be implemented separately in each tool. Yeah, really, isnt the point of GEGL and other realted stuff? > > Note that merging Film Gimp and GIMP does not mean that everybody > would have to use the same user interface. The split between core and > UI that occured during the development of GIMP 1.3.x means that it > would be much easier now to create a slightly different user interface > that is optimised for working with films. Some features could be > hidden or accessed in a different way if they are not so useful for a > specific version of the user interface. > Yeah, that would be cool. But really, I would want this in the same app. If Im editing images (normal gimp mode) I want it to look one way, if Im editing movies (film gimp mode) I want it to look another way. > The two most requested features for the GIMP are CMYK support and > 16-bits support. Other popular feature requests are layer groups, > active layers (adjustement layers or styles), EXIF and others, but > they come far behind CMYK and 16-bits channels. So we will have to > add those features to the GIMP soon, probably by using the GEGL > library. Another feature that will be integrated in the GIMP soon is > a macro recorder (and playback). This is also on the Film Gimp todo > list. Same for the support for Python, which has been added to the > current GIMP. Actually, Im going to use my evil weapon of mass destruction here. "Adobe Photoshop does cmyk and layer groups." But Ill be fair here and say its got an ugly renderer like we do. BTW, Im not specifically pushing for Images themselves in 16-bit channel mode, but a renderer that works at a very high precision (once again, single precision floats comes to mind, so we can use gcc 3.2.x's -mfpmath=sse,387 and such) independent of what the image itself is. This especially would be good for film gimp's 16-bit mode because its more than twice the bitdepth (32-bit yes, but its also float.) So doing multiple layers will result in very high quality images no matter what. Btw, has there been a discussion on how layer grouping will work? I want to be able to both group layers in just a group (aka doesnt change how rendering works at all) then also be able to group layers together, and have the output of that act as a layer (aka, for calculating the "virtual" layer, only the layers inside of it are done, no outside layers interact with these except through the final "virtual" layer.) -- Patrick "Diablo-D3" McFarland || unknown@xxxxxxxxx "Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music." --Kristian Wilson, Nintendo, Inc, 1989
Attachment:
pgpITGo5TyLpm.pgp
Description: PGP signature
