Re: [Gegl-developer] babl docs
On Wed, Sep 1, 2010 at 9:47 AM, Rupert Weber g...@leguanease.org wrote: Hi, trying to get to know babl (wrt the LCH layer modes), quite a few questions came up that made me wish for a babl 'Conversion implementor's guide'. (If such a document exists just disregard the rest of this mail -- but please show me where). So maybe the best I could do for starters is write such guide -- as long as I still remember what the questions are of someone newly confronted with babl. But I'll need a little help with the answers... ;o) Sounds like a great idea! First, two general questions about babl: - babl decides which conversion to use, based on speed and accuracy. Is that a build-time or run-time decision? IIRC Oyvind said this is checked at run time. Adding conversions to babl: I haven't gone deep into the babl source yet (and hope I won't have to), so the following is a mixture of my best guesses and some open questions. I'll be glad for 'yes/no' confirmations and of course any additional info/answers: - Create source file in subdirectory 'extensions' and add it to extensions/Makefile.am. The rest is automagic. True. - Source must have 'int init (void)' function which announces/registers the new conversions: Seems true to me, but I haven't tested it yet. - Register color model and its components using babl_component_new() [ what about luma, chroma, alpha? ] AFAICS those are misleading -- I think they are booleans (ie 'this is a luma channel'* (L of LAB/LCH or Y of (graY)), 'this is a chroma channel' (A/B of LAB; Cb/Cr of YCbCr), 'this is an alpha channel' (.. alpha) ) Grepping through the appropriate files, you can see that: plain R,G,B are registered with LUMA and CHROMA, without ALPHA. Ra,Ga,Ba are registered with all 3; R', G', B' are registered similar to R,G,B; R'a, G'a, B'a are registered similar to R,G,B (this seems to be a copy/paste error; AFAICS they should also have the ALPHA flag) Naive CMYK are registered without any flags - this probably reflects the naivety. All Y variants are registered as only LUMA (including the premultiplied variants). This seems wrong also; perhaps Oyvind can shed some light on this. LAB /LCH A,B+C,H channels are registered with CHROMA flag, which makes sense, but L isn't registered with LUMA. (I don't really understand that, either) * AFAICS, 'luma' is meant in a loose sense here..this channel encodes brightness in some sense not this channel encodes X specification of brightness babl_model_new() [ lots of parameter possibilities... ] [ naive-CMYK e.g. registers CMYK but not RGBA. RGBA is the responsibility of model-rgb.c , IIRC. I'm not sure what it was you meant to say here. I assume RGBA is a core-format that can always be relied on to exist? Is there a list of such formats? I figured that http://gegl.org/babl/#Features (under the 'vocabulary' heading) had such a list (click 'color models' and 'pixel formats'); maybe not 'forever', but 'for the foreseeable future.' The 'extensions' dir is a little confusing. I interpret the this 'canonical' set of extensions as implying additional color models that are virtually fixtures (though the implementation of them may vary -- eg. the LCH being implemented in both CIE.c and gggl-lies.c, with the latter being ignored at runtime due to lesser quality.) PS: babl-core.c suggests that RGBA (+ its components) is the only hardcoded model, along with the PAD component and the double type. PPS: babl-base.c has additional types and models: types: float/u8/u16/u32 models: (plus respective components Ra/R'/R'a etc.) RGB: RGB/RaGaBaA/R'G'B'/R'G'B'A/R'aG'aB'aA Gray: Y/YA/YaA/Y'/Y'A/Y'aA YCbCr: YCbCr/YCbCrA... now it gets confusing. Where the hell does y' come from? Y is not registered by the YCbCr module because the Gray module already registered it. That's fine (component lookups are indirected through the BABL core to allow things like this.). (if you have a component with actually different meaning but the same mnemonic letter/s, that's a different issue.) As far as I can see, you probably only want to: 1. register two new formats CIE LCH(ab) u16 and CIE LCH(ab) alpha u16; 2. register some conversions from/to eg R'G'B'A u8 (it should be pretty easy to also make versions for RGBA u8, too). You might want to consider defining conversions from the grey formats (Y' ,Y,Y'a,YA) too; I was just thinking about how your LCH layer modes act like Normal mode when applied to Grayscale images. 3. (no need to register new models or components) Hope that helped :) ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] gsoc2010: a collection of filters for GEGL
On Sun, Apr 4, 2010 at 2:03 PM, Øyvind Kolås islew...@gmail.com wrote: GMIC and resynthesizer do some of these things with some approaches, netiher of them do it as GEGL ops nor are they usable for GIMP or other applications as GEGL operations. Thus from a purely GEGL based view no such functionality is available. /Øyvind K. Sorry, I misread the message headers and thought this was the GIMP list. ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] gsoc2010: a collection of filters for GEGL
On Sun, Apr 4, 2010 at 11:54 AM, Danny Robson da...@blubinc.net wrote: Hi all, I am a PhD candidate at the Australian National University, currently creating and evaluating performance profiling tools for NUMA systems. I have always had an interest in the realm of graphics, though I have only managed minor patches for GEGL/BABL in the past. As the deadline for gsoc2010 applications is far too rapidly approaching, I was curious about thoughts on another alternative proposal: implementing a collection or series of related filters. I have a selection of ideas which I have briefly investigated, and may be of interest: 1. While GEGL has excellent support for high depth colour spaces, there are few examples of filters which take advantage of this explicitly. I would be interested in implementing (or porting) a collection of tone mapping operators as native GEGL filters. This leads me to wonder what kind of operation the GEGL 'tone-map' op currently performs. 2. Image matting techniques with trimaps, such as the closed form of Levin et. al., have very interesting applications for end users. I would be interested in implementing one such technique and further filters applying it (such as haze removal and spatially varying white balance). 3. The matting of #2 could segue nicely into an implementation of image completion/inpainting (which is receiving more public exposure due to similar techniques in the upcoming Adobe CS5). GMIC and Resynthesizer already do this. Perhaps they could do it faster or better. I'm not quite clear on the level of complexity required for a gsoc proposal so I have left the extent and combination of ideas open. I would be open to further suggestions for this style of proposal, and shall use any input for a more concrete proposal if there is interest. I'll try to catch some people on IRC (under the nick 'eNGIMa') to discuss the idea's desirability. Many thanks for your consideration, - Danny Robson ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] blurb about gegl
Hello Martin! On Wed, Feb 18, 2009 at 4:39 PM, Martin Nordholts ense...@gmail.com wrote: Nicolas Robidoux wrote: Hello all. GEGL is expected to bring non-destructive editing, high dynamic range, and large image support to the next major release of the GIMP (GNU Image Manipulation Program). Hi The only thing that I found somewhat inaccurate is the and large image support bit. GIMP already has support for 26 x 26 images which I would call large. Did you refer to something other than image dimensions with large perhaps? I thought by this that Nicolas meant better handling. Because currently, large images are pretty slow, and eat more memory than is strictly necessary ( I certainly find them unusable for any kind of intensive painting or manipulation). Perhaps 'better large image handling' instead? David ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] New GEGL logo
Hi Oyvind, i like it a lot! It's ironic that the gamma is wrong on the main lettering. You can produce gamma = 1.0 images with GIMP, using the 'CIE 1931 D65 Gamma 1.0' profile (and possibly also the 'nativePC' profile, to produce nice-looking sRGB data if needed), from here: http://www.aim-dtp.net/aim/techniques/linear_raw/index.htm I just used those profiles to quickly improve the antialiasing quality on the letters (with the side effect that th shadows dropped on neighbouring letters are not as dark as they should be any more.) Hopefully you'll re-render the logo in a linear colorspace so everything looks right. David ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
[Gegl-developer] PyGEGL instant crash
Using Python 2.6, typing 'import gegl' at the interpreter prompt causes the following crash to immediately happen: babl-db.c:100 babl_db_insert() Ek Using host libthread_db library /lib/tls/i686/cmov/libthread_db.so.1. [Thread debugging using libthread_db enabled] [New Thread -1210014016 (LWP 30914)] 0xe410 in __kernel_vsyscall () #0 0xe410 in __kernel_vsyscall () #1 0xb7e97933 in waitpid () from /lib/tls/i686/cmov/libc.so.6 #2 0xb7e413c9 in strtold_l () from /lib/tls/i686/cmov/libc.so.6 #3 0xb7f6e7dd in system () from /lib/tls/i686/cmov/libpthread.so.0 #4 0xb6e93df4 in babl_backtrack () at babl-internal.c:68 #5 0xb6e93e15 in babl_die () at babl-internal.c:74 #6 0xb6e8d352 in babl_db_insert (db=0x0, item=0x82bbff8) at babl-db.c:100 #7 0xb6e968be in babl_type_new (first_arg=0xb6ef90d6) at babl-type.c:135 #8 0xb6ef7dea in init () at CIE-Lab.c:427 #9 0xb7b191b3 in babl_extension_init () at babl-extension.c:194 #10 0xb7b16a2f in babl_init () at babl.c:40 #11 0xb7b3630e in gegl_post_parse_hook (context=0x0, group=0x0, data=0x0, error=0x0) at gegl-init.c:199 #12 0xb7b364d5 in gegl_init (argc=0xbffa1038, argv=0xbffa1034) at gegl-init.c:73 #13 0xb7f8494d in pygegl_register_classes (d=0xb7d27714) at gegl.override:139 #14 0xb7f82f21 in initgegl () at geglmodule.c:57 #15 0x080d742f in _PyImport_LoadDynamicModule (name=0xbffa2177 gegl, pathname=0xbffa1103 /usr/lib/python2.6/site-packages/geglmodule.so, fp=0xfe00) at ./Python/importdl.c:53 #16 0x080d5327 in load_module (name=0xbffa2177 gegl, fp=0x0, buf=0xbffa1103 /usr/lib/python2.6/site-packages/geglmodule.so, type=3, loader=0xbffa0974) at Python/import.c:1752 #17 0x080d578c in import_submodule (mod=0x81343c0, subname=0xbffa2177 gegl, fullname=0xbffa2177 gegl) at Python/import.c:2394 #18 0x080d59d1 in load_next (mod=0x81343c0, altmod=0x81343c0, p_name=value optimized out, buf=0xbffa2177 gegl, p_buflen=0xbffa3178) at Python/import.c:2214 #19 0x080d5e0d in import_module_level (name=0x0, globals=0xb7de2acc, locals=value optimized out, fromlist=0x81343c0, level=-1) at Python/import.c:1995 #20 0x080d62de in PyImport_ImportModuleLevel (name=0xb7d23374 gegl, globals=0xb7de2acc, locals=0xb7de2acc, fromlist=0xfe00, level=-512) at Python/import.c:2066 #21 0x080b5658 in builtin___import__ (self=0x0, args=0xfe00, kwds=0xfe00)c:1995 at Python/bltinmodule.c:47 #22 0x0805a8ac in PyObject_Call (func=0xbffa0974, arg=0xfe00, kw=0xfe00) at Objects/abstract.c:1860 #23 0x080b9c39 in PyEval_CallObjectWithKeywords (func=0xfe00, arg=0xb7ddecac, kw=0x0) at Python/ceval.c:3433 #24 0x080bc631 in PyEval_EvalFrameEx (f=0x81ebf24, throwflag=0) at Python/ceval.c:2071 #25 0x080c133f in PyEval_EvalCodeEx (co=0xb7d9d968, globals=0xb7de2acc, locals=0xb7de2acc, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2840 #26 0x080c14c6 in PyEval_EvalCode (co=0xfe00, globals=0xfe00, locals=0xfe00) at Python/ceval.c:493 #27 0x080df9dc in PyRun_InteractiveOneFlags (fp=0xfe00, filename=0x8116d6e stdin, flags=0xbffa3688) at Python/pythonrun.c:1293 #28 0x080dfbd0 in PyRun_InteractiveLoopFlags (fp=0xb7f37240, filename=0x8116d6e stdin, flags=0xbffa3688) at Python/pythonrun.c:723 #29 0x080e030b in PyRun_AnyFileExFlags (fp=0xb7f37240, filename=0x8116d6e stdin, closeit=0, flags=0xbffa3688) at Python/pythonrun.c:692 #30 0x08056dad in Py_Main (argc=0, argv=0xbffa3724) at Modules/main.c:527 #31 0xb7e20ea2 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6 #32 0x08056251 in _start () at ../sysdeps/i386/elf/start.S:119 I don't find this terribly enlightening, except it looks very much like a crash I was getting before with BABL (but that was seemingly fixed). #11 seems to be the place where things first start going wrong. I'm also pretty sure that the bug lies in the pygegl module, as I've compiled and used many other modules for Python 2.6, with no problems, and I ran the babl and gegl tests successfully (and the gegl editor works okay too) Does anyone know what may be going wrong here? ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] PyGEGL instant crash
Oh, and BTW: I noticed that the 'text' node does not allow you to enforce an antialiasing policy. This means, for example, that on my system the default gegl editor graph's 'GEGL' text is rendered with no antialiasing (unlike eg. GIMP, where AA is explicitly specified and behaves correctly in both cases.). Obviously this is not anything major, but it might warrant a FIXME comment in the source. ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
