segmentation fault when trying to replace deprecated functions in lcms.c
This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.
This is a read-only list on gimpusers.com so this discussion thread is read-only, too.
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 0x00007f216af03c2f 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
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 0x00007f216af03c2f 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
segmentation fault when trying to replace deprecated functions in lcms.c
On 9/6/12, Michael Natterer 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
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
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
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
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
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 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.htmlThat'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
segmentation fault when trying to replace deprecated functions in lcms.c
On 18 September 2012 06:40, trapDoor
wrote:
Hello,
Any source repo for this? What about setting up a new branch for lcms2-high-bit in the gimp git repository?
Why a new branch?
Things in other branches tend to bit-rot horribly. This is GIMP unstable -
it should go into master.
Regards,
Tomasz B.On Mon, Sep 17, 2012 at 7:46 PM, Michael Natterer 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.htmlThat'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
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
segmentation fault when trying to replace deprecated functions in lcms.c
On Tue, Sep 18, 2012 at 7:33 PM, Joao S. O. Bueno 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?
Chris
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) 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
segmentation fault when trying to replace deprecated functions in lcms.c
On Wed, Sep 19, 2012 at 2:13 PM, Guillermo Espertino (Gez) < gespertino@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.
I agree color management is important but it's not worth derailing other developers just because it's on some list. Breaking master is a good way to drive away new developers, and there's nothing wrong with working on branches until some feature "basically works" and just needs integration touch-up and fine-tuning.
Perhaps some people think this has reached that point, but it does not seem that the person working on it thinks so, and I would put a lot more value on her opinion and ability to request it be merged.
Chris
segmentation fault when trying to replace deprecated functions in lcms.c
On 19 September 2012 16:10, Elle Stone wrote:
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
Hi Elle, glad to see you are still working on this. Could you provide a patch with your changes? This makes it easy for others to review your changes and apply them.
The easiest way (unless you've added files) to make a plain patch is to do the following in the GIMP git directory: git diff origin/master > geglify-lcms-plugin.patch
For more info on git usage, including how to make a git-formatted
patch see for instance:
http://git-scm.com/book
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) < gespertino@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
segmentation fault when trying to replace deprecated functions in lcms.c
On Thu, Sep 20, 2012 at 12:37 AM, Michael Natterer 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) < gespertino@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
segmentation fault when trying to replace deprecated functions in lcms.c
On 9/20/12, trapDoor wrote:
On Thu, Sep 20, 2012 at 12:37 AM, Michael Natterer 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) < gespertino@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
segmentation fault when trying to replace deprecated functions in lcms.c
On 9/19/12, Jon Nordby wrote:
Hi Elle, glad to see you are still working on this. Could you provide a patch with your changes? This makes it easy for others to review your changes and apply them.
The easiest way (unless you've added files) to make a plain patch is to do the following in the GIMP git directory: git diff origin/master > geglify-lcms-plugin.patch
For more info on git usage, including how to make a git-formatted patch see for instance:
http://git-scm.com/book--
Jon Nordby - www.jonnor.com
Hi Jon,
I uploaded a patch, but it's a very simple patch, not done using git (sorry! at the moment I don't have the energy to learn about patch and git together). So the patch would need to be applied by putting it in the gimp/plug-ins/common directory and using patch. Also, I had to put ".txt" at the end of the file-name or else it won't download from my website. The direct link to the patch file is: http://ninedegreesbelow.com/temp/gimp29/lcms2-works/lcms2-babl-files/lcms-no-deprecated.patch.txt
Elle
segmentation fault when trying to replace deprecated functions in lcms.c
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. 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.
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
segmentation fault when trying to replace deprecated functions in lcms.c
On 20 September 2012 11:58, trapDoor wrote:
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?
Let me explain you "what is the fuss":
There is no one working full time in GIMP. Mitch magically and wonderfully can pull a lot of time each week to go ahead with the codebase -- every few couple of months one or another person can pull to some more constant work, just to not be able to keep with it in another few months.
There are however people who can contribute ocasionally, and those can keep a build tree for GIMP master and follow what is happening on master - that is my case -- so once each week or so, I can check new features, see the logs, and I suppose this is the case with most long-time contributors.
Putting it in another branch would require me, when comming to this "weekly GIMP hacking" to checkout another branch, build it, maybe overwrite my main unstable-gimp, or have to fuzz around with prefixes and such so that I can run both - I don't know for the others but I simply won't do that. I'd suspect most people following GIMP won't care either.
While if I checkout GIMP and it does not build, or has some obvious problem in basic usuablity due to unstable code in master: well, those following GIMP do _know_ it is unstable, so no one should be pissed for it ocasionally not working. And all of them will see the problem, and make an attempt to fix it, in the few hours they have to play along GIMP's code.
That is the "fuss".
js ->
Regards,
Tomasz B.
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 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
