Re: [Gimp-developer] segmentation fault when trying to replace deprecated functions in lcms.c
Hello, Any source repo for this? What about setting up a new branch for lcms2-high-bit in the gimp git repository? Regards, Tomasz B. On Mon, Sep 17, 2012 at 7:46 PM, Michael Natterer mi...@gimp.org wrote: 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-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
No, it is a 64-bit computer and a 64-bit build of Gimp 2.9, running Linux (OpenSuse 12.2). It's just not a very new computer and doesn't have a lot of RAM by today's standards. I compiled Gimp using --enable-debug so perhaps the terminal output that I'm seeing is only available if --enable-debug is used. I can easily set the tile cache size larger than 2GB using Edit/Preferences/Environment, Resource Consumption: Tile cache size. The problem is that when starting Gimp from the command line and then setting the tile cache size to more than 2GB, I see a warning in the terminal output telling me that the maximum tile cache size has been exceeded. The warning says that the type for the tile cache size is gint, which means 2GB really is the limit. At least on my system. To check the maximum that gint can hold on my system, I added in a printf statement in the lcms plug-in code that I'm working on, to print out G_MAXINT, which turns out to be 2GB. See http://developer.gnome.org/glib/stable/glib-Basic-Types.html#G-MAXINT:CAPS. As anything greater than 2GB exceeds the limit of what gint can hold, I don't see how setting anything greater than 2GB through Preferences actually gets you more than 2GB. Elle On 9/17/12, Liam R E Quin l...@holoweb.net wrote: 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 -- 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 Tue, Sep 18, 2012 at 2:15 PM, Elle Stone l.elle.st...@gmail.com wrote: ... The warning says that the type for the tile cache size is gint, which means 2GB really is the limit. At least on my system. To check the maximum that gint can hold on my system, I added in a printf statement in the lcms plug-in code that I'm working on, to print out G_MAXINT, which turns out to be 2GB. See http://developer.gnome.org/glib/stable/glib-Basic-Types.html#G-MAXINT:CAPS. As anything greater than 2GB exceeds the limit of what gint can hold, I don't see how setting anything greater than 2GB through Preferences actually gets you more than 2GB. For me, as a not C developer, it looks like this should be changet to guint or even better guint64. But lets wait what Mitch things about this. Regards Tobias ___ 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 17 September 2012 20:23, Elle Stone l.elle.st...@gmail.com 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): (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. It is probably this issue: https://bugzilla.gnome.org/show_bug.cgi?id=648265 -- Jon Nordby - www.jonnor.com ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
[Gimp-developer] Possible issue regarding the Paint Tools
Hello. As regards to GIMP 2.8, in the Tool Options dialog shared by all the Paint Tools, there seems to be an oddity affecting the Size widget. Precisely, the relevant value is not updated when changing the active brush through the Brushes dialog, whereas it is supposed to automatically match the native size of the currently selected brush instead. In particular, as default setting and accordingly at the beginning of each GIMP session, the size value is always set to 20.00, no matter what is the specific brush chosen as the default, so the only way to obtain the correct size consists in clicking the Reset button placed alongside the slider every time you pick a diverse brush. Does this behavior have to be considered a bug or, on the contrary, has it been implemented as a new feature on purpose? Thanks in advance for any clarification. -- Gino D ___ 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 Tue, 2012-09-18 at 15:35 +0200, Tobias Jakobs wrote: On Tue, Sep 18, 2012 at 2:15 PM, Elle Stone l.elle.st...@gmail.com wrote: ... The warning says that the type for the tile cache size is gint, which means 2GB really is the limit. At least on my system. To check the maximum that gint can hold on my system, I added in a printf statement in the lcms plug-in code that I'm working on, to print out G_MAXINT, which turns out to be 2GB. See http://developer.gnome.org/glib/stable/glib-Basic-Types.html#G-MAXINT:CAPS. As anything greater than 2GB exceeds the limit of what gint can hold, I don't see how setting anything greater than 2GB through Preferences actually gets you more than 2GB. For me, as a not C developer, it looks like this should be changet to guint or even better guint64. But lets wait what Mitch things about this. I think pull, the code was broken: commit 52af6e3f3f67d37aa72d06a5f60b1a3967d6c297 Author: Michael Natterer mi...@gimp.org Date: Tue Sep 18 20:07:13 2012 +0200 app: fix the code that sets the 64bit tile cache size on GeglConfig app/gegl/gimp-gegl.c | 18 ++ 1 file changed, 14 insertions(+), 4 deletions(-) --mitch ___ 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 ?
Am 18.09.2012 07:05, schrieb Alexandre Prokoudine: 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. i think your example gives a compelling argument to enhance the export functionality a lot further. Not just auto-resize, but instead a complete GEGL side-chain for export! The promise of going non-destructive is that you will be able to correct the misspelling of your customer's name which you missed 50 steps ago. You should not have to manually repeat all those carefully finetuned resample sharpen steps just in order to export the corrected composition. The promise should not end when it comes to exporting. While GIMP can be understood as an XCF editor, XCF is almost never the deliverable. In my understanding the product vision identifies exporting as a primary necessity. The GEGL side-chain concept may work also on the import side: bla.siff - [OP1]-[OP2]-[OP3] - composition - [^OP3]-[^OP2]-[^OP1] - bla_worked.siff The necessary operations to convert a foreign file to a GIMP composition can be expressed as a small GEGL chain/tree. This import chain can be mirrored by a complementary export chain which contains the necessary operations to re-create the imported file. Or a least-surprise approximation of that file. The import and export trees can be saved in the XCF, so that all the steps can be repeated and adjusted as needed. Also no more worries about whether to save the composition before resizing or after. It can be saved anytime, as the resize operation is only part of the export side-chain. UI? For standard artistic usage, the classic pop-up dialog with checkboxes serves the common cases. Under the hood, a GEGL chain performes the flattening and compression etc. This chain is invisibly controlled by such exports dialogs as they are in place right now. For advanced scientific usage, a boxes-and-hoses GEGL side-tree can be tweaked to create just about any nasty structure for a foreign file that anyone may care to create *). Possibly, even the projection concept (as envisioned for CMYK) may be hijacked to carry the GEGL side chain as a kind of export projection. best regards, yahvuu *) for example, a SIFF file containing both layers with alpha and layers without without alpha. Or mixed 1bit/24bit layers with 8bit alpha. Whatever SIFF supports. (The names have been changed to protect the guilty). ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Nightly Builds
On 18.09.12 at 9:20 pm drawoc wrote: Sven: Try one of the builds from September 12 or later. Thanks, drawoc. I tried again, but GIMP still crashes when calling Edit/Modules. I have plans to make the debug builds happen every night as well, I just haven't gotten around to it yet. Yes, that would be nice. In the meantime I found another debugger (DrMingw), which is freely available and thus more useful for a wider audience. It can also read debug information in Stabs formats, generated by the Gnu C/C++ Compiler [1]. Perhaps these informations are easier to generate with JHBuild as PDB files (just a thought). Kind regards, Sven [1] http://code.google.com/p/jrfonseca/wiki/DrMingw ___ 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
El 18/09/12 20:33, Joao S. O. Bueno escribió: Why a new branch? Things in other branches tend to bit-rot horribly. This is GIMP unstable - it should go into master. +1. Merge! :) ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
