Re: [Gimp-user] large tile sizes and large images on Freebsd [solved]
Bram Van Steenlandt wrote: > Hi list, > > I run FreeBSD 6.2 (2 gig ram) and use gimp-2.2.17 for editing my large > (1x1pixels) photos. > This works when the tile cache is set to 256MB but this is not enough > for fast editing. > When I set the tile cache to 512MB or more it stops with error: > GLib-ERROR **: gmem.c:135: failed to allocate 16384 bytes > I checked in top while the gimp was opening the image and I still had > 400MB free before it stopped (not counting my 4000MB free swap). > After asking the gnome/freebsd guys some nice person said I should try adding kern.maxdsiz=1073741824 to /boot/loader.conf and reboot. This worked, the gimp now opens the large files when the tile cache is set to 512MB, editing is the same speed as fedora. turning off the layer preview things also helped a lot. I tried krita but it crashed when I asked to do a 90 degree turn. nip2 opened the files ok but it's kind of a strange program to work with. thanks all for the answers ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] large tile sizes and large images on Freebsd
Hi, On Wed, 2007-08-08 at 23:17 +0200, Bram Van Steenlandt wrote: > -Can't the gimp be configured to not save to disk after every edited pixel ? > If you put one pencil dot on an image it takes 4 seconds before you can > do the next. One thing that really helps a lot if you are low on memory and a lot of your image data is swapped out is to disable the generation of layer and channel previews. This is a setting in the Preferences dialog. Give it a try. Sven ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] large tile sizes and large images on Freebsd
Hi, On Wed, 2007-08-08 at 23:17 +0200, Bram Van Steenlandt wrote: > When I set the tile cache to 512MB or more it stops with error: > GLib-ERROR **: gmem.c:135: failed to allocate 16384 bytes No idea what is causing this. You should get your hands on copies of glib, gtk+ and gimp that include debugging symbols and run it in gdb. The stack trace will help us to find out what is going wrong here. > -Is there a way to work in ram only ? Sure, just set the tile-cache size large enough. It even makes sense to set it larger than the amount of physical RAM. If you think your OS is doing a better job swapping than GIMP does, then let it do the work and assign all your virtual memory to GIMP. Sven ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] large tile sizes and large images on Freebsd
On Wednesday 08 August 2007 18:31:10 jim feldman wrote: > Bram Van Steenlandt wrote: > > Hi list, > > > > I run FreeBSD 6.2 (2 gig ram) and use gimp-2.2.17 for editing my large > > (1x1pixels) photos. > > This works when the tile cache is set to 256MB but this is not enough > > for fast editing. > > When I set the tile cache to 512MB or more it stops with error: > > GLib-ERROR **: gmem.c:135: failed to allocate 16384 bytes > > I checked in top while the gimp was opening the image and I still had > > 400MB free before it stopped (not counting my 4000MB free swap). > > > > I have another computer with Fedora 7 and less RAM (1 gig) and here this > > does work, tile size is set to 512MB and editing is rather fast. > > > > I found this old thread: > > http://www.mail-archive.com/gimp-user@lists.xcf.berkeley.edu/msg07633.htm > >l wich a bit the same. > > > > So my questions are: > > -Is there some magic setting wich allows the tile size to be bigger ? > > -Can't the gimp be configured to not save to disk after every edited > > pixel ? If you put one pencil dot on an image it takes 4 seconds before > > you can do the next. > > -Is there a way to work in ram only ? > > Can I for example buy 2 additional gig and then force the gimp to use > > only this memory and give me a messages "out of memory" when this does > > not work > > > > ideas > > As the original poster of that thread, let me tell you what I know. > 1. No magic. I assume there's something bad happening between glib and > the FreeBSD memory allocation routines, but whatever it is carried > across 5.3 to 6.2. I'm pretty sure I logged a bugzilla case, but in the > end, I switched to a linux platform and lost interest. I get the > feeling that the GIMP devs don't use FBSD and as long as it builds and > runs, they're not all that interested in what seems like corner cases. > 2. You could try setting undo level to 0 at the risk of not being able > to recover from any mistake > 3. nope, at least not that I've found > 4. nope > > Don't bother with film-gimp or whatever they're calling the project > these days. It does HDR, but their big memory handling is even worse. > Turns out that the images projected in theaters are actually not all > that hi rez. Your eye fills in the missing spots frame by frame. If > you built KDE for your desktop, you might want to check out Krita as an > image editor. Last I looked at it (which is maybe 9 mos), I still > liked the GIMP better, but it (krita) handles images completely > differently, so it might be worth a shot. Didn't get a chance to run > any of my scans through it. > As a fellow and long time freebsd user I am puzzled why you should want to take such large images and process them using gimp which can only handle 8 bit per channel rather than 16bit. The concommitant loss of image quality makes this a no-no for me. I cannot image you are scanning images at 8 bit per channel. I concur with the last poster - look at krita or if you have an appropropriate alternative platfrom one of the latest versions of photoshop might be better. I am sorry to sayIMHO that (atm) there is nothing in the open source community that matches photoshop until gimp gets its act together to provide support for 16 bit (which I understand may be with us soon) and an optional GUI that makes the learning curve transition from photoshop to gimp relatively smooth. Personally, much as I would prefer to use gimp on my freebsd platform, I only use it for trvial image manipulation tasks until it has support for 16 bit and handling large image files more smoothly on all platforms. Gimp could have a wonderful future but I fear, for reasons I will not discus here, that it will always fall short of its real potential. Best of luck Freebsd gimp user ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] large tile sizes and large images on Freebsd
Bram Van Steenlandt wrote: > Hi list, > > I run FreeBSD 6.2 (2 gig ram) and use gimp-2.2.17 for editing my large > (1x1pixels) photos. > This works when the tile cache is set to 256MB but this is not enough > for fast editing. > When I set the tile cache to 512MB or more it stops with error: > GLib-ERROR **: gmem.c:135: failed to allocate 16384 bytes > I checked in top while the gimp was opening the image and I still had > 400MB free before it stopped (not counting my 4000MB free swap). > > I have another computer with Fedora 7 and less RAM (1 gig) and here this > does work, tile size is set to 512MB and editing is rather fast. > > I found this old thread: > http://www.mail-archive.com/gimp-user@lists.xcf.berkeley.edu/msg07633.html > wich a bit the same. > > So my questions are: > -Is there some magic setting wich allows the tile size to be bigger ? > -Can't the gimp be configured to not save to disk after every edited pixel ? > If you put one pencil dot on an image it takes 4 seconds before you can > do the next. > -Is there a way to work in ram only ? > Can I for example buy 2 additional gig and then force the gimp to use > only this memory and give me a messages "out of memory" when this does > not work > > ideas As the original poster of that thread, let me tell you what I know. 1. No magic. I assume there's something bad happening between glib and the FreeBSD memory allocation routines, but whatever it is carried across 5.3 to 6.2. I'm pretty sure I logged a bugzilla case, but in the end, I switched to a linux platform and lost interest. I get the feeling that the GIMP devs don't use FBSD and as long as it builds and runs, they're not all that interested in what seems like corner cases. 2. You could try setting undo level to 0 at the risk of not being able to recover from any mistake 3. nope, at least not that I've found 4. nope Don't bother with film-gimp or whatever they're calling the project these days. It does HDR, but their big memory handling is even worse. Turns out that the images projected in theaters are actually not all that hi rez. Your eye fills in the missing spots frame by frame. If you built KDE for your desktop, you might want to check out Krita as an image editor. Last I looked at it (which is maybe 9 mos), I still liked the GIMP better, but it (krita) handles images completely differently, so it might be worth a shot. Didn't get a chance to run any of my scans through it. ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
[Gimp-user] large tile sizes and large images on Freebsd
Hi list, I run FreeBSD 6.2 (2 gig ram) and use gimp-2.2.17 for editing my large (1x1pixels) photos. This works when the tile cache is set to 256MB but this is not enough for fast editing. When I set the tile cache to 512MB or more it stops with error: GLib-ERROR **: gmem.c:135: failed to allocate 16384 bytes I checked in top while the gimp was opening the image and I still had 400MB free before it stopped (not counting my 4000MB free swap). I have another computer with Fedora 7 and less RAM (1 gig) and here this does work, tile size is set to 512MB and editing is rather fast. I found this old thread: http://www.mail-archive.com/gimp-user@lists.xcf.berkeley.edu/msg07633.html wich a bit the same. So my questions are: -Is there some magic setting wich allows the tile size to be bigger ? -Can't the gimp be configured to not save to disk after every edited pixel ? If you put one pencil dot on an image it takes 4 seconds before you can do the next. -Is there a way to work in ram only ? Can I for example buy 2 additional gig and then force the gimp to use only this memory and give me a messages "out of memory" when this does not work ideas ? kind regards below is the full output: $ gimp --debug-handlers --stack-trace-mode always scan13.tif GLib-ERROR **: gmem.c:135: failed to allocate 16384 bytes aborting... gimp: terminated: Abort trap: 6 #0 0x28cea6cd in wait4 () from /lib/libc.so.6 #1 0x28cc96ad in waitpid () from /lib/libc.so.6 #2 0x28c75242 in waitpid () from /lib/libpthread.so.2 #3 0x28a3ad79 in g_on_error_stack_trace () #4 0x080646b4 in ?? () #5 0x083ace00 in ?? () #6 0xbfbfd560 in ?? () #7 0x in ?? () #8 0x24075e00 in ?? () #9 0x in ?? () #10 0x in ?? () #11 0x in ?? () #12 0x in ?? () #13 0xbfbfd584 in ?? () #14 0x28d631a0 in ?? () from /lib/libc.so.6 #15 0xbfbfd5b4 in ?? () #16 0xbfbfd5b4 in ?? () #17 0x0282 in ?? () #18 0x28c904b4 in ?? () from /lib/libpthread.so.2 #19 0xbfbfd5a8 in ?? () #20 0x080646e1 in ?? () #21 0x0001 in ?? () #22 0xbfbfd5b4 in ?? () #23 0x0006 in ?? () #24 0x28c904b4 in ?? () from /lib/libpthread.so.2 #25 0xbfbfd980 in ?? () #26 0xbfbfd6c0 in ?? () #27 0xbfbfd5c8 in ?? () #28 0x0806421d in ?? () #29 0x28d631a0 in ?? () from /lib/libc.so.6 #30 0x09042d00 in ?? () #31 0xbfbfd5d8 in ?? () #32 0x28c8e3d1 in __error () from /lib/libpthread.so.2 (script-fu:13073): LibGimpBase-WARNING **: script-fu: wire_read(): error ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
