Re: [Gimp-developer] A way to do 16 bits?
I would be the first to applaud when 16bit is integrated, yet this does not feel right long term, because any code written for 2 layers mode will have to change when the data is correctly layout as a true 16bit number. -Joseph William Skaggs wrote: I've been thinking about three things that are highly desired but have been waiting for the migration to gegl: support for 16 bits, layer groups, and procedural layers. It seems to me that all of them can be achieved in GIMP 2 without major infrastructure changes, not perhaps in the most ideal way, but not in a kludgy way either. Given that the switch to gegl will probably entail a long development cycle, it may be worth considering what can be done in the meantime with GIMP 2. In this email I will discuss the 16-bit-depth issue, and leave the others for later. The basic idea for supporting 16 bits is to treat a 16-bit layer as two 8-bit layers, a main layer for the high byte and an auxiliary layer for the low byte. The auxiliary layer would never be visible, would not appear in the Layers dialog, and would always move together with the main layer. The thing that makes this approach feasible is that for most purposes the low byte of a 16-bit layer is invisible to the user. As a starting point, then, it can simply be ignored in computing the projection. (Some composition modes, particularly divide, may ultimately want to make use of it, though.) The program would then be to build 16-bit support gradually into tools and filters. It needn't be done all at once, because a lack of 16 bit support simply means ignoring the low byte of the input, which is not a disaster in the great majority of cases. There are really only two things, as far as I can see, that would need to be done right at the start: change the Layers dialog so that auxiliary layers don't appear, and change the layer-moving commands so that main and auxiliary layers move together. Everything else could be added over time, and nothing in GIMP would be seriously broken during the process. I look forward to feedback :-). Best, -- Bill __ __ __ __ Sent via the KillerWebMail system at primate.ucdavis.edu ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] panel and winning splash
Sven Neumann wrote: Hi, Joseph Heled [EMAIL PROTECTED] writes: Selecting a splash is a daunting task. However, the weight may seem less assuming the following tidbits are made readily accessible (say via a Tip of the day) - How one can replace the default splash with a personal one. It's in the gimp man-page. - How one can use multiple splashes. We should probably add this information. I probably was not clear enough. I think in the man page might not be enough here. How about some mention of this in the first time setup? I am not saying it is a big deal. If you think it is pointless than forget it. I was just hoping there is an easy way to alleviate some pressure from the selection committee. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] multiple instances of splash winners
Note/Disclaimer: I am *not* suggesting adding this feature into gimp. And
please don't tell me I am doing something wrong or stupid or degrading gimp in
any way or form.
I like many of the splash screens submitted, so I select a random one at
startup. If you wish to do the same,
- create a gimp-splash subdirectory under ~/.gimp-2.2
- place all your favorites there
- Apply the included patch (patch -p1 rand-splash.diff)
- recompile gimp
-Joseph
*** gimp-2.2-pre2/app/gui/splash.c2004-12-13 08:46:25.0
+1300
--- gimp-2.2-pre2s/app/gui/splash.c 2004-12-13 08:46:25.0 +1300
***
*** 74,92
g_return_if_fail (splash == NULL);
! filename = gimp_personal_rc_file (gimp-splash.png);
! pixbuf = gdk_pixbuf_new_from_file (filename, NULL);
! g_free (filename);
!
! if (! pixbuf)
! {
! filename = g_build_filename (gimp_data_directory (),
!images, gimp-splash.png,
!NULL);
pixbuf = gdk_pixbuf_new_from_file (filename, NULL);
! g_free (filename);
}
if (! pixbuf)
return;
--- 74,119
g_return_if_fail (splash == NULL);
! {
! int nFiles = 0;
! GError* err;
! const char* folder = gimp_personal_rc_file(gimp-splash);
! GDir* d = g_dir_open(folder, 0, err);
!
! filename = 0;
! if( d ) {
! srandom(time(NULL));
! G_CONST_RETURN gchar* name;
! while( (name = g_dir_read_name(d)) ) {
! if( (random() % (nFiles+1)) == 0 ) {
! filename = g_build_filename(folder, name, NULL);
! }
! ++nFiles;
! }
! g_dir_close(d);
! }
!
! if( filename ) {
pixbuf = gdk_pixbuf_new_from_file (filename, NULL);
! g_free(filename);
}
+ }
+ if (!pixbuf ) {
+ filename = gimp_personal_rc_file (gimp-splash.png);
+ pixbuf = gdk_pixbuf_new_from_file (filename, NULL);
+ g_free (filename);
+
+ if (! pixbuf)
+ {
+ filename = g_build_filename (gimp_data_directory (),
+images, gimp-splash.png,
+NULL);
+ pixbuf = gdk_pixbuf_new_from_file (filename, NULL);
+ g_free (filename);
+ }
+ }
+
if (! pixbuf)
return;
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Histogram of selection?
Sven Neumann wrote: Hi, Joseph Heled [EMAIL PROTECTED] writes: In 2.2, the histogram always takes the full image. I thought that in the past it took the selection if there was one. Am I imagining this? Yes, I think you are imagining this. There's a rather old bug report about it and basically we agreed that we want to change the behaviour. It should be an easy change but so far noone got around to do it. Perhaps you might want to give it a try? If by the time I finish other stuff on higher priority it is still unresolved I will give it a try. Thanks for all the info on that. -Joseph Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Histogram of selection?
In 2.2, the histogram always takes the full image. I thought that in the past it took the selection if there was one. Am I imagining this? Is there a way to get the histogram for just the selection? -Joseph ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Histogram of selection?
William Skaggs wrote: Joseph Heled wrote: In 2.2, the histogram always takes the full image. I thought that in the past it took the selection if there was one. Am I imagining this? Is there a way to get the histogram for just the selection? See http://bugzilla.gnome.org/show_bug.cgi?id=72959 Feel free to add a comment to that bug report :-). Best, -- Bill That was opened more than a year ago. All the comments say it is easy. Nu it is not in 2.2 pre, so I guess no one was interested ... -Joseph ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Statistics on a selection? on an image
Is there a way to get some statistics on a selection? Say for each RGB channel Average, min max, STD, median? (I want this in some interactive way. i.e. to see the results while I play with the image/layers) And if not, how would one implement this? A plugin need to be re-activated every time the selection changes. A tool? there can be only one at a time. So you can't keep it open and play with the image or the selection. Can anyone suggest something? (And Carol, there is no need to point out it can be done by going over the pixels one by one and a hand calculator ) -Joseph ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Statistics on a selection? on an image
Carol Spears wrote: On Thu, Dec 09, 2004 at 05:58:51PM +1300, Joseph Heled wrote: (And Carol, there is no need to point out it can be done by going over the pixels one by one and a hand calculator ) i offer you a two step solution and you get worried that i will suggest a thousands of steps solution? what did i do to you? carol I felt it was inappropriate to be treated as a newbee, who could not think of the obvious workaround. I posted because I thought there should be a better way. The other response showed that this is a legitimate known issue/request. -Joseph ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Multiple Layers and curves?
Sven Neumann wrote: Hi, Joao S. O. Bueno Calligaris [EMAIL PROTECTED] writes: Meanwhile, the workaround for this is running 2 simultaneous GIMPs, and editing one of your layers as a separate image on other instance of the GIMP. Joao, I think you completely misunderstood the question. Sven I think he understood, but the suggested solution will not do, because the two layers are interacting via a layer mode, and I would like to view the effect interactively. -Joseph ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Judging the splash contest (mark 2)
It might have been me. I thought the the names will be announced later, after the panel is finalized. I have looked at all the entries, but not sure if I will be on the panel or not yet. -Joseph Carol Spears wrote: On Fri, Dec 03, 2004 at 01:06:47PM +0100, Dave Neary wrote: We now have 5 volunteers, and I think that's a nice sized panel. Thanks a lot to everyone for their answers. (should I say who the judges are? one of them replied to me off-list, so perhaps he wanted to stay anonymous...) yes, i would like to know who the judges are. there should be a global effort to track the payola. carol ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Best way for limit distance
Thanks for the suggestion. Using Joao [EMAIL PROTECTED] lead I use for now python-fu with the numarray extension. As far as I know such speedups are something scrip-fu is not capable off, and I truly hope one day script-fu will be phased out and python-fu (or any other sane scripting language) will take it's place.Others might disagree, but I don't consider perl sane :) BTW, all this was part of a small evaluation of CCD noise removal method. If you are interested, the details are in http://pages.quicksilver.net.nz/pepe/d70/Nikon_D70_on_Linux.html#ISONoise The results are quite dismaying. I appreciate any insight on the subject. However please note I am not looking for a solution for the specific image I used, but a generic one. -Joseph Øyvind Kolås wrote: On Tue, 30 Nov 2004 13:25:16 +1300, Joseph Heled [EMAIL PROTECTED] wrote: (I think this has been discussed on the list before, but not sure where/when.) What is the best way to achieve the following functionality - Given two layers L1 and L2, I want L2 limited by it's distance from L1 Result - L1 - MIN( MAX(L1 - L2), -20), 20) Options: A. Write a plugin B. Write it as a script-fu (not sure if script-fu can iterate on pixels, and what is the speed implication). And I hate scheme. C. Write it in python fu if I can compile it, but even though it is probably not as universally available as scrip-fu. Can I iterate over an image in python-fu? D. I know I can do it with 5 layers and overlay modes. write this as a script-fu. Not elegant and requires loads of memory for large images. E. extend gluas to be able to pick an auxiliary drawable for additional pixel sources, (essentially resurrecting some code I initially had in a different version of gluas, and write the expression in gluas). ( gluas is at http://pippin.gimp.org/plug-ins/gluas/ ) /pippin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Best way for limit distance
I am using gimp-2.2-pre2. I certainly get totally different results than you for the same setting. I would appreciate some advice on how to find out how can that be, -Joseph Øyvind Kolås wrote: On Fri, 03 Dec 2004 10:12:37 +1300, Joseph Heled [EMAIL PROTECTED] wrote: BTW, all this was part of a small evaluation of CCD noise removal method. If you are interested, the details are in http://pages.quicksilver.net.nz/pepe/d70/Nikon_D70_on_Linux.html#ISONoise The results are quite dismaying. I appreciate any insight on the subject. However please note I am not looking for a solution for the specific image I used, but a generic one. I think you are running with an old version of the gimp, the artifacts from the median filtering done in the Despeckle plugin doesn't look good at all in your image,. somehow it seems like the result I achieve in http://pippin.gimp.org/tmp/despeckle_adaptive_non_recursive_radius_1_black_level_0_white_level_256.png.html might be similar to what you want (note that I have run it on the jpeg version of your original.) running with a radius of 1. /pippin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Best way for limit distance
Øyvind Kolås wrote: http://pippin.gimp.org/tmp/despeckle_adaptive_non_recursive_radius_1_black_level_0_white_level_256.png.html might be similar to what you want (note that I have run it on the jpeg version of your original.) running with a radius of 1. /pippin I was careless and did not realize the jpeg will make such a big difference. I replaced the original on my page with a png file, which you can grab if you wish and see the problem for real. While your settings are definitely better, personally I find the result not good enough. And as I mentioned, the speed of the plugin is a big deterrent as well. -Joseph ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] open thumbnail and raw files
Hi, In most raw files the thumbnail exists as an embedded jpeg. I know how to read it to memory, but need advice on how to load it into gimp (i.e. create a valid image ID for it). Option a) Perhaps such functionality already exists - but I did not find it? Option b) Go through the file system - write a temporary file and load it via a PDB call. Option c) Use some jpeg library (say libjpeg) to read it. (b) is the probably the simplest, but I am not happy about going to the file system and all the issues it brings. On the other hand (c) is quite complicated. Can someone make a suggestion? Thanks, Joseph Sven Neumann wrote: Hi, a while ago Joseph Heled [EMAIL PROTECTED] wrote: The gimp Open Image dialog contains preview thumbnail. To generate them, gimp calls the plugin to generate them. Now, for raw digital camera files (.nef, .crw ...) this is a very expensive operation - and obviously one would love to use the prepared/pre-stored thumbnail which exists in the file. From what I could see, there is no way I (the plugin author) can detect if the call is for a thumbnail or not. Note that I have just added the missing API for plug-ins and also implemented the core functionality. What's missing now is some more plug-ins using this feature. See also http://bugzilla.gnome.org/show_bug.cgi?id=158190 http://bugzilla.gnome.org/show_bug.cgi?id=158191 http://bugzilla.gnome.org/show_bug.cgi?id=158192 http://bugzilla.gnome.org/show_bug.cgi?id=158193 Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] image growing size - is it true? is it normal?
Hi, I open a 3038x2012 photo (gimp 2.2-pre1). The caption below the image says 46.9 MB I add a layer with Layer/New Layer. The caption says 70.3 MB I delete the layer. Caption stays 70.3 MB I Layer/New Layer again. The caption says: 93.7 MB I delete the layer. Caption stays 93.7 MB Should I believe the numbers or not? I understand the gimp might be allocating memory and keeping it, but it does not mean the size of the image keep growing indefinitely? What am I missing? Thanks, Joseph ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] image growing size - is it true? is it normal?
Thanks for all of you who clarified this. My setting are Minimal number of undo levels - 20 Maximum Undo Memory - 64M I guess the two are in conflict for large images. I like a fairly liberal number of undo's, yet I did not realize the size can balloon in a such a way and hit 1.2G after a few applications of a scheme script (which makes liberal use of new layers), which brings gimp and the system to a long minutes of swapparoa fun. So, is there a way to limit the size per image? Or a better way to set up a machine with 750MB of memory and a large swap? Thanks, Joseph Joao S. O. Bueno Calligaris wrote: On Wednesday 17 November 2004 23:02, Joseph Heled wrote: Hi, I open a 3038x2012 photo (gimp 2.2-pre1). The caption below the image says 46.9 MB I add a layer with Layer/New Layer. The caption says 70.3 MB I delete the layer. Caption stays 70.3 MB I Layer/New Layer again. The caption says: 93.7 MB I delete the layer. Caption stays 93.7 MB Should I believe the numbers or not? I understand the gimp might be allocating memory and keeping it, but it does not mean the size of the image keep growing indefinitely? What am I missing? The information is still ther, as the layer deletion can be undone. Open the undo history dialog, and hit the clear undo history button - that is what you were missing. :-) Thanks, Joseph ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] open thumbnail and raw files
Sven Neumann wrote: Hi, Joseph Heled [EMAIL PROTECTED] writes: The gimp Open Image dialog contains preview thumbnail. To generate them, gimp calls the plugin to generate them. Now, for raw digital camera files (.nef, .crw ...) this is a very expensive operation - and obviously one would love to use the prepared/pre-stored thumbnail which exists in the file. From what I could see, there is no way I (the plugin author) can detect if the call is for a thumbnail or not. Can someone tell me if I am right or wrong? If wrong - how do I do it? If right, is there a chance this can be changed? You are right. You could suggest an API and we could consider to add it for GIMP 2.4. The most natural place is to add an optional argument to the run() gimp arguments. However I am not sure if this is possible. The plugin is a file loader, registered under Load gimp_install_procedure (file_rawphoto_load, ..., PLUG_IN_VERSION, Load/rawphoto, I guess Load implies some magic, since it is not visible in the regular menus. And perhaps 3 arguments is hardwired for such plugins? Can someone enlighten me? (P.S it would certainly make sense to run this plugin non interactively from a script, and in that case supply even additional arguments ...) -Joseph Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] open thumbnail and raw files
Sven Neumann wrote:
Hi,
Joseph Heled [EMAIL PROTECTED] writes:
Great. So what I suggest - i.e. a forth argument to run() to indicate
a request for a thumbnail should work and not break other plugins?
I think you need to make yourself familiar with the GIMP API. Did
you
ever look at the API reference manual?
Not in full, but I can't see why it will help, since this is internal
to gimp itself.
No it isn't. If I understand your approach, you suggested to add
parameters to run()
Not at all. I meant to add a parameter to 'param'
run(const gchar* name,
gint nparams,
const GimpParam* param,
...)
This affect only load plugins with 4 declared arguments (by the plugin), the
forth named thumbnail.
static GimpParamDef load_args[] =
{
{ GIMP_PDB_INT32, run_mode, Interactive, non-interactive },
{ GIMP_PDB_STRING, filename, The name of the file to load },
{ GIMP_PDB_STRING, raw_filename, URI of the file to load },
{ GIMP_PDB_INT32, thumbnail,use embedded thumbnail },
(I would need to be superman to make a working change to run() in 15 minutes ... :)
-Joseph
even though run() of course has a fixed set of
parameters. Since it is probably the most important function in the
GIMP API and implemented by all plug-ins, there is certainly not an
option to change it. What we need here is a way for load plug-ins to
register and additional procedure to load the thumbnail. This could
probably be designed in a way that would allow plug-ins to reuse their
main procedure.
I am however not going to continue this discussion in private mail. If
you want to talk about it, please use the mailing-list.
No problem. I thought it is best not to inflict my ignorance on the whole list.
Sven
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] preparing GIMP 2.2
I would argue that non interactive plugins (or interactive plugin run in non interactive mode, which I presume to be the same thing), should not bring up any progress bars. -Joseph Sven Neumann wrote: Hi, David Hodson [EMAIL PROTECTED] writes: What if there's no associated dialog? I have some plugins that call (lots of) Gimp functions non-interactively, with no image display. The result is that the progress dialog is constantly being created and destroyed. Things would be much neater if it was (optionally?) just part of the main toolbox window. The progress bar should then be part of the plug-in dialog that calls these functions. I don't think having the progress in the toolbox window is a good idea. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 16 bit Gimp?
It would be nice to be prove wrong, but I am not aware of such a plugin. Dave's (dcraw author) own plugin is just a simple text like interface o dcraw. My work is based on PTJ rawphoto, but it is already much better, I believe. Have a look at http://pages.quicksilver.net.nz/pepe/d70/Nikon_D70_on_Linux.html if you like. -Joseph David Neary wrote: Hi, Sven Neumann wrote: Joseph Heled [EMAIL PROTECTED] writes: (repeat) I am developing a plugin which loads raw images from digital cameras (CRW,NEF etc). I might be wrong, but doesn't such a plug-in exist already? One exists for dcraw (Canon's raw format). Don't know if that would work on the other formats. Shouldn't we consider including that in the main distribution for 2.2, since that type of format is now more more widespread? Who's the author? Cheers, Dave. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp-plugin-template: install
Sven Neumann wrote: Hi, Joseph Heled wrote: Can someone tell me how to configure gimp-plugin-template so that it installs locally(~/gimp-2.0) instead of the global /usr/local? gimp-plugin-template is an example of an autoconf/automake packaged plug-in that is to be installed system-wide. It doesn't handle installation to the users plug-in directory. Why should it? Because, - On some system you don't have administrative rights (say the university) - The gimp is set up to allow full plugins to be installed in ~..gimp-2.0 - 'gimptool --install' defaults to installing in ~/.gimp-2.0 -Joseph Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp plugin and gdb?
Exactly what I needed! Thanks a lot. I never wondered what's in that mysterious MAIN(). Now I know at least some of the answer :) -Joseph Manish Singh wrote: Check out the developer FAQ: http://developer.gimp.org/faq.html#id2778982 So yes, you overlooked some key things. ;) -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] gimp-plugin-template: install
Can someone tell me how to configure gimp-plugin-template so that it installs locally(~/gimp-2.0) instead of the global /usr/local? Thanks, Joseph ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] gimp-plugin-template: install
Can someone tell me how to configure gimp-plugin-template so that it installs locally(~/gimp-2.0) instead of the global /usr/local? Thanks, Joseph ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] plugin: can it tell when it is called to generate a thumnail?
The topic says it all. When the Open dialog needs to generate a preview thumbnail, it calls the open plugin non interactively. However, if the plugin knew that only a small thumbnail is needed, it can use in many cases the one stored in the file. This can result in a speed up of many orders of magnitude when raw files are the target. -Joseph ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp-plugin-template: install
David Neary wrote: Hi Joseph, Joseph Heled wrote: Can someone tell me how to configure gimp-plugin-template so that it installs locally(~/gimp-2.0) instead of the global /usr/local? configure --prefix=~/gimp-2.0 should work. But if you would like to install your plug-in in the GIMP user directory (in $HOME/.gimp-2.0/plug-ins), I don't know how to do that. which is exactly my problem. configure sets this from GIMP_LIBDIR=`$PKG_CONFIG --variable=gimplibdir gimp-2.0` And gives no way to override it. I think this is a configure mistake. -Joseph Cheers, Dave. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] OT: noise equivalence in HSV components
HSV is the wrong colorspace to use for this purpose. The LA*B* colorspace was designed to do what you are trying to accomplish: supposedly, equal distances in LA*B* coordinate space correspond to equal distances in human perceptual space -- although I understand that there is debate about whether this is really true. I might be wrong, but this will not solve it either. I assume the AB (color information) might be in the same units, but I don't think Luminosity is. (and I can make the argument that Hue and Saturation are in the same units as well, the problem being how to fit Value in) -Joseph ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Howto: store comments in image from plugin?
Thanks for all the people who answered. It turned out to be as simple as attaching a gimp-comment and jpeg-exif-data parasites to the image. (of course generating jpeg-exif-data is not trivial. Only implemented for my Nikon D70 at the moment. I guess others who like more formats will have to implement their own) -Joseph ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] OT: noise equivalence in HSV components
This is not a gimp question, but perhaps there is someone here who can shed light on this issue, How (or can you) combine errors/noise in HSV into one error/noise figure which reflects the total human visual error perception. I am sure this is not a good formulation of the question. Here is another way to put it, Take a picture I. Decompose to HSV. Now add noise Nh to H and recompose to get image I(h). Do the same for Ns to S and Nv to V. Now, what should the relation be between Nh,Ns,Nv so that a human would say All three images I(h). I(s) and I(v) look like they had the same amount of corruption relative to the original I. Now I am not necessarily asking for a rigorous answer. Any reasonable heuristic would do. -Joseph ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] 16 bit Gimp?
(repeat) I am developing a plugin which loads raw images from digital cameras (CRW,NEF etc). There is actually lots of the functionality I need support (and some I need to do) in the gimp already, if only the gimp was 16 bits ready. So, I wonder, any estimate how far in the future it is? -Joseph ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Howto: store comments in image from plugin?
(I hope this is the appropriate forum ...) I am developing a plugin which loads raw images from digital cameras (CRW,NEF etc). I would like to attach to the image some of the parameters of the conversion. I am not sure , - How do I add this info to the image (I open it with gimp_image_new(...) ) - Which file formats support this kind of comment/data? On a related issue, how can I add EXIF data to the image? Perhaps I can add some data in the EXIF comment? I would appreciate any help/ideas ... Joseph ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] compose - decompose nitpicking
Perhaps this is nitpicking, but would like your comments. (gimp 2.0.3) After decomposing an image to HSV (in layers mode), Filters/Colors/Compose brings up the following dialog: (*) RGB Red - image-HSV.jpg-3/value-8 Green - image-HSV.jpg-3/value-8 Blue - image-HSV.jpg-3/value-8 i.e. assumes RGB, and gives all channels the same layer. 1. If it possible to infer somehow that what I want (by default) is HSV, i.e the reverse? Even cluing on the layer names would work for the case where I make some changes in one layer and want to convert back. 2. Even assuming I have to check HSV manually, why not give the first 3 layers (when they exist) as the default? (for that to work, the order of the dialog has to match the order of created layers. right now it is the reverse) Thanks, Joseph ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp 2.0.2 and elusive detachabletear-ablemenus
Hi, Your remark about focus policy sent me to the KDE control center - and yes, it is a focus problem of sorts. I was running with focus strictly under mouse (CC/Look Feel/Window Behavior/Focus). When I Change that to Click to Focus, the menu remains until the window focus is lost. Would you do me a favor and see under which policy you run and if you get the same problem if you switch to another policy? (actually all you have to do is to detach a menu and switch focus by clicking on another window). Still, the menu disappears after a focus lose and does not return. This can be either a KDE bug or GTK bug. gimp 1.2 (under gtk 1.2) has no such problem since the menu has its own window, i.e.comes up with a title bar of it's own. And I have no other gtk2 program which brings up detachable menus ... Gnome is not an option right now. Even the installed one is broken after I updated the libg/gtk 2.4. I can't allow an upgrade the kill my KDE, which can happen :( -Joseph That would also be my guess. I've been using Gimp with KDE 3.[012] for some time, and although I (contrary to you) never ran into anything that I knew should work but didn't, there surely were moments that made me doubt the cleverness of its focus policy. Gnome 2.6.(2, currently) works better for me with regards to that, so I recommend that you give it a shot (if possible) and see if the problem remains, to narrow down the range of imagined possibilities. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp 2.0.2 and elusivedetachabletear-ablemenus
Yes it is certainly a KDE problem. Both WindowMaker and twm gave the menu a decoration (i.e. a title bar). Google shows that several others has encountered the problem on KDE 3.0X, and tearoff is disabled (and commented out) in KDE 3.1. I wonder if they solved it in 3.2/3.3? Thanks for your all of you who has responded !! Joseph ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Gimp 2.0.2 and elusive detachable tear-able menus
Gimp 2.0.2 and elusive detachable tear able menus Has anyone else experiences this? I can't get it to work. Say I bring the popup menu from the image, Layers, and press the dotted line. The menu detaches, but the moment the mouse leaves it it disappears. It re-shows when I switch to another desktop, but disappears the moment i try to place the mouse on it. I have no idea if this is a gtk problem, kde, or gimp?? $gimp --version GIMP version 2.0.2 $pkg-config --modversion gtk+-2.0 2.4.0 KDE 3.0.3-8 (stock from RH 8) $uname -a : Linux yoda 2.4.20-30.8.legacy #1 Fri Feb 20 18:58:10 PST 2004 i686 athlon i386 GNU/Linux Thanks, Joseph ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp 2.0.2 and elusive detachable tear-ablemenus
Please, by all means, update GTK+. Lots of bugs have been fixed in the 2.4 series and still using 2.4.0 is sortof lightheaded. Life is sort of slow with a 56K modem. Updated gtk+, glib and atk. The problem remains $pkg-config --modversion gtk+-2.0 2.4.4 $pkg-config --modversion glib-2.0 2.4.4 I guess that if no one else has this problem, it is a kde problem. I know there is a kde-3.0.5 available for RH 8.0, but I doubt something as obscure has been fixed in such a small upgrade. -Joseph ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
