Re: [Gimp-developer] Refactoring code from GPL to LGPL
Dave, It seems like you're limiting refactoring to code re-use via extraction to libraries. No, I'm using the same definition that Mat refers to: Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior. - Martin Fowler on http://www.refactoring.com/ What I am saying is that moving redundant code out of application space into libraries is a significant component of refactoring. My question was why not being able to do that due to license barriers isn't a significant obstacle to long term GIMP code maintenance. Sven has answered that question. The client-server design of the PDB sidesteps the license issue by exposing functionality in app (which includes the PDB) without linking (instead using sockets). This works for GIMP because no other apps use libgimp as a system library except for GIMP plug-ins, and plug-ins all expect to talk to the GIMP app rather than run independently without it. Appreciate the clarification. Thanks, Robin --- [EMAIL PROTECTED] Hollywood, California www.CinePaint.org Open source digital motion picture film software ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Refactoring code from GPL to LGPL
Sven, Just to clarify for others reading along, my question is not about linking GPL and LGPL. It is about cut-and-pasting code from GPL into LGPL during refactoring. With the benefit of hindsight years later, it seems a maintainer doing code clean-up should find application code that would better serve as library functions (refactoring). However, in GIMP such code can't be moved without getting everyone's permission due to the differing licenses. Sven has said in the past that he often checks in patches in his own name in CVS, that GIMP does not keep exact records of who its authors are. Sorry, but that's not true. Whenever I check code into CVS I mention the authors explicitely so it's completely possible to track the authors by looking at the CVS log. Pardon me if I misspoke based on recollection. I have now referred back to your post of December 2, 2002. You said: [ We often apply patches from people that don't have CVS commit access. I'd like to see the names of the patch authors in the list of contributors but it's not trivial to extract them from the ChangeLog entries. ] Related question, does GIMP always list the patch author and his contact info in CVS entries? How do you get permission to move GIMP code from GPL into LGPL? Basically we do this so rarely that is hasn't been a problem so far to get permissions from everyone who touched the code in question. May I ask why you are asking these questions? For years you have been saying that something that makes GIMP great is that you have taken the code through a major clean-up process. I wanted to understand how GIMP does refactoring without being held back by GPL/LGPL licensing barriers. However, you say above you rarely do refactoring. Why do you suppose little GIMP application code has migrated into libraries? Is refactoring unimportant? Thanks, Robin --- [EMAIL PROTECTED] Hollywood, California www.CinePaint.org Open source digital motion picture film software ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Refactoring?
Would like to better understand the development approach the GIMP has used over the years to segregate code in the main app from code in libgimp. Seem to recall seeing some app code that had moved into libgimp, but am not sure. Do GIMP maintainers later refactor code? Does code in app ever get moved into libgimp? In what cases and who decides? Related question, what tools use libgimp without GIMP? Thanks, Robin --- [EMAIL PROTECTED] Hollywood, California www.CinePaint.org Open source digital motion picture film software ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] CinePaint Roadmap
it is going to be a tough act to follow robin rowe and cinepaint. gimp-1.0 rox! Should I feel flattered that GIMP can't stop talking about me and CinePaint, even when it is to spread the misconception that CinePaint is GIMP 1.0? GIMP people have demonstrated a persistent interest in expressing their opinion about CinePaint and giving me unsought advice since I became the CinePaint project leader in 2002. For the benefit of those who seem confused about the difference between our projects, I would like to share CinePaint's long range roadmap and explain why GIMP isn't part of it. In addition, I will address some common misconceptions GIMP folks have repeatedly stated about CinePaint. CINEPAINT ROADMAP - Deep paint including support for exotic bit depth formats. We've supported 16-bit integer and 32-bit floating point for a long time. Recently, we implemented 16-bit binary fixed point, another bit depth format widely used in the motion picture industry. One reason deep paint matters in pro work is film has greater dynamic range than monitors. Deep paint images clipped to 8-bit will look fine on monitors (which can only display to 8-bit) but can show visible defects when output to film. - High dynamic range (HDR). We can read and write OpenEXR, an open source HDR format provided by ILM. We're adding paint features to better support HDR capabilities. HDR is to images what headroom is to audio. Without HDR an image clips white at 1.0. Colors in flames and other highlights can be lost, turn gray if the image is later adjusted back down again to be darker. HDR paint can repeatedly adjust image intensity without color loss. - Roto and vector 2D paint. CinePaint (and GIMP) are raster paint programs. CinePaint can be used for rotoscoping, but the lack of vector 2D paint support (especially splines) hampers that. Good vector 2D support is also needed for our new slideshow feature, described below. - 3D paint. CinePaint is used as a texture paint tool to support work with 3D packages such as Maya. We seek to have closer integration, be able to preview or even paint 3D in CinePaint using OpenInventor. - Colorspaces. CinePaint (and GIMP) only have RGB support now. We've begun work to implement CIELAB and CMYK. We want to add XYZ, sRGB, and scRGB. - Color management. We want output on film that matches what users see on monitors, to support precision and artistic control in how colors are displayed. We have recently implemented color management for 8-bit depth, but found the screen performance too slow. We have begun to overhaul our GIMP-based paint core to make CinePaint fast enough to handle CMS responsively. - World-class GUI. Our goal is to offer a user interface superior to Photoshop. - Slideshow feature. We want to offer an alternative to PowerPoint. We have a new slideshow feature built into the movie flipbook in CinePaint. - Compositing and effects. We want to offer an alternative to Apple Shake and Adobe AfterEffects. - Video editing. We want to add a flatbed film-style video editor including sound and support for transcoding to popular video codecs such as MPEG, DV, QuickTime, AVI, and MJPEG. We want to offer an alternative to Adobe Premiere, Apple FinalCut Pro, and Avid Composer. - High performance. We're developing a command-line tool with no GUI, something like ImageMagick 'convert' but to use CinePaint plug-ins. Our 'img_img' tool is intended initially for fast image file format conversions on renderfarms and came out of a major studio. For performance, img_img uses a scanline-based architecture. It's plug-in architecture is a totally new API I developed, and unlike the CinePaint and GIMP tile-based APIs. In keeping with our strategy of maximizing our compatibility across applications (e.g., GIMP, Photoshop, AfterEffects) we will enable img_img plug-ins (such as our new img_img JPEG2000 plug-in) to work in CinePaint, and tile-based legacy CinePaint plug-ins to work in img_img. CinePaint seems likely to evolve into a scanline architecture more like Shake. In 1998 the film industry decided to help GIMP by sponsoring development of deep paint. To enable GIMP developers to understand motion picture technology they were brought into the industry, given first-hand experience working at desks at film companies. GIMP maintainer Yosh Singh started as an intern at Silicon Grail and later became an employee. He did not accomplish his employer's mandate to build and release deep paint as a feature in mainline GIMP. After a year or so gaining experience in motion picture technology Yosh left Silicon Grail to go to LinuxCare. What he's done since I don't know. I once asked the current GIMP developers what qualifications they have to develop high end graphics software. The answer given was to point me to GIMP as their signature accomplishment. Sven Neumann has said on this list that he is offended because we have never sought his advice in how to implement CinePaint. I have taught computer science
Re: [Gimp-developer] GIMP Aqua GTK+OSX
David Odin [EMAIL PROTECTED] wrote: Yeah! Good job. Now, it would be great if you managed to do the same for gimp-1.3.x. If all the necessary libs were ported too, we could even consider to include this in the main tree, WDYT? Thanks, but John-Michael Mulesa deserves the credit. He did the work of getting GIMP to build on Aqua, with just a little help from the rest of us when he encountered a few problems. He also wrote the HOWTO. I'd be surprised if you want to include an experimental version of GTK in the GIMP CVS tree, but not my project. What you guys do with GIMP is your business. Our HOWTO does point out some minor problems encountered in the GIMP 1.2 code when compiling with GTK+OSX that you may want to fix. With regard to Dave Neary's question about a GTK2 port to Aqua, nobody is working on that. Before launching the GTK+OSX project I contacted Owen Taylor to find out if somebody else was already working on any GTK Aqua port so we wouldn't need to. He said there were no plans and encouraged us to pursue GTK2. GTK+OSX took over an abandoned half-done GTK1 port to OS/9. We weren't willing to accept the setback of starting over with GTK2. Perhaps after the GTK1 port is complete people will want to continue to a port of GTK2. Cheers, Robin --- [EMAIL PROTECTED] Hollywood, California www.CinePaint.org Free motion picture and still image editing software ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] GIMP Aqua GTK+OSX
GIMP on Mac OS X without X11: http://gtk-osx.sourceforge.net/docs/gimp.html Cheers, Robin --- [EMAIL PROTECTED] Hollywood, California www.CinePaint.org Free motion picture and still image editing software ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Film Gimp brushes
Sven, - We now support loading of GIMP brush format version 3. That is the format that was introduced by the FilmGimp or CinePaint developers (I don't know exactly when this change was made). CinePaint has made no changes to GIMP file formats. Those modifications predate our involvement, came from the GIMP HOLLYWOOD branch CVS in 2002 used to create Film Gimp 0.1. You should be able to figure out who extended/broke your file formats by researching your own CVS changelogs. Cheers, Robin --- [EMAIL PROTECTED] Hollywood, California www.CinePaint.org Free motion picture and still image editing software ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: WilberWorks
The [WilberWorks] website seems bought off and of course not much is left to be found on google and friends. This is the best link I could find: http://linux.rice.edu/webmap/appdescriptions/WilberWorks.html Let's hope one of the folks involved into this can tell us more about the goals of WilberWorks and why it didn't work (that well). Perhaps there are things we can learn from it... WilberWorks was founded by http://www.wired.com/news/print/0,1294,10975,00.html http://www.wired.com/wired/archive/3.12/alt.scientology.war.html?pg=2topic= And donations would be one of its major points. However having a reliable source of money, like manual and chachka sales can only help TGF be more helpful. Basically, _anything_ TGF does will cost money. The more money it has, the more helpful things it can do. If you put it that way (with all the other things you said in your reply) it feels a lot better already. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: WilberWorks
Sven, The [WilberWorks] website seems bought off and of course not much is left to be found on google and friends. This is the best link I could find... Google deserves more credit. Here's what Larry Ewing says: http://www.isc.tamu.edu/~lewing/gimp/wilber.html According to Wired, WilberWorks was founded by Scott Goehring. http://www.wired.com/news/print/0,1294,10975,00.html Can anyone say with certainty whether that is the same Scott Goehring that founded alt.religion.scientology? http://www.wired.com/wired/archive/3.12/alt.scientology.war.html?pg=2topic= Let's hope one of the folks involved into this can tell us more about the goals of WilberWorks and why it didn't work (that well). Perhaps there are things we can learn from it... Federico Mena Quintero and Scott Goehring reportedly worked on plug_in_whirl_pinch. http://hans.breuer.org/gimp/pdb/byauthor.html Perhaps Federico has a comment on Scott Goehring and what happened to WilberWorks. Cheers, Robin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] A comment on CinePaint (was Re: new-xcf)
At 5:10 PM -0400 7/17/03, Christopher Curtis wrote: Just for the record ... I read the CinePaint file format, and it doesn't even resemble XML. Yeah, I've had that argument with Robin - and lost :(. They are going for simple and scriptable over good design - I think they will regret it ver soon... Actually, it was simple and scriptable over good *XML* design that was my criteria for CPX. Whether good design and good XML design are the same is a matter of opinion and circumstances. In noting in the CPX spec that I had reused some good ideas from PPM P6 and XML I had not intended to suggest CPX was XML. Cheers, Robin --- [EMAIL PROTECTED] Hollywood, California www.CinePaint.org Free motion picture and still image editing software ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: [CinePaint-dev] GIMP GBR format spec
David,
As a proposal for a modification which would bring back
compatibility, we could expand the header by 4 bytes to include
bit depth (8 or 16), which could then be factored into the load
routines of both our apps (we would crush 16 bit nbrushes down to
8 bits, and you would expand 8 bit brushes to 16 bits). As a file
format change, it would allow is backward compatibility, since
the format changes nothing in the other header fields.
We're open to that. However, until someone volunteers and sends us a patch,
we have no one ready to take that effort when our format is about to be
replaced anyway.
The GIMP Paintbrush File Format Version 2 (.gbr)
HEADER
--
Bytes 0 - 3: header_size:
Type: 32 bit unsigned int
Value: size of brush header (28) + length of brush name
Bytes 4 - 7: version
Type: 32 bit unsigned int
Value: The file format version. Currently
Bytes 8 - 11: width
Type: 32 bit unsigned int
Value: Brush width
Bytes 12 - 15: height
Type: 32 bit unsigned int
Value: Brush height
Bytes 16 - 19: bytes
Type: 32 bit unsigned int
Value: Colour depth of brush.
1 = greyscale, 4 = RGBA
Bytes 20 - 23: magic_number
Type: 32 bit unsigned int
Value: GIMP brush magic number.
('G' 24) + ('I' 16) + ('M' 8) + 'P'
Bytes 24 - 27: spacing
Type: 32 bit unsigned int
Value: Default spacing to be used for brush. Percentage
of brush width.
Bytes 28 - (header_size - 28):
Type: char *
Value: UTF-8 string - name of brush
BODY
Size: width * height * bytes
Type: uchar *
Value: Pixel values (row-first) for brush
Thanks, appreciate the docs!
To return the favor, enclosed is the spec for CPX that I posted in June. It
is so new it hasn't made it onto our web page docs yet. For clarification,
since my preliminary spec was rather terse, the data blob in CPX is a raw
write of the raster like the PPM P6 format. The CPX format was inspired by
the simplicity of PPM, but with the enhancement of XML tags. Like PPM, all
CPX tags are text but raster data is binary. See at the bottom below.
it would be incorrect to say that we don't identify our team.
I can clarify my meaning, although it seems a moot point. Some GIMP
developers are identified in internal documents within the source code, as
you correctly point out. However,when I asked for a list of developers on
the GIMP list I was told those documents were too inaccurate to be trusted.
It was suggested I could get the names of the GIMP developers by grepping
the check-in names from GIMP CVS -- which seemed a bit of bother -- but I
took the effort to do so anyway. I offered to give that list back to GIMP so
they could post a better public list of developer acknowledgements. The
response was that no new list should be posted by GIMP until it was perfect,
and that my list was inaccurate because Sven and others often check in
patches on behalf of others. I was also told my help wasn't needed.
FYI, using the best information I could gather, we have a list on our web
site recognizing the GIMP developers.
http://cinepaint.sourceforge.net/people/gimp.html
Cheers,
Robin
---
[EMAIL PROTECTED] Hollywood, California
www.CinePaint.org Free motion picture and still image editing software
- Original Message -
From: Robin Rowe [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Saturday, June 07, 2003 3:11 PM
Subject: [CinePaint-dev] cpx file type
Hi. Just FYI, creating a new image format called CPX (CinePaint XML).
This format will be similar in simplicity to PPM but more flexible using
XML
tags. Both spec and code will be made available.
A 640x480 8-bit image file example.cpx would be laid out something like
this:
CPX
IMG width=640 height=480 depth=8u raster=RGB compress=none bytes=921600
data=...[921,600 raw bytes]...
'depth' may be 8u|16u|16f-ilm|16f-rnh|32f
'raster' may be RGB|RGBA|RGBAZ or alternatively 'planes' with the same
choices
A lot more features could be added later. This is just to let everyone
know
this is in the works and coming maybe in July.
Cheers,
Robin
--
-
[EMAIL PROTECTED] Hollywood, California
www.CinePaint.org Free motion picture and still image editing software
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: [CinePaint-dev] GIMP/CinePaint fileincompatibility
Ernst, Couldn't both teams try to find a common format? In theory yes, but it seems unlikely. Sven said today that GIMP has been (privately) discussing a new XML-based file format for GIMP for more than three years -- which is the first I've heard of it. However, no spec has been made available. Without any knowledge of what GIMP was up to, I've been working on the design of a new XML-based file format for CinePaint for two months. I posted the preliminary spec for comment a month ago, and it is about to go into implementation. It could appear in CinePaint in as little as a month. We're not going to wait for GIMP. Cheers, Robin --- [EMAIL PROTECTED] Hollywood, California www.CinePaint.org Free motion picture and still image editing software ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] someone's hairy to-do list
Sean, i scratched-together a to-do list for my own GIMP wants wishes, and put it online, thought it might be worth sharing: http://gimbal.paunix.org/cs/img/gimp/todo.html ... from the URL: CinePaint cannibalization whatever CinePaint [was: Film GIMP] has for supporting additional image formats, bring it into the GIMP's current CVS, progressively. Note that this would require the addition of some used and new code, for 48-bit image handling. CinePaint is more versatile than 48-bits RGB. It handles 8, 16, or 32-bits per channel, which means 128-bits of RGBA. To handle OpenEXR, the new ILM/NVIDIA Half float 16-bit format, requires CinePaint use 32-bit IEEE float internally because we don't handle ILM Half float. OpenEXR 16-bit float images are promoted to 32-bit when loaded. Cheers, Robin --- [EMAIL PROTECTED] Hollywood, California www.CinePaint.org Free motion picture and still image editing software ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Which Gimp
Tor, I agree that with Sven that it's wrong to call GIMP for Windows a separate project. What makes it seem a project is that it has a separate Web page, separate mailing lists, and a well known project leader (you). However, as you now say otherwise, I have updated the Web page accordingly. Thank you for the clarification. Cheers, Robin --- www.FilmGimp.org www.LinuxMovies.org www.OpenSourceProgrammers.org ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Which Gimp
Sven, I thank Patrick and Raphaël for the apologies they posted. I think that shows class on their part. And even though the discussion became unnecessarily heated, everyone has learned more about the various projects. [Robin's] list gives the wrong impressions that there are separate ports of The GIMP to the Windows and Macintosh platforms. This is wrong. The relationship between GIMP and GIMP for Windows is made clear, and everyone seems to agree nobody knows what the MacGimp effort really does. WinGimp and MacGimp projects (if there are any) are solely providing binary versions of the one true GIMP and I don't think they should be listed as separate GIMP projects. If you want to keep them in the list, you should also add GIMP for FreeBSD, GIMP for OpenBSD, GIMP for Debian Linux, GIMP for Solaris, GIMP for SuSE Linux, GIMP for AIX, GIMP for RedHat Linux, ..., ... and probably even GIMP for OS/2. If anyone would show me a separate Web site or independent project leader for those platforms I would certainly consider listing them. It is true that there are different mailing-lists for users of GIMP on UNIX and users of GIMP for Windows. It turned out that this separation makes sense although I never liked the idea of making a difference between the same application running on different platforms. It is however wrong that there are different mailing-lists for the development of The GIMP. I guess you are unaware of the gimpwin-dev list. Overall, this new page on the filmgimp site is once more full of wrong facts that I have to try hard to suppress the feeling that Robin is knowingly and willingly spreading fear, uncertainty and doubt on The GIMP and I wonder what's the rationale of this. Instead of attacking me personally why don't you stick to GIMP issues? You seem to want to foster the misimpression that GIMP is all just one big project centrally administered. That sophism causes such absurdities as requests to fix Film Gimp bugs being posted to the GIMP list, the status of GIMP bugs being posted to the Film Gimp list as though we should know what that's talking about, and cross-posted flamewar traffic that disrupted developers working on Film Gimp. My true goal in documenting GIMP-related projects is to stem widespread supposition and misinformation. The total absence of documentation on the GIMP Web site regarding the status and relationships of the many GIMP ports and projects has caused everyone confusion. Cheers, Robin --- www.FilmGimp.org www.LinuxMovies.org www.OpenSourceProgrammers.org ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Which Gimp
Sven, The whole point here is that instead of a collaborative effort to provide some urgently needed information about the GIMP projects, you just went ahead and put something into public space. It would have been a lot better to prepare a draft and discuss it on the appropriate lists before putting this online. The point is that it isn't for you to direct how an independent project is run. I've made as much accomodation to you and Raphaël as I can. I won't spin what I write to fit your viewpoint. If you still have a problem with the Web page at http://filmgimp.sourceforge.net/docs/which.gimp.html, post the truth as you see it on your Web page. Let people judge for themselves. Cheers, Robin --- www.FilmGimp.org www.LinuxMovies.org www.OpenSourceProgrammers.org ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Film Gimp and GIMP
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 joined Film Gimp and helped it succeed even more. The Mac Film Gimp port team, all Film Gimp newcomers by the way, have done a fabulous job! The Mac version released this week had been planned for 2003. Completed ahead of schedule. Simple way to fix red eye: select the eye, select only the red channel, desaturate. Repeat for other eye. Try other channels for Bowie effect. Thanks for the great tip on how to remove red-eye! I may put that into the Film Gimp documentation. Removing the red-eye in my glamour shot on the People page wasn't high on my to-do list, but since you point it out as objectionable I will correct that right away. Appreciate the feedback! Cheers, Robin --- www.FilmGimp.org www.LinuxMovies.org www.OpenSourceProgrammers.org ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Film Gimp and GIMP
Raphaël, For an up-to-date GIMP contributor list see the bottom of http://filmgimp.sourceforge.net/people/index.html . As you have probably seen in the recent discussions on the gimp-developer mailing list, it is not easy to get a correct list of As you have probably seen in the recent discussions on the gimp-developer mailing list, it is not easy to get a correct list of contributors. ;-) Looking only at the CVS commits or at the authors of the ChangeLog entries is unfortunately not fair to those who do not have CVS write access and whose patches are committed by someone else. Let's see what comes out of the discussion on the gimp-developer mailing list. The point is that the ChangeLog is more accurate than the credits list on GIMP's own Web site. Because I brought the topic up, the GIMP list is now debating how best to put together a perfect contributor list. Some people feel that being fair means being perfect sometime later, but I think that being fair involves doing your best with what you have now. For the time being anyway, the Film Gimp Web site has a more accurate list of GIMP contributors than GIMP's own Web site. When you have something better please let me know so I can update our Web page appropriately. Some users or developers would like Film Gimp to become more and more independent from the GIMP, without attempting to converge whenever possible. We are independent. It is only certain people who imagine otherwise. ;-) Cheers, Robin --- www.FilmGimp.org www.LinuxMovies.org www.OpenSourceProgrammers.org ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] dependable contributions lists
Carol, one person understood my request though :) Robin Rowe volunteered with some scripting. i had really thought that there were enough people in the various gimp places, clever and talented people, that this would not be an issue. Robin volunteering was a nice spot in my day, however, i was hoping that some of those gimp people whom are just typing away at email or into an irc window to help so that actual gimp work did not suffer. I'm glad my note cheered you. Thanks for letting me know. My helping you couldn't make actual gimp work suffer. At most it might delay my finishing the Windows port of Film Gimp. ;-) By the way, the release of Mac Film Gimp was announced today. http://filmgimp.sourceforge.net/press/filmgimp.pr.02.12.5.html i had this week off from work, which is a very very rare thing. You work? Didn't you say you don't believe in money, that you oppose on principle open source developers being paid? Pardon my curiosity. Are you working for free? What do you do? Cheers, Robin --- www.FilmGimp.org www.LinuxMovies.org www.OpenSourceProgrammers.org ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Film Gimp and GIMP
Sven, This document is probably still valid in a lot of points: http://developer.gimp.org/gimp-future Who is working on GEGL and how active is that? Your GIMP team list at http://www.gimp.org/the_gimp_org_about.html includes Mattis and Kimball. Have they done anything with GIMP since 1997? What are Mattis and Kimball doing now? Who is actively working on GIMP? Thanks, Robin --- www.FilmGimp.org www.LinuxMovies.org www.OpenSourceProgrammers.org ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: GIMP Funding
Carol, $1k would not be enough to by the beer for the people who develop The GIMP (if i can at least add correctly). It's true that $1k isn't generally considered a lot of money in funding a software project, but I appreciate getting anything. Linux Fund was very kind to give me a grant. None of the grant is going toward beer, by the way. It is for Film Gimp GUI enhancements and a keyboard/mouse macro recorder/player. You've piqued my curiosity. How large is GIMP's development budget? How is it funded? Cheers, Robin --- www.FilmGimp.org www.LinuxMovies.org www.OpenSourceProgrammers.org ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Film Gimp and GIMP
Hi. Different thoughts about Film Gimp have been been expressed by Gimp folks on the Gimp-developer list over the Thanksgiving holiday. As the Film Gimp release manager, I've found it stimulating reading. Probably anything interesting about that debate has already been thrashed out by others there. All I have to add are a few missing facts. It is worth noting that the target audience of Film Gimp is motion picture studios. It makes sense for Film Gimp to have goals distinct from Gimp. GEGL is a different codebase from Gimp or Film Gimp. All three are run as independent projects with different management styles and different goals. It is reflection of the diversity and depth of the development and user communities that three projects seem justified. Four, if we also count ImageMagick. Windows and Mac ports of Gimp already exist. To do the same with Film Gimp is not radical. The Film Gimp porting teams have referred to the Gimp ports, but not followed them closely. The Windows port is not based on gcc or cygwin, rather VC++. Regardless of that, Film Gimp is a unifed codebase. All Film Gimp platforms compile from the same code. Gimp maintainer Sven Neumann says, 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. It's true I haven't sought Sven out. It was Gimp maintainer Yosh Singh, one of the original Film Gimp developers, that I conferred with. He agreed to grant me an account at gimp.org so I could maintain the Film Gimp project at the existing site there, but after months of delays it was mutually agreed that SourceForge would be a better home. Gimp site maintainer Raphaël Quinet says the Gimp committee didn't really vote against Film Gimp, that it was only decided that the merge would be done later. I wan't there, and can only report what I've learned from talking with others. Everyone seems to agree that Gimp never said it was in favor of merging with Film Gimp later. What was said was Film Gimp should be thrown away and re-implemented as GEGL. GEGL is not Film Gimp, therefore that imagined later merge would not be with Film Gimp. Raphaël is right, as far as I know, that there was no us versus them feeling at the vote. Everyone was us (a Gimp developer) and the vote was unanimous against accepting the Film Gimp branch. Although nobody argued Film Gimp should live, it woudn't die. There was no available alternative for its users. Conspiracy theorists may become doubly alarmed, but I've taken Raphaël's advice and tried to downplay the wording of the Film Gimp history. I've also added more details. http://filmgimp.sourceforge.net/docs/history.html Please note that I work on Film Gimp because I enjoy it. What some imagine would be mindless duplication of effort between similar projects I see as an exciting opportunity to create alternative designs to delight users in new ways. Many project leaders seem to feel the same way. We have Linux and BSD, KDE and Gnome, and so forth. Being independent has some advantages. Film Gimp has achieved tremendous progress since July. In addition to that satisfaction, I have the pleasure of working with a team that I enjoy and that say they appreciate me. Cheers, Robin --- www.FilmGimp.org www.LinuxMovies.org www.OpenSourceProgrammers.org ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Film Gimp, GIMP, and GEGL
Patrick, Hi. Please don't suggest I said that Film Gimp is merely trying to do its own thing. It has been its own thing for many years. I couldn't help but notice that within minutes of recommending Film Gimp abandon itself to join GEGL, you posted a question to gimp-developer asking how to create a bit converter function using Gimp. May I ask a silly question? Since you are so keen on GEGL, why aren't you developing with it? A question for everyone who is recommending GEGL, have any of you ever tried it? Cheers, Robin --- www.FilmGimp.org www.LinuxMovies.org www.OpenSourceProgrammers.org - Original Message - From: Patrick McFarland [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, November 30, 2002 3:20 AM Subject: Re: [Gimp-developer] Re: Film Gimp and GIMP I want to develop stand alone 24bit - 8bit converter function, and also a bicubic resizer. Now, I noticed gimp has really high quality versions would it be possible to convert gimps functions to do: (with the converter) take an int 24bitimage[width][height] and return a char 8bitimage[width][height] and a int palette[256], those 256 entries being the 256 most used colors and all colors that dont match are set to the closest palette entry that matches. (with the bicubic resizer) take an int 24bitimage[width][height], and int newheight, newwidth, and return int 24bitimage[newwidth][newheight] I probably shouldnt ask this on here, but a) this is the only place that people familiar with the gimp source go, and b) I cant find what the functions are even called, nor what file they would be in. -- Patrick Diablo-D3 McFarland || [EMAIL PROTECTED] 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 - Original Message - From: Patrick McFarland [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, November 30, 2002 3:13 AM Subject: [Gimp-developer] I am a newbie, yes its true On 30-Nov-2002, Robin Rowe wrote: A lot of text about how film gimp is trying to be its own thing. Well, first I would like to say film gimp should be moving to a GEGL target. Not because film gimp is gegl, but because gegl is so damn useful. (Well, will be useful if/when it gets done.) And gegl would be the perfect place for film gimp and gimp to share all the difficult base code (like, dare I say it, single precision fp layer rendering code.) Speaking of that, has anyone seen fg's xcf loader plugin? I heard he was sick... Maybe someone should send him some chicken soup? -- Patrick Diablo-D3 McFarland || [EMAIL PROTECTED] 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 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Re: regex+
Carol, this is such a good topic for a tutorial! i needed help to see this stuff at first as well. i don't have time to write the tutorial, but i got some screenshots for it when i have the time. Hi. Thank you for the detailed response. I found that enlightening. Cheers, Robin --- www.FilmGimp.org www.LinuxMovies.org www.OpenSourceProgrammers.org ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] regex+
David, I think the point is probably to do a trawl through legacy code and see how much of it can be flushed, if any. I wish! Sometime later. Although regex is available with *nix, it isn't part of Windows. My choice is to remove it or fix the broken regex implemenation included in Film Gimp. That regex code is full of difficult to debug macros. Now that Robin knows that the regex code is useful, at least to some people, he's not planning on touching it. I'm not? Cheers, Robin --- www.FilmGimp.org www.LinuxMovies.org www.OpenSourceProgrammers.org ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] regex
Sven, The regex code is used by gimp-plug-ins-query (and a similar function in script-fu). Yes, I can follow that from the code. I understand what regex does generally, just not why gimp-plug-ins-query needs it. My confusion relates to script-fu and gimp plug-ins with respect to regex. Why query a plug-in as a regular expression? What's the point? Thanks! Robin --- www.FilmGimp.org www.LinuxMovies.org www.OpenSourceProgrammers.org ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] regex+
Simon, My confusion relates to script-fu and gimp plug-ins with respect to regex. Why query a plug-in as a regular expression? What's the point? To have a nice way to specify a search pattern. For thinks like a PDB-Browser for example. Ok, I guess I'm just not making my question clear. I understand that regex enables doing a wildcard search in the plug-ins database. What I have trouble imagining is the scenario where regex search in Gimp is necessary or useful. Few users even know how to phrase a regex search. Is this just feature-itis? Do I correctly surmise that regex could be removed without being missed? Thanks, Robin --- www.FilmGimp.org www.LinuxMovies.org www.OpenSourceProgrammers.org ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: regex+
Carol, well, i use it. honest. Robin, ever try to write a gimp plug-in? How would regex help me write a gimp plug-in? Cheers, Robin --- www.FilmGimp.org www.LinuxMovies.org www.OpenSourceProgrammers.org ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] regex
Hi. GIMP has its own regex.c that the procedural database uses. That seems to look up plug-ins using regexec. I'm having a little difficulty understanding the logic of the code. Can anybody explain how regex is used by GIMP? Why is it necessary? Thanks! Robin --- www.FilmGimp.org www.LinuxMovies.org www.OpenSourceProgrammers.org ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Return of 16-bit Per Channel Rendering
Check https://lists.xcf.berkeley.edu/mailman/listinfo/gimp-film/ The berkeley.edu list is superceded by the Film Gimp list at SourceForge. For current information about Film Gimp see filmgimp.org. Cheers, Robin Film Gimp Release Manager --- www.LinuxMovies.org http://filmgimp.sourceforge.net www.OpenSourceProgrammers.org ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] CMYK 16-bit print developer sought
I was reading today in the gimp-mailinglist Your dialog with Robert L. Krawitz on 26. september 2002. I hope You can decide for making together an print-plugin in filmgimp. 16 bit is an issue for any serious artist. I work with scanned 16bitimages for creating panoramas. I need to present them on the web and on paper too. Please help to come away from a simple 8bit-gimp. Good luck for your project at all. How to proceed has not been resolved. The Film Gimp project is focused on motion picture applications. As you know from my exchange with Robert I would like to see addressed the well known Gimp shortcomings with print and CMYK. However, this is not an application area motion picture technology developers understand well and no one from print has offered to lead this mission. If any developer has the expertise and interest to work on improving CMYK and 16-bit per component print please contact me or post a note to the filmgimp-developer list. Thanks, Robin --- www.LinuxMovies.org http://filmgimp.sourceforge.net www.OpenSourceProgrammers.org ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: CMYK 16-bit print developer sought
Robert, This can't really be lead from the print side. We'll have no problem with 16-bit and CMYK (although we don't currently support 16-bit RGB), but the GIMP side needs to spec an API for it. Hi. Thanks for the clarification. What I meant was print in the magazine/book publishing sense, not gimp-print. A developer knowledgable in the print side of the business would help in building the right 16-bit CMYK stuff. With a little more digging I discovered some email discussion with John Culleton in the archives describing using netpbm pnmtotiffcmyk (http://sourceforge.net/projects/netpbm/) for command line conversion. tifftopnm RGB.tiff | pnmtotiffcmyk CMYK.tiff Looking further I find pnmtotiffcmyk (http://sourceforge.net/projects/netpbm/) and CMYKTiff (http://www.acooke.org/jara/cmyktiff/). In theory someone could take that into a Film Gimp plug-in pretty easily, and that could output to gimp-print. Is that what we need? Cheers, Robin cc: John Culleton --- www.LinuxMovies.org http://filmgimp.sourceforge.net www.OpenSourceProgrammers.org ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Film Gimp climbing the charts
Film Gimp is a 16-bit per channel version of Gimp intended for frame-by-frame retouching of motion pictures. Movies that used it include Scooby-Doo, Harry Potter, and Stuart Little. Film Gimp is available for Linux and Irix, with Windows and Macintosh planned. With the announcement of the release of version 0.4 at SourceForge, Film Gimp is starting to climb the charts. Activity rating has passed 90% and Film Gimp is now ranked at #912 on SourceForge. For further information see: http://filmgimp.sourceforge.net Cheers, Robin Rowe Film Gimp Release Manager --- www.LinuxMovies.org www.OpenSourceProgrammers.org ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Film Gimp-print
Robert, The Gimp-print package is 16-bit capable (obviously the standard GIMP Print plugin, which is part of the Gimp-print package, isn't). While the only 16-bit input mode provided is CMYK, we could either add a 16-bit RGB input, or do the appropriate conversion module. Would you folks be interested in working on that with us? Yes, I think so. Even though print in the context of Film Gimp first brings to mind a reel of motion picture film. How would you want to approach it? Gimp doesn't do much with CMYK, which has been a long standing complaint: http://gimp-savvy.com/BOOK/index.html?node53.html There is a CMYK plug-in for gimp: http://registry.gimp.org/plugin?id=227 Does anyone have an interest in CMYK in Film Gimp? Thanks, Robin --- www.LinuxMovies.org http://filmgimp.sourceforge.net www.OpenSourceProgrammers.org ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] xwd screen shot problems
it seems you are mistaken. What makes you think xwd can't capture TrueColor? How are you using the term 24-bit visuals here (24 bit color-depth or 24 bit aligned pixels) ? xwd: Warning. Error in XWD-color-structure (flag) xwd: EOF encountered on reading xwd: load_image (xwd): XWD-file /root/.gimp/tmp/gimp_temp.277523.xwd has format 2, depth 24 and bits per pixel 24. Currently this is not supported. This message was generated attempting to capture glxgears using Gimp (xwd). What do you suppose it means? Capturing motion video windows is really flakey with xwd. Usually it fails, but sometimes it doesn't. It seems to be influenced by what other windows are being displayed. Sven and GSR, any further thoughts? Cheers, Robin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] xwd screen shot problems
Hi. Unless I'm mistaken xwd isn't capable of capturing 24-bit visuals. It seems almost useless on modern hardware. Is this an issue that has been discussed here before? Attempting to capture graphics-intense windows with xwd on x86-based XFree86 3.x or 4.x just gives a misleading error message, extra confusing because other simpler windows on the same desktop will capture without trouble. The ImageMagic import utility works consistently and writes directly to png. Is there any thought to switching Gimp screen capture to use import? Cheers, Robin - Original Message - From: Sven Neumann [EMAIL PROTECTED] To: Federico Mena Quintero [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, June 26, 2001 11:28 AM Subject: Re: [Gimp-developer] 1.2 Bug Hunting Hi, Federico Mena Quintero [EMAIL PROTECTED] writes: I've had this problem, and it appears to exist only with the version of xwd that's shipped with XFree86 4.0.x where x=2. I upgraded to 4.0.3 and the problem went away. Same problem (with same version of X) existed with WindowMaker too. Oh dear. Don't tell me that the GIMP uses xwd for getting screenshots. If so, please please *please* feel free to steal the code from gdk_pixbuf_get_from_drawable(). it does ;-) The screenshot plug-in is kind of old and has always been a quick hack. On the other hand it works pretty well for most users... Yes, we are considering another solution for the next version of Gimp. Since we will use GTK+-2.0, we will also use gdk-pixbuf and can thus use the functionality gdk-pixbuf provides. For Gimp-1.2 however things will not change. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
