Re: Problem building an gimp-1.1.32 RPM
Henning Sauer [EMAIL PROTECTED] writes: today I tried to build a an rpm of gimp-1.1.32 from the source via "rpm -ta gimp-1.1.32.tar.bz2", but it didn't work because in the installation phase it couldn't find the gimp executable in the /usr/bin directory under BuildRoot. Instead the gimp exectuable as well as the plug-ins, modules and libraries where directly installed to /usr. Is their a way to correct this behaviour and build an RPM ? Yes, there is indeed. Someone needs to correct the spec file that is distributed with The GIMP. This file is unmaintained at the moment and I wonder if we should probably remove it from 1.2 if noone takes care of fixing it. Salut, Sven
Re: divide by 255
On Wed, Dec 20, 2000 at 08:19:01PM +, Nick Lamb wrote: 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. This would probably be OK for display, but it's not acceptable in the Gimp's internals where errors might propagate. Oh, this reminds me something about the alpha channel I would qualify as a bug, but maybe I misunderstood something: Alpha to selection + invert + paint does NOT fill the whole alpha channel. Is this the correct behaviour ? Steps to reproduce: - New image/100x100 RGB White - Foreground color: Black - Filters/Render/Pattern/Grid/1 2 0 - New layer/100x100 Transparent - Foreground color: Red - Brush: Circle Fuzzy 19 - Tool: Paint brush = Do draw something (let's say: a cross) - Layers/Alpha to selection - Select/Invert - Tool: Fill (options: 100 Normal 255) = Do fill You should have a red square, but the cross is still here. Jerome.
Re: Pupus pipeline: what Adam has been doing, etc. etc.
[lots of interesting stuff and ASCII art not quoted] Does this mean we can do something like xRes, ie. process first a `preview' in low-res (to show to the user) and then, as an idle task (or possibly even scheduled for later work, do the full-res version? /* Steinar */ -- Homepage: http://members.xoom.com/sneeze/
Re: Pupus pipeline: what Adam has been doing, etc. etc.
Hi Adam, On Thu, Dec 21, 2000 at 11:15:17PM +, Adam D. Moss wrote: How would the "pupus" functionality be directly exposed to users? The answer is that it most assuredly WOULD NOT. I do not advocate, in fact I ABHOR the idea that the user should end up drawing a little tree of boxes connected with wires. That's your view as a programmer I want it! Hey, this is interactive Script-Fu! There should definitely be an option to view and manipluate the trees. The possibilities are endless. (e.g.: change a Dynamic Text and have changes propagate automatically; very nice for batch jobs - perform task once, launch "feed-and-save-lots-of-images" plugin and tell it what files to load and where to save them; etc. etc.) BTW: I thought about such a concept myself but not very detailed. This is a MUST for GIMP 2.0. It's written from scratch anyway so we could back it with some heavy tech like Adam's. Bye, Tino. -- * LINUX - Where do you want to be tomorrow? * http://www.tu-chemnitz.de/linux/tag/ 3rd Chemnitzer Linux-Tag from 10th to 11th March 2001 at Chemnitz University of Technology!
Re: Problem building an gimp-1.1.32 RPM
Henning Sauer wrote: Is their a way to correct this behaviour and build an RPM ? Certainly. I'd be happy to look at the RPM file and fix it. Its probably a minor thing. Everytime I look at .spec files I learn something. The problem is that with Christmas just about here, I may (but may not) have a chance to look at it later today or early tomorrow. If not, I won't be able to look at this until sometime in the afternoon on the 27th of this month at the earliest. I'm tempted to have my name put down as the maintainer of the .spec file as I like building RPMs when needed. I have rolled a few of my own already from source files. I do have a remote site I administer where I could store SRPM and RPM files. Consider my name written down in pencil for now. After Christmas I'll see if it will get written down in ink. Happy holidays to everyone! Cheers! Kevin. (http://www.interlog.com/~kcozens/) Internet:kcozens at interlog.com |"What are we going to do today, Borg?" or:ve3syb at rac.ca |"Same thing we always do, Pinkutus: Packet:ve3syb@va3bbs.#scon.on.ca.na| Try to assimilate the world!" #include disclaimer/favourite| -Pinkutus the Borg
Re: Pupus pipeline: what Adam has been doing, etc. etc.
Hi, all.
I want it! Hey, this is interactive Script-Fu! There should definitely
be an option to view and manipluate the trees. The possibilities are
endless. (e.g.: change a Dynamic Text and have changes propagate
automatically; very nice for batch jobs - perform task once, launch
"feed-and-save-lots-of-images" plugin and tell it what files to load and
where to save them; etc. etc.)
Just to throw some info on this truly exciting idea for Gimp, I ask
you dudes to take a look at Khoros, which is a package mainly aimed at
image processing. It uses something similar to such boxes, called
'glyphs'. It even has a visual editor to construct dataflows, called
Cantata.
It's a pity, Khoros used to be free (in the beer sense, anyway), but
now you have to pay for it. Its website is rather scarce of
screenshots, but you can take a look at:
http://www.khoros.com/
http://www.khoros.com/khoros/cantata_desc.html
From what I remember from an early version that I used at
university, each box runs as a separate Unix process with the data
passed in a standard file format through pipes. I guess this can be
much more improved preformance-wise...
BTW, their white paper has few more details and images:
http://www.khoros.com/ideas/technology/cantata.pdf
Regards,
Marcelo Malheiros
--
%!PS % Marcelo de Gomensoro Malheiros [EMAIL PROTECTED] % USE LINUX
/d{def}def/r{rotate}d/t{translate}d/F{0 0 moveto 2 0 lineto 2 0 t stroke}d
/X{dup 0 eq{}{dup 1 sub X -90 r Y F -90 r pop} ifelse}d/Y{dup 0 eq{}{dup 1
sub 90 r F X 90 r Y pop} ifelse}d 220 300 t 15 X pop showpage
Re: Problem building an gimp-1.1.32 RPM
Henning Sauer wrote: Is their a way to correct this behaviour and build an RPM ? I managed to take a quick look in to this. I believe the problem is not with the spec file but with the Makefile's. The 'make install' invoked by the spec file is installing gimp, gimp-tool, gimp-remote, and a sym link for gimp-config in to /usr/bin instead of into the directory specified by the prefix= and PREFIX= arguments passed on the command line to the make program. Cheers! Kevin. (http://www.interlog.com/~kcozens/) Internet:kcozens at interlog.com |"What are we going to do today, Borg?" or:ve3syb at rac.ca |"Same thing we always do, Pinkutus: Packet:ve3syb@va3bbs.#scon.on.ca.na| Try to assimilate the world!" #include disclaimer/favourite| -Pinkutus the Borg
Re: Pupus pipeline: what Adam has been doing, etc. etc.
"Adam D. Moss" wrote: The somewhat-simplified idea common to both proposals is that a list/tree of little black boxes is set up, where images get fed into the tree at the bottom, get chewed up by the black boxes through which they are sequentially sent, and at the end of the line comes a result. Adam, this all sounds very cool and I'd love to see what code you've got, keep in touch and check how things are progressing. Do you have any experience with commercial systems that work this way? It's getting to be popular for 3d as well as 2d stuff. By the way, don't get too upset about the user drawing lines between boxes - it may not be the best interface, but it can be very useful to be able to access that level, and some of the top effects systems use nothing else. You might want to take a look at my (very alpha) efforts at: http://www.ozemail.com.au/~hodsond/gimpeon.html Like you, I'm far too short of time to work on all this stuff. Been busy bugfixing Gimp and working on some plugins recently, but I might be able to find some time over the holidays to get some more work done on it. -- David Hodson -- [EMAIL PROTECTED] -- this night wounds time
Re: Bug#35315: Right.
On Fri, Dec 22, 2000 at 12:26:54PM -0600, Federico Mena Quintero wrote: "Adam D. Moss" [EMAIL PROTECTED] writes: Right, this is a bad-data problem, and "WON'T FIX". The source XCF image contains pixels with an index of 34 (the screen on the computer icon) but only declares a palette of 20 colours. Why? You tell me! Had the original image been anywhere near a really old version of GIMP? There was a palette bug from GIMP 0.53.0 - 0.99.low-x which could cause such a problem. The GIMP should not crash on a corrupt image file. Ever. The GIMP should not crash, ever. Period. Gimp is in userspace and running on hardware, so the latter is a bit harsh IMHO. Let's say rather "Gimp should not cause itself to crash" Hmmm. Use a fixed 256 RGB triples in the palette, then change existing code to only overwrite it, never re-allocate. Out-of-bounds index values will not have a defined color, but they won't crash. The "size" of the palette can still be an internal variable, it just won't reflect the _literal_ size of the palette array. This is safe and easy. More "thorough" fixes can be left for another version of Gimp I think. Nick.
