Re: [Gimp-developer] segmentation fault when trying to replace deprecated functions in lcms.c

[Elle Stone]

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
___
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

[Joao S. O. Bueno]

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.
___
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

[Michael Natterer]

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


___
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

[Elle Stone]

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
___
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

[Elle Stone]

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) <
>>> 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

[trapDoor]

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) <
>> 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

[Michael Natterer]

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

[Jon Nordby]

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

-- 
Jon Nordby - www.jonnor.com
___
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

[Christopher Curtis]

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.

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
___
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

[Guillermo Espertino (Gez)]

El 19/09/12 10:43, Christopher Curtis escribió:
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?


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

[Elle Stone]

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

Re: [Gimp-developer] segmentation fault when trying to replace deprecated functions in lcms.c

[Christopher Curtis]

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
___
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

[Guillermo Espertino (Gez)]

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

[Joao S. O. Bueno]

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.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
>
___
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

[trapDoor]

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.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

[Michael Natterer]

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

Re: [Gimp-developer] segmentation fault when trying to replace deprecated functions in lcms.c

[Elle Stone]

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

[Elle Stone]

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

Re: [Gimp-developer] segmentation fault when trying to replace deprecated functions in lcms.c

[Elle Stone]

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

[Elle Stone]

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
___
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

[Michael Natterer]

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

[Gimp-developer] segmentation fault when trying to replace deprecated functions in lcms.c

[Elle Stone]

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