Re: Gimp to MacOS
Hello, pixel fairy wrote: > > impress is probably as good as weve got for a page layout app. so > something like that would be a good development, especially with your > experience. > > we do need good non linear animation, I, and others. are working on that with matterial ( http://matterial.sourceforge.net/ ). > but i think the best way to do that > would be to build it around the gimp, alot like GAP, Although the GIMP's interface is great as a graphics editor, it is not that great as a non-linear editor. See ya Charles Iliya Krempeaux
Re: Gimp to MacOS
On 7/23/2000 19:22, Jason T. Slack at [EMAIL PROTECTED] wrote: > Is there a nice Desk-top publishing app for Linux out? (Something Like Quark > Xpress, PageMaker or Indesign?) there is a version of FrameMaker available for Linux as a beta. It's currently free, but once the beta is done, that may change. -- __ _ Carl B. Constantine / / (_)__ __ __ [EMAIL PROTECTED] / /__/ / _ \/ // /\ \/ / (2.2.14)http://www.pobox.com/~macman //_/_//_/\_ _/ /_/\_\ Stormix 2000 PGP key available on request VLUG - Victoria Linux Users GroupICQ: 26351441
Re: Gimp to MacOS
impress is probably as good as weve got for a page layout app. so something like that would be a good development, especially with your experience. we do need good non linear animation, but i think the best way to do that would be to build it around the gimp, alot like GAP, but to support some the cool features of mng and other such niceities the export would have to be directly from it, not back to the gimps layered amination thing. meaning it would have its own format which i would either include the xcf files or pointers to them (like in index in a directory, which may really be a tgz file or some such). wonder how hard sound syncronization would be... anyway, theres some stuff for you to think about. hope it helps. > So maybe GIMP is not an option for me to work on. However, I want to develop > something. I have approximately 6 years of C/C++ experience with assembler > developing commercial applications. My interests are graphics, Desk-top > publishing and system level utilities. > > Is there a nice Desk-top publishing app for Linux out? (Something Like Quark > Xpress, PageMaker or Indesign?) I have used Quark and developed extensions > for it for years, I have also written a few Photoshop plug-ins. As far as > system apps, I like writing disk utilities, I started writing ghosting > software a year or so ago before I finished college. > > Can anybody help me decide where to focus my efforts? I don't really want to > duplicate efforts if someone else is trying to do something. However, I > would like to contribute to bringing quality, commercial, and professional > open software to the community. > > So can anybody give me suggestions as what to develop, what is needed out > there, everytime I want to do something, it seems that someone else is > either doing it, or it is done. > > Sorry for the Off-topic post and the cross post, but I think that perhaps > your input can help me out. > > Jason >
Re: Gimp to MacOS
Charles Iliya Krempeaux wrote: > > "Jason T. Slack" wrote: > > So maybe GIMP is not an option for me to work on. However, I want to develop > > something. I have approximately 6 years of C/C++ experience with assembler > > developing commercial applications. My interests are graphics, Desk-top > > publishing and system level utilities. > > > > Is there a nice Desk-top publishing app for Linux out? (Something Like Quark > > Xpress, PageMaker or Indesign?) > > I haven't used any of those, but from what I guessing their just Vector graphic > programs. So,... as for existing projects for Vector Graphic programs, there > is... > > GYVE > Sketch > KIllustrator > Sodipodi > TGIF The 5 programs listed above are vector graphic based editors. The programs Jason named are all desktop publishing programs. Very roughly speaking they are highly specialized word processors. Many current word processors have some features normally found in DTP packages. Vector graphics programs is an area which seems to be covered quite nicely now. We have many text editors and a word processor or so around. A Linux DTP package would be nice to have. I used to use Professional page on my Amiga some years back but the word processor allows me to do what I used to use PPage for although not as well. Jason, search the Linux software project listings. If you don't find a DTP package in the works and you think this is something you would like to do, then go right ahead. Let me know if you start such a project. I can't promise to help much however as I am involved in several other projects right now.
Re: Gimp to MacOS
Hello, "Jason T. Slack" wrote: > > on 7/23/00 3:30 PM, Charles Iliya Krempeaux at [EMAIL PROTECTED] wrote: > > > :-) This isn't my project. The port is being done by Jason T. Slack > > <[EMAIL PROTECTED]> . > > > > I've got enough work, working on matterial ( http://matterial.sourceforge.net/ > > ). > > Ok, I am cross posting this to both Gimp-Devel and GTK-Devel (So Be careful > with the 'reply to all') > > Here the scoop: > > It seems that others are porting GTK+ to Mac OS X. Can you port GIMP to OS X > without GTK+ being there? Not really yet I understand. > > So maybe GIMP is not an option for me to work on. However, I want to develop > something. I have approximately 6 years of C/C++ experience with assembler > developing commercial applications. My interests are graphics, Desk-top > publishing and system level utilities. > > Is there a nice Desk-top publishing app for Linux out? (Something Like Quark > Xpress, PageMaker or Indesign?) I haven't used any of those, but from what I guessing their just Vector graphic programs. So,... as for existing projects for Vector Graphic programs, there is... GYVE http://www.gyve.org/ Sketch http://sketch.sourceforge.net (Although parts of it are in Python,... as well as C.) KIllustrator http://wwwiti.cs.uni-magdeburg.de/~sattler/killustrator.html (It uses QT, not GTK+ though.) Sodipodi http://sodipodi.sourceforge.net/ TGIF http://bourbon.cs.umd.edu:8001/tgif/ (There's probably more. Just search around.) > I have used Quark and developed extensions > for it for years, I have also written a few Photoshop plug-ins. As far as > system apps, I like writing disk utilities, I started writing ghosting > software a year or so ago before I finished college. > > Can anybody help me decide where to focus my efforts? Well, if you're determined to work on a vector graphic application, then you have the list above. But, if you are also considering things more broad than that (... more broad than just vector graphics applications...) then I can give you an even larger list of projects to choose from. > I don't really want to > duplicate efforts if someone else is trying to do something. However, I > would like to contribute to bringing quality, commercial, and professional > open software to the community. > > So can anybody give me suggestions as what to develop, what is needed out > there, everytime I want to do something, it seems that someone else is > either doing it, or it is done. > > Sorry for the Off-topic post and the cross post, but I think that perhaps > your input can help me out. Hope that helps. See ya Charles Iliya Krempeaux
Re: Gimp to MacOS
on 7/23/00 3:30 PM, Charles Iliya Krempeaux at [EMAIL PROTECTED] wrote: > :-) This isn't my project. The port is being done by Jason T. Slack > <[EMAIL PROTECTED]> . > > I've got enough work, working on matterial ( http://matterial.sourceforge.net/ > ). Ok, I am cross posting this to both Gimp-Devel and GTK-Devel (So Be careful with the 'reply to all') Here the scoop: It seems that others are porting GTK+ to Mac OS X. Can you port GIMP to OS X without GTK+ being there? Not really yet I understand. So maybe GIMP is not an option for me to work on. However, I want to develop something. I have approximately 6 years of C/C++ experience with assembler developing commercial applications. My interests are graphics, Desk-top publishing and system level utilities. Is there a nice Desk-top publishing app for Linux out? (Something Like Quark Xpress, PageMaker or Indesign?) I have used Quark and developed extensions for it for years, I have also written a few Photoshop plug-ins. As far as system apps, I like writing disk utilities, I started writing ghosting software a year or so ago before I finished college. Can anybody help me decide where to focus my efforts? I don't really want to duplicate efforts if someone else is trying to do something. However, I would like to contribute to bringing quality, commercial, and professional open software to the community. So can anybody give me suggestions as what to develop, what is needed out there, everytime I want to do something, it seems that someone else is either doing it, or it is done. Sorry for the Off-topic post and the cross post, but I think that perhaps your input can help me out. Jason
Re: The Gimp is wasting a lot of memory
On Mon, Jul 24, 2000 at 12:16:30AM +0200, Tomas Ogren <[EMAIL PROTECTED]> wrote: > > operations (rectangular select, crop, flip, and I'll write the > > striping thing) on huge images? That would save the reputation of > > Linux in front of those guys. > > ImageMagick? Available on just about every Unix, Windows etc. Ehrm, his problem was memory consumption ;) ImageMagick is quite a hog, as it opzimizes for quality much more than even gimp (which IMHO also favours quality over speed). -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: The Gimp is wasting a lot of memory
On Sun, Jul 23, 2000 at 04:01:37PM -0500, [EMAIL PROTECTED] wrote: > I'm not sure if the projection buffer is constructed conservatively or > not. As I recall projection is done bottom-up instead of top-down, > which makes conservative construction difficult. I planned a top-down No matter what, gimp-2.0 _will_ be conservative about allocating tiles. I know, this doesn't help much yet ;) -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: The Gimp is wasting a lot of memory
On 23 July, 2000 - somnorici sent me these 2.8K bytes:
> Do you guys know of any open-source program for linux that does simple
> operations (rectangular select, crop, flip, and I'll write the
> striping thing) on huge images? That would save the reputation of
> Linux in front of those guys.
ImageMagick? Available on just about every Unix, Windows etc.
/Tomas
--
Tomas Ögren, [EMAIL PROTECTED], http://www.ing.umu.se/~stric/
|- Student at Computing Science, University of Umeå
`- Sysadmin at {cs,ing,acc}.umu.se
Re: The Gimp is wasting a lot of memory
On Sun, 23 Jul 2000 20:45:32 -, "somnorici " <[EMAIL PROTECTED]> said: >Kelly: no, I'm not asking gimp to not store the image decompressed, I >just want it to use a display buffer sized to the window size, not to >the image size. Of course, several copies of the image (in this case >105megs) will be used for layers, alpha, undo, whatever. However, >when I crop and I have zero levels of undo, the swap file size should >not grow! If I work on a rectangular selection, there should be no >working copy, just work on the current image. I'm not sure if the projection buffer is constructed conservatively or not. As I recall projection is done bottom-up instead of top-down, which makes conservative construction difficult. I planned a top-down revision once but never implemented it because it was too extensive a change. If we had top-down projection, the projection buffer would only be populated by those tiles actually needed for the displayed region. The entire tile manager would be allocated, of course, but only those tiles actually accessed would be populated. I've also wanted to allow for a left and top offset into tile memory so that tiles could be partially shared. This makes crop a zero-copy operation; the cropped image would reference the same tiles with left and top offsets. Again, never done because of the extensiveness of modification required. Kelly
Re: The Gimp is wasting a lot of memory
That's the point: I need no alpha, layers or something. Just a rectangular selection for crop, flip and a simple striping plugin (which I wrote). And the swap file went to three times the size by just loading the image, not even moving or clicking the mouse, zero undo levels. 64 megs of ram is just for testing the behaviour. The machine that was supposed to do this job was upgraded to 256 megs of ram. I didn't dare to count the time spent there watching gimp load a 10 meg tiff file, which caused gimp to grow the swap to about 1.7 gig, then when I tried to crop it, grew the swap to 2.whatever gig (the file size limit on ext2fs), then filled up the ram, then crashed. I guess it was at least half an hour for all this. And it was with 0 undo levels, and 190 megs tile cache size. Kelly: no, I'm not asking gimp to not store the image decompressed, I just want it to use a display buffer sized to the window size, not to the image size. Of course, several copies of the image (in this case 105megs) will be used for layers, alpha, undo, whatever. However, when I crop and I have zero levels of undo, the swap file size should not grow! If I work on a rectangular selection, there should be no working copy, just work on the current image. The sad part is that the company that asked me to do this told me to skip it 'cause it's not working. They reverted to using a *cough*win*cough*dows program which loads and displays and flips and crops in seconds (!) and they're striping the images manually because it's faster than gimp. Ouch, that hurts... I'm going to ask them and find out the hard/soft config of that machine. Gimp is great: it has many complex features, but they work on small images (compared to these which get to be meters of printing on a A3 printer). Do you guys know of any open-source program for linux that does simple operations (rectangular select, crop, flip, and I'll write the striping thing) on huge images? That would save the reputation of Linux in front of those guys. Thanks, -Oliver --- In [EMAIL PROTECTED], [EMAIL PROTECTED] wrote: > On 20 Jul, somnorici wrote: > > > I set the undo levels to zero and loaded an image. 9376 by 11488 > > pixels grayscale is 107,711,488 bytes. My display depth is 16 bits. It > > didn't take long to link this with the swap file, which after > > loading the image was 292,421,632 bytes, plus the 32 megs of tile > > cache (it's on a 64 megs machine used for testing), it kinda equals > > three times the size of the image. > > The raw data are 105 MB without alphachannels, layers or something > else. GIMP may be more efficient with memory, but I don't think > it's such a big issue which would lead us to reconsider the memory > management before our 1.2 release. 64 MB of main memory won't make > you happy with that imagesizes anyway > > -- > > Servus, >Daniel
Re: Gimp to MacOS
Hello, [EMAIL PROTECTED] wrote: > > On 23 Jul, Charles Iliya Krempeaux wrote: > > > OK, I'll do that (eventually). But my point is, if X Windows isn't > > available on every Mac system... or at least if they can't get it > > for free... then it is worth porting the GIMP (and GTK+, GDK, etc) to > > the native MacOS API. > > I'm not against a port. If you'd like to do that, feel free to start > hacking. As soon as I have my G4 box I may start helping you but until > then you have to find other poeple with knowledge of Mac API's and stuff > like that to port gdk over to it :-) This isn't my project. The port is being done by Jason T. Slack <[EMAIL PROTECTED]> . I've got enough work, working on matterial ( http://matterial.sourceforge.net/ ). (I've just been participating in the thread, because I know people, Mac users, who would love to have the GIMP on their computers.) Sorry if I gave the impression that I was doing all this. You should talk to him if you'd like to work on it at all. (The only time I've ever got a Mac to use, is when I can borrow one of my friend's PowerBooks.) See ya Charles Iliya Krempeaux
Re: Gimp to MacOS
On 23 Jul, Charles Iliya Krempeaux wrote: > OK, I'll do that (eventually). But my point is, if X Windows isn't > available on every Mac system... or at least if they can't get it > for free... then it is worth porting the GIMP (and GTK+, GDK, etc) to > the native MacOS API. I'm not against a port. If you'd like to do that, feel free to start hacking. As soon as I have my G4 box I may start helping you but until then you have to find other poeple with knowledge of Mac API's and stuff like that to port gdk over to it -- Servus, Daniel
Re: Gimp to MacOS
Hello, [EMAIL PROTECTED] wrote: > > On 23 Jul, Charles Iliya Krempeaux wrote: > > > Will it be free? Will it be a standard part of MacOS? > > (Or is it something Mac users will have to pay for?) > > Sorry, I have got no details handy. Read about it on slashdot or > somewhere. Have a look at the usual MAC places to get info about that... OK, I'll do that (eventually). But my point is, if X Windows isn't available on every Mac system... or at least if they can't get it for free... then it is worth porting the GIMP (and GTK+, GDK, etc) to the native MacOS API. After all, if (almost) nobody has X Windows on the Mac (because you have to pay for it), then nobody will be using a GIMP (that needs X Windows on the Mac to run). It was the same with the (MS) Windows version of the GIMP. Sure, you could tell people to go buy X Windows for (MS) Windows. But who was going to do that. That's why the GIMP (and GTK+, GDK, etc) got ported over to the native (MS) Windows' API. (There was actually an X Windows version of the GIMP for Windows around before, but how many people could use it?) See ya Charles Iliya Krempeaux
Re: Gimp on MacOS
On Fri, 21 Jul 2000 16:09:31 -0400, "Jason T. Slack" <[EMAIL PROTECTED]> said: >A question: (An odd question) How did GIMP get permission to use the >same Icons in the toolbox as Photoshop. Did they have to goto Adobe >and get permission? They just look the same. Doctrine of merger would probably apply (there's only so many ways to draw a paintbrush). Kelly
Re: The Gimp is wasting a lot of memory
On Thu, 20 Jul 2000 21:45:05 -, "somnorici " <[EMAIL PROTECTED]> said: >I set the undo levels to zero and loaded an image. 9376 by 11488 >pixels grayscale is 107,711,488 bytes. My display depth is 16 >bits. It didn't take long to link this with the swap file, which >after loading the image was 292,421,632 bytes, plus the 32 megs of >tile cache (it's on a 64 megs machine used for testing), it kinda >equals three times the size of the image. Yes, because there's a selection mask of equal size to the image, and a projection buffer, also of equal size to the image. Although I think that if there's no selection mask, that tilemanager should be unallocated, and when there's only one layer, the background layer doubles as the projection buffer, so there shouldn't be a separate projection buffer. It's been quite a while since I dug around in this part of the code, though. >This takes me to the conclusion that gimp kindly allocates the memory >for storing the image after extracting it from the file, and the >whole image used for displaying, instead of only 3-7% which is >actually used for an image so big. Now this is a serious thing, and >I'll have to start digging the source to fix it... Is there anyone >else aware/working on this issue? Well, it has to allocate the memory to store the image somewhere, even for parts that aren't presently being viewed. It's not practical to swap image data from the source file; most image storage formats are compressed such that it is not possible to read data out of the file except sequentially from the start. Kelly
Re: Gimp to MacOS
On 23 Jul, Charles Iliya Krempeaux wrote: > Will it be free? Will it be a standard part of MacOS? > (Or is it something Mac users will have to pay for?) Sorry, I have got no details handy. Read about it on slashdot or somewhere. Have a look at the usual MAC places to get info about that... -- Servus, Daniel
Re: Gimp to MacOS
Hello, Will it be free? Will it be a standard part of MacOS? (Or is it something Mac users will have to pay for?) See ya Charles Iliya Krempeaux [EMAIL PROTECTED] wrote: > > On 21 Jul, Michael Natterer wrote: > > > I guess that Gtk+ and Gimp will run more or less automatically > > on MacOS X' BSD API once there is an X server, so there should > > be no need to "port" it. > > A X server for MacOS is due to be released by Apple, soon > > -- > > Servus, >Daniel
Re: The Gimp is wasting a lot of memory
On 20 Jul, somnorici wrote: > I set the undo levels to zero and loaded an image. 9376 by 11488 > pixels grayscale is 107,711,488 bytes. My display depth is 16 bits. It > didn't take long to link this with the swap file, which after > loading the image was 292,421,632 bytes, plus the 32 megs of tile > cache (it's on a 64 megs machine used for testing), it kinda equals > three times the size of the image. The raw data are 105 MB without alphachannels, layers or something else. GIMP may be more efficient with memory, but I don't think it's such a big issue which would lead us to reconsider the memory management before our 1.2 release. 64 MB of main memory won't make you happy with that imagesizes anyway -- Servus, Daniel
Re: please
On 21 Jul, blue wrote: > i will try and compile this today and see if i have the same > problems. have you tried compiling one of the 1.2 versions? I suggested him to try the latest stable glib and gtk+ version as well as the latest unsatble GIMP because it work compile and work a lot nicer on non Intel machines. Unfortunately insists on porting 1.0.4 whyever -- Servus, Daniel
Re: Gimp to MacOS
On 21 Jul, Michael Natterer wrote: > I guess that Gtk+ and Gimp will run more or less automatically > on MacOS X' BSD API once there is an X server, so there should > be no need to "port" it. A X server for MacOS is due to be released by Apple, soon -- Servus, Daniel
