Re: [Gimp-developer] segmentation fault when trying to replace deprecated functions in lcms.c
Just an update: I finally have the lcms plugin doing high bit depth ICC profile conversion without using any deprecated functions. There are still some issues to address, but if anyone is curious, the code is at: http://ninedegreesbelow.com/temp/gimp-lcms-deprecated.html Elle ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] segmentation fault when trying to replace deprecated functions in lcms.c
On Mon, 2012-09-17 at 13:36 -0400, Elle Stone wrote: > Just an update: I finally have the lcms plugin doing high bit depth > ICC profile conversion without using any deprecated functions. There > are still some issues to address, but if anyone is curious, the code > is at: > http://ninedegreesbelow.com/temp/gimp-lcms-deprecated.html That's great news! :) I had your mail from last week marked as "important" for replying, but was horribly busy at work, sorry about that. Will try the new stuff asap. --mitch ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
[Gimp-developer] 2GB limit on Resource Consumption: Tile cache size
While making changes to "Edit/Preferences/Environment, Resource Consumption: Tile cache size", I noticed a warning when I tried to increase the cache size to 2 gigabytes, or 2048 megabytes (terminal output, Gimp 2.9, started from the command line): (gimp-2.9:3518): GLib-GObject-WARNING **: value "-2147483648" of type `gint' is invalid or out of range for property `cache-size' of type `gint' If I set the cache size to 2047 megabytes, there is no warning. If I set the cache size to more than 2048 megabytes, the 'GLib-GObject-WARNING **: value' gets correspondingly larger. I only have 4 GB of ram on my computer, but I have successfully given more than 2GB to other image editing programs. A lot of people have computers with way more than 4GB of ram. Would it make any practical difference to be able to use more than 2GB of ram for the tile cache when using Gimp? It seems odd to be limited to less than 2GB for the tile cache size, solely because the type is gint. Kindest regards, Elle Stone -- http://ninedegreesbelow.com Articles and tutorials on open source digital imaging and photography ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] 2GB limit on Resource Consumption: Tile cache size
On Mon, 2012-09-17 at 14:23 -0400, Elle Stone wrote: > While making changes to "Edit/Preferences/Environment, Resource > Consumption: Tile cache size", I noticed a warning when I tried to > increase the cache size to 2 gigabytes, or 2048 megabytes (terminal > output, Gimp 2.9, started from the command line) I take it that this is a 32-bit computer and 32-bit build of GIMP? If so, yes, 2G is likely the limit. On many 32-bit Linux systems there's also a 3G process size limit. On 64-bit systems you can set the tile cache size larger, at least on Linux systems. Liam -- Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ Pictures from old books: http://fromoldbooks.org/ Ankh: irc.sorcery.net irc.gnome.org freenode/#xml ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] [Gimp-user] [Request] Do not confirm closing if unsaved image was exported/overwrited ?
No. GIGO applies here - GIMP assumes that the state of the image when you hit Save is exactly what you want to be saved to disk, so that's precisely what it does. In cases where it's not (such as with resizing the whole image) GIMP has no way to tell know better. However, a resize-during-export could make an interesting feature request -- Stratadrake strata_ran...@hotmail.com Numbers may not lie, but neither do they tell the whole truth. > Date: Sun, 16 Sep 2012 08:58:20 -0700 > From: w...@ieee.org > To: gimp-developer-list@gnome.org > Subject: Re: [Gimp-developer] [Gimp-user] [Request] Do not confirm closing if > unsaved image was exported/overwrited ? > > This sounds to me like a bug - possibly a specification error? > > Certainly adds some possibly useful context to the longlasting (and > unfortunately overly acrimonious) dispute about the save-export behavior in > 2.8. > > In my experience, it is extremely difficult to apprehend all the varieties of > ways people like to use complex tools, especially in a world environment > enamored with the famous Steve Jobs aphorism - "things should 'just work'" - > and > adapting - even when necessary - is uncomfortable, and often painful. > >-- Burnie > > On 09/16/2012 08:10 AM, Richard Gitschlag wrote: > > > > > From: l...@holoweb.net > > > To: ofn...@laposte.net > > > Date: Sat, 15 Sep 2012 20:23:36 -0400 > > > CC: gimp-user-l...@gnome.org > > > Subject: Re: [Gimp-user] [Request] Do not confirm closing if unsaved > > > image > > was exported/overwrited ? > > > > > > On Sat, 2012-09-15 at 23:12 +0200, Ofnuts wrote: > > > > [...] saving as XCF > > > > "by accident" may make you lose some time, but will never make you lose > > > > data, because you can always save the JPG again from the XCF. > > > > > > This isn't always true. > > > > > > For example, after working on a photograph I scale it down e.g. to 600 > > > pixels across, and export a jpeg. If at that point I save the xcf file, > > > I will lose data, because xcf does not store the undo history. > > > > > > Yes, I could use ImageMagick to scale the image, but (1) I do want to > > > see the jpeg preview, as it often needs some extra work in curves or > > > sharpen, and (2) I'm already in gimp :) > > > > > > Liam > > > > > > -- > > > Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ > > > Pictures from old books: http://fromoldbooks.org/ > > > Ankh: irc.sorcery.net irc.gnome.org freenode/#xml > > > > > > ___ > > > gimp-user-list mailing list > > > gimp-user-l...@gnome.org > > > https://mail.gnome.org/mailman/listinfo/gimp-user-list > > > > That is unfortunately true, GIMP has no ability to automatically scale-down > > the image to a different size as part of the export process. When you hit > > Save GIMP records everything necessary to recreate the image *as it was > > when > > you hit Save*, whether it is the preferred way of storing your overall > > project > > file or not. The XCF is not a full version repository logging everything > > that > > happened to the image since its creation - I imagine that should be the > > role > > of an XCF subformat so that the user has per-file control over whether or > > not > > they need that extra information taking up extra hard drive space. > > > > -- Stratadrake > > strata_ran...@hotmail.com > > > > Numbers may not lie, but neither do they tell the whole truth. > > > > > > > > ___ > > gimp-user-list mailing list > > gimp-user-l...@gnome.org > > https://mail.gnome.org/mailman/listinfo/gimp-user-list > > ___ > gimp-developer-list mailing list > gimp-developer-list@gnome.org > https://mail.gnome.org/mailman/listinfo/gimp-developer-list ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] [Gimp-user] [Request] Do not confirm closing if unsaved image was exported/overwrited ?
On Tue, Sep 18, 2012 at 7:36 AM, Richard Gitschlag wrote: > No. GIGO applies here - GIMP assumes that the state of the image when you > hit Save is exactly what you want to be saved to disk, so that's precisely > what it does. In cases where it's not (such as with resizing the whole > image) GIMP has no way to tell know better. > > However, a resize-during-export could make an interesting feature > request In my experience, exporting with existing samplers needs to be a user-controlled action. It really depends on the kind of image you are resizing. For screenshots, automatic resizing simply produces horribly looking pictures. One of the reasons I run GIMP 2.9 for Git master is because I can access LoHalo sampler which works far better for resizing down than anything else in GIMP 2.8. And even then I need to add a bit of unsharp masking, depending on particular case. Alexandre Prokoudine http://libregraphicsworld.org ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
