[Gimp-developer] Information on IWarp
Dear GIMP developers, I really like the effects possible with the IWarp plugin. But what is the technical background this plugin is based on? Where can I find some information about the theory? What buzz words do I have to feed the search engines with? Best regards, Teddy _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Thoughts on CMYK, and getting it without implementing it.
Anyways, I had some conversation with two graphics designers about CMYK problems and the Gimp at the Systems, and I think it might be worthwhile to read the following sometimes true observations. Remember, they are hearsay ;) Thanks for writing this stuff up. I think I should mention that I work in the prepress department of a highend lithographic printing company so that you know what my biases are when reading my comments below. 1. colour matching for photos is a don't care. Ok, this is a blatant lie, however, exact colours are not that much of a concern for photos. Much more important are logo colours (most companies have pretty strict definitions of these). If a photo doesn't exactly match the screen colours (which screen colours, anyways) this is often not a reason to not use gimp. If a logo colour can't be reproduced, however, it keeps Gimp from being used. You should not create a logo requiring Logo Colours in a program such as photoshop or gimp. You will get superior results using a vector based application such as illustrator. Sometimes you will need to match a logo captured in a photograph to a specific logo colour , but the first step would be to convert your photograph to CMYK. Logo Colours (aka spot colors or PMS colors) can already be used in gimp if you are only using one ink at a time. Just save your image as a grayscale tiff and place the image in quark using whatever ink you want. 2. Logo colours are not CMYK. Yupp. Logo colours might not be representable in CMYK at all (gold etc...). Even if, you often (but not always) want seperate planes for important colours. Most uses of spot colours want the concept of an indexed channel, i.e. a channel where each value represents a different palette colour. No bleeding with image contents. Gimp's channels can be used instead, which is not that perfect for all uses, but exists and at least photoshop doesn't offer a better solution ;) They also allow gradients of a single spot colour, which indexed channels wouldn't allow. Wether all this makes them easier or harder to use is something to explore. In my experience, when you are using a spot color in a raster image you are not usualy working with a logo. Usually you are trying to match a color in a photograph that is not representable in the CMYK color space such as some reds and oranges. Any image that you would want indexed Logo Colours for would be better off handled in a vector based program such as illustrator. 3. You don't print from within the gimp. At least you don't print brochures from within the Gimp. You use gimp for artwork, often the logos, but you obviously don't set text using the Gimp. You instead import images into some layout program (quark xpress ;). I was told that the principal reason for bad quality of gimp images within quarkxpress is that quarkxpress imports gimp's rgb tiffs like garbage. I was told that loading the rgb data into photoshop, associating sRGB with it (changing _nothing_ else) improved the quality very much, making the results reproducable on printers. Without absolute colours, they look different. In my experience people don't use gimp (or photoshop) for logos (I mean for print work, of course the web is a whole different story) I am not certain, but I think that the rgb-cmyk conversion is not done by quark, but by the postscript rip when you print your file. Regardless of weather it is quark or the rip that convert the colour, setting the colour profile to sRGB in gimp is the wrong fix. There should be a setting on either quark or the rip that tells it what color profile to use for images that have no assigned profile. Where I work, we _never_ place rgb files in quark. If a client of ours gives us file in RGB the first thing we will do is convert it to CMYK in photoshop. 5. Logos are done by overlays. At least one method of using spot colours is to create them as seperate channels. Tiff/Eps are reportadly able to save additional channels in a way that a program can read them sensibly. The spot colour planes are then laid over the other graphics. For this to work a mask is necessary, since channels range from white (not transparent) to channel colour, at leats in quarkxpress. It seems that traditional masks are not what's called for - instead you want a path saved in the tiff/eps file (don't ask me wether that is possible). This clipping path is then used for the overlay - gimp can't create this kind of paths, nor can it save it. The industry standard way of saving raster files that have spot channels in them is the DCS file format (A very close cousin of EPS). Clipping paths are commonly used to overlay an image over text or another image in quark.
Re: [Gimp-developer] Developers and users (was: Bug week like thing for GIMP?)
Hi, Lourens Veen [EMAIL PROTECTED] writes: On Wednesday 28 November 2001 15:17, Sven Neumann wrote: could you explain how you tried to find out? I can't really imagine what difficulties you had and it would be interesting to know. I browsed things for a bit, and I think I know the problem I had back then. I totally missed the devel-docs directory. *DOH*. I had a look around now (in the past 5 minutes, I'm in the middle of exams here) and it's pretty good. What I miss though is a rather high-level overview, something along the lines of Gimp consists of libgimp, which contains the drawing functions, gimpui, which is the user interface, . insert pretty diagram These are connected by . Having all the interface definitions is very good, but I think it would be handy if you could read how it's being used rather than how to use it. the devel-docs are meant as an API reference for plug-in developers, so they don't really help if you want to start hacking the GIMP core. Nevertheless it would be nice if someone would spend some time polishing the docs. For gimp-1.3 we plan to add docs for the internal API too. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Common dir of plug-ins (patch about OK button)
Hi, Guillermo S. Romero / Familia Romero [EMAIL PROTECTED] writes: OK, I have been reviewing the common dir, I think I rearranged all them so they have the OK in the new place. I also have read some code (that is the only reason for so boring task) and next will try to finish the others as well as improve thos that look pretty bad (like five buttons, of which three just change things, but are not reset | cancel | ok, not anything in that line). The gz was done with cvs diff -u in the common dir, and does not include the patchs I already sent to sven mitch. please, don't compress patches, simply include them in your mail. That makes it much easier to look through them in the mail reader and to comment on the patch in a reply. No need to resend this patch however, I'll look through all the patches you sent right now... Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: ANNOUNCE: GIMP 1.3.1
I have a dumb idea. If the other mail-lists that are concerned with subscribe to the gimp-announce list (like gug, and gimpi) then everyone will get the announcements. You could even subscribe gimp-dev and gimp-user so you don't need to worry about everyone; one simple announce will do it. carol [EMAIL PROTECTED] (2001-11-25 at 1347.12 +0100): Hi, for the curious and brave, here is another release in the unstable 1.3 series of The GIMP: ftp://ftp.gimp.org/pub/gimp/v1.3/v1.3.1/ This release depends on: glib-1.3.11 pango-0.22 (with FT2 support) atk-0.7 gtk+-1.3.11 Beware, this is an unstable developers release. Don't use it for real work, it's rough around the edges, it crashes, it might not even compile. Overview of Changes in GIMP 1.3.1 = - Follow GTK+-2.0 and Pango API changes [Yosh, Mitch, Sven] - Added Color Erase paint mode [Simon Budig] - Proofreading of messages [Rebecca Walter] - Improvements to container views [Mitch] - Improved tool options [Mitch] - Made --no-interface mode work without calling gtk_init() [Mitch] - Reworked paint_funcs [Daniel Egger] - Added SF-DIRNAME script-fu parameter [Matteo Nastasi] - Lots of internal cleanups [Mitch, Sven] - More stuff not mentioned here (see the ChangeLog) Other Contributors: Guillermo S. Romero, David Neary Happy GIMPing, 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] Plug-in development
Hi all. I'm a poor newbie trying to code a plugin for the Gimp, but I'm encountering some problems: I don't really understand all kind of things I did but finally succeeded to compile and install my plugin. The problem is that it is disabled in the menu. 1) I'm not sure this is the good place to ask this question, but it seemed to before I read the last 10 messages ;-) 2) If this is more easy for you to reply in seeing/compiling my code (commented out in french, sorry), you can find it here : http://tharibo.free.fr/GIMP/isodata.tar.gz Thanks in advance. -- [EMAIL PROTECTED] Le temps ne fait rien à l'affaire, quand on est con, on-est-con ! -- Georges Brassens ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] first CVS gimp try
Hi!
I got problems setting up a CVS gimp version (see at the bottom). The
reason I am/was trying is, that I wanted to submit a patch and
figured, you'd like it more if it was against a current CVS
version. ;-) Let me explain what my patch is about and what my
problems are at the end.
Some time ago, I tried to redo an effect someone else did with
Photoshop. It's about the surroundings (aura - how do pro's call
it?) of the text in the logo of Blue Twister (www.bluetwister.de).
If the server's up again, please have a look at
http://www.bluetwister.de/images/btlogo_medium.jpg
I figured it was just a matter of the distance metric used in the
grow selection function - gimp would use an Eucledian metric whereas
a 4- or 8-neigbours (manhatten/checkerboard/whateveryoucallthem)
metric would have been neccessary for this effect.
So I decided to implement them and in a very easy way I succeeded. I
made the internal functions for selection growing accept an additional
parameter and since I don't know much about gtk, just implemented a
script-fu interface which I used from my website with gimp-perl.
The patch still has two problems(?):
- It is against 1.2.1
- I guess it's impossible to have optional parameters in script-fu?
Then it'll probably be neccessary to rename the new function and
provide the old one for backwards-compatibility.
I attached it nevertheless - please have a look whether you think
sth. like this is useful to more people than me (a gtk ui should be
trivial?) and whether you want to merge it into CVS. If you tell me
that you want the patch and you want it against CVS and you can help
me setting that version up I'd be willing to try to adopt it again
(since it's mostly done code-wise, only I can't get it to run atm).
My problem with setting up Gimp-CVS basically was, that it's not
trivial. ;-))
I installed gtk+-1.3.10, pango-0.21, atk-0.6 and stuff in the right
order - no problems so far (using pkgconfig-0.8.0 from Mdk8.1 BTW).
The Gimp compiles with some small setup-hazzles, but has at first some
strange stuff at starting up:
---8 snip 8---
using MMX: yes
gimp (pid:11899): ** WARNING **: No fonts found by pangoft2. Things will probably not
work
gimp (pid:11899): ** WARNING **: Didn't read any pango ft2 fontalias file. Things will
probably not work.
gimp: query called
gimp: query done
gimp: run called extension_plugin_helper
gimp: Could not open module /usr/local/lib/gimp/1.3/plugin-modules/libiwarp.so!
gimp: time for the evil loop
gimp_dialog_factory_add_dialog: registering toplevel gimp:toolbox
---8 snip 8---
Where to a newbie it seems that
- Pango has problems. (?)
- An evil loop can't be very nice to have ;-)
The latter lead me to plugin-helper.c:
---8 snip 8---
query_module (/usr/local/lib/gimp/1.3/plugin-modules/libiwarp.so);
g_message (time for the evil loop);
gimp_extension_ack ();
while (TRUE) /* this construction bothers me deeply */
gimp_extension_process (0);
---8 snip 8---
Which really seems to be strange stuff... @-}
However, the real problem is that the loading of images fails:
- GIFs have 0 layers
- JPGs are not really loaded (only the progress dialog appears, until
I press cancel)
- The same with PNGs
- TIFs report an error incorrect count for field MaxSampleValue (1,
expecting 3); tag ignored and some module segfaults (I get this:
/usr/local/lib/gimp/1.3/plug-ins/tiff: fatal error: Speicherzugriffsfehler
/usr/local/lib/gimp/1.3/plug-ins/tiff (pid:12118): [E]xit, [H]alt, show [S]tack trace
or [P]roceed:
While I could imagine some of them are temporary problems in a
development version, I don't believe you all get all those.. ?
--
Ciao, / /
/--/
/ / ANS .,* Hamburg, Germany *,.
diff -u2bdr gimp-1.2.1/app/apptypes.h /usr/src/gimp-1.2.1-patched/app/apptypes.h
--- gimp-1.2.1/app/apptypes.h Sat Dec 16 22:36:51 2000
+++ /usr/src/gimp-1.2.1-patched/app/apptypes.h Tue May 22 01:02:36 2001
@@ -89,4 +89,12 @@
NEGATIVE_CONVOL /* add 127 to values */
} ConvolutionType;
+
+/* Distance Metrics */
+typedef enum
+{
+ DIST_EUCLID,/* Euclidean distance: sqrt((x1-x2)^2 + (y1-y2)^2) */
+ DIST_CITYBLOCK, /* Cityblock/Manhattan distance: abs(x1-x2) + abs(y1-y2) */
+ DIST_CHECKERBOARD /* Checkerboard distance: min(abs(x1-x2), abs(y1-y2)) */
+} DistanceMetric;
/* Brush application types */
Only in /usr/src/gimp-1.2.1-patched/app: apptypes.h.orig
Only in /usr/src/gimp-1.2.1-patched/app: asupsample.o
Only in /usr/src/gimp-1.2.1-patched/app: batch.o
Only in /usr/src/gimp-1.2.1-patched/app: bezier_select.o
Only in /usr/src/gimp-1.2.1-patched/app: blend.o
Only in /usr/src/gimp-1.2.1-patched/app: blob.o
Only in /usr/src/gimp-1.2.1-patched/app: boundary.o
Only in /usr/src/gimp-1.2.1-patched/app:
Re: [Gimp-developer] Thoughts on CMYK, and getting it without implementing it.
On Thu, Nov 29, 2001 at 03:17:51AM -0800, Jay Cox [EMAIL PROTECTED] wrote: pretty strict definitions of these). If a photo doesn't exactly match the screen colours (which screen colours, anyways) this is often not a reason to not use gimp. If a logo colour can't be reproduced, however, it keeps Gimp from being used. You should not create a logo requiring Logo Colours in a program such as photoshop or gimp. You will get superior results using a vector based application such as illustrator. That's what I was told, too (together with: many people do it with photoshop anyways ;) Sometimes you will need to match a logo captured in a photograph to a specific logo colour , but the first step would be to convert your photograph to CMYK. But how critical is that process? Do you think that my main point - cheap conversion to cmyk in the tiff/eps-plugin(s) - would really ease life and would enable gimp to enter prepress world (even if not at all perfect)? Logo Colours (aka spot colors or PMS colors) can already be used in gimp if you are only using one ink at a time. Just save your image as a grayscale tiff and place the image in quark using whatever ink you want. What about the clipping path, though? I'd guess you want to overlay these layers often. are not usualy working with a logo. Usually you are trying to match a color in a photograph that is not representable in the CMYK color space Any image that you would want indexed Logo Colours for would be better off handled in a vector based program such as illustrator. I was told that trapping can be done with expensive plug-ins for photoshop only, which would make sense, since trapping is (AFAICS, no idea actually) not really well-defined for photos, what users would buy such a trapping plug-in for photoshop? In my experience people don't use gimp (or photoshop) for logos (I mean for print work, of course the web is a whole different story) But gimp already works fine for the web, so that's a problem ;) I am not certain, but I think that the rgb-cmyk conversion is not done by quark, but by the postscript rip when you print your file. That would nicely explain why it looks like crap. setting the colour profile to sRGB in gimp is the wrong fix. There should be a setting on either quark or the rip that tells it what color profile to use for images that have no assigned profile. Unfortunately, users usually don't have control over the rip. I guess whatever rip is used just uses it's defaults for RGB. quark is a difefrent story - what if quark doesn't have such a setting? But I think that acse would be rather irelevant once we have CMYK in tiff. can't create this kind of paths, nor can it save it. The industry standard way of saving raster files that have spot channels in them is the DCS file format (A very close cousin of EPS). I knew eps couldn't do it (directly ;). Ok, prepare for: REVISED CONCLUSIONS (ordered my importance). 1. implement CMYK saving in tiff and eps. 2. enhance tiff(?) eps to save all channels paths in whatever format is actually understood (DCS for eps). one path must be marked as clipping path (e.g. by name Clipping Path or by some parasite (gimp-clippath on the image containing the ascii form of the path tattoo or somesuch). 3. (optional, but important) finally enhance the paths to be multipart, contain holes etc. simon? smoon? ;) -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
