Re: TGA plug-in patch
On Tue, Sep 12, 2000 at 01:53:54AM +0100, Nick Lamb <[EMAIL PROTECTED]> wrote: > On Mon, Sep 11, 2000 at 03:38:29PM +0200, Marc Lehmann wrote: > > Ah! ;) Still gimp would not support uncommon errors by giving the user more > > freedom. > > Fine, I'll put the "PC vs Mac" option back into Gimp's TIFF filter and > mail you all the confused whining from users. :) I don't understand your whining reaction... you rally do not want the patch (for some reason nobody understands), so let's just cut this thread here... > Unfortunately what they come down to is that you can choose to make PS4 > do a lot worse than Gimp, or nearly as good. Since Gimp is already as > good as Gimp, having options to make it worse seems pointless, no? Could you point out the logic that supposedly was used to construct the above sentences? O yes, you are right, Gimp is always as good as Gimp, so there is no need to make it better, yes? -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: TGA plug-in patch
Including a nine yard long list of options in every dialog is bad. But let us not forget that we have a rich legacy of Unix heritage to uphold. What that means to me is giving the power user the option of taking enough power to burn out every synapse in her body, if she so desires... just don't make it *too* easy for her to get at it. The PDB is a terrific junk heap of an interface. If you want to provide some obscure options, I think that's the place to do it. Anyone weird enough to want them can homebrew (and/or distribute) a script to use what's there. And the rest of us, who see in the red-to-violet spectrum, have no more than two eyes per head, and have deep-seated notions about which way is "up", will keep control of the mainstream interface for our own selfish desires. This message has been sponsored in part by the "Software for Terrans" campaign, Keeping Free Software Free -- for Humans. -- Kevin Turner <[EMAIL PROTECTED]> | OpenPGP encryption welcome here Plug-ins: They make GIMP do stuff. http://gimp-plug-ins.sourceforge.net/ This list is archived at http://marc.theaimsgroup.com/?l=gimp-developer To unsubscribe, mail [EMAIL PROTECTED]
Re: TGA plug-in patch
On Mon, Sep 11, 2000 at 03:38:29PM +0200, Marc Lehmann wrote: > Ah! ;) Still gimp would not support uncommon errors by giving the user more > freedom. Allowing users to needlessly create bizarre image files that will then cause them trouble in other packages is just _asking_ for trouble. > This is windows thinking a lot. Not implementing something because it is > costing a lot of time would be understandable, but not offering features > because the user might be too dumb is never a good idea (IMHO). Fine, I'll put the "PC vs Mac" option back into Gimp's TIFF filter and mail you all the confused whining from users. :) > > working image app... I want to have a genuine REASON to add any > > options like this before I risk confusing users further. > > Well, we could also always write png's with compression=9, for example, as > the resulting image is the same in all cases ;) What an appropriate choice. Check out PS 4.0 and see what the equivalent dialog says there. There sure are a lot more options in the compression section. An Adobe engineer probably spent a few hours on that dialog. Unfortunately what they come down to is that you can choose to make PS4 do a lot worse than Gimp, or nearly as good. Since Gimp is already as good as Gimp, having options to make it worse seems pointless, no? Photoshop 5.0 abandons the unnecessary extra options AFAIK. Still, your point is taken, some behaviour that's not directly visible to the user needs to be reflected in the options. I agree, but it's not universally true that more options is good. > > Still, a good reason may be forthcoming and if it is I'll happily > > integrate this patch or one like it. > > A very good reason _not_ to is that it might be pretty unimportant, so > coding these features might be a waste of time... Some options do not appear to buy anything except additional code complexity. I differ with Marc here, I don't mind coding it, but I do object to untested code paths. I'm not going to write a test suite to check the umpty-zillion possible alternatives if we try all the options. So even though this TGA patch is "free", I still don't expect to apply it without a good reason. Nick.
Re: TGA plug-in patch
On Mon, Sep 11, 2000 at 07:33:24PM +0200, Marc Lehmann wrote: >This is a wonderful case for "he who needs it sends a patch2 ;) *ahem* I thought the initial message _did_ have a patch included? /* Steinar */ -- Homepage: http://members.xoom.com/sneeze/
Re: TGA plug-in patch
[EMAIL PROTECTED] (2000-09-11 at 1933.24 +0200): > > is a bug, a new release would be cool anyway). But I would like to see > > the options in future versions. > This is a wonderful case for "he who needs it sends a patch2 ;) He send them first. ;] GSR
Re: TGA plug-in patch
On Mon, Sep 11, 2000 at 04:33:13PM +0200, "Guillermo S. Romero / Familia Romero" <[EMAIL PROTECTED]> wrote: > can not be a bug (varies with personal opinion, and even if you say it > is a bug, a new release would be cool anyway). But I would like to see > the options in future versions. This is a wonderful case for "he who needs it sends a patch2 ;) -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: TGA plug-in patch
[EMAIL PROTECTED] (2000-09-11 at 1538.29 +0200): > > wacky things you legally _can_ write to a TGA file, I am offering the > > opinion that we should generally shield users from the dozens of valid > > yet unimportant TGA options, and set them for our convenience, as we > > do with TIFF. > This is windows thinking a lot. Not implementing something because it is > costing a lot of time would be understandable, but not offering features > because the user might be too dumb is never a good idea (IMHO). Specially for those of use that like Unix tools cos they allow more things than other tools. If the user is Window style he knows what to do: click "OK". But I preffer choice, cos sometimes it saves your day in a few seconds. I want to open / save everything, and leave headaches for other OSs. IMHO this should not implemented now, Gimp is frozen and this can or can not be a bug (varies with personal opinion, and even if you say it is a bug, a new release would be cool anyway). But I would like to see the options in future versions. GSR
Re: TGA plug-in patch
On Mon, Sep 11, 2000 at 01:15:18AM +0100, Nick Lamb <[EMAIL PROTECTED]> wrote: > > If the abovce is true and the file format indeed supports this (in the > > spec, if any), then this is not an "error" but "valid but uncommon". > > Ah no, writing images to TGA with "flip-vertical" flag set is both valid > and common, almost universal in fact. But not being willing or able to > load top-down images like Gimps would be an uncommon error, Ah! ;) Still gimp would not support uncommon errors by giving the user more freedom. > wacky things you legally _can_ write to a TGA file, I am offering the > opinion that we should generally shield users from the dozens of valid > yet unimportant TGA options, and set them for our convenience, as we > do with TIFF. This is windows thinking a lot. Not implementing something because it is costing a lot of time would be understandable, but not offering features because the user might be too dumb is never a good idea (IMHO). > [x] Top-left start [ ] Top-right start [ ] Bottom-right start [ ] ... > [x] R-G-B [ ] B-R-G [ ] R-B-G [ ] B-R-A-G Make sa lot of sense to me. TGA images are a common format for programs that have special requirements (like a special layout). > [ ] Mysteriously allocate but don't use colourmap > [ ] Make alternate scanlines inverted for some reason > [ ] Write four channels, but then only use three These are of a something different quality, though. > working image app... I want to have a genuine REASON to add any > options like this before I risk confusing users further. Well, we could also always write png's with compression=9, for example, as the resulting image is the same in all cases ;) > Still, a good reason may be forthcoming and if it is I'll happily > integrate this patch or one like it. A very good reason _not_ to is that it might be pretty unimportant, so coding these features might be a waste of time... -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: TGA plug-in patch
On Mon, Sep 11, 2000 at 01:17:25AM +0200, Marc Lehmann wrote: > On Sun, Sep 10, 2000 at 07:16:22PM +0100, Nick Lamb <[EMAIL PROTECTED]> wrote: > > > strange to do, it is a supported feature of the file format and OpenGL > > > > apply the patch and (b) I don't think Gimp should offer too many > > features that work around uncommon errors in other systems at a cost of > > If the abovce is true and the file format indeed supports this (in the > spec, if any), then this is not an "error" but "valid but uncommon". Ah no, writing images to TGA with "flip-vertical" flag set is both valid and common, almost universal in fact. But not being willing or able to load top-down images like Gimps would be an uncommon error, I've never yet seen anything that can't cope. The spec, such as it is says to look at the flag and obey it -- no confusion there. The patch is for _writing_ TGA files, and like TIFF there's plenty of wacky things you legally _can_ write to a TGA file, I am offering the opinion that we should generally shield users from the dozens of valid yet unimportant TGA options, and set them for our convenience, as we do with TIFF. I don't think it makes sense to have a dialog like this: [x] Top-left start [ ] Top-right start [ ] Bottom-right start [ ] ... [x] R-G-B [ ] B-R-G [ ] R-B-G [ ] B-R-A-G [ ] Mysteriously allocate but don't use colourmap [ ] Make alternate scanlines inverted for some reason [ ] Write four channels, but then only use three Given that the image will look the same in Gimp either way, have (almost) the same file size, load and look the same in any other working image app... I want to have a genuine REASON to add any options like this before I risk confusing users further. Still, a good reason may be forthcoming and if it is I'll happily integrate this patch or one like it. Nick.
Re: TGA plug-in patch
On Sun, Sep 10, 2000 at 07:16:22PM +0100, Nick Lamb <[EMAIL PROTECTED]> wrote: > > strange to do, it is a supported feature of the file format and OpenGL > > apply the patch and (b) I don't think Gimp should offer too many > features that work around uncommon errors in other systems at a cost of If the abovce is true and the file format indeed supports this (in the spec, if any), then this is not an "error" but "valid but uncommon". -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: TGA plug-in patch
On Sat, Sep 09, 2000 at 07:45:17PM -0400, Brandon wrote: > Below is a patch to add support for saving TGA files upside down. > Although it sounds > strange to do, it is a supported feature of the file format and OpenGL > expects its > textures to be upside down. Support already exists for reading such files > but it > was impossible to save them. The spirit is appreciated, but (a) The TGA filter is being reworked at present and may (in my tree) no longer resemble the original enough to apply the patch and (b) I don't think Gimp should offer too many features that work around uncommon errors in other systems at a cost of confusing users... Did you want this to make a specific application go faster? Or because of a bug in someone else's TGA loader that means you can't load images the right way up? I know that OpenGL's internal store doesn't resemble a TGA very much, but I'd argue that the vertical orientation is the least of your troubles. Nick.
Re: TGA plug-in patch
>Below is a patch to add support for saving TGA files upside down. >Although it sounds strange to do, it is a supported feature of the >file format and OpenGL expects its textures to be upside down. Support >already exists for reading such files but it was impossible to save >them. As far as I know OpenGL expects its textures to be in RGBA format while TGA saves in ABGR so you have to do some extra work per pixel anyway, and then you can just as well read them in upside down, can't you?
TGA plug-in patch
Below is a patch to add support for saving TGA files upside down. Although it sounds
strange to do, it is a supported feature of the file format and OpenGL expects its
textures to be upside down. Support already exists for reading such files but it
was impossible to save them.
Brandon
Index: tga.c
===
RCS file: /cvs/gnome/gimp/plug-ins/common/tga.c,v
retrieving revision 1.20
diff -c -r1.20 tga.c
*** tga.c 2000/08/28 00:42:20 1.20
--- tga.c 2000/09/09 23:16:49
***
*** 95,105
--- 95,107
typedef struct _TgaSaveVals
{
gint rle;
+ gint vertrev;
} TgaSaveVals;
static TgaSaveVals tsvals =
{
1,/* rle */
+ 0,/* Bottom to Top ordering */
};
typedef struct _TgaSaveInterface
***
*** 1186,1192
struct tga_header hdr;
int (*myfwrite)(guchar *, int, int, FILE *);
! guchar *data;
drawable = gimp_drawable_get(drawable_ID);
dtype = gimp_drawable_type(drawable_ID);
--- 1188,1194
struct tga_header hdr;
int (*myfwrite)(guchar *, int, int, FILE *);
! guchar *data, *tmpbuf;
drawable = gimp_drawable_get(drawable_ID);
dtype = gimp_drawable_type(drawable_ID);
***
*** 1199,1205
memset (&hdr, 0, sizeof (hdr));
/* We like our images top-to-bottom, thank you! */
! hdr.descriptor |= TGA_DESC_VERTICAL;
/* Choose the imageType based on our drawable and compression option. */
switch (dtype)
--- 1201,1210
memset (&hdr, 0, sizeof (hdr));
/* We like our images top-to-bottom, thank you! */
! /* Not all of us :-P */
! if (!tsvals.vertrev) {
! hdr.descriptor |= TGA_DESC_VERTICAL;
! }
/* Choose the imageType based on our drawable and compression option. */
switch (dtype)
***
*** 1363,1369
{
/* Get a horizontal slice of the image. */
tileheight = MIN(tileheight, height - i);
! gimp_pixel_rgn_get_rect(&pixel_rgn, data, 0, i, width, tileheight);
#ifdef VERBOSE
if (verbose > 1)
--- 1368,1388
{
/* Get a horizontal slice of the image. */
tileheight = MIN(tileheight, height - i);
! if (!tsvals.vertrev) {
! gimp_pixel_rgn_get_rect(&pixel_rgn, data, 0, i, width, tileheight);
! } else {
! gimp_pixel_rgn_get_rect(&pixel_rgn, data, 0, MAX(height - i - tileheight,
0), width, tileheight);
! bsize = width * pelbytes; /* the width of a row */
! tmpbuf = (guchar *) g_malloc(bsize);
! for (j = 0; j < tileheight/2; j++)
! {
! memcpy(tmpbuf, data + (j * bsize), bsize);/* Move top row to the
tmpbuf */
! memcpy(data + (j * bsize), data + ((tileheight - j - 1) * bsize),
!bsize);/* Move bottom row to the top */
! memcpy(data + ((tileheight - j - 1) * bsize), tmpbuf, bsize);
! }
! g_free(tmpbuf);
! }
#ifdef VERBOSE
if (verbose > 1)
***
*** 1473,1478
--- 1492,1506
GTK_SIGNAL_FUNC (gimp_toggle_button_update),
&tsvals.rle);
gtk_toggle_button_set_active (GTK_TOGGLE_BUTTON (toggle), tsvals.rle);
+ gtk_widget_show (toggle);
+
+ /* Bottom to Top Ordering */
+ toggle = gtk_check_button_new_with_label (_("Upside Down Image"));
+ gtk_box_pack_start (GTK_BOX (vbox), toggle, FALSE, FALSE, 0);
+ gtk_signal_connect (GTK_OBJECT (toggle), "toggled",
+ GTK_SIGNAL_FUNC (gimp_toggle_button_update),
+ &tsvals.vertrev);
+ gtk_toggle_button_set_active (GTK_TOGGLE_BUTTON (toggle), tsvals.vertrev);
gtk_widget_show (toggle);
gtk_widget_show (vbox);
