On 12/03/2013 02:10 PM, Teo Mazars wrote:
Hi,
The way GEGL currently exposes each numerical parameters is as follow:
1) A nominal range, say [a, b], which represents the range where the operation
is expected to work
2) An UI range, [a', b'] included in [a, b], representing the area of interest
Hi all,
As Gimp 2.10 seems to be closer to being a reality, I wanted to bring up
some minor but annoying useability issues with Gegl Gaussian Blur and
Unsharp Mask.
Gegl USM slider range - can't use the slider for small values:
There are many algorithms to add "local contrast enhancement" t
tp://ninedegreesbelow.com/gimpgit/gimp-openexr.html has
pictures showing the problem. There are also download links for several
linear gamma ICC profiles and some sample OpenEXR files in different
color spaces. I could make a complete set of linear gamma working space
profiles availab
Massimo made a patch that was so much better than my poor effort. His
patch worked really well. Then Mitch did a whole bunch of code writing
and now Gimp from git can properly display linear gamma images.
Thank you Massimo! Thank you Mitch!
___
gimp-d
ack to September 1, and Gegl built
without any problem.
My computer doesn't play nice with opencl, if that is relevant. Is there
a way to disable opencl before building?
--
Elle Stone
http://ninedegreesbelow.com
Articles on color management and open source photography
On 10/9/13, Simon Budig wrote:
> Another (slightly philosophical) issue for me is, that you never explain
> what you mean by color.
I added a one-paragraph summary of color:
http://ninedegreesbelow.com/photography/xyz-rgb.html
What do you think? Will my one-paragraph summary work?
> It might be
On 10/9/13, Øyvind Kolås wrote:
> Combined with your color knowledge you are be much more well suited to
> clarify what the babl format strings we keep using in GIMP mean, as well as
> how it fits into our overall scheme of things in current and future GIMP.
> What you do not understand; we might
On 10/9/13, Liam R E Quin wrote:
> On Wed, 2013-10-09 at 16:32 -0400, Elle Stone wrote:
>> perhaps I should move the Guide out of the "temp"
>> folder (which is for temporary posts) and over to the "photography"
>> folder, with appropriate license
On 10/9/13, Rolf Steinort wrote:
> On 09.10.2013 15:20, Elle Stone wrote:
>> If my Guide seems useful to developers, I'll put the content under an
>> applicable license so it can be hosted elsewhere and modified by other
>> people.
> Please do that! I'll make
quot; doesn't produce this
> result.
>
> Is there an explanation to this? And can it be avoided?
> ___
> gimp-developer-list mailing list
> List address:gimp-developer-list@gnome.org
> List membership:
> https://mail.gnome.org/ma
es to RGB and XYZ)
* YCbCr, YUV, HSL, and HSV (how these derivative color spaces are
connected to their parent RGB color space)
* LCMS2 (how it links working space profiles with monitor, camera, and
printer profiles)
Elle
--
Elle Stone
http://ninedegreesbelow.com
Just bec
break?
cairo-1.12.16 is available in gentoo but masked. Helmut, which version
of cairo are you using? Mitch, what version of cairo do you recommend?
--
Elle Stone
http://ninedegreesbelow.com
Just because it's a standard, doesn't mean it's right.
> known bug?
>
> Thanks,
> Helmut
> ___
> gimp-developer-list mailing list
> List address:gimp-developer-list@gnome.org
> List membership:
> https://mail.gnome.org/mailman/listinfo/gimp-developer-list
>
--
Elle Stone
http://ninedegrees
or managed look
like when viewed in an ICC profile color managed image editor? Does
anyone have an image created using one of the earliest versions of
Gimp that I could look at, preferably an image that is supposed to
have areas of light gray or white?
Elle
--
Elle Stone
http://ninedegreesbel
A technically correct luminance-based conversion to black and white is
done using this formula:
L = R*Yr + G*Yg + B*Yb
where R, G, and B are the image RGB values for any given pixel and Yr,
Yg, and Yb are the Y values from the image's actual ICC profile. If
the profile white point isn't D50, the
ues for
converting an sRGB image to black and white using Luminance are the
D50-adapted Y values from the D50-adapted sRGB profile that's actually
embedded in the sRGB image.
--
Elle Stone
http://ninedegreesbelow.com
Just because it's a standard, doesn't mean it's right.
__
e or less imperfectly achieved D65 white point,
just to match the white point of an sRGB-calibrated CRT manufactured
in the 1990s. Different times, different technology.
> Isn't the second (adapted) transform going to give us a D50 Y instead
> of a D65 Y?
Yes, it will, and that's preci
On 9/21/13, Michael Henning wrote:
> Both babl's RGB format and Y format are currently defined with a white
> point of D65. Because of this, I believe the code's current luminance
> values are correct.
>
The whitepoint of an ICC profile might have a D65 white point without
a chad tag, if it's a V
I was curious as to why the Babl/Gegl/Gimp code uses the unadapted
sRGB luminance values rather than the adapted values.
Quoting Lindbloom
(http://www.brucelindbloom.com/index.html?WorkingSpaceInfo.html):
Since the ICC specification and Adobe Photoshop both use a reference
white of D50, the worki
Hi Daniel,
Thanks! for the input. I'm pondering your suggestions about the code
and I'll check in with you and Mitch on IRC in the next couple of
days.
--
http://ninedegreesbelow.com
Just because it's a standard, doesn't mean it's right.
___
gimp-devel
On 9/12/13, Jon Nordby wrote:
> On 12 September 2013 16:08, Elle Stone wrote:
>> The problem at this point is that the image won't display properly
>> until something like doing a very small levels correction forces a
>> screen redraw. After forcing a screen redr
I've made progress getting a linear gamma image to display without
posterization in the shadows. I put up a temporary web page with the
modified code and a picture:
http://ninedegreesbelow.com/temp/convert-buffer-before-cairo.html
The problem at this point is that the image won't display properly
Hmm, I managed to get past the problem of not linking to lcms2. The
solution was to compile Gimp using MAKEOPTS="-j3"
CFLAGS=-Wl,--no-as-needed LDFLAGS=-llcms2 ./autogen.sh . . .
not that I know why that seems to have worked.
On to the next step.
--
http://ninedegreesbelow.com - articles on colo
Hi Jon, Daniel, all,
On 9/10/13, Daniel Sabo wrote:
> The conversion happens in app/display/gimpdisplayshell-render.c :
> gimp_display_shell_render() .
> Look for the gegl_buffer_get call that converts to babl_format
> ("cairo-ARGB32").
On 9/11/13, Jon Nordby wrote:
>> Quoting Jon's suggestion:
For some silly reason I assumed that the Gimp color picker's displayed
colors are accurately displayed if one is working on an sRGB image.
But that isn't true because the Gimp color picker isn't color-managed.
Instead the color picker RGB values are sent straight to the screen
without having first
On 11/12/12, Elle Stone wrote:
> On 11/10/12, Michael Natterer wrote:
>> On Sat, 2012-11-10 at 15:17 -0500, Elle Stone wrote:
>>> On 11/8/12, Jon Nordby wrote:
>>> > * Change the lcms-based conversion (modules/display-filter-lcms.c)
>>> > from being a g
I just looked at the questionaires. The questions imply/offer a narrow
business-oriented view on open source projects, it seems to me.
I recall one person saying in a recent post, possibly on the Gimp
users list, that he contributed code because he liked to code, he
wanted to make something in par
Michael,
>So, building with spiro won't change gimp at all.
Thanks! for answering. I won't install spiro.
Elle
--
http://ninedegreesbelow.com - articles on open source digital photography
___
gimp-developer-list mailing list
List address:gimp-dev
What benefits are there from installing the spiro libraries for gegl to use?
According to the spiro website: http://libspiro.sourceforge.net/
Using bézier splines an artist can easily draw curves with the same
slope on either side of an on-curve point. Spiros, on the other hand,
are based on clo
Gimp from git allows the user to choose which image precision to use
while editing the image. The choices used to be 8-bit, 16-bit, and
32-bit integer, plus 16-bit and 32-bit floating point. The choices
have recently doubled: for each image precision choice, the user must
choose whether to work in
Hi Mitch,
Thanks! Now the levels tool really does have 999 increments (and I
really should stop assuming everything "as is" is a feature rather
than a bug).
Elle
--
http://ninedegreesbelow.com - articles on open source digital photography
___
gimp-dev
Hi all,
When working on a 16-bit integer or 32-bit floating point image, Gimp
from git "levels" tool shows increments of 0.1 on a scale from 0 to
100.0, theoretically giving 999 increments.
However, when using levels to slowly raise or lower the black point or
the white point, the displayed input
Pngs, tiffs, jpegs:
I did some more testing. I tried opening an assortment of pngs, jpegs,
and tiffs created by a variety of image editing programs (recent
versions of krita, cinepaint, showfoto, an older version of Photoshop,
and test images downloaded from the web), and Gimp opened them all
with
On 5/24/13, Mukund Sivaraman wrote:
> The following file plug-ins have been revised to use GIMP's new API.
> I feel they need more testing as the changes are intrusive and the file
> types can support a variety of pixel formats. I have tested these to my
> satisfaction. Please test these if you ca
On 5/8/13, Clayton Walker wrote:
> Considering the fact that Adobe even has a separate program called Adobe
> Camera Raw, I don't see why gimp should necessarily include a raw loader.
> Perhaps maintainers could bundle gimp with ufraw, but to combine the two
> projects makes little sense.
The thi
" settings, but you probably would
want to experiment to find the settings that are prettier to you.
dcraw is a pure raw processor, that is, it doesn't do any
"prettifying" post-interpolation image processing, so the results will
look flat until you add your own curves, saturation, etc
This is not a response to your request for which sections of Gimp code
are involved - sorry! However, wmii is a tiling window manager,
meaning it wants to put all windows side by side, no overlaps, perhaps
that is a clue to the behavior?
Probably no one has responded because wmii is not so commonl
Those marching ants do chew up CPU power at the default speed. I have
them set at 1000, which means one update per second. Setting them to
1000, 5000, or doesn't make any perceptible difference in the
total CPU usage. Just now I tried setting the default speed to "0",
but it reset to 10.
--
More RAM does help quite a bit. With 12GB RAM instead of just 4GB. +
using the optimized babl/gegl/Gimp installation. + starting Gimp with
"GEGL_SWAP=RAM", painting with a brush is no longer quite the painful
chore that it was.
The main sticking point now is redrawing the canvas (correct
terminolo
On 3/2/13, Partha Bagchi wrote:
> I thought Gentoo was all about optimizing a linux distribution to your
> specific proecessor. :)
>
> Anyway, try the following optimization and see if it makes a difference in
> your setup:
>
> ./autogen CFLAGS="-O3 -ffast-math -ftree-vectorize" ...
Sorry! I spok
Being curious about optimization, I set up two identical installations
of babl, gegl, and Gimp, in separate, side-by-side prefixes (same
partition, hard drive):
In "gimp291" babl, gegl, and Gimp were compiled with ./autogen.sh . . .
In "gimp292" babl, gegl, and Gimp were compiled with
CFLAGS="-m
On 2/28/13, Liam R E Quin wrote:
> Quark Express used to have the notion of a "project folder", and if you
> put fonts in it, they'd be activated only when working on the files in
> that folder. I miss this, but gimp is scatterbrained when it comes to
> folders, with export going to the last place
I followed Nicolas' suggestion and recompiled babl, gegl and gimp with
CFLAGS="-march=native -O3" CXXFLAGS="-march=native -O3". The computer
didn't blow up or anything. But I can't say whether Gimp runs any
faster.
The idea of optimization seemed promising and I found this thread:
http://www.gimpu
On 2/28/13, Liam R E Quin wrote:
> In the meantime,
> (1) look at what other processes are running - e.g. in "top" you can
> press M (not m) to sort processes by size, and the results can sometimes
> be surprising...
Thanks very much! for the tip on how to sort in top.
> (2) in gimp...
> even w
On 2/28/13, Nicolas Robidoux wrote:
> Warning: Untested
>
> If you build/compile GIMP and key libraries (e.g. GEGL, BABL) from source,
> maybe you should try
>
> CFLAGS="-march=native -O3" CXXFLAGS="-march=native -O3" ./autogen.sh ...
CFLAGS is for c code CXXFLAGS is for c++ code, according to in
On 2/28/13, Elle Stone wrote:
> One thing I wish Gimp had is a better eyedropper tool for checking
> color values. That is the one thing, practially the only thing, that
> PhotoShop had (and presumably still has) that I wish Gimp had. The
> PhotoShop eyedropper tool simultaneousl
e on how to
improve performance would be greatly appreciated.
Kind regards,
Elle Stone
--
http://ninedegreesbelow.com - articles on open source digital photography
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list
One thing I wish Gimp had is a better eyedropper tool for checking
color values. That is the one thing, practially the only thing, that
PhotoShop had (and presumably still has) that I wish Gimp had. The
PhotoShop eyedropper tool simultaneously showed RGB, CMYK, and LAB
values, at user-settable 8-bi
converting from eg 16-bit integer grayscale input
to 32-bit floating point RGB, or from 32-bit floating point RGB to
8-bit CMY(K) output, the code will get a lot more complicated.
Kind regards,
Elle Stone
--
http://ninedegreesbelow.com - articles on open source digital photography
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list
On 11/29/12, Øyvind Kolås wrote:
> On Fri, Nov 30, 2012 at 7:28 AM, Elle Stone wrote:
>> So gathering the gist of this discussion, it would be useful to add
>> the code for 16-bit floating point and 32-bit integer to the lcms
>> plug-in?
>>
>> And presumably if/w
d color
space information that isn't in the form of an ICC profile), I've
started very preliminary checking into how other floss image editors
handle that problem.
Kind regards
Elle Stone
___
gimp-developer-list mailing list
gimp-developer-li
I'm sure other people will have better answers.
> Q: What is the tool that you use for Gimp development (ex: Vim, Emacs,
> Eclipse, Netbeans, Anjuta, ...)?
> A:
code editor (Geany) + a virtual terminal + valgrind + GDB
> Q: Does your development environment support direct compilation (answer
> Ye
n preparing an image for the web.
Presumably converting an image to the "extended" sRGB color space
won't clip, for example, the colors in a ProPhoto image or an image
that is still in the camera input space. But exporting the image as
pure regular sRGB certainly could (a
On Wed, Nov 28, 2012 at 8:04 AM, Elle Stone wrote:
> On Wed, Nov 28, 2012 at 4:11 AM, Tobias Jakobs wrote:
>
> with all this changes and the recent work in git it looks very promising.
>> Thank you and every one from the Gimp Team who help for this work. Could
>> you perhaps
On Wed, Nov 28, 2012 at 4:11 AM, Tobias Jakobs wrote:
with all this changes and the recent work in git it looks very promising.
> Thank you and every one from the Gimp Team who help for this work. Could
> you perhaps give us short status update about what is now working and what
> is still missing
On 11/24/12, Elle Stone wrote:
> If something works when the babl file *is* modified to eliminate the
> back and forth conversions, and doesn't work when the babl file
> *isn't* modified, that suggests that some bit of Gimp code - code that
> is not inside the lcms.c plug
version process.
Hopefully the resulting terminal output will be useful in tracking
down which Gimp functions (not lcms.c functions) are calling which
babl functions during the ICC profile conversion process.
On 11/23/12, Øyvind Kolås wrote:
> On Sat, Nov 24, 2012 at 10:33 AM, Elle Stone
>
not
familiar with Gimp's overall "undo" code path, so any guidance,
suggestions, input is more than welcome, whether by email or IRC or
etc.
Kindest regards,
--
Elle Stone
http://ninedegreesbelow.com - articles on open source digital photography
Hi all,
A couple different lines of discussion are in this thread, the correct
way to implement Overlay in regular sRGB, the effect of linear gamma
blending with respect to changing w3 standards, how to deal with
legacy blend modes after the switch to linear light image editing.
An implicit assum
On 11/10/12, Michael Natterer wrote:
> On Sat, 2012-11-10 at 15:17 -0500, Elle Stone wrote:
>> On 11/8/12, Jon Nordby wrote:
>> > Has your work on replacing the deprecated functions found its way into
>> > git master?
>>
>> No. With Mitch's help I
On 11/8/12, Jon Nordby wrote:
> Has your work on replacing the deprecated functions found its way into
> git master?
No. With Mitch's help I did made a patch file (which might be out of
date by now, as Gimp keeps changing):
http://ninedegreesbelow.com/temp/gimp-lcms-deprecated.html#patch
> * Cha
Thanks! That fixed it!
Elle
On 9/28/12, Ville Sokk wrote:
> Hi. It was my fault in GEGL again. Try pulling and building GEGL master
> again.
>
> On Fri, Sep 28, 2012 at 8:02 PM, Elle Stone wrote:
>> When using Gimp from git (updated today, no modifications), curves
>>
9:9896): GEGL-gegl-tile-backend-file-async.c-WARNING **:
leaking all entries in GeglTileBackendFile->index
Gimp 2.8 (compiled from source before the latest Gimp 2.8 release)
doesn't have this problem.
Kind regards,
Elle Stone
--
http://ninedegreesbelow.com
Articles and tutorials on
image
> and its options also contain Black point compensation.
>
The Gimp Color Proof Display Filter seems to offer everything anyone
would want in the way of softproofing and display options.
Unfortunately, as far as I can tell from comparing the results to
other image editors (Cinepaint,
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 deprecate
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
ould 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
On 9/18/12, Michael Natterer wrote:
> I think pull, the code was broken:
>
> commit 52af6e3f3f67d37aa72d06a5f60b1a3967d6c297
> Author: Michael Natterer
> 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 |
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 t
uot;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 wrote:
> On Mon, 2012-09-17 at 14:23 -0400, Elle Stone wrote:
>> While making changes to "Edit/Preferences
ile 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
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
_
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-de
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,
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 r
B 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/te
2 >= lcms_required_version,
AC_DEFINE(HAVE_LCMS, 1, [Define to 1 if lcms is available])
LCMS='lcms$(EXEEXT)',
have_lcms="no (lcms not found or unusable)")
Help! Please help!
Elle Stone
--
http://ninedegreesbelow.com
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list
On 8/31/12, Jon Nordby wrote:
> On 31 August 2012 17:39, Elle Stone wrote:
>> What's the right way to compile a module such as display-filter-lcms.c?
>
> The build of the in-tree modules is already set up in automake. Just
> change the file after having compiled GIMP wit
t numbers might be pertinent to crafting the remaining
80%. But if not, then I apologize for posting it.
Elle
On 8/31/12, Alexandre Prokoudine wrote:
> On Fri, Aug 31, 2012 at 7:37 PM, Elle Stone wrote:
>> I keep coming back to this question. If your goal is to convert all
>> image
: ld returned 1 exit status
Compiling all of Gimp takes a half hour on my old, slow machine, so
there has to be a better way to recompile the display-filter-lcms
module.
Thanks in advance if anyone can help,
Elle Stone
--
http://ninedegreesbelow.com
Articles and tutorials on open source digi
maginary colors. But
this whole negative floating point values thing for ICC profiles is
new territory to me. I've known about it theoretically for a long
time, but until now never had the wherewithal (the new LCMS
utilities/capabilities) or reason (your linear light color space) to
acquire any pr
-bit
image that doesn't have the sRGB TRC. Please see this page for an
example using Gegl blurring:
http://ninedegreesbelow.com/temp/gimp29-gegl-blur-prophoto.html
My color conversion code is NOT involved in blurring, and to make
double sure, I replaced my lcms2 plug-in with the default Gimp lcm
On 8/30/12, Jon Nordby wrote:
> On 30 August 2012 01:01, Elle Stone wrote:
>> Regarding sRGB and rendering to the screen:
>> Could you explain more about what you mean by "rendering to the screen
>> is done using sRGB"? What about the actual monitor profile?
ng exactly that. It was the
next step anyway, but I was feeling very discouraged about the whole
babl/babl/util.h thing.
Regarding sRGB and rendering to the screen:
On 8/29/12, Jon Nordby wrote:
> On 29 August 2012 19:03, Elle Stone wrote:
>> Why does the /babl/babl/util.h code get execute
diverse TRCs. Monitor profiles do *not* always have the
sRGB TRC. Some monitor profiles aren't even matrix profiles. This
diversity of TRCs is handled quite well by using LCMS to convert from
one color space to another.
Respectfully, with kindest regards, and also with ever-increasing c
If anyone would like to try the lcms2 high bit depth plug-in, I put up
instructions on compiling Gimp from git and the lcms2 plug-in, plus
babl and gegl, with the modified babl/babl/util.h file:
http://ninedegreesbelow.com/temp/gimp-lcms-6.html
--
http://ninedegreesbelow.com
Articles and tutori
On 8/27/12, Øyvind Kolås wrote:
> On Mon, Aug 27, 2012 at 4:08 PM, Elle Stone wrote:
>> My lcms2 plug-in now does do correct ICC profile conversions, from any
>> RGB color space, to any RGB color space, at 8-bit integer, 16-bit
>> integer, and 32-bit floating point.
>&g
My lcms2 plug-in now does do correct ICC profile conversions, from any
RGB color space, to any RGB color space, at 8-bit integer, 16-bit
integer, and 32-bit floating point.
However, to get it to work, I had to modify the babl/babl/util.h file.
After modifying the babl/babl/util.h file, 16-bit tif
Working on getting high bit depth color conversion to work (still not
there yet!) has meant peeking into a lot of babl/gegl/gimp code. I
noticed unusual sRGB tone curve values in the functions
"linear_to_gamma_2_2" and "gamma_2_2_to_linear", defined in
/babl/babl/util.h.
The standard values are: 0
I noticed an error in the resulting values when changing image
precision from 8-bit integer to 16-bit integer.
For example, in a ten-block 8-bit RGB test image, the block with the
linear gamma sRGB 8-bit values of (1,1,1) should be (257,257,257) upon
changing the precision to 16-bit integer. But i
On 8/13/12, Elle Stone wrote:
> Upon converting to any other ICC profile, the colors come out all wrong
> . . . then the colors are magically right. Which is both bizarre and wrong.
A coding error/oversight on my part is the answer to the "magically
right": the new profile is
I posted an update to my effort to port the lcms plugin to lcms2 and
get it to do high-bit-depth color conversions:
http://ninedegreesbelow.com/temp/gimp-lcms-4.html
Summary of current state of plugin:
It uses lcms2.
It does high bit depth conversions, but some options are not available yet.
It
On 8/8/12, Michael Natterer wrote:
> By discussing here, you turned yourself into a contributor to
> the definition of that future workflow and feature set. Since
> you know quite a lot and have an opinion, why not suggest how
> it *should* work, in your opinion, along the constraints that
> the c
On 8/7/12, Øyvind Kolås wrote:
> On Mon, Aug 6, 2012 at 7:35 PM, Elle Stone wrote:
>> On 8/5/12, Øyvind Kolås wrote:
>> I don't think I understand what the preceeding sentence says. I think
>> it says that ultimately, when all changeover to gegl/babl is complete,
>
On 8/5/12, Øyvind Kolås wrote:
> GIMP-2.9 is only partially on it's way through to be fully working
> properly with GEGL/babl. ICC profiles should only need to be involved
> upon loading files from disk and exporting to files used outside -
> internally it is up to GIMP/GEGL/babl to assign approp
Some day I might figure out how to use email. In the meantime, here's
the rest of what should have been part of the previous email:
> but the meta data
> passed around in terms of bablformats in the GeglBuffer will still
> state that this is sRGB data, and when gegl:gaussian-blur is blurring
> it
On 8/5/12, Øyvind Kolås wrote:
> On Sat, Aug 4, 2012 at 11:44 PM, Elle Stone wrote:
>> While working on the article, I noticed that the Gimp Gegl gaussian
>> blur nicely blurs *regular* sRGB images without the darkening
>> artifacts that normally accompany gaussian blurr
aussian blur "pixel": Size 10 seems to be approximately 30 pixels,
which will take some getting used to. I didn't check to see if the
Size/pixel ratio seems constant across different sizes. Does anyone
know if it is?
Elle Stone
--
http://ninedegree
On 7/24/12, Michael Schumacher wrote:
> there are two bug reports in Bugzilla about changes in GIMP related to
> lcms2:
>
> This one introduces lcms2 to get support for ICC V4 profiles:
> https://bugzilla.gnome.org/show_bug.cgi?id=662739
>
>
> That one has been created to move everything to lcms2
>So please, just go ahead, look at the patches in bugzilla, pick the
>best stuff from your patches and the bugzilla ones, and all will be
>fine.
OK, I'm working on it. And I promise to keep communicating actively.
I'm making two Gimp from git installations, one for the existing lcms2
patches (than
501 - 600 of 616 matches
Mail list logo
