Re: [Gimp-developer] segmentation fault when trying to replace deprecated functions in lcms.c
Per Jon's suggestion, I did git diff origin/master geglify-lcms-plugin.patch. Per Mitch's suggestion, I put the contents of geglify-lcms-plugin.patch up on my website: http://ninedegreesbelow.com/temp/gimp-lcms-deprecated.html geglify-lcms-plugin.patch can be downloaded from the same page. On 9/21/12, Michael Natterer mi...@gimp.org wrote: On Thu, 2012-09-20 at 14:46 -0400, Elle Stone wrote: If anyone wants to try my lcms plug-in code and let me how it works for them, that would be fantastic. The version that uses deprecated code works perfectly, as far as I can tell, but I'm only one person, using one computer. The only thing is, you do need to modify one Babl file, babl/babl/base/model-rgb.c, and then recompile Babl. Hi Elle, Thanks for the updated files, I'd really like to try them when I have some time on the weekend. It would really help to get more review if you didn't upload entire files, but also patches against git master, so everybody can see the *changes* not just their result, by just looking at your web page. The effort to download the file, copy it into the source and then say git diff is always a good reason to say nah i'll do that later ;) Regards, --mitch Kind regards, 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 Thu, Sep 20, 2012 at 12:37 AM, Michael Natterer mi...@gimp.org wrote: On Wed, 2012-09-19 at 14:47 -0400, Christopher Curtis wrote: On Wed, Sep 19, 2012 at 2:13 PM, Guillermo Espertino (Gez) gespert...@gmail.com wrote: El 19/09/12 10:43, Christopher Curtis escribió: Wouldn't it be better to keep the mainline in a near-releasable state rather than letting things bit-rot in master, causing 3-year intervals between releases? Moving it to master could mean that mode developers and contributors realize its importance and they won't let it bitrot. Well, as I haven't contributed code I'll step out after this comment, but I don't think that merging something that breaks common work flows, seriously degrades performance, and causes segmentation faults belongs in master. What makes you think we would merge something to master that would definitely crash? We do use some common sense while we sit on our fat asses and do nothing while the world waits for the next release. --mitch I don't understand why did i trigger such reactions. I thought it's obvious that letting more testers to try out the new code would be only to the GIMPs benefit - and the best way to do it is to publish it in the gimp git repo. Whether to keep it in separate branch (obviously temporarily - I didn't mean forever) or merge right away into master - that should be decided upon by the devs. My idea was nothing unusual (many new GIMP features were grown initially in separate branches) - so what's the fuss? Regards, Tomasz B. ___ 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 9/20/12, trapDoor trapdo...@gmail.com wrote: On Thu, Sep 20, 2012 at 12:37 AM, Michael Natterer mi...@gimp.org wrote: On Wed, 2012-09-19 at 14:47 -0400, Christopher Curtis wrote: On Wed, Sep 19, 2012 at 2:13 PM, Guillermo Espertino (Gez) gespert...@gmail.com wrote: El 19/09/12 10:43, Christopher Curtis escribió: Wouldn't it be better to keep the mainline in a near-releasable state rather than letting things bit-rot in master, causing 3-year intervals between releases? Moving it to master could mean that mode developers and contributors realize its importance and they won't let it bitrot. Well, as I haven't contributed code I'll step out after this comment, but I don't think that merging something that breaks common work flows, seriously degrades performance, and causes segmentation faults belongs in master. My lcms.c high bit depth code doesn't degrade performance and doesn't cause segmentation faults. When I first was attempting to wrap my brain around gegl buffers, I had a problem with segmentation faults, which is why I started this thread. But after consuming copious quantities of coffee, time, and a huge helping of the gegl api, much delving into Gimp code for examples, and a hint or two from Mitch, the segmentation problems have all been fixed. I'm not sure what you mean by breaks common work flows. You probably don't mean that having the option to do a high bit depth color conversion without ending up with an 8-bit color gamut is going to break anyone's workflow! The reason that I don't think my code is ready for uploading to master is because: *I haven't found the time to finish rewriting all the code sections to get them to work with gegl buffers (alpha channel, the progress bar). *I don't think I'm closing out the buffers properly, which is probably why undo isn't working properly. I need some input on this issue. *Some of the functions in babl/base/model-rgb.c seem to be getting in the middle of the high bit depth ICC profile conversions, but not in the middle of 8-bit profile conversions. I don't know how to track down which Gimp functions are invoking these problematic Babl functions. One interim way to deal with the situation is comment out the calls to the functions in util.h that are done by the functions in model-rgb.c. Another way would be to locate the Gimp functions that are calling the model-rgb.c functions in the middle of the ICC profile conversion and modify them. I've put up parallel terminal output comparing 8-bit and 16-bit profile conversions here: http://ninedegreesbelow.com/temp/gimp-lcms-deprecated.html#bitdepth What makes you think we would merge something to master that would definitely crash? We do use some common sense while we sit on our fat asses and do nothing while the world waits for the next release. --mitch I just want to say that I've always taken Gimp for granted. Having spent some time working with a small portion of the code, I see with new eyes. The code base is huge. The user base is huge. The number of active developers seems to be not very many. I don't understand why did i trigger such reactions. I thought it's obvious that letting more testers to try out the new code would be only to the GIMPs benefit - and the best way to do it is to publish it in the gimp git repo. Whether to keep it in separate branch (obviously temporarily - I didn't mean forever) or merge right away into master - that should be decided upon by the devs. My idea was nothing unusual (many new GIMP features were grown initially in separate branches) - so what's the fuss? Regards, Tomasz B. If anyone wants to try my lcms plug-in code and let me how it works for them, that would be fantastic. The version that uses deprecated code works perfectly, as far as I can tell, but I'm only one person, using one computer. The only thing is, you do need to modify one Babl file, babl/babl/base/model-rgb.c, and then recompile Babl. Instructions for compiling the plug-in and also download files for both versions of the plug-in and the modified babl file are here: http://ninedegreesbelow.com/temp/gimp-lcms-6.html. Kindest regards, Elle Stone ___ 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 Tue, Sep 18, 2012 at 7:33 PM, Joao S. O. Bueno gwid...@mpc.com.brwrote: Why a new branch? Things in other branches tend to bit-rot horribly. This is GIMP unstable - it should go into master. Wouldn't it be better to keep the mainline in a near-releasable state rather than letting things bit-rot in master, causing 3-year intervals between releases? Chris ___ 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
My lcms.c high bit depth profile conversion code still some major issues to iron out, including: *I haven't rewritten to use nondeprecated functions the code section that takes care of alpha channels. *The show-stopper: the code still doesn't work correctly at high bit depths unless some/all of the Babl functions that convert back and forth between the sRGB TRC and linear gamma TRC are modified to stop the back-and-forth conversion. Otherwise, as I've noted before, tonality AND color are wrong after the profile conversion. Unfortunately, replacing the deprecated functions didn't fix this problem. The problem seems to be that when doing an ICC profile conversion on an image with a bit-depth greater than 8 bits, a couple of functions in babl/base/model-rgb.c are called midway through the ICC profile conversion. These functions are not called when converting an 8-bit image. I haven't been able to track down what bit of Gimp/Babl code calls the functions in model-rgb.c while the ICC profile conversion is in progress. Elle On 9/19/12, Guillermo Espertino (Gez) gespert...@gmail.com wrote: 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 -- 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] segmentation fault when trying to replace deprecated functions in lcms.c
El 19/09/12 10:43, Christopher Curtis escribió: On Tue, Sep 18, 2012 at 7:33 PM, Joao S. O. Bueno gwid...@mpc.com.br mailto:gwid...@mpc.com.br wrote: Why a new branch? Things in other branches tend to bit-rot horribly. This is GIMP unstable - it should go into master. Wouldn't it be better to keep the mainline in a near-releasable state rather than letting things bit-rot in master, causing 3-year intervals between releases? AFAIK, the work Elle is doing is critical for a proper color managed workflow in high bit depths. Without it the next realease of GIMP, even if it's released earlier, won't use the real benefit of high bit depth, because color transforms would throw away the extra color depth. Moving it to master could mean that mode developers and contributors realize its importance and they won't let it bitrot. Proper color management is as important as high bit depth for people who really needs high bit dept. Gez. ___ 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 Wed, 2012-09-19 at 14:47 -0400, Christopher Curtis wrote: On Wed, Sep 19, 2012 at 2:13 PM, Guillermo Espertino (Gez) gespert...@gmail.com wrote: El 19/09/12 10:43, Christopher Curtis escribió: Wouldn't it be better to keep the mainline in a near-releasable state rather than letting things bit-rot in master, causing 3-year intervals between releases? Moving it to master could mean that mode developers and contributors realize its importance and they won't let it bitrot. Well, as I haven't contributed code I'll step out after this comment, but I don't think that merging something that breaks common work flows, seriously degrades performance, and causes segmentation faults belongs in master. What makes you think we would merge something to master that would definitely crash? We do use some common sense while we sit on our fat asses and do nothing while the world waits for the next release. --mitch ___ 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
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] 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
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
Hi, Mitch, All, Two related questions: 1. Deprecated functions: I managed to replace the deprecated functions in 'lcms_image_transform_rgb', which sets up the ICC profile transform. But I'm having a lot of trouble with 'lcms_drawable_transform', which actually performs the ICC profile conversion. You can find my failed efforts to replace the deprecated functions here: http://ninedegreesbelow/temp/gimp-lcms-deprecated.html I am clueless as to how to make any further progress. Any insight would be more than welcome. 2. The whole image, tile by tile, or line by line: According to the lcms2 documentation, cmsDoTransform can transform the entire image all at once, or tile by tile, or line by line. Also, apparently the Windows OS needs cmsDoTransform to happen line by line. But the existing Gimp lcms.c plug-in transforms by tiles. Is the current Windows version of Gimp capable of doing ICC profile conversions? I couldn't get the whole image at once or line by line to work. I haven't tried tile by tile because I don't understand how tiles work. line by line makes sense to me, and might make it easier to port the lcms.c plug-in code to Windows. Elle Stone ___ 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
Sorry, that link to my failed efforts should be: http://ninedegreesbelow.com/temp/gimp-lcms-deprecated.html -- 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
[Gimp-developer] segmentation fault when trying to replace deprecated functions in lcms.c
When I try to call the recommended new functions to replace the deprecated functions in the lcms.c plug-in, the code segmentation faults. To illustrate the problem, I wrote a line of code to call 'gimp_drawable_get_buffer' and put a printf statement just above and below: printf(lcms: lcms_drawable_transform: before call to GeglBuffer\n); GeglBuffer *buffer = gimp_drawable_get_buffer (layer_id); printf(lcms: lcms_drawable_transform: after call to GeglBuffer\n); The code segmentation faults when it gets to GeglBuffer *buffer = gimp_drawable_get_buffer (layer_id);. Although I am not experienced in interpreting backtraces, and could easily be completely wrong, it looks like the problem is that babl doesn't accomodate the file format RGB u16: #6 0x7f216af03c2f in babl_format (name=0xb50610 RGB u16) at babl-format.c:667 line 667 is the end of babl-format.c and RGB u16 does not occur anywhere in babl-format.c. I am not sure how to fix this problem. The full backtrace and the relevant lcms.c code (high bit depth version) can be found here: http://ninedegreesbelow.com/temp/gimp-lcms-deprecated.html 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] segmentation fault when trying to replace deprecated functions in lcms.c
Do you call gegl_init()? Look at file-pat.c or goat-exercise.c for simple examples of gegl-enabled plugins. --mitch On Thu, 2012-09-06 at 12:59 -0400, Elle Stone wrote: When I try to call the recommended new functions to replace the deprecated functions in the lcms.c plug-in, the code segmentation faults. To illustrate the problem, I wrote a line of code to call 'gimp_drawable_get_buffer' and put a printf statement just above and below: printf(lcms: lcms_drawable_transform: before call to GeglBuffer\n); GeglBuffer *buffer = gimp_drawable_get_buffer (layer_id); printf(lcms: lcms_drawable_transform: after call to GeglBuffer\n); The code segmentation faults when it gets to GeglBuffer *buffer = gimp_drawable_get_buffer (layer_id);. Although I am not experienced in interpreting backtraces, and could easily be completely wrong, it looks like the problem is that babl doesn't accomodate the file format RGB u16: #6 0x7f216af03c2f in babl_format (name=0xb50610 RGB u16) at babl-format.c:667 line 667 is the end of babl-format.c and RGB u16 does not occur anywhere in babl-format.c. I am not sure how to fix this problem. The full backtrace and the relevant lcms.c code (high bit depth version) can be found here: http://ninedegreesbelow.com/temp/gimp-lcms-deprecated.html Elle Stone ___ 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 9/6/12, Michael Natterer mi...@gimp.org wrote: Do you call gegl_init()? Look at file-pat.c or goat-exercise.c for simple examples of gegl-enabled plugins. On Thu, 2012-09-06 at 12:59 -0400, Elle Stone wrote: When I try to call the recommended new functions to replace the deprecated functions in the lcms.c plug-in, the code segmentation faults. Thanks! gegl_init() enabled the plug-in to run without segmentation faulting. Now to see if I can actually replace a deprecated function or five! Elle ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
