[Gimp-developer] Scanner Epson FS200 negs wrong pixel line SUGGESTIONS
Hi All, I have a problem with a Epson FS200 Slide/negs Scanner. The problem is more obvious with negatives than with slides. The problem is that I always get one of the pixels in the negs more clearer than the rest of them (i.e. a white line crossing the scanned negative). In the case of the slides the line is darker than the rest of the scanned slide. Scanner is out of warranty. First thing I have tried was to clean the lens just in case but, it did not solved the problem. I do not want to go deeper in cleaning it just in case I spoil the alignment of the lens. I use gimp/sane to scan slides. I tested the scanner also at win9x to see if it could be a problem of the soft but the offending pixels were there too. I was thinking of editing negs/slides, but it is going to be a long and tedious work. The failure in the case of slides is almost unperceptible. Negatives is really obvious. The question: Have gimp some special feature so that if I am able to identify the pixel line (supposing it is always at the same position) I could apply a script to correct the pixel line ? My idea is this (supposing an horizontal pixels line): the offending pixel line would be corrected to the value of the pixel above and/or the pixel below it (like an interpolation between the pixels above and below the wrong line of pixels). I am not sure if I am said something really with nonsense. I would appreciate some ideas about how to proceed. Javi, _ [EMAIL PROTECTED] |http://www.europa3.com/users/fjherna/ \_(_)_/ http://www.valux.org/ !___!___!___ FidoNet= 2:346/207.48 The only thing cheaper than hardware is talk. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] gimp HEAD and glib from CVS
Hi,
we have tried to keep the CVS version of GIMP compileable with the
latest releases of GTK+ and friends as well as with the current state
of these modules in CVS. The latest (small) changes in glib break
source compatibility and since the glib version number has not yet
been incremented, I don't see a way to conditionalize the code so
that it works with both versions of glib. As a first solution, I'm
posting a patch here for the people among you that follow CVS
development of glib, pango, atk and gtk+. I'd like to know how many
of you would prefer to have this changes applied to the gimp CVS
tree now and how many would prefer us to stay source compatible with
the latest glib, pango, atk and gtk+ development releases.
Salut, Sven
Index: libgimpbase/gimpparasiteio.c
===
RCS file: /cvs/gnome/gimp/libgimpbase/gimpparasiteio.c,v
retrieving revision 1.9
diff -u -r1.9 gimpparasiteio.c
--- libgimpbase/gimpparasiteio.c2001/08/01 00:35:48 1.9
+++ libgimpbase/gimpparasiteio.c2001/10/02 17:32:26
@@ -161,8 +161,8 @@
for (i = 0; i params-dim; i++)
{
- g_string_printfa (s, rank%d:%d, i, params-rank[i]);
- g_string_printfa (s, sel%d:%s, i, params-selection[i]);
+ g_string_append_printf (s, rank%d:%d, i, params-rank[i]);
+ g_string_append_printf (s, sel%d:%s, i, params-selection[i]);
}
str = s-str;
Index: plug-ins/ifscompose/ifscompose_storage.c
===
RCS file: /cvs/gnome/gimp/plug-ins/ifscompose/ifscompose_storage.c,v
retrieving revision 1.8
diff -u -r1.8 ifscompose_storage.c
--- plug-ins/ifscompose/ifscompose_storage.c2001/08/01 00:35:57 1.8
+++ plug-ins/ifscompose/ifscompose_storage.c2001/10/02 17:32:26
@@ -27,6 +27,7 @@
#include ifscompose.h
+
enum {
TOKEN_INVALID = G_TOKEN_LAST,
TOKEN_ITERATIONS,
@@ -422,8 +423,9 @@
scanner-input_name = IfsCompose Saved Data;
for (i = 0; i nsymbols; i++)
-g_scanner_add_symbol (scanner,
- symbols[i].name, GINT_TO_POINTER (symbols[i].token));
+g_scanner_scope_add_symbol (scanner, 0,
+symbols[i].name,
+GINT_TO_POINTER (symbols[i].token));
g_scanner_input_text (scanner, str, strlen (str));
@@ -450,51 +452,51 @@
gint i;
GString *result = g_string_new (NULL);
- g_string_printfa (result, iterations %d\n, vals-iterations);
- g_string_printfa (result, max_memory %d\n, vals-max_memory);
- g_string_printfa (result, subdivide %d\n, vals-subdivide);
- g_string_printfa (result, radius %f\n, vals-radius);
- g_string_printfa (result, aspect_ratio %f\n, vals-aspect_ratio);
- g_string_printfa (result, center_x %f\n, vals-center_x);
- g_string_printfa (result, center_y %f\n, vals-center_y);
+ g_string_append_printf (result, iterations %d\n, vals-iterations);
+ g_string_append_printf (result, max_memory %d\n, vals-max_memory);
+ g_string_append_printf (result, subdivide %d\n, vals-subdivide);
+ g_string_append_printf (result, radius %f\n, vals-radius);
+ g_string_append_printf (result, aspect_ratio %f\n, vals-aspect_ratio);
+ g_string_append_printf (result, center_x %f\n, vals-center_x);
+ g_string_append_printf (result, center_y %f\n, vals-center_y);
for (i=0; ivals-num_elements; i++)
{
g_string_append (result, element {\n);
- g_string_printfa (result, x %f\n, elements[i]-v.x);
- g_string_printfa (result, y %f\n, elements[i]-v.y);
- g_string_printfa (result, theta %f\n, elements[i]-v.theta);
- g_string_printfa (result, scale %f\n, elements[i]-v.scale);
- g_string_printfa (result, asym %f\n, elements[i]-v.asym);
- g_string_printfa (result, shear %f\n, elements[i]-v.shear);
- g_string_printfa (result, flip %d\n, elements[i]-v.flip);
- g_string_printfa (result, red_color { %f,%f,%f }\n,
-elements[i]-v.red_color.r,
-elements[i]-v.red_color.g,
-elements[i]-v.red_color.b);
- g_string_printfa (result, green_color { %f,%f,%f }\n,
-elements[i]-v.green_color.r,
-elements[i]-v.green_color.g,
-elements[i]-v.green_color.b);
- g_string_printfa (result, blue_color { %f,%f,%f }\n,
-elements[i]-v.blue_color.r,
-elements[i]-v.blue_color.g,
-elements[i]-v.blue_color.b);
- g_string_printfa (result, black_color { %f,%f,%f }\n,
-elements[i]-v.black_color.r,
-elements[i]-v.black_color.g,
-elements[i]-v.black_color.b);
- g_string_printfa (result, target_color { %f,%f,%f }\n,
-elements[i]-v.target_color.r,
-
[Gimp-developer] test
Testing -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: GIMP Tip of the Day messages
Hi, Christian Rose [EMAIL PROTECTED] writes: Hmm, would it be possible to make GIMP tips translatable in a po file in the future? That would probably ease translation, since gettext has some nice features: it's easy to compare the original message and the translation, easy to spot messages that changed or new messages, and so on. The messages could be put in a header file, or an XML file of some sort (if you use intltool/xml-i18n-tools). If it's too much to put in gimp.pot, it could be a translation catalog of its own. What do you think? I'm all for it. I have already considered doing such a change in gimp HEAD. I'd favor a separate translation domain for the tips since we could avoid to bind to this domain until the tips dialog is actually shown. A header file with static strings should probably do the trick most easily or do you think an XML file would give any advantages? Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: GIMP Tip of the Day messages
Sven Neumann wrote: Hmm, would it be possible to make GIMP tips translatable in a po file in the future? That would probably ease translation, since gettext has some nice features: it's easy to compare the original message and the translation, easy to spot messages that changed or new messages, and so on. The messages could be put in a header file, or an XML file of some sort (if you use intltool/xml-i18n-tools). If it's too much to put in gimp.pot, it could be a translation catalog of its own. What do you think? I'm all for it. I have already considered doing such a change in gimp HEAD. I'd favor a separate translation domain for the tips since we could avoid to bind to this domain until the tips dialog is actually shown. A header file with static strings should probably do the trick most easily or do you think an XML file would give any advantages? No, as you say, a header file is probably the easiest solution, there is probably no need for XML as there are no attributes etc. Thanks for looking into this! Christian ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GIMP Tip of the Day messages
it would matter if you could name an advantage it would give us. I don't mind adding a simple XML-parser to GIMP-1.4 since it's pretty simple using GMarkup from GLib-2.0, but I don't want to do so without a good reason. hmm.. XML could be quickly converted to HTML and used on the web site as a something-or-other? (actually it doesn't matter to me, I am just being silly) Could these tip dialogs providee click to link thingies to hand people over to GIMP help? Just wodnering if that might be useful in planning for the future. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GIMP Tip of the Day messages
Hi Rebecca, [EMAIL PROTECTED] (2001-10-05 at 2030.20 +0200): it would matter if you could name an advantage it would give us. I don't mind adding a simple XML-parser to GIMP-1.4 since it's pretty simple using GMarkup from GLib-2.0, but I don't want to do so without a good reason. hmm.. XML could be quickly converted to HTML and used on the web site as a something-or-other? XML is supposed to make information more portable into the future, right? GIMP is being used in classrooms lately, it would be nice if we have the option to print all gimp documentation in any form we should choose. carol ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] GIMP Translations
Hi. Does it bother anyone else that GIMP translations are being handled by Gnome? I sort of enjoyed the whining when it was being handled by GIMP people. carol ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Scanner Epson FS200 negs wrong pixel line SUGGESTIONS
On 5 Oct 2001, at 19:56, Steinar H. Gunderson wrote: On Tue, Oct 02, 2001 at 09:56:08AM +0200, Javier Hernandez wrote: The question: Have gimp some special feature so that if I am able to identify the pixel line (supposing it is always at the same position) I could apply a script to correct the pixel line ? Well, if it's _always_ in the same position, could I recommend creating a selection based on that pixel information, rotating the image, selecting a small selection around it and doing deinterlace? Should be quite easy to script with Gimp-Perl, given that it's exactly in the same spot. Couldn't Resynthesize help here? -- branko collin [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: GIMP Tip of the Day messages
Hello again Rebecca, [EMAIL PROTECTED] (2001-10-05 at 2147.11 +0200): XML is supposed to make information more portable into the future, right? GIMP is being used in classrooms lately, it would be nice if we have the option to print all gimp documentation in any form we should choose. I'm not as familiar with XML conversion tools as I am with SGML, but I think they exist. It is like the GIMP help. We write the help in Doc Book SGML. It can be converted to cool stuff including PDF. Pippin has been writing our SGML to PDF converter. It can also be converted to HTML. (Which is what gets done before it goes into the release right now anyway) Okay, everything I know about XML I learned by osmosis (ie, i slept with XML in a Nutshell under my pillow), but XML seems to make sense and be a lot less rigid than SGML. Also, XML is mentioned in this document: http://developer.gimp.org/gimp-future (Sorry if the line wrapping is messed up. Evo is misbehaving) Try mutt! I love it. I will send you my config files if you like ... carol ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP Translations
Am Fre, 2001-10-05 um 21.40 schrieb 1002310814: Does it bother anyone else that GIMP translations are being handled by Gnome? I sort of enjoyed the whining when it was being handled by GIMP people. Huh? How do you mean? I really don't care who translates our messages as long as the GIMP people have the decision on the project. -- Servus, Daniel ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GIMP Tip of the Day messages
Am Fre, 2001-10-05 um 21.47 schrieb 1002311231: It is like the GIMP help. We write the help in DocBook SGML. It is SGML right now but is written with XML compatibility in mind so we would simply need to flip a switch (in every file that is) to have full XML. It can be converted to cool stuff including PDF. Pippin has been writing our SGML to PDF converter. If you don't mind to be corrected here: I wrote the SGML-TeX converter which is used for the PDF output by feeding the intermediate .tex file into pdflatex. pippin helped me with his TeX and layouting skills to make the output much better. -- Servus, Daniel ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GIMP Tip of the Day messages
Am Die, 2001-10-02 um 19.14 schrieb 1002042874: No, as you say, a header file is probably the easiest solution, Actually if there was an XML parser this would be the simplest solution. It is just that we'd need a parser and I haven't evaluated the GMarkup part of the new glib yet. there is probably no need for XML as there are no attributes etc. If you use XML for texts like tips or dialogparts then attributes are being used for specifying the language the text is in. A tip might look like this: tip lang=deNiemals GIMP schließen/tip tip lang=enNever close the GIMP/tip DIA for instance uses something alike to implement modular extensions to the graph set. It's a lot more versatile then the header approach with my lovely friend gettext since the information is not spread over several files which need to be generated, compiled and installed. If we had more tips we could even categorize them. Actually using XML would also solve a part of the how do we localise plugins that are not part of the distribution problem and might lead to a leaner core distribution and an intelligent repository which is a really cool thing. Back when we implemented the first round of the now active stuff this techniques were not available for consideration and thus we ended with the kludgy solution. -- Servus, Daniel ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GIMP Tip of the Day messages
Daniel Egger wrote: No, as you say, a header file is probably the easiest solution, Actually if there was an XML parser this would be the simplest solution. It is just that we'd need a parser and I haven't evaluated the GMarkup part of the new glib yet. Ok. there is probably no need for XML as there are no attributes etc. If you use XML for texts like tips or dialogparts then attributes are being used for specifying the language the text is in. A tip might look like this: tip lang=deNiemals GIMP schließen/tip tip lang=enNever close the GIMP/tip If you use a single file, that is true, yes. DIA for instance uses something alike to implement modular extensions to the graph set. It's a lot more versatile then the header approach with my lovely friend gettext since the information is not spread over several files which need to be generated, compiled and installed. If we had more tips we could even categorize them. I agree about the advantage over several files, but even a single Gimp Tips XML file would have to be generated (with translations from the PO files), probably with the help of intltool. But a single generated file is probably better than a whole lot of them, yes. Actually using XML would also solve a part of the how do we localise plugins that are not part of the distribution problem and might lead to a leaner core distribution and an intelligent repository which is a really cool thing. Back when we implemented the first round of the now active stuff this techniques were not available for consideration and thus we ended with the kludgy solution. Ok. Christian ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: patch for gimp/po/fr.po
On 02 Oct 2001 16:44:18 -0500, Federico Mena Quintero [EMAIL PROTECTED] said: It is physically impossible to synchronize clocks. Sounds like a fundamental problem with the design of the universe. Indeed. We should return the universe for a refund. Kelly ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Adaptive Contrast Enhancement
I added a new version of Adaptive Contrast Enhancement to the plugin registry because Kevin doesn't support it anymore. The gtk part is not perfect, so could anyone help to improve this part? Martin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
