Re: Feature Request: Layer Export
On Wed, Apr 12, 2000 at 11:28:44AM -0400, "Christopher W. Curtis" [EMAIL PROTECTED] wrote: don't want to give them a non-flexible image. I realize that I can do this already, but I thought it would be a nice feature (that seems like it would be easy to implement) if you could right-click on a layer in After 1.2 it will hopefully be possible to attach plug-ins to the Layers menu. It would then be trivial to add such a plug-in. Of course, it might quickly become a core feature then ;) -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Feature Request: Layer Export
On Wed, Apr 12, 2000 at 11:16:29PM +0200, Mattias Engdegård wrote: But there seems to be no way to do it from a script. I had to resort to duplicating the entire image and delete the unwanted layers, which seemed slightly wasteful. I don't understand, scripts are supposed to ALWAYS work this way, and you say that there's no way to do it? If you save a layer from a script it should just... save that layer, unless the file format is capable of multiple layers, then you'll get all of them I think. Nick.
Re: Feature Request: Layer Export
But there seems to be no way to do it from a script. I had to resort to duplicating the entire image and delete the unwanted layers, which seemed slightly wasteful. I don't understand, scripts are supposed to ALWAYS work this way, and you say that there's no way to do it? If you save a layer from a script it should just... save that layer, unless the file format is capable of multiple layers, then you'll get all of them I think. Perhaps some of the file plug-ins are buggy. I get the complaint: ERROR: Procedural database execution failed on invalid input arguments: (gimp_file_save 1 0 4 "zoop.xpm" "zoop.xpm") and nothing was saved. (Running in interactive mode works.) TGA and XCF works. PNG tells me "can't save image with alpha". Weird.
Re: Feature Request: Layer Export
Sven Neumann wrote: I'm using the GIMP (1.1.17; debian unstable) to create some mockups for our prepress guys. They want to use some of the things I've done, but I don't want to give them a non-flexible image. I realize that I can do this already, but I thought it would be a nice feature (that seems like it would be easy to implement) if you could right-click on a layer in the layerschannels dialog and export it to a file. You can already do this. Simply save your image and "Ignore" the export step. All fileformats that only handle a single layer silently only save that single layer. Yes, that is what I realized, and it would work for me. However, I think it's an artificial limitation and has two drawbacks: First, it is non-obvious, if not outright confusing; Second, formats that _do_ support layers (most notably Photoshop) will defeat this. Dragging the layer to the toolbox works very well. I highly recommend making this a tip if it is not already. It just seemed most intuitive to me to have an export option available at the lc menus. This is where I first looked and thus I would think that's the best place to put it. =) It also seemed easy enough. If you folks think not to do because of the drag-n-drop feature, that's fine, but it should definately be a tip. regards, Christopher
Re: Feature Request: Layer Export
TGA and XCF both have INDEXED modes, so you can save TGA or XCF from
an INDEXED image, you *should* be able to save INDEXED PNGs with an
alpha channel, but I only recently checked in the functionality to
do that, and doubtless you have an older version of Gimp.
This is 1.1.19. From png.c:
case INDEXEDA_IMAGE :
g_message (_("Can't save image with alpha\n"));
return 0;
break;
I won't fix that right away (maybe later, if I have time).
XPM doesn't have an INDEXED mode at all -- how then should Gimp save
your XPM? Since you're a developer, not just a humble end user, it
is expected that you'll take care of that sort of thing yourself.
Sorry, I didn't mean to whine (I was determined to fix it myself but all
sorts of things cropped up). XPM is by definition an indexed image format,
though it allows for colormaps large enough for saving RGB images.
It was a surviving bug in the XPM plugin (got the argument count wrong).
I also changed the threshold from a 0..1 double to a 0..255 int, for
consistency with threshold_alpha. I found one curious line, xpm.c:170:
"saves files in the xpm file format (if you're on a 16 bit display...)",
However, a cursory glance revealed nothing supporting this warning. Perhaps
it was true in an earlier revision? Then we should change it.
One problem with gimp-file-save is that for file plug-ins that need extra
args, it simply passes zeroes (or empty strings). If this is the default,
all is well, but not in this case (XPM). I have no quick solution.
--- xpm.c~ Tue Mar 28 11:55:07 2000
+++ xpm.c Thu Apr 13 03:08:55 2000
@@ -53,7 +53,7 @@
/* Structs for the save dialog */
typedef struct
{
- gdouble threshold;
+ gint threshold;
} XpmSaveVals;
typedef struct
@@ -113,7 +113,7 @@
static XpmSaveVals xpmvals =
{
- 0.50 /* alpha threshold */
+ 127 /* alpha threshold */
};
static XpmSaveInterface xpmint =
@@ -148,6 +148,7 @@
{ PARAM_DRAWABLE, "drawable", "Drawable to save" },
{ PARAM_STRING, "filename", "The name of the file to save the image in" },
{ PARAM_STRING, "raw_filename", "The name of the file to save the image in" },
+{ PARAM_INT32,"threshold", "Alpha threshold (0-255)" }
};
static gint nsave_args = sizeof (save_args) / sizeof (save_args[0]);
@@ -267,16 +268,16 @@
case RUN_NONINTERACTIVE:
/* Make sure all the arguments are there! */
- if (nparams != 4)
+ if (nparams != 6)
{
status = STATUS_CALLING_ERROR;
}
else
{
- xpmvals.threshold = param[4].data.d_float;
+ xpmvals.threshold = param[5].data.d_int32;
- if (xpmvals.threshold 0.0 ||
- xpmvals.threshold 1.0)
+ if (xpmvals.threshold 0 ||
+ xpmvals.threshold 255)
status = STATUS_CALLING_ERROR;
}
break;
@@ -570,7 +571,7 @@
GHashTable *hash = NULL;
gint i, j, k;
- gint threshold = 255 * xpmvals.threshold;
+ gint threshold = xpmvals.threshold;
gint rc = FALSE;
@@ -824,11 +825,12 @@
scale_data = gimp_scale_entry_new (GTK_TABLE (table), 0, 0,
_("Alpha Threshold:"), SCALE_WIDTH, 0,
-xpmvals.threshold, 0.0, 1.0, 0.01, 0.1, 2,
+xpmvals.threshold, 0, 255, 1, 8, 0,
TRUE, 0, 0,
NULL, NULL);
+
gtk_signal_connect (GTK_OBJECT (scale_data), "value_changed",
- GTK_SIGNAL_FUNC (gimp_double_adjustment_update),
+ GTK_SIGNAL_FUNC (gimp_int_adjustment_update),
xpmvals.threshold);
gtk_widget_show (dlg);
Re: Feature Request: Layer Export
TGA and XCF both have INDEXED modes, so you can save TGA or XCF from an INDEXED image, you *should* be able to save INDEXED PNGs with an alpha channel, but I only recently checked in the functionality to do that, and doubtless you have an older version of Gimp. Sorry for my earlier message; I misread your mail and didn't see that you had already fixed it. Thanks! -- Mattias
Re: Feature Request: Layer Export
On Thu, Apr 13, 2000 at 03:40:49AM +0200, Mattias Engdegård wrote: I won't fix that right away (maybe later, if I have time). No need, like I said, I only recently checked in the change -- days ago in fact, after 1.1.19 was released. Just wait for 1.1.20, or get the current CVS Gimp, or if you really need INDEXED+A PNG right away, contact me and I can mail it to you. Sorry, I didn't mean to whine (I was determined to fix it myself but all sorts of things cropped up). XPM is by definition an indexed image format, though it allows for colormaps large enough for saving RGB images. Doh, I was thinking from the POV of the Gimp loader (it's always loaded as RGB regardless of how it was saved), not from the POV of the Save plug-ins. "saves files in the xpm file format (if you're on a 16 bit display...)", However, a cursory glance revealed nothing supporting this warning. Perhaps it was true in an earlier revision? Then we should change it. Some Gimp plug-ins are derived from various unrelated sources, like the netpbm filters, scraggy bits of code hanging around in CS dumpsters and the like. This probably puts them on shaky legal ground and definitely means they have some weird comments in. XPM could well be one of them. Nick.
