Re: Bumpmap with negative Depth ??
lasm [EMAIL PROTECTED] writes: Thanks for your explanation. I am not familiar with the algorithm.. but just curious, would there be any difference if the Depth takes in negative integer (currently only positive accepted) ? Can you comment on this ? It wouldn't make any difference. The surface normal vectors would just point in the other direction, which is what you already get with "invert bumpmap". Federico
Re: Bumpmap with negative Depth ??
"Steinar H. Gunderson" [EMAIL PROTECTED] writes: The question is: Does it use 255-bm or just -bm? And would that make any difference? It wouldn't change anything. The local differences that are used to compute the surface normal would be exactly the same. Dude, follow the math! Read the source! Federico
Re: Bumpmap with negative Depth ??
[EMAIL PROTECTED] writes: What he is suggesting is to invert the color value, so white becomes black, and black areas become white, so that the bumpmap will take a different height field to achieve the "inverse" effect.. I have tried it before but do not quite like the result.. IMHO, the PS Lighting effects did it more "politically correct". If you press the "inverse bumpmap" there, the effect is different from the "Invert" Bump Map in Gimp.. Just try it out yourself and see if you agree... don't ask me to explain, I can't .. ;-) The Bumpmap plug-in works by taking the intensity values to be height values and computing the surface normal at each point. Then it does simple Gouraud-like shading on the destination image. Inverting the bumpmap source is exactly the same as using the "invert" button on the plug-in's dialog box; the intensity values are inverted and the surface normals will point in the opposite direction. I.e. it is essentially a cheap embossing effect. Photoshop's Lighting Effects produces much better results because it actually does Phong shading of the image, and it general it has better lighting models that you can choose. You can do this in the GIMP with Tom Bech's plug-in of the same name. Federico
Re: divide by 255
Nick Lamb [EMAIL PROTECTED] writes:
General purpose compose operations usually include a division by 255 of
a number in the range 0 ... 65025. While fixing up Mozilla's alpha
compositor I disturbed a sleeping hacker who has provided a (tested and
working) macro which computes this operation much more quickly than
any other solution tested, including GCC -On speed-ups using similar
but different tricks.
Of course, GCC cannot use this FAST_DIVIDE_BY_255 because it is safe
only for 0 ... 65025, but I think it might be useful to Gimp, both in
the core (which I presume has several alpha compositors) and in
plug-ins, where alpha composition is also a popular operation.
So, does Gimp already have something like this in core? Or should we
consider borrowing this macro from wherever it originated and using
it throughout Gimp (after 1.2, naturally) ?
You have to make sure that the code that uses such techniques indeed
has 255*255 as an upper bound. A long time ago the GIMP was full of
inconsistencies where some parts assumed 256*256, others 255*255, yet
buggier ones 256*255.
Anyways, in libart and gdk-pixbuf we have code like this to composite
an RGBA image over an RGB pixel:
a0 = p[3];
if (a0 == 255) {
dest[0] = p[0];
dest[1] = p[1];
dest[2] = p[2];
} else {
int tmp;
tmp = ((int) p[0] - r2) * a0;
dest[0] = r2 + ((tmp + (tmp 8) + 0x80) 8);
tmp = ((int) p[1] - g2) * a0;
dest[1] = g2 + ((tmp + (tmp 8) + 0x80) 8);
tmp = ((int) p[2] - b2) * a0;
dest[2] = b2 + ((tmp + (tmp 8) + 0x80) 8);
}
Here, dest points to the position of the destination pixel in a guchar
array, and p points to the source pixel. r2/g2/b2 are the background
color (here it is from a checkerboard, but it could be the background
RGB pixel). a0 is p[3], which is the alpha value for the source
pixel.
In the border cases (alpha = 0, alpha = 255) this produces exact
results. In the intermediate ones, the maximum difference between
doing a "slow but accurate" division and all this bit twiddling is at
most 1. So it is just what you want.
For compositing RGBA over RGBA, you could pull similar tricks.
I think the bigger problem is auditing the GIMP to make sure that
there are no inconsistencies in the valid ranges for color values when
compositing stuff together.
What code does Mozilla use? If it is different, could we run some
benchmarks for speed and accuracy?
Federico
Re: ANNOUNCE: GIMP 1.1.29
Manish Singh [EMAIL PROTECTED] writes: GIMP 1.1.29 is out there. This is a release candidate for 1.2. So scream if you see any major brokenness. Ugh. I haven't got around to fixing the (lack of) premultiplied alpha in the Blend tool when using custom gradients. [I downloaded the SRPM with the intention of writing a patch, forgot about it, and was reminded until now. Excuses, excuses.] You could say that it is a major piece of brokenness for the GIMP not to do garbage collection around buggy plug-ins or scripts, but I know this is nontrivial to fix. Federico
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: Code cleanup
Nick Lamb [EMAIL PROTECTED] writes: If p is a null pointer then "free (p)" may (and should!) crash. You are incorrect here. sigh You are completely wrong, see KR's treatment of ANSI C Sorry, my bad. I just checked the ISO standard and indeed, free(NULL) is safe. I guess that makes me an old fogey. Federico
Re: Help files
Kevin Turner [EMAIL PROTECTED] writes: Format issue 1: DocBook or HTML? DocBook. It is the Right Thing(tm) and GNOME has already assembled a nice set of tools to handle it. I'm sure the the GIMP documentation team can use some ideas and conventions from the GNOME documentation project. Please feel free to browse the nice GDP web pages. Format issue 2: Style guidelines. = Everyone probably agrees that we shouldn't have a different background colour for every help page. It might also be nice if there was some organizational consistancy from page to page. Also, is there anything that shouldn't be in the help file, or should always be in seperate files? For instance, should information about using the plug-in non-interactively not be displayed in the same file as the rest, to avoid exposing the user to "scary pdb stuff"? The way GNOME documentation is organized is more or less something like this: set titleFooApp Documentation/title book titleFooApp User's Guide/title ... /book book titleFooApp Developer's Guide/title part titleWriting Applications/Plug-ins for FooApp/title ... /part part titleFooApp API Reference/title ... /part /book /set The Evolution groupware suite uses this structure. It leads to nice results, I think. As for the look of the final output, it is just a stylesheet issue. The GDP has nice stylesheets both for printing and for generating HTML. Egger argues, "GIMP doesn't *need* help files to run, so they can be distributed seperately." Software is not complete until it has documentation. The documentation must be shipped along with the GIMP's code. (You'll also need to do that if you have automatically-generated docs for the API reference guide). Why? It's the "Who has cvs.gnome.org write-access?" song again. But it's only been three days since Piers (our new Help-guy) requested write access, so I don't feel that's a cause for alarm yet. How did Piers request access? You can always ask [EMAIL PROTECTED] and we'll take care of it. Again, please feel free to ask the GDP team if you have questions about how to write or ship documentation. Good luck, Federico
XCF loader for gdk-pixbuf
Hello, dudes, Jens Finke [EMAIL PROTECTED] has sent me an amazing patch to add support for XCF file loading to gdk-pixbuf. I would really like to have this sort of functionality so that simple programs like EOG can view GIMP files. However, there is the issue of licensing. Gdk-pixbuf is released under the LGPL, and the XCF loader uses big chunks of GPLed code from the GIMP. I am not sure what is the best way to proceed. [For the GIMP developers who may not be aware of how gdk-pixbuf works, it is a little library that lets you load images and perform some simple operations on them. The image loaders are loaded on demand as shared libraries, so we have dynamic objects for GIF, JPEG, PNG, TIFF, etc.] I would appreciate your suggestions. Thanks, Federico
Re: Coding style (was: PROPOSAL: New i18n solution)
:set cinoptions={0.5s,^-2,e-2,n-2,p2s,(0
Works most of the case.. (maybe not perfect, but..)
Thanks a lot! I just put it in the programming guidelines.
Federico
Re: Magicless file formats
Targa files have no magic header, and cannot be reliably identified that way. [snip] "New" Targa files have a magic string at the end of the file[1], plus a bunch of extra information. The Targa specification tells you how and where to expect it. It does says that for old files you are basically screwed :-( Federico [1] Yes, this is broken.
Re: Coding style (was: PROPOSAL: New i18n solution)
Uhm, I use vim and vim uses tabs by default and doesn't indent
the { after an if like GNU suggests. Du you have working settings to
achieve this?
I don't know if this will be useful at all, but the GNOME Programming
Guidelines has a snippet for .vimrc to set the Linux kernel
indentation style. If you tweak it a bit it may work for GNU
indentation style. You can look at it here:
http://developer.gnome.org/doc/guides/programming-guidelines/code-style.html
Please tell me if this works or if you had to change something; I'd
like to keep that part of the programming guidelines as accurate as
possible.
Sorry if this is not of any help, I don't do vi :-)
Federico
Re: Coding style (was: PROPOSAL: New i18n solution)
If you tweak it a bit it may work for GNU indentation style. No, unfortunately I couldn't get vim used to GNU indention style. Please tell me if this works or if you had to change something; I'd like to keep that part of the programming guidelines as accurate as possible. It'd work, but not for GIMPs code. :/ Oh, well. Thanks anyway. Please tell me if you find a way to make it work; other people may find it useful. Federico
Re: Edit Fille behaviour change?
Fill (by default Ctrl-.) has filled using the background colour in the GIMP for as long as I can remember. I don't think it's a bug [snip] I agree. I have grown very accustomed to the existing behavior, and I don't think it should be changed. I know it hasn't been customary in the past, but I think such a user-visible change should be discussed a little bit. What does Photoshop do? Federico
Re: Print plug-in
GIMP's a lot lighter than gnome-libs. I would substantially oppose any serious dependence on gnome-libs in GIMP. Especially since gnome-libs appears to depend on a library that is only available if you have RPM installed. Kelly, please don't spread FUD. People build gnome-libs on Debian boxes, old broken Slackware boxes, FreeBSD, Solaris, and other beasts. What library are you talking about? I think the GIMP would gain a lot from using the core GNOME libraries; right now it has a lot of reinvented wheels as it is. Users are going to want a consistent desktop experience, so the GIMP should not stand out as a sore thumb. Mind you, all the user interface improvements that the GIMP team has done are excellent. It is much better than the 1.0 series. Keep up the good work, Federico
Re: Print plug-in
We might also choose to use the upcoming Gnome Print System if it turns out to fit our needs and appears to be portable to non-Linux systems. As long as it doesn't require actually running Gnome (works with bare X, KDE, etc.) and its footprint is reasonably light, that sounds like a reasonable thing to do. As far as I know no GNOME application requires a running GNOME session, if by such thing you mean running the gnome-session program. If a GNOME program does not run under "bare" X or KDE, then it is broken and should be fixed. Do you have any examples of such programs? (As for footprint, well, the GIMP is not terribly lightweight either) :-) Federico
Re: Speaking of additional plug-ins
For the record, I think a plug-in CVS tree independent of Gimp is a good idea. "Let's focus, people!" [snip] The issue is: who has the time? Without people, good ideas remain abstract. I have no time, but I would nevertheless devote part of on merges between the two cvs trees. I could also set up a cvs server, but I firmly believe that it should be related to the gimp.org domain, and I would first have to ask my "boss" wether abusing a machine at the university would be ok (this is a space issue). delurk People should feel free to ask for a CVS account on the cvs.gnome.org box. If they have something cool they are working on for the GIMP, we can certainly give them access, provided they are willing to follow the standard GNOME CVS etiquette. As far as the GIMP is concerned, people could maintain their own experimental plug-ins in little CVS modules and later, when the plug-in is Done(tm), they could ask a CVS maintainer to physically move it to the main GIMP module. Or it could be linked as a virtual module, which also is a nice solution. This way you can have branches for particular plug-ins. In particular, I would love to see the fantastic Print plug-in on the GNOME CVS :-) Of course, that is up to Robert to decide. If there is anything the CVS maintainers can do to make Robert's life easier, I'd love to hear about it. /delurk Federico
Re: Help System
- Help us to make a seperate version of GtkXmHtml that compiles on a lot of setups and fix the Gimp configure script. Just so you know, GNOME is dropping GtkXmHTML because it is no longer being maintained and is not very good in general. Anders is working on a very nice GtkHTML widget, and the new GNOME help browser will use it while Mozilla will hopefully be finished somewhere in the next millenium. The GIMP should really use the GNOME help browser instead of reinventing the wheel. Federico
Re: limited slider range
20 pixels is pretty small (on 300 dpi that means 1.69 millimeters) Shouldn't these ranges be tied to the resolution setting? ie change the resolution and the ranges will update (well, maybe not for an open dialog, but perhaps the next time its opened). Using sliders for these things is wrong. You cannot specify things precisely and they have a limited range. These should be GtkSpinButtons with a *big* adjustment range instead. Federico
Re: swap files
I think this will just give you the LENGTH of the file? So, I don't know if it matters, but ISTR that Gimp uses files with holes, and therefore LENGTH != SIZE. Oh, I didn't know this. In any case, the program *does* know (or should) know the number of tiles that it can have (tile cache size), the number of tiles in memory (referenced tiles plus unswapped tiles), and number of tiles on disk (swapped tiles). So you really don't care much about the size of the swapfile, since it can only get so big. Federico
