Re: [Gimp-developer] Image cut-n-paste; Mac clipboard plugin
On June 13 I wrote: So far as I recall, Gimp has always lacked the ability to copy and paste images to other applications. Is this something that still requires support from Gtk to do cleanly? I noticed that the Win32 port of Gimp ships with a plugin that hacks in some clipboard support, and have had a go at porting it to Mac OS X: http://leuksman.com/mac/gimp/clipboard/ It's been brought to my attention that 2.1 now uses the GTK+ system clipboard for copying images, so it might be nice to integrate the native clipboard with that more directly. After a lot of recompiling, I've managed to get 2.1 running from CVS. It seems to be doing _something_ with the clipboard, but I haven't yet gotten anything resembling an image out of it. Is there any X11-based program known to interoperate with it that I could test with to make sure it's working? GTK+ on Mac OS X is stuck in the X11 ghetto; Apple's X11 server tries to keep the X and Mac clipboards in sync, but seems to manage plain text only... on the Mac side I see only empty text on the clipboard after copying an image. Either Gimp or GTK+ could be hacked up to use the Mac clipboard directly, I suppose. Any opinions on what's the correct place to do this? The plugin I've been working on also provides access to the Grab and Image Capture services for screen capture and scanning (services communicate over the same NSPasteboard interface as the clipboard), so it'll likely continue to be independently useful even after a hypothetical Mac-clipboard-enabled Gimp 2.2. -- brion vibber (brion @ pobox.com) signature.asc Description: OpenPGP digital signature
Re: [Gimp-developer] Read/write plugin
Hi, Shlomi Fish <[EMAIL PROTECTED]> writes: > If there's an API function that you don't understand you can look at > its description in the header files and source code under > "libgimp/", "libgimpbase", etc. grep is your friend. I also suggest you use the API documentation which can be found in the GIMP source tree in the devel-docs folder or online at http://developer.gimp.org/api/2.0/ Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Image cut-n-paste; Mac clipboard plugin
Hi, Brion Vibber <[EMAIL PROTECTED]> writes: > After a lot of recompiling, I've managed to get 2.1 running from > CVS. It seems to be doing _something_ with the clipboard, but I > haven't yet gotten anything resembling an image out of it. Is there > any X11-based program known to interoperate with it that I could test > with to make sure it's working? The easiest way to test is to use a second instance of GIMP. Another application that is known to work is the word-processor Abiword. Here are some links that explain how the X clipboard is supposed to be used: http://tronche.com/gui/x/icccm/ http://www.jwz.org/doc/x-cut-and-paste.html http://www.freedesktop.org/standards/clipboards-spec/clipboards.txt GIMP passes image data in the PNG format and announces it using the "image/png" mimetype identifier. > Either Gimp or GTK+ could be hacked up to use the Mac clipboard > directly, I suppose. Any opinions on what's the correct place to do > this? It definitely belongs into GTK+ in the long run. Perhaps it would be good to start a GDK backend for MacOS X that is based on the GDK-X11 backend but deals with clipboard and other interoperability issues. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Read/write plugin
Hi again Thanks for all the reply's - that was really fast. Anyway, I'll be looking into the bmp plug-in and then I'll properbly come running for help again. Thanks all, Søren ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Script-fu-server and queuing
Hi, I use the script-fu-server and came across this remark at http://people.westminstercollege.edu/students/d-b1649/linux/gimp_server.html Adding a Queue Because the Gimp was not originally designed as a server, it does not follow some conventions that are necessary for such a mode. This includes the issue of managing shared resources among different threads of execution. A few of the resources that are not 'thread-safe' include the current foreground/background color and brush shape. An example of the severity of this problem is if you are running two Perl scripts at once on the same Gimp server. Let's say that the first script needs to write some white text on a black background, and the second one needs to write black text on a white background. Because the two are running at the same time, the following sequence of events may occur: 1. #1 sets the foreground color to white. 2. #2 sets the foreground color to black. 3. #1 writes some text to its black image, using the current foreground color (which is now black.) 4. #2 writes some text to its white image, using the current foreground color (still black.) Obviously, script #1 ends up with an image that has the incorrect color of text. The solution to this problem is to only allow the Gimp server to run one script at a time. This is easier said than done, especially if you have multiple scripts that run every few minutes. What you need to do is create a queue system that maintains a list of scripts that need to be run and have a separate program feed them into the Gimp, one by one. When a script wants to run, it is submitted to the queue and waits for its turn. This kind of system is almost identical to print queues, where multiple computers share one printer. On the other hand I took a look at the gimp sources and it seems there is some kind of queuing mechanism build inside gimp. I have also read the post "http://marc.theaimsgroup.com/?l=gimp-developer&m=103142913407902&w=2"; about queuing (for perl-fu, but I guess it's the same for script-fu) >From this post it seems that I can safely sent multiple concurrent requests to the script-fu-server (apart the problem of memory consumption raised by the initial poster of that thread). What is the reality in this regard? Do I have to build my own queue or is it handled by gimp. I use v 1.2.3 but plan to upgrade to gimp 2.0. Is there a difference in that respect between the two versions? Thanks. __ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Script-fu-server and queuing
Hi, Oscar Picasso <[EMAIL PROTECTED]> writes: > I use the script-fu-server and came across this remark at > http://people.westminstercollege.edu/students/d-b1649/linux/gimp_server.html > > > > Adding a Queue > > Because the Gimp was not originally designed as a server, it does > not follow some conventions that are necessary for such a mode. This > includes the issue of managing shared resources among different > threads of execution. A few of the resources that are not > 'thread-safe' include the current foreground/background color and > brush shape. > > An example of the severity of this problem is if you are running two > Perl scripts at once on the same Gimp server. Let's say that the > first script needs to write some white text on a black background, > and the second one needs to write black text on a white > background. Because the two are running at the same time, the > following sequence of events may occur: > >1. #1 sets the foreground color to white. >2. #2 sets the foreground color to black. >3. #1 writes some text to its black image, using the current foreground > color (which is now black.) >4. #2 writes some text to its white image, using the current foreground > color (still black.) > > Obviously, script #1 ends up with an image that has the incorrect > color of text. The solution to this problem is to only allow the > Gimp server to run one script at a time. This is easier said than > done, especially if you have multiple scripts that run every few > minutes. What you need to do is create a queue system that maintains > a list of scripts that need to be run and have a separate program > feed them into the Gimp, one by one. When a script wants to run, it > is submitted to the queue and waits for its turn. This kind of > system is almost identical to print queues, where multiple computers > share one printer. > > I don't think a queue is the way to go here. In gimp-2.0 we have introduced the concept of a GimpContext that holds the foreground and background colors, current brush, pattern, gradient and all that. The solution is though to let each script/plug-in run in it's own context. We didn't do that yet because some scripts rely on the possibility to manipulate the user context. The best thing to solve this is probably to let scripts work in their own context by default and add an API to manipulate the user context. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Roadmap for 2.2 (and beyond)
Hi, one of the things we discussed last week at GIMPCon was planning the 2.2 release. I didn't take notes from our discussions but I will try to summarize the results and will also try to be more specific when it comes to the features we'd like to see in 2.2. We agreed that 2.2 will take some more time and decided to set a date for a final feature freeze by the end of August. Since I was actually in favor of an earlier date I plan to be very strict about this date. Any feature that isn't basically finished by the end of August will have to be backed out for the 2.2 release. We'd like to know about all features that people are working on before the end of July. Do not expect us to accept larger patches that introduce completely new features close to the feature freeze at the 31th of August. This schedule gives everyone four weeks to announce their plans and eight weeks to finish them. Since the tree is currently rather stable and we don't expect that to change during the next weeks, we hope to be able to flush out remaining bugs rather quickly and aim to release GIMP 2.2 by the end of September. When 2.2 is out, we'd like to invite all GIMP developers to help on bringing GEGL to a state where we can start to use it from GIMP (and other apps). This will slow down GIMP development for a while but we need to finally make the move towards GEGL. There's a lot more to say about GIMPCon but I will try to do that in separate mails in an attempt to keep the discussion focused on a particular topic. So stay tuned for more mails to come during the next days... Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Image cut-n-paste; Mac clipboard plugin
Hi Brion, it would be very helpful if you could point us to some documentation about the MacOS X clipboard. I am particularily interested in the formats that are typically used to exchange data using the clipboard. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Image cut-n-paste; Mac clipboard plugin
Sven Neumann wrote: it would be very helpful if you could point us to some documentation about the MacOS X clipboard. I am particularily interested in the formats that are typically used to exchange data using the clipboard. http://developer.apple.com/documentation/Cocoa/Conceptual/CopyandPaste/index.html Cocoa apps (those written with the NeXT-derived toolkit) use TIFF for transferring raster images. Older apps (like Photoshop) tend to use PICT, which is a metafile format encapsulating calls to the QuickDraw drawing library. Using the Cocoa NSPasteboard interface, I can copy a TIFF and it performs the conversion to PICT for me, but when pasting I need to handle both formats. Additionally rich text data may contain TIFF images, which can be extracted (this is useful for copying images from an RTFD document in TextEdit). Cocoa prefers premultiplied alpha, so there's some lossy conversion for images with partially transparent areas. (This could probably be eliminated between instances of the Gimp by using libtiff to create & read the TIFFs rather than NSBitmapImageRep which I'm using at the moment.) How is image cut-n-paste handled on Win32? Windows apps use DIB (.bmp) format for clipboard transfer; does the GDK backend handle DIB<->PNG conversion? I took a quick look around gdkselection-win32.c & friends but didn't see anything obvious. -- brion vibber (brion @ pobox.com) signature.asc Description: OpenPGP digital signature
Re: [Gimp-developer] Image cut-n-paste; Mac clipboard plugin
Hi, Brion Vibber <[EMAIL PROTECTED]> writes: > Cocoa apps (those written with the NeXT-derived toolkit) use TIFF for > transferring raster images. Older apps (like Photoshop) tend to use > PICT, which is a metafile format encapsulating calls to the QuickDraw > drawing library. Using the Cocoa NSPasteboard interface, I can copy a > TIFF and it performs the conversion to PICT for me, but when pasting I > need to handle both formats. We use gdk-pixbuf to handle the clipboard image data. So far we only use the PNG format but it would be reasonable to extend this to the full range of formats supported by gdk-pixbuf. There's an API that we can use that allows us to retrieve the list of supported formats and the associated mime-types. There's a tiff loader in GTK+ but no way to save TIFF files. There doesn't seem to be support for PICT (except perhaps in a 3rd party pixbuf loader that I don't know about). So the best way to address this would probably be to write a PICT loader and either get it into GTK+ or bundle it with GIMP for MacOS X. > How is image cut-n-paste handled on Win32? Windows apps use DIB > (.bmp) format for clipboard transfer; does the GDK backend handle > DIB<->PNG conversion? I took a quick look around > gdkselection-win32.c & friends but didn't see anything obvious. It would not be the job of the backend to handle the format conversion. The backend only needs to expose the clipboard in a compatible manner (e.g. data with associated mime-types). It's the application's job to handle the actual clipboard data. Of course it would be nice if everyone could agree on using PNG but that's unfortunately not how it works. So in order to use the win32 clipboard we will need to support BMP support in gdk-pixbuf. This is there fortunately but it seems to be limited to reading. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Image cut-n-paste; Mac clipboard plugin
Sven Neumann wrote: >> Is there any X11-based program known to interoperate with it that >> I could test with to make sure it's working? The easiest way to test is to use a second instance of GIMP. Another application that is known to work is the word-processor Abiword. Thanks, it seems to be working on the X11 side. I do sometimes get what looks like an RGBA/ARGB mixup copying from Abiword to Gimp though; I'll try to isolate that and report the bug to the guilty party... :P -- brion vibber (brion @ pobox.com) signature.asc Description: OpenPGP digital signature
[Gimp-developer] color management
Hi, one of the things we dicussed shortly at GIMPCon was how to add basic color management to GIMP. We know that it will be a major effort to integrate this and it will need GEGL to do it properly. However there are a few things in this area that we should be able to do for GIMP 2.2. That should help users that are waiting for these features and it should help us to get some experise in this area. So here's the plan... We agreed that lcms (http://www.littlecms.com/) seems to be a good choice for our needs. We already use it for the proof display filter so it's basically already a dependency and the plan I am going to outline is not going to make it a hard dependency. So if anyone wants GIMP w/o color management and w/o a dependency on lcms that will continue to be possible. There are a couple of things we want to to achieve: (1) color-correct the image display according to a monitor profile (2) make it easier to do soft-proofs (3) use color profiles embedded into files we open (4) embed color profiles into files we save (5) do color separation based on color profiles ... How much of this will make it into 2.2 depends on how much work is put into this which in turn means that it depends on your contributions. Some parts can be achieved by means of modules and plug-ins and can thus be developed further after the GIMP 2.2 release. We should now focus on the changes to the core and to the libgimp and module APIs that we need to get this done. I will try to propose some ideas that aim to implement the points mentioned above: (1) color-correct the image display according to a monitor profile This can be done rather easily using the existing display filters architecture. What stands in the way here is that display filters are not very well integrated yet. As a user you should not have to configure the monitor profile for every image display you open. So what needs to be done here is to improve integration of color display filters. Mitch and me already started to make some changes that are supposed to lead to a set of global display filters that are configured in the user's filterrc and that are loaded by default. The user can then configure a monitor display filter that color-corrects all image displays for her monitor. We will have to extend this to previews and color selectors in order to provide a consistently color-corrected user interface. (2) make it easier to do soft-proofs We have a display filter already that does soft proofs. At the moment it is however rather akward to use. I see two ways to improve this. One is to make it remember it's configuration and we are already working on providing that functionality for all display filters. The other improvement I see is to adapt to standard locations for color profiles. The file selector for color profiles should contain bookmarks for the default locations for color profiles as they have been suggested on the OpenICC mailing-list on freedesktop.org ($prefix/share/color/icc and ~/.color/icc). Perhaps we even want to add a special widget to select color profiles? (3) use color profiles embedded into files we open When an image file we open has an embedded color profile we should ask the user if the image should be converted to linear sRGB (which is what GIMP assumes internally). This will need changes to a couple of plug-ins and these changes need to go into #ifdef's since we don't want to depend on lcms. Or should we just add this dependency? (4) embed color profiles into files we save Not sure how much sense this makes. If we had a widget to select color profiles, then it would be easy to add ways to attach color profiles to images. I am just not sure if that makes sense for us since we can't (yet) work in the color spaces defined by these profiles (expect for the linear sRGB profile). (5) do color separation based on color profiles There are two plug-ins that can do color separation based on color profiles. One is the separate plug-in: http://www.blackfiveservices.co.uk/separate.shtml The other is the TIFF plug-in by Kai-Uwe Behrmann. I haven't looked at it recently and don't know what state it is in. But AFAIK it also does color separation to CMYK. I have some sentiments against including a plug-in with lots of #ifdef'ed code that is supposed to work for various flavours of GIMP as well as CinePaint but it would certainly be good to evaluate if and how this plug-in could replace the current tiff plug-in. Since I am not a color management expert myself, there might be fundamental design flaws in the stuff I outlined above. Please let me know about them and please contribute your ideas. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Image cut-n-paste; Mac clipboard plugin
Hi, Brion Vibber <[EMAIL PROTECTED]> writes: > > The easiest way to test is to use a second instance of GIMP. Another > > application that is known to work is the word-processor Abiword. > > Thanks, it seems to be working on the X11 side. I do sometimes get > what looks like an RGBA/ARGB mixup copying from Abiword to Gimp > though; I'll try to isolate that and report the bug to the guilty > party... :P I've seen that as well. I suspect it's the GIMP code that still assumes that a GimpBuffer is always RGBA while the clipboard code happily passes it a RGB tile-manager if the PNG data doesn't have an alpha channel. I am just not sure where this would best be fixed. We need to either remove that assumption or add an alpha channel when converting the pixbuf to a tile-manager. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Image cut-n-paste; Mac clipboard plugin
Tor Lillqvist wrote: Brion Vibber writes: > How is image cut-n-paste handled on Win32? There is a (Windows-specific) GIMP plug-in that does the "paste from (Windows) Clipboard" and "copy to Clipboard". That code probably should move to GTK+. (I doubt it's straightforward, though, so it hardly will get done in GTK+ 2.6.) Yeah, that's the plugin I ported to Mac OS X. :( -- brion vibber (brion @ pobox.com) signature.asc Description: OpenPGP digital signature
Re: [Gimp-developer] Image cut-n-paste; Mac clipboard plugin
Brion Vibber writes: > How is image cut-n-paste handled on Win32? Windows apps use DIB (.bmp) > format for clipboard transfer; does the GDK backend handle DIB<->PNG > conversion? I took a quick look around gdkselection-win32.c & friends > but didn't see anything obvious. There is a (Windows-specific) GIMP plug-in that does the "paste from (Windows) Clipboard" and "copy to Clipboard". That code probably should move to GTK+. (I doubt it's straightforward, though, so it hardly will get done in GTK+ 2.6.) --tml ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] color management
Sven Neumann writes: > When an image file we open has an embedded color profile we should ask > the user if the image should be converted to linear sRGB (which is > what GIMP assumes internally). Er, what's "linear" about sRGB? It's gamma encoded (and that's a good thing). Doesn't the term "linear" in the context of colour spaces mean one with components that are linear in intensity, i.e. a linear transformation of the CIEXYZ colour space, which sRGB isn't. Or am I confused? I don't know, maybe we should also allow other (more wider gamut) internal working colour spaces than sRGB? A lot of the proprietary software users seem to use the "Adobe RGB" colour space. I don't know if they are just kidding themselves or whether it actually is noticeably better to use a wider gamut when working on photographic images. (If one uses a colour space with a much wider gamut than the monitor, or different primaries, (most monitors are "close" to sRGB), one definitely has to use a display profile.) BTW, a good site with colour management info is www.brucelindbloom.com --tml ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Image cut-n-paste; Mac clipboard plugin
Hi, Tor Lillqvist wrote: > There is a (Windows-specific) GIMP plug-in that does the "paste from > (Windows) Clipboard" and "copy to Clipboard". That code probably > should move to GTK+. (I doubt it's straightforward, though, so it > hardly will get done in GTK+ 2.6.) What is the state of support for the GDK clipboard in the win32 backend? Michael reported that he can't even copy and paste image data from one GIMP instance to the other on Win32. Would that be supposed to work? Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Image cut-n-paste; Mac clipboard plugin
Sven Neumann writes: > What is the state of support for the GDK clipboard in the win32 > backend? For the *GDK* clipboard only cut&paste of text is supported. The winclipboard plug-in uses the Windows clipboard directly. > Michael reported that he can't even copy and paste image data > from one GIMP instance to the other on Win32. Would that be supposed > to work? Yes it does work. (Although I now notice that it always copies the whole drawable to the Windows clipboard, not just the selection as one would expect). --tml ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Image cut-n-paste; Mac clipboard plugin
I wrote: Thanks, it seems to be working on the X11 side. I do sometimes get what looks like an RGBA/ARGB mixup copying from Abiword to Gimp though; I'll try to isolate that and report the bug to the guilty party... :P Patch in bugzilla: http://bugzilla.gnome.org/show_bug.cgi?id=145482 -- brion vibber (brion @ pobox.com) signature.asc Description: OpenPGP digital signature
