Colour balance
I think it is time to repeat this message, from a year ago... The same
strange-looking code is still present in color_transfer.c. Is it a
bug? Should it be fixed before 1.2? Is my suggestion below a good one?
It seems obvious to me that the current color_transfer_init() function
in color_transfer.c has some cut-and-paste bug in it:
for (i = 0; i < 256; i++)
{
highlights_add[i] =
shadows_sub[255 - i] = (1.075 - 1 / ((double) i / 16.0 + 1));
midtones_add[i] =
midtones_sub[i] = 0.667 * (1 - SQR (((double) i - 127.0) / 127.0));
shadows_add[i] =
highlights_sub[i] = 0.667 * (1 - SQR (((double) i - 127.0) / 127.0));
}
Note how the third assignment statement uses the same value as the
second. Can this be the intention, that adjusting shadows up is the
same as adjusting midtones up? (And adjusting highlights down the same
as adjusting midtones down.)
And, what *is* the definition of what the colour balance adjustment
should do? I couldn't find any deeper explanation in my Photoshop
books. Are the sliders you adjust from -100 to 100 percentages (in
that case, percentages of what?), or pixel values?
I would tentatively suggest replacing those lines with the following
code. This uses Bernstein polynomials as weight curves, with are
scaled with the difference from the min or max channel value (0 or
255) and the current value, depending on if we are subtracting or
adding. (Er, that probably isn't very clearly said. Play with gnuplot
to visualize these curves... Gnuplot rocks.)
for (i = 0; i < 256; i++)
{
/* Let's try using Bernstein polynomials... At least this gives
* a certain smoothness to the transfer functions. This is
* definitely not what P*shop, uses, however. In P*shop if you
* apply +100 shadows and -100 highlights, you get back what you
* started with. Should this be our goal, too? To me, this seems
* conceptually a bit odd, why should reducing red from
* highlights be the opposite of adding red to shadows? Note
* that it doesn't work in the other order, though, so maybe
* it's just a coincidence, and not a design goal. */
#define C41 ((4*3*2*1)/(1 * 3*2*1))
#define C42 ((4*3*2*1)/(2*1 * 2*1))
#define C43 ((4*3*2*1)/(3*2*1 * 1))
#define B14(u) (C41*u*(1-u)*(1-u)*(1-u))
#define B24(u) (C42*u*u*(1-u)*(1-u))
#define B34(u) (C43*u*u*u*(1-u))
shadows_add[i] = B14((double) i / 255.0)*(255 - i);
shadows_sub[i] = B14((double) i / 255.0)*i;
midtones_add[i] = B24((double) i / 255.0)*(255 - i);
midtones_sub[i] = B24((double) i / 255.0)*i;
highlights_add[i] = B34((double) i / 255.0)*(255 - i);
highlights_sub[i] = B34((double) i / 255.0)*i;
}
And the code that uses these tables, in the function
color_balance_create_lookup_tables() in color_balance.c, would be
modified as follows (treat the slider values as percentages of the
above values, clamp each channel value only once ).
r_n += cbd->cyan_red[SHADOWS]/100.0 * cyan_red_transfer[SHADOWS][r_n];
r_n += cbd->cyan_red[MIDTONES]/100.0 * cyan_red_transfer[MIDTONES][r_n];
r_n += cbd->cyan_red[HIGHLIGHTS]/100.0 * cyan_red_transfer[HIGHLIGHTS][r_n];
r_n = CLAMP0255 (r_n);
g_n += cbd->magenta_green[SHADOWS]/100.0 * magenta_green_transfer[SHADOWS][g
_n];
g_n += cbd->magenta_green[MIDTONES]/100.0 * magenta_green_transfer[MIDTONES]
[g_n];
g_n += cbd->magenta_green[HIGHLIGHTS]/100.0 * magenta_green_transfer[HIGHLIG
HTS][g_n];
g_n = CLAMP0255 (g_n);
b_n += cbd->yellow_blue[SHADOWS]/100.0 * yellow_blue_transfer[SHADOWS][b_n];
b_n += cbd->yellow_blue[MIDTONES]/100.0 * yellow_blue_transfer[MIDTONES][b_n
];
b_n += cbd->yellow_blue[HIGHLIGHTS]/100.0 * yellow_blue_transfer[HIGHLIGHTS]
[b_n];
b_n = CLAMP0255 (b_n);
cbd->r_lookup[i] = r_n;
cbd->g_lookup[i] = g_n;
cbd->b_lookup[i] = b_n;
Comments, please?
--tml
Re: Bug? cannot duplicate color channel
pixel fairy wrote: > is seems you cannot do to the three color channels what you can to any other, such >as duplicate. > duplicating a color channel is usefull for things like masking out complex >selections (like hair) Color channels are special; you can't get there from here. But you can come close. Here's a few exercises. 0. Open an RGB image. 1. Image->Mode->Decompose 2. Pick any decomposition into Red Green Blue; Hue, Saturation, Value 3. OK (Decomposing...) 4. You now have three or four greyscale images which can be readily fashioned into channels. 5. Layers->Layers, Channels, and Paths... 6. Use the image menu to select the various decomposed greyscale images 7. Now you can drag-and-drop or copy and paste your decomposed greyscale images back onto the original to create additional layers, channels, alpha masks Or you can mess around with them with levels and curves first, for all kinds of odd and interesting selection tricks. Have fun. Be good, be well Garry
Re: GUI Bugs: Levels and Curves
On Tue, Mar 14, 2000 at 03:42:29PM -0600, Jon Winters wrote: >123, 123, 123 is a shade of gray >115, 115, 115 is a shade of gray >139, 139, 139 is a shade of gray > >Trust the numbers, they don't lie. Of course they do, if one of these apply: 1. Your film is colour-balanced. 2. Your scanner is colour-balanced. 3. The light isn't even. 4. The Levels thingy in point 1 has destroyed all the grays, just because (e.g.) there was less blue in the shadows than there was red. I'd say that normally _all four_ apply. The numbers lie. The Curves correction is an attempt to make them truthful :-) /* Steinar */ -- Homepage: http://members.xoom.com/sneeze/
Re: GUI Bugs: Levels and Curves
>> There appears to be some problems in this algorithm. I'm certainly no colour >> expert, but the weak point seems to be in: >> >> >2. take a color pick of some point that has to be gray (say: 123 / 115 / 139) >> >> How can you know that this colour is supposed to be grey, and not a gray with >> a tint of blue, for instance? The problem is finding what is supposed to be >> exactly gray :-) >> >> The other problem seems to be that you'll lose some precision, but hopefully >> it's not more than a bit or perhaps two. >> >> For the UI adjustments, I'll leave that to the others :-) Hi Steinar, In fact you never really know what the correct colors in a photo should be unless you have a known point of reference (like a color or grayscale card in the photo). Even so, the lighting conditions may be such that the color card is no longer relevant. Nevertheless, you can often look at a photo and see that it is not quite right. When this happens you can experiment with adjusting the colors so that certain measured pixels in the image are forced to be neutral (that is, gray). For most photos of normal scenes it is often very easy to identify parts that "should" be gray: road surfaces, car wheel rims, other steel objects, etc. Adjusting the color of these parts of the image to a neutral value often makes the whole image look much better (for examples, you can see Chapter 6 of Grokking the GIMP, in particular the parts at http://gimp-savvy.com/BOOK/node60.html and following -- but you may need to wait for the slashdot effect to subside first ;-). Also, keep in mind that color correction is largely a function of the artist's perception. In the original scene, gray objects may not appear gray at all due to the spectrum of the illumination. However, the artist's objective is not necessarily to make the image appear as it did when photographed. Often it is to produce an image which looks like it was taken under "natural" or "studio" lighting conditions (but not always). Carey Bunks Dr. Carey Bunks Senior Scientist BBN Corp. 70 Fawcett St, 15/2A Cambridge, MA 02138 tel: 617-873-3028 fax: 617-873-2918 email: [EMAIL PROTECTED]
Re: GUI Bugs: Levels and Curves
On Tue, 14 Mar 2000, Steinar H. Gunderson wrote: > Uwe, > > There appears to be some problems in this algorithm. I'm certainly no colour > expert, but the weak point seems to be in: > > >2. take a color pick of some point that has to be gray (say: 123 / 115 / 139) > > How can you know that this colour is supposed to be grey, and not a gray with > a tint of blue, for instance? The problem is finding what is supposed to be > exactly gray :-) No problemo... 123, 123, 123 is a shade of gray 115, 115, 115 is a shade of gray 139, 139, 139 is a shade of gray Trust the numbers, they don't lie. -- Jon Winters http://www.obscurasite.com/ "Everybody loves the GIMP!" http://www.gimp.org/
Re: GUI Bugs: Levels and Curves
Uwe, There appears to be some problems in this algorithm. I'm certainly no colour expert, but the weak point seems to be in: >2. take a color pick of some point that has to be gray (say: 123 / 115 / 139) How can you know that this colour is supposed to be grey, and not a gray with a tint of blue, for instance? The problem is finding what is supposed to be exactly gray :-) The other problem seems to be that you'll lose some precision, but hopefully it's not more than a bit or perhaps two. For the UI adjustments, I'll leave that to the others :-) /* Steinar */ -- Homepage: http://members.xoom.com/sneeze/
Roadmap
Hi, I was wondering if anyone could compile a kind of Roadmap for future development of The Gimp (or direct me towards it if one is in existance). I see a Roadmap as outlining future developments such as the release of v1.2.0 (and the critical stuff which needs addressing before then), and the implementation of CMYK support (presumably some time into v1.3.x) which will require a major rewrite, etc, etc. Naturally, of course, I may be completely wrong!! I'd be interested to know other people's thoughts on this, Thanks, - Piers [v.c]
Re: [gimp-devel] Re: Bug#6916: [gimp-bug] Wrong PERL Path in ./plug-ins/perl/pxgettext
On Tue, 14 Mar 2000, Simon Budig <[EMAIL PROTECTED]> wrote: > Raphael Quinet ([EMAIL PROTECTED]) wrote: > > I think that the only way to guard against users having a broken path > > is to hardcode the location of the perl executable in the scripts. > > Actually, this should also be done for python because using "env" will > > create exactly the same problems. > > Using "env" is much more portable than always using "/usr/bin/python". > Determining the location of the binary at compile time is a good > compromise IMHO. So where is our autoconf/automake guru? :-) The advantage of "env" is that you can copy a script from one machine to another and it will work as long as the user has set her path correctly. The disadvantage is that the user will get very strange results if he has an older version of the interpreter in her path. The advantage of hardcoding the path is that you can be sure that the scripts will always work on the machine on which they were installed, regardless of what the user has in her path. The disadvantage is that you cannot simply copy the script to another machine and expect it to work if the two machines are set up differently. On a multi-user system, I would certainly prefer the second solution. But if it is important for you to be able to copy some files from one machine to another without re-configuring and re-installing the software, then the first solution is better. It all depends on the usage scenario. > > Just to give you an example, there are several versions of Perl in my > > path on one of the systems I use at work: > > > > $ /usr/bin/perl -v > > This is perl, version 5.003 with EMBED > > $ /opt/local/bin/perl --version > > This is perl, version 5.004_04 built for sun4-solaris > > $ /Local/bin/perl --version > > This is perl, version 5.005_03 built for sun4-solaris > > Ouch! > > > There are also some older versions of Perl available, but fortunately > > they have been renamed (e.g. perl4, oldperl) so that they are not used > > by default. > > /me wants to say "please fix the version chaos on this machine" but > I understand, that there are Systems with lots of perl installations > where the Gimp-Admin is != Perl-Admin... It is not only a matter of persons, it could also be a matter of security policy. Some companies will only install software packages in "system" directories after they have passed several audits. This leads to a situation in which the system directories contain some old but relatively safe programs and the other directories such as /usr/local or /opt/local contain newer programs. I do not consider the system described above as being "broken" or suffering from a "version chaos": you only have to take into account the fact that different packages are installed in different places for different purposes. Then it is up to the users to decide how they configure their path. You cannot force anyone to use all the newest tools if they do not really need them, so many users have "/usr/bin" and "/bin" first in their path. They are happy with that and all the tools they use regularly do work fine. But if one of the tools that is not installed in /usr/bin (e.g. a Perl-Fu script) depends on another tool that is available in several directories, then it is necessary to be careful. One solution is to write a wrapper around the Gimp which will reset the path before invoking the application. But this will not work if the scripts can be invoked directly, so another solution is to hardcode the paths in the scripts themselves. -Raphael
Re: [gimp-devel] Re: Bug#6916: [gimp-bug] Wrong PERL Path in ./plug-ins/perl/pxgettext
Raphael Quinet ([EMAIL PROTECTED]) wrote:
> > Are there really multiple different executables named "perl" (not "perl4" or
> > so!) in your path? So when you work in your shell you always execute
> > version 4 of perl, when you invoke "perl"?
>
> I suppose that Marc meant that the person running a Perl-Fu script
> might not the the person who has configured and installed it. It is
> likely that the one who configures the Gimp has set his path correctly
> (in order to be able to run configure without errors) but it can
> happen that another user has a broken path, with old tools listed
> first. In that case, the user would get a different version of perl
> than the one that Gimp was configured with.
I see the point. So it is probably really the best to hardcode the
path to perl at ./configure-time. Though I dont like situations as in
your example. This is a perfect way to create great confusion among the
users... ("But it works for me! Why?")
> I think that the only way to guard against users having a broken path
> is to hardcode the location of the perl executable in the scripts.
> Actually, this should also be done for python because using "env" will
> create exactly the same problems.
Using "env" is much more portable than always using "/usr/bin/python".
Determining the location of the binary at compile time is a good
compromise IMHO. So where is our autoconf/automake guru? :-)
> Just to give you an example, there are several versions of Perl in my
> path on one of the systems I use at work:
>
> $ /usr/bin/perl -v
> This is perl, version 5.003 with EMBED
> $ /opt/local/bin/perl --version
> This is perl, version 5.004_04 built for sun4-solaris
> $ /Local/bin/perl --version
> This is perl, version 5.005_03 built for sun4-solaris
Ouch!
> There are also some older versions of Perl available, but fortunately
> they have been renamed (e.g. perl4, oldperl) so that they are not used
> by default.
/me wants to say "please fix the version chaos on this machine" but
I understand, that there are Systems with lots of perl installations
where the Gimp-Admin is != Perl-Admin...
Bye,
Simon
--
[EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Re: [gimp-devel] Re: Bug#6916: [gimp-bug] Wrong PERL Path in ./plug-ins/perl/pxgettext
On Tue, 14 Mar 2000, Simon Budig <[EMAIL PROTECTED]> wrote: > Marc Lehmann ([EMAIL PROTECTED]) wrote: > > This might work for python, but it will not work for perl. It will find > > the first perl in your path (which is often perl4), not the perl gimp > > was configured with. > > Are there really multiple different executables named "perl" (not "perl4" or > so!) in your path? So when you work in your shell you always execute > version 4 of perl, when you invoke "perl"? I suppose that Marc meant that the person running a Perl-Fu script might not the the person who has configured and installed it. It is likely that the one who configures the Gimp has set his path correctly (in order to be able to run configure without errors) but it can happen that another user has a broken path, with old tools listed first. In that case, the user would get a different version of perl than the one that Gimp was configured with. I think that the only way to guard against users having a broken path is to hardcode the location of the perl executable in the scripts. Actually, this should also be done for python because using "env" will create exactly the same problems. Just to give you an example, there are several versions of Perl in my path on one of the systems I use at work: $ /usr/bin/perl -v This is perl, version 5.003 with EMBED built under solaris at Nov 10 1996 13:23:19 + suidperl security patch ... $ /opt/local/bin/perl --version This is perl, version 5.004_04 built for sun4-solaris ... $ /Local/bin/perl --version This is perl, version 5.005_03 built for sun4-solaris ... There are also some older versions of Perl available, but fortunately they have been renamed (e.g. perl4, oldperl) so that they are not used by default. When I configure the Gimp, I always have /Local/bin first in my path. But this is not the case for all users: some of them have /usr/bin or /opt/local/bin first, so they will have problems if they try to execute the Perl-Fu scripts with perl 5.003 or 5.004. This problem can be solved by hardcoding the path to the perl executable in all scripts during the configure step. -Raphael
Re: Bug? cannot duplicate color channel
Carey Bunks wrote: >> is seems you cannot do to the three color channels what you can to any >> other, such as duplicate. >> duplicating a color channel is usefull for things like masking out >> complex selections (like hair) Dear Pixel Fairy, Try using Decompose (found in the Image:Image/Mode menu) with the RGB option. Your friend, The Tooth Fairy ;-) YEY!! Tooth fairy thanks.
Re: [gimp-devel] Re: Bug#6916: [gimp-bug] Wrong PERL Path in ./plug-ins/perl/pxgettext
Marc Lehmann ([EMAIL PROTECTED]) wrote: > On Mon, Mar 06, 2000 at 04:16:04PM +0100, Simon Budig <[EMAIL PROTECTED]> >wrote: > > There is a better way. > > This might work for python, but it will not work for perl. It will find > the first perl in your path (which is often perl4), not the perl gimp > was configured with. Are there really multiple different executables named "perl" (not "perl4" or so!) in your path? So when you work in your shell you always execute version 4 of perl, when you invoke "perl"? Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Re: running ldconfig
On Tue, 14 Mar 2000, Robert L Krawitz <[EMAIL PROTECTED]> wrote: >From: [EMAIL PROTECTED] (Raphael Quinet) > >Yup! I have an elf-based Solaris system that does not know anything >about ldconfig... :-) > > It's happened with at least 1.1.17 and 1.1.18. The fact that you're > using Solaris explains why you don't have a problem. Hmmm... I should have said that I _also_ have an elf-based Solaris system. My development machine at home is a PC running Linux (based on SuSE 6.3, as I described in another message). I did not have any problems on my Linux system, but this is probably because I am so used to running ldconfig after installing anything that I did not even remember that I had to use it. ;-) > All that ldconfig -n does is create the links. It doesn't update the > cache. ld.so (at least on Linux) needs the cache: You are right, I should have thought about why libtool uses the "-n" option. I think that libtool runs "ldconfig -n" because this is the only option that can be used safely, since it does not require more permissions than the ones for installing the libraries. Libtool already prints a message telling the user to run "ldconfig" or "ldconfig -v" after installing something, so any user who watches the installation process should know what to do. The Gimp Makefile (not libtool) could have an additional call to "ldconfig" or "-(PATH="\$PATH:/sbin" ldconfig) > /dev/null" immediately after calling "$(LIBTOOL) --mode=install". But the installation rules in the Makefiles are generated by autoconf/automake and it could be a bit tricky to hack them. -Raphael
another expo needs Gimp presence
(A little off topic, sorry for the interruption.) Is there anyone in the Denver region (within a days drive, perhaps) that would be interested in giving either a Demo or BoF session at the Colorado Linux Info Quest? We've got lots of embedded, business, server and developer types talking already (found 3 Debian developers to give a Debian BoF), but we're missing desktop issues. GNOME and KDE would also be interesting topics. I'd do it, but I'm chairing this expo so won't have time. I can probably cover a nights hotel for anyone who volunteers (plus free admission, of course). I don't think I can cover airfare, however. This wouldn't be a "talk" per se - a "Demo" would be a real demo of Gimp's capabilities and a "BoF" is an informal gathering of similar thinkers, headed by one or more individuals. If you're interested, drop me an email. Info on the conference and exhibit can be found at www.thecliq.org. Its going to be held on Saturday, April 1st. Thanks. -- Michael J. Hammel The Graphics Muse [EMAIL PROTECTED] http://www.graphics-muse.com -- If you want to live a happy life, tie it to a goal, not to people or things. -- Albert Einstein
Re: fu ?
Raphael Quinet said... | |On Tue, 14 Mar 2000, FUJITA Yuji <[EMAIL PROTECTED]> wrote: |> 1. Does anyone know what "fu" is ? | |I think that it was a pun on "kung-fu". Not sure, though. It was. -Miles
Re: The virtuall CVS checkin (aka the TODO list) (fwd)
Hi all. Xach missed the CCC-Notes, here they are again ;-) Bye, Simon - Forwarded message from Sven Neumann <[EMAIL PROTECTED]> - X-Mailer: exmh version 2.0zeta 7/24/97 To: Olof S Kylander <[EMAIL PROTECTED]> Cc: Michael Natterer <[EMAIL PROTECTED]>, Simon Budig <[EMAIL PROTECTED]> From: Sven Neumann <[EMAIL PROTECTED]> Subject: Re: The virtuall CVS checkin (aka the TODO list) Date: Thu, 12 Aug 1999 21:24:00 +0300 Hi Olof, > It was a very nice weekend (CCC camp) and I hope I can meet you all again. > Anyway I hope that you all had some luck with the eclipse. Below is the > edited todo list. Any questions just mail me otherwise I will send it to > the mailing list as a post from us all Friday or Saturday. > Yes it was indeed very nice to be at the camp! The eclipse wasn't as impressing as I hopes it to be due to the fact that it was raining and we haven't seen the total eclipse phase at all. However the moment when the light went off was pretty chilling... I have attached an overworked version of your TODO proposal. These are only small formatting changes ( and I changed tile cash to tile cache ). Salut, Sven Start - Hello Gimpers! As some of you may know, we (Sven, Mitch, Simon and Olof) have had a Gimp session at the CCC camp in Berlin. Naturally, this resulted in a lot of hacking and we have added some nice new features to Gimp. Most of our current project is not finished yet, and some of the features aren't in a presentable state, so we can can't commit them now. But freezing Gimp without adding these new features makes some of our work quite useless. We have therefore redefined the meaning of "feature freeze", and hereby add those features (listed below) to the development version of Gimp. You can consider them virtually checked into the current CVS tree :-). ** * Features added by Sven, Mitch, Simon and Olof into the * * current CVS tree as of 8 August 1999, Berlin Germany: * ** *Drag&Drop*: Channels-> drag channel to toolbox to create new image (both grayscale and RGB) -> drag alpha channels to image to add channels to that image (both single and multiple selected channels) -> drag color from color selection dialog or fg/bg color swatches to colorify channel Layers -> drag to palette (new palette from the current layer) -> drag to brush (new brush from layer) -> drag to pattern (new pattern from layer) -> drag to gradient (extract palette and distribute in HSV space :-) -> drag to layer mask Selected layers -> the same functions as for Layers Layer Masks -> the same functions as for Layers Image -> drag image to layer dialog to create new layer of image (select (modifier key) to drag all visible layers or just the active layer) -> drag image to layer mask (select (modifier key) to drag all visible layers or just the active layer) -> drag image to channel (select (modifier key) to drag all visible layers or just the active layer) -> to palette (new palette from the active layer) -> to brush (new brush from image) -> to pattern (new pattern from image) -> to gradient (extract palette and distribute :-) File-> drag filename (from the File Open dialog) to layer -> to layermask -> to channel -> to palette (new palette from the active layer) -> to brush (new brush from image) -> to pattern (new pattern from image) -> to gradient (extract palette and distribute :-) Toolbox -> drag foreground color in fg/bg color swatch to background or vice versa -> drag color, pattern or gradient to status dialog Path-> drag selected paths to image (will copy paths from one image to another) Color selectors -> use the standard GTK color-drag -> color to channel -> color to Q-mask Dev
Re: Bug? cannot duplicate color channel
>> is seems you cannot do to the three color channels what you can to any >> other, such as duplicate. >> duplicating a color channel is usefull for things like masking out >> complex selections (like hair) Dear Pixel Fairy, Try using Decompose (found in the Image:Image/Mode menu) with the RGB option. Your friend, The Tooth Fairy ;-)
Re: Bug? cannot duplicate color channel
On Tue, Mar 14, 2000 at 06:13:18AM -0800, pixel fairy wrote: > is seems you cannot do to the three color channels what you can to any > other, such as duplicate. > duplicating a color channel is usefull for things like masking out > complex selections (like hair) The RGB channels are not real channels, unfortunately. They're pseudo-channels that don't act normal. Perhaps they will be promoted to real channels after 1.2 comes out. (Here is where Sven chastises me for saying this and tells me to read his notes from the Camp...I would, if I knew where they were!) :) Zach -- Zachary Beane [EMAIL PROTECTED] PGP mail welcome. http://www.xach.com/pgpkey.txt
Bug? cannot duplicate color channel
is seems you cannot do to the three color channels what you can to any other, such as duplicate. duplicating a color channel is usefull for things like masking out complex selections (like hair)
Re: running ldconfig
Date: Mon, 13 Mar 2000 17:22:50 +0100 (MET) From: [EMAIL PROTECTED] (Raphael Quinet) > > Like I said: this should be run as part of the installation procedure > > "on Elf-based systems, at any rate". > > But "Elf" and "ldconfig" are not too related to each other. Yup! I have an elf-based Solaris system that does not know anything about ldconfig... :-) It's happened with at least 1.1.17 and 1.1.18. The fact that you're using Solaris explains why you don't have a problem. > However, the solution is easy: somebody who wants it should write the > necessary autoconf and makefile magic to detect wether ldconfig exists and > (at installation time) wether it should be run (uid == 0 is a good hint). First, I would like to be sure that it happens with the latest version of the Gimp. I just checked the source for 1.1.17 and 1.1.18, and both of them are distributed with a version of libtool that includes the following on Linux systems: finish_cmds='PATH="\$PATH:/sbin" ldconfig -n $libdir' This is run immediately after installing each library in $libdir. So at least the recent versions of the Gimp _do_ run ldconfig as part of "make install" and you should not have any problems. All that ldconfig -n does is create the links. It doesn't update the cache. ld.so (at least on Linux) needs the cache: ld.so(8) ld.so(8) NAME ld.so/ld-linux.so - dynamic linker/loader DESCRIPTION ld.so loads the shared libraries needed by a program, pre pares the program to run, and then runs it. Unless explicitly specified via the -static option to ld during compilation, all Linux programs are incomplete and require further linking at run time. The necessary shared libraries needed by the program are searched for in the following order o Using the environment variable LD_LIBRARY_PATH (LD_AOUT_LIBRARY_PATH for a.out programs). Except if the executable is a setuid/setgid binary, in which case it is ignored. o From the cache file /etc/ld.so.cache which contains a compiled list of candidate libraries previously found in the augmented library path. o In the default path /usr/lib, and then /lib. On the other hand, maybe you are having a problem with ld.so.conf, not with ld.so.cache. The latter is updated by ldconfig, but the former can only be modified by hand. I think that it would be wrong for a tool to attempt to modify ld.so.conf automatically, because the order of the directories is important and some modifications could break the whole system. My ld.so.conf is correct (if it weren't, running ldconfig wouldn't solve the problem). I agree that make install should not attempt to edit ld.so.conf. Botching that will trash the system. -- Robert Krawitz <[EMAIL PROTECTED]> http://www.tiac.net/users/rlk/ Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for The Gimp Print -- http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton
Re: fu ?
On Tue, 14 Mar 2000, FUJITA Yuji <[EMAIL PROTECTED]> wrote:
> 1. Does anyone know what "fu" is ?
> I mean "script-fu", "perl-fu" or some kind of these names.
I think that it was a pun on "kung-fu". Not sure, though.
> 2. What is the biggest barriar to support 16bit depth in the GIMP ?
> I'm just reading xcf.c or tile.c and their related stuff and
> am in distress.
Many parts of the code assume that an image channel has exactly 8 bits.
For example, all paint operations (brushes, bucket fill, transforms...)
work on 8 bits. Changing that is already a huge amount of work. But
this also applies to all plug-ins: they will have to be re-written in
order to take several bit depths into account.
Maybe you should have a look at Gimp16 project ("Hollywood"). I do not
know the current status of the project (it looks like nothing happened
recently) but the Gimp16 homepage is at:
http://film.gimp.org/
-Raphael
fu ?
Hi, dear developers. I have two questions, maybe one of them is trifling. 1. Does anyone know what "fu" is ? I mean "script-fu", "perl-fu" or some kind of these names. 2. What is the biggest barriar to support 16bit depth in the GIMP ? I'm just reading xcf.c or tile.c and their related stuff and am in distress. regards. FUJITA Yuji [EMAIL PROTECTED] http://www.wl.me.titech.ac.jp/~yuji/yuji-pubkey.asc
