Re: idea: "tighten" current selection
On Tuesday, 5 Dec 2000, David Bonnell wrote:
> On Wed, 6 Dec 2000, Austin Donnelly wrote:
>
> > ...
> > Probably the easiest way would be to use select by colour, but that
> > would catch other stuff that was a similar colour.
> >
> Could change "Select by Colour" to only select pixels within the current
> selection if there is one, or the entire image (or layer) if there
> isn't an active selection.
>
> > With this, you could lasso the general area the text is in, then go
> > /Selection/Tighten to get just your text.
> >
> That would certainly be a very useful tool.
Oops. I accidentally implemented it.
Patch against 1.1.29 attached below.
It needs some work:
o The algorithm to find the start point for the seed fill is pretty
dumb: it picks the topmost image pixel in the selection, and flood
fills from there. Plus its a really inefficient implementation of
this brain dead algorithm.
o No PDB access functions.
o No help file.
o No way to tweak edge detection threshold
o No way to set sample merged, so it only works on the current layer
(These last two are because it has no UI. I don't think it should
have a UI since it's supposed to be quick and just do the right
thing. Mostly it does.)
If anyone feels like playing with it, let me know how you get on.
I think it's pretty cool (but then I'm biased).
Austin
--- commands.c~ Mon Oct 30 01:33:11 2000
+++ commands.c Wed Dec 6 17:05:24 2000
@@ -390,6 +390,19 @@
gtk_widget_show (shrink_dialog);
}
+
+void
+select_tighten_cmd_callback (GtkWidget *widget,
+gpointer client_data)
+{
+ GDisplay *gdisp;
+ return_if_no_display (gdisp);
+
+ gimage_mask_tighten (gdisp->gimage);
+ gdisplays_flush ();
+}
+
+
void
select_grow_cmd_callback (GtkWidget *widget,
gpointer client_data)
--- commands.h~ Mon Oct 30 01:33:11 2000
+++ commands.h Wed Dec 6 17:25:14 2000
@@ -52,6 +52,7 @@
void select_feather_cmd_callback (GtkWidget *, gpointer);
void select_sharpen_cmd_callback (GtkWidget *, gpointer);
void select_shrink_cmd_callback (GtkWidget *, gpointer);
+void select_tighten_cmd_callback (GtkWidget *, gpointer);
void select_border_cmd_callback (GtkWidget *, gpointer);
void select_grow_cmd_callback (GtkWidget *, gpointer);
void select_save_cmd_callback (GtkWidget *, gpointer);
--- gimage_mask.c~ Mon Oct 30 01:33:14 2000
+++ gimage_mask.c Wed Dec 6 18:06:40 2000
@@ -22,6 +22,7 @@
#include "floating_sel.h"
#include "gdisplay.h"
#include "gimage_mask.h"
+#include "fuzzy_select.h"
#include "gimprc.h"
#include "layer.h"
#include "paint_core.h"
@@ -478,6 +479,55 @@
edge_lock);
}
+
+void
+gimage_mask_tighten (GImage *gimage)
+{
+ Channel *mask;
+ Channel *shrinkage;
+ GimpDrawable *drawable;
+ gint x1, y1, x2, y2;
+ gint x;
+
+ g_return_if_fail (gimage != NULL);
+ drawable = gimage_active_drawable (gimage);
+ g_return_if_fail (drawable != NULL);
+
+ mask = gimage_get_mask (gimage);
+ g_return_if_fail (mask != NULL);
+
+ undo_push_group_start (gimage, MASK_UNDO);
+
+ channel_push_undo (mask);
+
+ /* if there was no selection, then assume the entire image was selected */
+ if (channel_is_empty (mask))
+ channel_all (mask);
+
+ /* Pick a point within the selection from which to start the seed
+ * fill. */
+ channel_bounds (mask, &x1, &y1, &x2, &y2);
+ x = x1;
+ /* XXX FIXME: seriously costly loop: should do pixel iteration
+ * ourselves */
+ while (x < x2 && channel_value (mask, x, y1) < 128)
+ x++;
+
+ /* XXX Need to find some way of presenting the threshold and sample
+ * merged options to the user, without getting in their way. */
+ shrinkage = find_contiguous_region (gimage, drawable,
+ /* antialias */ TRUE,
+ /* threshold */ 15,
+ x, y1,
+ /* sample merged */ 0);
+ channel_combine_mask (mask, shrinkage, SUB, 0, 0);
+ channel_delete (shrinkage);
+
+ gimage_mask_invalidate (gimage);
+
+ undo_push_group_end (gimage);
+}
+
void
gimage_mask_layer_alpha (GImage *gimage,
--- gimage_mask.h~ Mon Oct 30 01:33:14 2000
+++ gimage_mask.h Wed Dec 6 17:29:56 2000
@@ -81,6 +81,8 @@
gint shrink_pixels_y,
gboolean edge_lock);
+voidgimage_mask_tighten (GImage *gimage);
+
voidgimage_mask_layer_alpha (GImage *gimage,
Layer*layer);
--- menus.c~Mon Oct 30 01:33:22 2000
+++ menus.c Wed Dec 6 17:24:42 2000
@@ -285,6 +285,8 @@
"select/sharpen.html", NULL },
{ { N_("/Select/Shrink..."), NULL, select_shrink_cmd_callback, 0 },
"select/dialogs/shrink_selection.html", NULL },
+ { { N_("/Select/Tighten"), NUL
Re: idea: "tighten" current selection
On Wed, 6 Dec 2000, Austin Donnelly wrote: > ... > Probably the easiest way would be to use select by colour, but that > would catch other stuff that was a similar colour. > Could change "Select by Colour" to only select pixels within the current selection if there is one, or the entire image (or layer) if there isn't an active selection. > With this, you could lasso the general area the text is in, then go > /Selection/Tighten to get just your text. > That would certainly be a very useful tool. -Dave
Re: idea: "tighten" current selection
On Wed, Dec 06, 2000 at 04:10:18PM +, Austin Donnelly wrote: > B) Is there an easier or better way of doing this task? Try the Intelligent Scissors? /* Steinar */
idea: "tighten" current selection
I had an idea for a new way of modifying the current selection: tighten. The problem it solves is as follows: suppose you have some dark coloured text on a white background, and you'd like to select it. The problem is that none of the current tools allow you to do that easily. Probably the easiest way would be to use select by colour, but that would catch other stuff that was a similar colour. So my proposal is a new "tighten" operation on the current selection. What it (conceptually) does is shrink the current selection, stopping when it hits an edge in the image, until the selection shrink wraps the edges. With this, you could lasso the general area the text is in, then go /Selection/Tighten to get just your text. I think Color-It! or possibly SuperPaint on the Mac had this about 8-10 years ago. Questions: A) Does this already exist? B) Is there an easier or better way of doing this task? Obviously, you wouldn't implement it as I described above: it would probably be better to do some kind of seeded flood fill in the selection mask based on image pixel gradients. You could probably do this in a plugin too, a bit like Andy's sel2path. Anyone feel like running with this idea and coding it up? Obviously not something for 1.2, but as a plugin it has its own separate existence. I give my usual excuses about not having enough time. Austin
Re: 2-D Gradients
Shlomi; On Wed, Dec 06, 2000 at 11:21:36AM +0200, Shlomi Fish wrote: > If anybody is familiar with the Gimp's gradient editting > capabilities then he is probably familiar with the state-of-the-art > one dimensional (1-D) gradient editting. My problem is that it's > only one dimensional and does not allow you to edit a gradient in a > plane. > > Does anybody know of any methodologies and algorithms for creating a > two-dimensional gradient editting. I.e: I will be able to define > points and shapes on the plane with colors that correspond to those > handles, and then use blending methods between them, so that I'll > eventually have a gradient that spreads across the 2-D plane. > > The question is: how do I do it? > > So, if anybody can enlighten me or point to a reference or link > about it, please do. I recommend that you look at swirl.c in xscreensaver: http://www.jwz.org/xscreensaver/ It makes nice swirly patterns based on the distance/angle of each pixel from a random set of points. Shouldn't be to hard to add lines/shapes to the algorithm as there are plenty of good closest-point-on-shape algorithms out there. An editor for this sort of gradient, attached to GIMP gradients and all other GIMP goodness, would be great fun. Cheers, Tom -- -- Tom Rathborne [EMAIL PROTECTED] http://www.aceldama.com/~tomr/ -- "It's Like A Warzone, Deep Inside Of Me / When My Mind Becomes My Enemy" -- -- Praga Khan, "My Mind Is My Enemy"
Re: [PATCH] improving on i18n
On Wed, 2000-12-06 at 14:19:02, Sven Neumann wrote:
> I have discussed your patch with Mitch and it really looks safe. The
> problem we see is that most likely translators will find a lot of
> collisions and each string marked with your Q_ macro will end up being
> untranslated in all languages until translators change the po-files
> (...)
Thanks tor this! It should be no problem for translators - I have another
patch, that doesn't _require_ modified translations. If you replace
_("File") with Q_("!menu!File") in your code, old translations (containing
only "File") will still work. I'll send improved patch tomorrow.
> I'd still prefer a clean solution that would give every translator the
> chance to apply different translations for every string without the need
> to change the original string. This would make it possible to work around
> (...)
So do I :-)
Believe me, I _hate_ gettext, but it's the only thing we have _now_.
Zbigniew
Re: [PATCH] improving on i18n
Zbigniew Chyla <[EMAIL PROTECTED]> writes: > This patch _fixes_ GIMP translations. Currently it's _impossible_ to > correctly translate GIMP to any slavic language (and probably many others). > Polish GIMP users keep saying "Can you speak Polish? Translation is broken!" > and the only thing we can say is "Sorry, it's developers' fault, but please > wait another 1-2 years for GIMP 1.4/2.0 release and hopefully it will be > useable". > Patch is extremely simple, it doesn't touch existing code at all. Why don't > you like it? I have discussed your patch with Mitch and it really looks safe. The problem we see is that most likely translators will find a lot of collisions and each string marked with your Q_ macro will end up being untranslated in all languages until translators change the po-files again. Since we want to release 1.2.0 real soon now this change would significantly degrade the status of i18n we have reached so far. I suggest we reconsider applying your patch after 1.2.0 so it could become part of the 1.2.x series but early enough before a release to give translators a chance to update translations. To do so we'd need a list of colliding strings from all translators as soon as possible. I'd still prefer a clean solution that would give every translator the chance to apply different translations for every string without the need to change the original string. This would make it possible to work around collisions without breaking the translation for all other supported languages. Salut, Sven
