Re: gradients and pre-multiplied alpha
Nick Lamb [EMAIL PROTECTED] writes: Probably some UI improvements needed in the gradient editor then, other packages I've seen use a separate edit bar for alpha. I would not advocate such a change to Gimp, but it is at least inspiration. The gradient editor's user interface sucks harder than a realdoll plugged to a pneumatic pile driver set on reverse. Whoever wrote it should be put in a mental institution. Oh, wait. That would be me. Anyways, it is due for a rewrite. The code sucks. It was my first GTK+ application :-) I would be very happy to take suggestions for a better user interface. And yes, the blend tool should do the right thing with alpha values, i.e. premultiply them before compositing them in. I'll submit a patch for it in the afternoon. Federico
Re: gradients and pre-multiplied alpha
Federico Mena Quintero wrote: And yes, the blend tool should do the right thing with alpha values, i.e. premultiply them before compositing them in. I'll submit a patch for it in the afternoon. rant_and_rave I don't think this episode uncovered an alpha-related bug, so what needs to be fixed? Mr. Turner's example (unwittingly, perhaps) specified two different gradients (in the unmultiplied color space). And two different results were obtained. What went wrong? *Should* the gradient tool work in the premultiplied space, while GIMP mostly functions in the unmultiplied one? Won't this give users different alpha characteristics in different places? Won't they be better served with a consistent alpha channel behavior of the unmultiplied space in *most* places? Especially since - for better or worse - the rendering pipeline functions with unmultiplied alpha only? The gaussean blur HAS to pull premultiplied tricks. No surprises there either, for just as Mr. Lamb observed with premultiplied alpha, the unmultiplied space is no cure for the blues either. They happen to be two (mutually exclusive) conventions that can be applied to the alpha channel, and one has a Real Slick compositing algorithm associated with it, blessed by the Computer Graphics Gurus. In light of this, then, I think we should be very careful in preserving a consistent behavior when it come to how the alpha channel behaves, and warn users when inconsistencies (invariably) arise. /rant_and_rave Be good, be well. Garry
IScissors patch.
Does anyone find iscissors useful? Does it do what you would
like or expect? If not, then you may want to test this patch for me.
Since ISCISSORS is currently a bug, help fix it.
This patch adds the livewire path to iscissors. Now you can
see where the actual line is going to end up. There are still a few
bugs and some memory leaks that should be worked out soon, but I am
interested in a complete rewrite.
There are a few issues with a rewrite of iscissors. In order
to be effective I need to know how to do the following:
1. Allocate a buffer the same size as the (x,y) of the visible portion
of the image. This buffer will be destroyed when the tool is closed
or the image changes.
2. Allocate a task to compute values in the background so that the
mouse can still be moved while the computation takes place.
#2 is the hard part. I can do #1 with the current tile system.
Are there any capabilities in the gimp to allow #2? If not, then
iscissors probably won't get much better than this patch.
(ok, a little, but it can't keep up when running on a i586 233 MMX over a
10 MBit network connection to the xserver--my test setup ).
Anyway, try it out, tell me if you like it. I may become motivated to
finish it then...
Laramie
--- iscissors.old Fri Sep 15 18:51:04 2000
+++ iscissors.c Fri Sep 15 19:59:43 2000
@@ -30,6 +30,10 @@
* The 0.54 version of the algorithm was then forwards ported to 1.1.4
* by Austin Donnelly. */
+/* Modifications to implement the livewire boundary were done in version
+ * gimp 1.1.25 by Laramie Leavitt */
+
+
#include "config.h"
#include stdlib.h
@@ -89,8 +93,10 @@
DRAW_NOTHING = 0x0,
DRAW_CURRENT_SEED = 0x1,
DRAW_CURVE= 0x2,
- DRAW_ACTIVE_CURVE = 0x4
+ DRAW_ACTIVE_CURVE = 0x4,
+ DRAW_LIVEWIRE = 0x8
} Iscissors_draw;
+
#define DRAW_ALL (DRAW_CURRENT_SEED | DRAW_CURVE)
typedef struct _iscissors Iscissors;
@@ -107,6 +113,8 @@
TempBuf*dp_buf; /* dynamic programming buffer */
+ ICurve *livewire;
+
ICurve *curve1; /* 1st curve connected to current point*/
ICurve *curve2; /* 2nd curve connected to current point*/
@@ -121,6 +129,8 @@
/* XXX might be useful */
Channel*mask; /* selection mask */
TileManager*gradient_map; /* lazily filled gradient map */
+ TileManager*cost_map; /* lazily filled in cost map */
+
};
typedef struct _IScissorsOptions IScissorsOptions;
@@ -136,22 +146,35 @@
/* Other defines... */
#define MAX_GRADIENT 179.606 /* == sqrt(127^2 + 127^2) */
+
#define GRADIENT_SEARCH 32 /* how far to look when snapping to an edge */
+#define GRADIENT_RADIUS (GRADIENT_SEARCH 1)
+
#define TARGET_HEIGHT 25
#define TARGET_WIDTH 25
+
#define POINT_WIDTH 8 /* size (in pixels) of seed handles */
#define POINT_HALFWIDTH (POINT_WIDTH / 2)
+
#define EXTEND_BY 0.2 /* proportion to expand cost map by */
#define FIXED 5 /* additional fixed size to expand cost map */
#define MIN_GRADIENT 63 /* gradients this are directionless */
#define MAX_POINTS2048
+#define POS_GRADIENT 0
+#define POS_COST 1
+#define POS_DIR 2
+#define POS_LAPLACE 3
+
#ifdef USE_LAPLACIAN
-# define COST_WIDTH3 /* number of bytes for each pixel in cost map */
+# define TOTAL_COST_WIDTH 4
#else
-# define COST_WIDTH2 /* number of bytes for each pixel in cost map */
+# define TOTAL_COST_WIDTH 3
#endif
+
+#define TILE_LAYER( tile, layer ) ((tile_ewidth(tile)*tile_eheight(tile))*layer)
+
#define BLOCK_WIDTH 64
#define BLOCK_HEIGHT 64
#define CONV_WIDTH(BLOCK_WIDTH + 2)
@@ -174,7 +197,6 @@
#define PIXEL_COST(x) (x 8)
#define PIXEL_DIR(x) (x 0x00ff)
-
/* static variables */
/* where to move on a given link direction */
@@ -212,7 +234,15 @@
D(static guint sent2 = 0xd2d2d2d2);
static guchar maxgrad_conv2 [TILE_WIDTH * TILE_HEIGHT * 4] = "";
D(static guint sent3 = 0xd3d3d3d3);
+static guchar costgrad_conv0 [TILE_WIDTH * TILE_HEIGHT * 4] = "";
+D(static guint sent1 = 0xd4d4d4d4);
+static guchar costgrad_conv1 [TILE_WIDTH * TILE_HEIGHT * 4] = "";
+D(static guint sent2 = 0xd5d5d5d5);
+#ifdef USE_LAPLACIAN
+static guchar costgrad_conv2 [TILE_WIDTH * TILE_HEIGHT * 4] = "";
+D(static guint sent2 = 0xd6d6d6d6);
+#endif
static gint horz_deriv [9] =
{
@@ -228,6 +258,12 @@
-1, -2, -1,
};
+static gint blur_32 [9] =
+{
+ 1, 1, 1,
+ 1, 24, 1,
+ 1, 1, 1,
+};
#ifdef USE_LAPLACIAN
static gint laplacian [9] =
@@ -238,13 +274,7 @@
};
#endif
-static gint blur_32 [9] =
-{
- 1, 1, 1,
- 1, 24, 1,
- 1, 1, 1,
-};
-
+static gboolean
Re: gradients and pre-multiplied alpha
On Sun, Sep 17, 2000 at 06:33:09PM +0100, Nick Lamb [EMAIL PROTECTED] wrote: Pre-multiplying is a performance hack only, please don't let people think of it as something that will cure "black fringes" -- it won't. If at all, it will only create even more visual artifacts due to greatly reduced colour resolution for nearly-transparent pixels. The point of not using premultiplied alpha is freedom to change and edit your images, similar to providing 12, 16 or more bits per colour component. Using 8 bits (or using premulitplied alpha) is simply a performance issue, NOTHING else. (Sorry, Nick, when I just re-iterated your point, but I had to provide a strong "me too" ;-) -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: gradients and pre-multiplied alpha
On Mon, Sep 18, 2000 at 05:24:20PM -0400, Garry R. Osgood wrote: Nick Lamb wrote: Pre-multiplying is a performance hack only, please don't let people think of it as something that will cure "black fringes" -- it won't. Perhaps that wasn't your intention, but in any case... Perhaps a later Gimp will know how to consume premultiplied alpha (you'll have to throw some switches) the 1.x Gimps of the next two years or so won't know how to do it. This is exactly what I was worried about -- Gimp already DOES convert premultiplied alpha from the one source I'm sure uses it, TIFF. It is trivial (though perhaps sometimes costly) to convert TIFFs during loading so we (almost) always do. Support _internally_ in Gimp (which you're proposing for 2.0) is orthogonal to loading external data correctly. If someone finds me an MS internal document dictating that BMP uses pre-multiplied alpha I'll add the conversion functions in days -- to the BMP loader. For undisciplined formats a load-time option is not a sensible way to go, we'll probably have to provide a plug-in which does the conversion and include help that explains what it's for / how to use it to handle either case, some heuristics in the plug-in can help. I'm not willing to write such a plug-in not only because I'm already too busy, but because I think the film/ rendering communities brought this on themselves. I've seen too much evidence that says they don't care about standards, or interoperability. Nick.
