Re: [CREATE] Photo from libregraphics on BBC Chinese site?
I do not know what this particular article says in detail - but it is about an illusion i discovered this summer, which also made appearances in pop.sci. sections in parts of many print and online media in the following couple of months, for a little bit more information, see https://www.patreon.com/posts/color-grid-28734535 I have vague ideas about why it works, when devising it I based it on knowledge and fascination of how other illusions that do work are using interesting properties of our visual systems. I enjoy that some of the worlds acclaimed academic visual illusionists are incorporated some of the new knoledge from this discovery in their new eperiments. /pippin On Tue, Oct 22, 2019 at 4:03 PM Gregory Pittman wrote: > > On 10/22/19 9:05 AM, Øyvind Kolås wrote: > > The image is also on its way into a psychology text-book, possibly > > more. When this went viral online and in printed media .. most did not > > contact me. :) /pippin > > > > On Tue, Aug 6, 2019 at 7:32 AM Tom Lechner wrote: > >> > >> These days it's so hard to live off the grid! > >> > >> On 8/5/19 3:13 PM, Ricardo Lafuente wrote: > >>> > >>> One day you pop over at a graphics nerds conference, five years later > >>> boom you're in BBC China with colored squares on your face :-) > >>> > >>> (Yes it's in Leipzig, and next to me and Ana Isabel Carvalho it's > >>> Stuart Axon and Tom Lechner) > >>> > >>> On 03/08/19 12:00, Hin-Tak Leung wrote: > >>>> Hi, > >>>> > >>>> I was reading stuff and BBC Chinese - I am pretty sure the photo used > >>>> was taken in libregraphics one year (which?) as I recognize three > >>>> people in the photo! > >>>> One of them is Tom, the other is Ranaldo(?) and Ana? > >>>> > >>>> It is an article about color illustrations. > >>>> > >>>> https://www.bbc.com/zhongwen/trad/science-49218450 > > Does anyone know what this article is saying? This doesn't look like any sort > of optical illusion I am familiar with. > > Greg > > ___ > CREATE mailing list > CREATE@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/create ___ CREATE mailing list CREATE@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/create
Re: [CREATE] Photo from libregraphics on BBC Chinese site?
The image is also on its way into a psychology text-book, possibly more. When this went viral online and in printed media .. most did not contact me. :) /pippin On Tue, Aug 6, 2019 at 7:32 AM Tom Lechner wrote: > > These days it's so hard to live off the grid! > > On 8/5/19 3:13 PM, Ricardo Lafuente wrote: > > > > One day you pop over at a graphics nerds conference, five years later > > boom you're in BBC China with colored squares on your face :-) > > > > (Yes it's in Leipzig, and next to me and Ana Isabel Carvalho it's > > Stuart Axon and Tom Lechner) > > > > On 03/08/19 12:00, Hin-Tak Leung wrote: > >> Hi, > >> > >> I was reading stuff and BBC Chinese - I am pretty sure the photo used > >> was taken in libregraphics one year (which?) as I recognize three > >> people in the photo! > >> One of them is Tom, the other is Ranaldo(?) and Ana? > >> > >> It is an article about color illustrations. > >> > >> https://www.bbc.com/zhongwen/trad/science-49218450 > >> > >> ___ > >> CREATE mailing list > >> CREATE@lists.freedesktop.org > >> https://lists.freedesktop.org/mailman/listinfo/create > > > > ___ > > CREATE mailing list > > CREATE@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/create > ___ > CREATE mailing list > CREATE@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/create ___ CREATE mailing list CREATE@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/create
Re: [CREATE] Some questions about OpenRaster Format, Color and GEGL
On Mon, Jun 3, 2019 at 4:12 PM Jan-Peter Homann wrote: > 3) GEGL and Color > Pippin, did I understood you at LGM correct, that GEGL is able to use > different ICC-profiles for chunks/nodes in the GEGL tree ? > If yes, is it correct, that OpenRaster would not be an appropriate file > format for such cases? > or, If yes, do you provide an extension the the OpenRaster format? > If not, this was probably a missunderstanding from my side... > > If yes, the complexity of interactions between colormanagement and blending > modes will increase massively. Photoshop still avoids this complexity by > allowing only one profile per document. If any new image with a differnt > colorspace (e.g. CMYK instead of RGB) or different profile (e.g. sRGB instead > of AdobeRGB) will be added to an document, all image colors will concerted to > actual document colorspace. GEGL doesn't make use of OpenRaster, but there is nothing in the design of OpenRaster that is contrary to internal color management within the processing graph, PNG files (and OpenRaster extended with for instance TIFF or JPG or CMYK) can each independently hold the ICC information. The bottom-most/background layer in a sense becomes or dictates the document working space, since for compositing nodes the internal working space is a floating point associated-alpha variant of the pixel format accepted on the input pad, the data coming in on the secondary/"aux" pad gets converted to match the other, and the data is provided for further processing in the tree/graph in a space with primaries/ICC profile "inherited" from the background layer. In addition to this, GIMP goes further than GEGL in the compositing of its layers, the operations implementing layer modes permit specifying if they request data with no-TRC, the TRC from the ICC profile or a TRC with the float value 0.5 as middle gray. This permits maintaining the legacy results one gets with naive compositing of 8bit sRGB data for some layers as well as in the same document having more correct compositing without the gamma-related fringing doing it in sRGB would result in. This locally-in-graph handling of color space information also makes it possible to have multiple documents with different color spaces, as well as doing copy and paste between buffers with different model/precision/color space. /pippin P.S.: I encourage color focused participants of LGM to ask for a color-BoF for asking and getting answers to such questions as well as color specific notes sharing between projects at LGM, we used to have this in the past. Face to face communication is a lot more efficient use of time than mailinglists for, among others, dyslectic non-native english speakers - and in my experience color discussions seem particularly badly suited for mailinglists often deterioating into terminology related confusion, misunderstandings, and flames. ___ CREATE mailing list CREATE@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/create
Re: [CREATE] Fw: CxF- colour plattes (e.g. from freie Farbe) in Open Source applications
On Tue, Dec 5, 2017 at 11:57 AM, Tobias Ellinghaus wrote: > Am Montag, 4. Dezember 2017, 11:03:29 CET schrieb Christoph Schäfer: > [...] > >> -- - Do you know any existing open source libraries, which are converting >> spectral-data to Lab ? > > How do these values look like? How many samples per patch are given? I don't > know of such a library, but I know people who deal with these things and I > might be able to get sample code to turn into a small library. I've recently made a new project that aims to deal with this by continuing workon other spectral color processing code. Coloritto is now a protoype CxF viewer/editor, that includes computing CIE XYZ from reflectance spectra in cxf files. My plan is towards supporting ISO17972 CxF-4 spectral characterization with tint ramps on black and white substrates - for custom spectral separation and simulation/proofing see https://gitlab.gnome.org/ok/coloritto/ for further information. The color hue match in the Freie Farbe data set is good, good enough that one can spot many errors that seem to be due to shuffling of colors or rows of colors during measurement, one such color is selected in the following screenshot : http://pippin.gimp.org/tmp/freie-farbe-bug.png and text file dump: http://pippin.gimp.org/tmp/freie-farbe.txt this screen shot uses an orthogonal projection along the L axis, the straighter the spokes the better the exact hue has been matched. PS: I plan to implement interpolation based reconstructinon of spectrum from CIE XYZ using the freie-farbe dataset as ground reference lookup table, and thus should be able to generate a new synthethic dataset based on the existing HLC_EPV_M0_V2-3.cxf that yields exact CIE Lab/lch/HCL based on these representative spectra. /Øyvind Kolås ___ CREATE mailing list CREATE@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/create
Re: [CREATE] Code of Conduct
On Thu, Jan 16, 2014 at 4:09 AM, Susan Spencer susan.spen...@gmail.com wrote: I applaud the statements that the LGM CoC should be phrased in a positive way. But this is not about staying within comfort zones, its about protecting people. If anyone were comfortable with this subject matter then they would be very odd indeed. So please consider the practical nature of the CoC, and embrace a small bit of 'uncomfortableness' because it may help someone in the future. I expect everyone considering to attend a conference to read and understand a code of conduct. To me, the hate-speech against humanity CoC, is the same as showing a graphically explicit video of examples of non-toleratable behavior at the start of the meeting (perhaps daily); similar to a safety video on an airplane. The first time I read this text; it caused be to be disgusted with a conference I had enjoyed attending the year before - in the end I chose to attend and express the reaction I had to the new humanity hostile impression the conference now was tainted with. ___ CREATE mailing list CREATE@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/create
Re: [CREATE] CREATE Digest, Vol 102, Issue 7
On Wed, Jan 15, 2014 at 3:12 AM, Susan Spencer susan.spen...@gmail.com wrote: Can LGM adopt the PSF policy as a temporary measure? I might agree to a positively phrased; based on the belief that humans can be good; and that our participants respect each other desire good towards each other, and are able to think.. http://www.python.org/psf/codeofconduct/ But not a policy with an entirely negative view of humanity; enumerating how one can be unexellent towards each other http://geekfeminism.wikia.com/wiki/Conference_anti-harassment/Policy that itself deserves trigger warnings,. and one would expect every attendee to read before participating; filling their minds with negativity.. /pippin ___ CREATE mailing list CREATE@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/create
Re: [CREATE] Linear light workflow
On Thu, Mar 29, 2012 at 4:27 PM, Boudewijn Rempt b...@valdyas.org wrote: I might be missing something here... But isn't the potential for confusing much bigger in the case where there's no clear definition of the image's color space? Krita actually doesn't have an internal working space, gegl does have one, but it differs from MyPaint's again. Nitpick, GEGL doesn't actually have an internal (global) working space, each operation has it's own preferred representation used to manipulate the colors. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson ___ CREATE mailing list CREATE@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/create
Re: [CREATE] Linear light workflow
On Wed, Mar 28, 2012 at 7:33 PM, Andrew Chadwick a.t.chadw...@gmail.com wrote: On 28 March 2012 17:08, Boudewijn Rempt b...@valdyas.org wrote: I tested today in krita -- it's a little known thing that Krita supports a linear-light workflow perfectly well. Basically, it's a matter of using the right icc profile to define the working space and the example Andrew showed just works in Krita. Wouldn't it be easier to just define the working space with a profile in openraster, and take it from there? The approach that I think will make sense for GIMP is not a global working space, but as I outlined different working spaces for different compositing/layer-modes. In GEGL each operation specifies how it wants to work with the pixels. The implemented porter-duff modes are in linear; the SVG variants should probably specify sRGB so that an SVG reinterpreted as a GEGL compositing graph would render correctly. In GEGL this does not only apply to compositing but also to filters like blur, since blurring of a gamma corrected image also leads to unexpected results. /Ø -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://twitter.com/hodefoting ___ CREATE mailing list CREATE@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/create
Re: [CREATE] Linear light workflow
On Tue, Mar 27, 2012 at 5:35 PM, Andrew Chadwick a.t.chadw...@gmail.com wrote: How do (did) GIMP and Krita manage this for their native formats, OOI? GIMP doesn't, yet. In the goat-invasion of GIMP gimp is even lying to GEGL about the gamma by using the babl-format RGBA u8 which is linear 8bit data rather than R'G'B'A u8 which is 2.2 gamma corrected 8bit data to get the expected legacy renderings. This will need to change - as GEGL itself is preferring to do compositing in .. RaGaBaA float linear premultiplied 32 bit floating point RGB. The way that it will have to be handled is to add GEGL ops (perhaps internal to GIMP) that does the compositing in gamma 2.2 rather than linear. I hope that these layer modes will in the end only be used when loading legacy XCF files and newer linear compositing will be used when creating new images from scratch (the 2.2 gamma layer modes could then be hidden.) The need for having the legacy layer modes around will be required to continue producing the same composited result (the same applies to some of the odd HSV defined modes in GIMP.) /Øyvind K. -- ___ CREATE mailing list CREATE@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/create
Re: [CREATE] [ORA spec] effects filters are incompletely specified
On Mon, Mar 26, 2012 at 10:12 PM, Andrew Chadwick a.t.chadw...@gmail.com wrote: ... (pure selfishness, not wanting to implement blur with MyPaint's tile-based representation right now). GIMP's integration of GEGL is proceeding nicely now. A plan that was formed a good while ago is now well on it's way through execution. The old tile based API of GIMP, known as TileManager was used to provide a tile backend for GeglBuffer. This means that wherever there is a TileManager in GIMP a GeglBuffer wrapper can be created and operated on with GEGL (when destroying or flushing the wrapper cached changes are synced back). Such tile-backends can even use zero-copy and directly use the data from the underlying tile implementation, we chose to stop doing so in GIMP since GEGL is happier tile sizes larger than 64x64px which GIMP has been using. As an example of what is needed for such integration look at: http://git.gnome.org/browse/gimp/tree/libgimp/gimptilebackendplugin.c?h=goat-invasion Which is an implementation of such a backend on the plug-in side for GIMP. The reason I mention this is that doing a similar thing for MyPaint makes it possible to use any GEGL op, including on other tile based representations. Perhaps overkill for just gaussian-blur - but the approach, though transitional for GIMP can enable other applications to reuse GEGLs plug-ins. /Ø -- ___ CREATE mailing list CREATE@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/create
Re: [CREATE] Status of ORA animation draft
2012/3/25 Manuel Quiñones ma...@laptop.org: Personally I don't really think of OpenRaster as an animation format, but if it can be made to work as one in a way that's compatible with static image editors (ideally in a way that doesn't break when edited by a static image editor (good luck[1]!)), why not? I think in order to keep the formal, baseline part of the spec nice and light, animation would have to be an extension - though possibly a very standard extension if it's well specified, would work with more than one app, and seems sound to a consensus of animators. Before OpenRaster was even thought of I was working on a format for a video editor that included animation, this format served as the inspiration for the XML I used in GEGL which in turn provided one of the bases of experience that OpenRaster is built on. The original format I refer to I called oxide and it is documented here http://codecave.org/oxide/ not sure if it really has that much to do with OpenRaster but it can serve as inspiration for something else. Note that the interpolation methods for the time/value keyframed property animation was also possible to specify. /Ø ___ CREATE mailing list CREATE@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/create
Re: [CREATE] Libre Graphics workshops, BoFs, et.c. sessions at DesktopSummit 2011
On Wed, Jun 29, 2011 at 1:00 PM, Jon Nordby jono...@gmail.com wrote: On 20 June 2011 10:32, Jon Nordby jono...@gmail.com wrote: The call for participation for Workshop BoFs for the DesktopSummit 2011 (which is in Berlin between August 6th and 12th) has just been published. Info here: http://desktopsummit.org/program/workshops-bofs Excerpt: All forms of activities that aim to further the Free Desktop by getting people together to discuss, work and make decisions are welcomed. Examples of such sessions include BoF sessions (http://en.wikipedia.org/wiki/Birds_of_a_Feather_%28computing%29), project and cross-project meetings, workshops, hacking sessions and training/teaching sessions. Each session is self-organized and it is up to the hosts and participants to decide if the session is to be loosely oriented around a set of topics, or have a well-defined agenda. As graphics software is a critical part of a desktop, I would say that Libre Graphics is naturally a critical part of the Free Desktop. This might be especially interesting for: - BoFs, et.c. on topics that have an impact on a wider audience and (color management, file formats, general interoperability, et.c.) - Projects meetings for projects who did not have a strong presence in LGM 2011 in Montreal that still want to get together face-to-face this year. - Teaching our tools to the free desktop contributors who rely on them in their workflow, and getting feedback from them - Hacking sessions I am going to be present at least, and if there is interest will do a session on OpenRaster (I have a lighting talk on it as well). I've created a proposal now: http://wiki.desktopsummit.org/Workshops_%26_BoFs/2011/OpenRaster_workshop For the session to be accepted as a pre-registered session, and show up in the printed schedule I will need a co-host. Anyone interested? CC'ing some of the usual suspects. Full announcement follows = Call for Participation: Workshops BoFs at the Desktop Summit 2011 The Desktop Summit 2011 is a joint conference organised by the GNOME and KDE communities in Berlin, Germany from the 6th August 2011 to the 12th August 2011. Held annually in cities around Europe, GUADEC and Akademy are the world's largest gatherings of those involved with the free desktop or mobile user interfaces. Developers, artists, translators, community organisers, users, and representatives from government, education, and businesses and anyone else who shares an interest are welcome. GNOME and KDE are Free Software communities that drive the user interfaces of many GNU/Linux-powered devices, ranging from smartphones to laptops, or personal media centers. This year, for the second time, both communities have decided to organise a single, joint conference expecting over a thousand participants, covering both projects as well as related technologies. h2Not Just Presentations/h2 The Desktop Summit will have an exciting program of talks (https://www.desktopsummit.org/program). But the most important part of the conference are the Workshop BoF days. This is the part of the conference where the participants get together to discuss and work on the future of the Free Desktop. It is where the latest technology is demonstrated in a one-to-few setting and where decisions are made. The organisation committee would like to schedule as many of these sessions beforehand as possible. We expect over 1000 visitors and scheduling helps to ensure minimal overlap with other sessions and allows us to provide a clear timetable for the visitors. The remainder of the rooms will be scheduled via the wiki but we urge you all to try and get a proposal in before the deadline! We realize that many sessions are meant to be about current and urgent topics so we don't expect proposals to have an exact agenda, nor do we mind if the subject changes later on. h2Session requirements/h2 All forms of activities that aim to further the Free Desktop by getting people together to discuss, work and make decisions are welcomed. Examples of such sessions include BoF sessions (http://en.wikipedia.org/wiki/Birds_of_a_Feather_%28computing%29), project and cross-project meetings, workshops, hacking sessions and training/teaching sessions. Each session is self-organized and it is up to the hosts and participants to decide if the session is to be loosely oriented around a set of topics, or have a well-defined agenda. Each session is meant to be open to anyone who is interested, if you want to organize a closed session on a subject, contact the organisation (details below). We encourage participants to make use of the fact that the Desktop Summit will bring together people from several different communities, and the unique opportunities this creates. h2Reserving a spot on the Workshop BoF Days/h2 To register a session, use the form found on the the Workshops BoFs webpage on the Desktop
[CREATE] pinpoint 0.1.2 - Sushi Monday
pinpoint 0.1.2 - a tool for making hackers do excellent presentations = Pinpoint a simple presentation tool that hopes to avoid audience death by bullet point and instead encourage presentations containing beautiful images and small amounts of concise text in slides. Pinpoints main web-presence is a page in the GNOME wiki: http://live.gnome.org/Pinpoint This release of pinpoint comes shortly after last weeks initial release, along with the last item on the list (ahem) there is some more regular improvements and fixes as well. • New background scaling type 'stretch' • Handle relative paths fully • Added '.mkv' to list of video extensions • Only treat # at start of line as comments • Improve documentation • Distribute ClutterScript based transitions in tarball (without it pinpoint didnt work) You can download the pinpoint 0.1.2 distribution tarball from http://ftp.gnome.org/pub/GNOME/sources/pinpoint/0.1/pinpoint-0.1.2.tar.gz The sha1sum of this archive is: 3c22b446234fc8cd307aa6829303ace13e6a7f76 pinpoint-0.1.2.tar.gz You can clone the pinpoint git repository with the following command, or other equivalent commands for GNOME git repositories. git clone git://git.gnome.org/pinpoint Dependencies: Clutter 1.4 or newer GdkPixbuf 2.0 or newer GIO 2.0 or newer cairo-pdf 1.9.12 or newer and pangocairo (for optional PDF export) ClutterGst 1.3 or newer (for optional live videos as slide backgrounds) Dax 0.2 or newer (for experimental SVG slide background support) This pinpoint release was possible due to contributions from: Damien Lespiau, Øyvind Kolås, Jussi Kukkonen and Chris Lord -- Øyvind Kolås @ Intel Open Source Technology Centre - London ___ CREATE mailing list CREATE@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/create
Re: [CREATE] pinpoint
On Fri, May 20, 2011 at 12:09 AM, Gregory Pittman gpitt...@iglou.com wrote: Requested 'clutter-1.0 = 1.3' but version of Clutter is 1.2.14 I guess all clutters are named clutter-1.0, even though the version might be 1.3, 1.4, etc. (sigh) They are all named clutter-1.0 since later versions of the 1.x series are compatible with 1.0 Off to finding and compiling clutter... Oh me... This is too much work. It seems that there really is a long list of dependencies of advanced versions of various things, but configure only tells you one at a time, and they are generally not in fedora's repositories in recent enough versions. Just don't have the energy for compiling 10 different packages just to _try_ to compile pinpoint. Pinpoint should depend on Clutter 1.4 or newer, (the oddness of x.3 indicates that it depended on the development version of clutter at the time it was written). Clutter 1.4.0 was released 2010-09-24, you might be better off trying to compile that version of clutter and installing its dependencies than going for a bleeding edge version of Clutter. Alternatively... fedora 15 is out in a couple of days. /pippin -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ CREATE mailing list CREATE@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/create
[CREATE] pinpoint 0.1.0
pinpoint - a tool for making hackers do excellent presentations === Pinpoint a simple presentation tool that hopes to avoid audience death by bullet point and instead encourage presentations containing beautiful images and small amounts of concise text in slides. Pinpoints main web-presence is a page in the GNOME wiki: http://live.gnome.org/Pinpoint This is the first release of pinpoint, with the following features: • Text position • Styling of font, text-color, contrast background and text positioning for global default and per slide overrides. • Image backgrounds • Video backgrounds • Pango markup inside slides • Transitions, extendable through json • PDF export • Embedding commands to run for demos in slides, with editable commandline during presentation. • Monitoring of source file with live updates of changed slide for authoring The following illustrates what a pinpoint presentation looks like, for a more exhaustive overview of pinpoints features see the included sample presentation. __[example pinpoint presentation]___ # the 0th slide provides default styling for the presentation [bottom] # position of text [slide-bg.jpg] # default slide background --- [black] [center] # override background and text position A presentation - # lines starting with hyphens separate slides The format is meant to be usimple/u --- [ammo.jpg] # override background • Bullet point lists through unicode • Evil, but sometimes needed You can download the pinpoint 0.1.2 release from http://ftp.gnome.org/pub/GNOME/sources/pinpoint/0.1/pinpoint-0.1.0.tar.bz2 The sha1sum of this archive is: 4b56dfa36662fb8034e61cf12d1d006775e0a3a3 pinpoint-0.1.0.tar.bz2 You can clone the pinpoint git repository with the following command, or other equivalent commands for GNOME git repositories. git clone http://git.gnome.org/browse/pinpoint Dependencies: Clutter 1.4 or newer GdkPixbuf 2.0 or newer GIO 2.0 or newer cairo-pdf 1.9.12 or newer and pangocairo (for optional PDF export) ClutterGst 1.3 or newer (for optional live videos as slide backgrounds) Dax 0.2 or newer (for experimental SVG slide background support) This release of pinpoint has been realized through contributions from: Øyvind Kolås, Damien Lespiau, Emmanuele Bassi, Neil Roberts, Nick Richards and Daniel G. Siegel. ___ CREATE mailing list CREATE@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/create
Re: [CREATE] Reclaim your identity.
On Wed, Jan 12, 2011 at 8:18 PM, Alexandre Prokoudine alexandre.prokoud...@gmail.com wrote: On 1/12/11, Boudewijn Rempt wrote: Well... Maybe LGM can sponsor you? I did miss your input (and you) in Brussels, and I'm sure the same goes for others. Everybody knows that LGM stands for Liam Graphics Meeting really :) Liam Graphics Meeting is in Montreal this year, which hopefully makes it easier for the core audience to arrive from the vicinity of Toronto ツ /Øyvind K. ___ CREATE mailing list CREATE@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/create
Re: [CREATE] OpenRaster fallbacks (proposal/RFC)
On Thu, Jul 30, 2009 at 12:51 PM, Alexandre Prokoudinealexandre.prokoud...@gmail.com wrote: Just to make sure... Should some particular hinting be forced for fallback bitmaps of text or the app should store what the user sees when saving? Text rendering is one of the things that one can expect slight differences in implementation (or even more commonly; a font used not being installed/embedded) to cause massive differences in output. Thus it should be encouraged for some OpenRaster exhange setting of export to save a rasterization of text. It probably also should be part of any export (or export profile) dialog, where the user is asked what to do with different categories of filters/plug-ins/capabilities. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ CREATE mailing list CREATE@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/create
Re: [CREATE] OpenRaster fallbacks (proposal/RFC)
On Thu, Jul 30, 2009 at 7:40 AM, Jon A. Cruzj...@joncruz.org wrote: On Jul 28, 2009, at 7:43 AM, Cyrille Berger wrote: On Saturday 25 July 2009, Martin Renold wrote: Does anyone think this is a bad idea? Anyone got a different idea? I don't think that having a tag decided the use of the next tag is a good XML design (but then I am not an expert at XML...), I am not even sure we can enforce that in a schema. Um... eek! When phrased that way, it seems like a very un-XML approach to things. It strikes me that the MIME fallback approach might be something to keep in mind. A simple container of multipart/mixed, then a list of possible alternatives in order of preference. I do not think there is many scenarios where there would be multiple alternatives, it would probably always be intended XML code, and possibly a fallback render. I'd prefer some even simpler augmentation of what we already have, along the lines of Cyrille's projection tag, or perhaps even make the projection/ fallback/cache rendering reference just an attribute of the filter/stack/layer. We should permit fallbacks as a subelement of all possible OpenRaster XML elements, and that it would be encouraged to make this information survive an load/edit/save cycle. Making a language on top which is what the try/catch like approach reminds me of seems contrary to that. The idea of multiple alternative fallbacks also seem more complex than necessary. It should be possible to use and possibly exchange and to some extent modify files with other users that do not have the same plug-ins (and perhaps even different versions of the same plug-ins) without resorting to a central repository. A file saved with maximum portability would be huge, and I also wonder what needed extra support in user interfaces would be needed to tune such detailed control over what renderings are retained when opening a file. There is currently no render element in OpenRaster. I think we need one and I'm using it the following hypothetical examples: image w='512' h='384' stack cache src='caches/stack-1f3a.png' / filter type='gegl:unsharp-mask' cache src='caches/gegl-unsharp-mask-2bf1.png' version='gegl-0.1'/ params param name='std-dev'4.8/param param name='scale'2.0/param /params /filter render type='gegl:checkerboard' cache src='caches/gegl-checkerboard-01b2.png' version='gegl-0.1'/ params param name='x'20/param param name='y'20/param param name='color1'rgb(0.2,0.2,0.2)/param param name='color2'rgb(0.4,0.4,0.4)/param /params /render /stack /image Or perhaps even the shorter: image w='512' h='384' stack cache='caches/1f3a.png' filter type='gegl:unsharp-mask' cache='caches/2bf1.png' params param name='std-dev'4.8/param param name='scale'2.0/param /params /filter render type='gegl:checkerboard' cache='caches/01b2.png' cache-version='gegl-0.1' params param name='x'20/param param name='y'20/param param name='color1'rgb(0.2,0.2,0.2)/param param name='color2'rgb(0.4,0.4,0.4)/param /params /render /stack /image /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ CREATE mailing list CREATE@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/create
Re: [CREATE] project logos in svg format
On Sat, Mar 7, 2009 at 2:24 PM, alessandro rimoldi ale.comp...@xox.ch wrote: i'm doing a poster about libre graphics and i need the logos of the lgm projects in svg format... (and i guess that we may need the logos also for the program at lgm 2009...) can you send me links to svg files for your project? (a file attached to an email will also do :-) The GEGL logo can be found at http://svn.gnome.org/viewvc/gegl/trunk/docs/images/ (GEGL.svg) and the babl logo is at http://svn.gnome.org/viewvc/babl/trunk/docs/graphics/ (babl-48x48.svg) /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ CREATE mailing list CREATE@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/create
Re: [CREATE] OpenRaster and filters
On Tue, Jun 17, 2008 at 7:43 AM, Kai-Uwe Behrmann [EMAIL PROTECTED] wrote: Am 17.06.08, 00:01 +0200 schrieb Cyrille Berger: On Friday 13 June 2008, Kai-Uwe Behrmann wrote: b) to make options a non pixel thing, e.g. move to a precentage relationship How would you define a percentage for a radius ? Well, there are some logical answeres. I would choose the OpenRaster image width as the reference. The width of the image is not good for OpenRaster as an OpenRaster document essentially can be copied and pasted as a layer into another OpenRaster document. For this to work you would have to work on the extent of the input buffer not the extent of the image (a final crop). Besides the whole premise of this discussion is wrong as we most probably shouldn't be discussing an ill-defined radius for a gaussian but the standard deviation to be used (in pixels or not is still relveant though). There are filters that only take parameters making sense in pixels though, the way the SVG 1.2 filter specification solves this is to specify a specific resolution that the filter should be interpreted at. With pixel independency the filters can easily be applied to several image resolutions without any recalculations. This is not likely to happen in this manner, since both the filters and the images involved form part of a composition. We haven't been discussing resolution independence in OpenRaster at any length yet, and I think it is premature to do so. Both Krita and GIMP are mainly focused on layers that remain at fixed scale and measture their positioning using pixel. It is important that we get this working before we start worrying about positioning the upper left of the auxiliary buffer in the over operation based on relations to the input buffer, as well as build scaling of the layer according to it's parent layer). If/when we go down the route of incorporating relative units for geometry related properties I do hope that we stick with numbers in the 0.0-1.0 range instead of 0.0-100.0. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ CREATE mailing list CREATE@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/create
Re: [CREATE] OpenRaster and filters
On Mon, Jun 16, 2008 at 8:41 AM, Kai-Uwe Behrmann [EMAIL PROTECTED] wrote: Validation of variables is very useful to find out a matching filter. As the image description (OpenRaster) and the filter are different things, I'd say this makes sense. I am assuming here concurrenting filter sets, which can easily occure. The core of OpenRaster could specify a set of core filters. If this is easier to validate in attributes syntax, why not? If for extensions, compared to the OpenRaster core, the elements approach seems more easy, so take this? We'd probably have a core set of filters that are part of the standard, GEGL would have it's own set of filters in it's own name space, so would GIMP (by adding additional plug-ins). In the same manner krita would be extending it with it's own filters. The user himself might download plug-ins for any of the above mentioned packages that install yet more filters and composers that can be used when describing OpenRaster documents; this is where I think automatic validation based on XML schemas loaded from plug-ins etc fail; since an OpenRaster file might very well be using plug-ins that are not available in the host loading the document. Making this load fail gracefully (or fall back to stored caches in the composition) is what I see as problematic. After all it might appear like a feature, to check for strict or lazy following the OpenRaster specification. There already has been discussions about various levels of confrmance or strictness. This is more about which core functionality is used, the representation of the buffers (additional files stored along the .xml) etc. It is for instance very likely that GEGL will not use OpenRaster files with .png's .jpg's or .exr's when saving natively but use some of the same technologies using it's internal GeglBuffer on-disk representation. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ CREATE mailing list CREATE@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/create
Re: [CREATE] OpenRaster and filters
On Thu, Jun 12, 2008 at 11:32 PM, Liam R E Quin [EMAIL PROTECTED] wrote: On Wed, 2008-06-11 at 21:20 +0200, Cyrille Berger wrote: [...] 1) filter name=standard:blur type=standard:gaussianblur params param name=radius10/param /params /filter 2) filter:standard:blur radius=10 / 3) filter:standard:blur radius10/radius /filter:standard:blur The main weakness of 1) is that this doesn't allow DTD/RelaxNG checking and validation, but it makes easier to extend since you don't have to write the schema for your filter Yes, although with W3C XML Schema 1.1 you'd be able to do some checking here, it would not be in a very modular way, I think. How are we supposed to deal with third party filters that are not installed when parsing/validating? Personally I would prefer if the specification itself was a fixed rather rigid structure that allowed for expansion within that structure instead of expanding the tag/attribute vocabulary available. A compromise between (2) and (3) is to allow both attributes and elements, blur radius=10 / being the same as blurradius10/radius/blur This is more complex to implement, and if the complexity isn't worth while, I'd go for elements, i.e. (1) or (3). GEGL currently supports boths, though the parser used currently isn't validating. The main reason for supporting the following syntax: filter type='standard:gaussian-blur' std-dev-x='4.5' std-dev-y='2.5' / as well as: filter type='standard:gaussian-blur' params param name=std-dev-x4.5/param param name=std-dev-y2.5/param /params /filter is that it scales further to animation based formats like used in http://pippin.gimp.org/oxide/ which is one of my earlier but larger in scope XML based formats like this. filter type=''gegl:opacity' params param name='level' value time='0.0'1.0/value value time='125.0'1.0/value value time='250.0'0.0/value /param /params /filter You then have to ask what sort of validation you want; both can have validation applied at some level. Supplying a schema of some sort that says that a particular set of parameters are needed might be useful, although in general it can get arbitrarily complex... I do not see the added value this provides, for unknown uninstalled third party filters validation will not succeed, but it should still be possible to parse most of the structure and use it. In general I'm in favour of 1), in GEGLs parsing code we permit a variation of 2) that uses non-namespaced attributes directly inside the filter tag, this mostly because it is a human writable short hand, the serialization code avoids it though. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ CREATE mailing list CREATE@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/create
Re: [CREATE] presentations, photos :)
On 5/8/07, Alexandre Prokoudine [EMAIL PROTECTED] wrote: As another reminder, please consider uploading your presentation files for downloading and post links here so that we have as much information as possible. I did exactly (apart from s/FOSDEM/LGM/) the same presentation as at FOSDEM this year, but I am uncertain what is the best way to make this presentation available. http://codecave.org/?weblog_id=fosdem2007 contains links to both a tarball with the things needed to perform the presentation as well as a quite large PNG image containing the presentation. FOSDEM chose to convert the PNG to a PDF which they put on their site. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ CREATE mailing list CREATE@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/create
Re: [CREATE] OpenRaster, some open points
On 3/13/07, Cyrille Berger [EMAIL PROTECTED] wrote: . mask handling, currently, while it's not clearly stated in the draft, masks are stored as children nodes of the layer on which they are applied. But a second proposition has been made: masks could be handled as a filter layer, The main drawback is that the XML looks heavier this way, but the implementation should be easier, as you won't need to add a special way to handle masks as they would be correctly handle by the allready existing filter mechanism. . it needs to be bullet proof, I would like to know if there is any points that need clarification ? Handling layer masks as a special filter effect was the way I originally proposed, and I am glad it is moving back in that direction. I hope to have the available time to do some OpenRaster hacking in ruby on top of GEGL before LGM, for the immediate future I have limited amounts of available hacking time though. - supported color spaces in baseline, RGBA (integer and float for HDR) 8/16bits, GRAYA (integer) 8/16bits, CMYKA (integer) 8/16bits are must have. But Krita and gegl supports (or will supports) a much broader variety of color spaces (LABA, XYZA, YCbCrA...), the question is : is there an interest to consider some of those as important for interoperability, and therefor, needed to be included in baseline ? - data storage specification . png for RGBA integer 8/16bits and GRAYA integer 8/16bits . exr for RGBA float 16/32bits I think it makes sense to limit the baseline to RGB(A) and GRAY(A), with 8bit/16bit precision, thus making PNG an adequate format. OpenRaster is meant to be used primarily for work that is raster graphics, our primary source of raster images are digital cameras and digital cameras produce RGB images. The sensors of the human eye are (linear) RGB. CMYK only makes real sense as an output format tied to a specific output device (with a profile) not as an input image to do compositing on. When mixing layers that are RGB and CMYK an application will most probably have to convert the CMYK data to RGB to do the compositing anyways. Some have expressed concern that having a specific data storage specification will make it complicated for a great variety of projects to write a complete implementation. On the other hand, at least CMYK 8/16bit is a must have, and none of the above fileformat supports it. And I also thinks that the above formats (or any other) are not unnecessarily the most efficient file formats for daily usuage in either the Gimp or Krita, and having either of them use a (even slightly) different fileformat will defeat one of the strongest interest of OpenRaster. EXR allows storing an arbitrary amount of named components per pixel, storing CMYK, HSV, CIE Lab or other arbitrary representations are possible there. When it comes to the issue of daily use I do not think it is reasonable to expect a power user to be saving an exchange-ready OpenRaster document when he is working on a project; it is more likely that he would be exporting to exchange-compliant OpenRaster when moving data between applications. I foresee for instance that a GEGL using application might be using it's own internal swap format for the buffers when working on the image for fast save/load times. When archiving the project those buffers would be serialized as EXR/PNG as appropriate. - vector layer, tinySVG (see http://www.w3.org/TR/SVGMobile12/) seems to be enough for the need of OpenRaster Replying to a reply to this mail, I think the same issue applies here, CMYK should not be the responsibility of OpenRaster, and neither should final vector output be, if in a layout in scribus the user wants to combine CMYK/spot color based vector graphics over an image that vector graphics should originate in scribus and not the OpenRaster document, for all purposes a color managed RGB output _raster_ from an OpenRaster rendering engine would be appropriate to turn into CMYK. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ CREATE mailing list CREATE@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/create
Re: [CREATE] OpenRaster core XML pondering (Re: OpenRaster page)
* Jon Phillips [EMAIL PROTECTED] [060821 10:22]: ... This all looks pretty interesting...where else is this spec'd out? Krita-devs, what are you guys thinking? Pippin, it would be great to get some more core gimp developers on here to discuss this as well... This isn't spec'ed further out, except perhaps a few more examples done with pen in a notebook. and thus is not implemented yet. But it can be seen as an evolution of oxide[1], xcf2[2] or the current XML processing tree format in GEGL CVS [3]. What does OpenDocument use for the root element? I wonder how we can best integrate with ODF? This is only the core XML representation of a tree of layers. Further specing would also entail things like deciding if groups of layers even should be allowed in a baseline, what set of operations needs to be available etc. For now I might even just continue using gegl as the root level element. /Øyvind K. 1: http://pippin.gimp.org/oxide/ 2: http://pippin.gimp.org/xcf2/ 3: http://pippin.gimp.org/gegl/ -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ CREATE mailing list CREATE@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/create
[CREATE] OpenRaster core XML pondering (Re: OpenRaster page)
On 8/10/06, Øyvind Kolås [EMAIL PROTECTED] wrote: On 8/10/06, Alexandre Prokoudine [EMAIL PROTECTED] wrote: On 8/10/06, Jon Phillips wrote: I'd like to elaborate on e). We can't design a flawless new file format just theoretically, because as soon as we start implementing support for it, we shall struggle with all kinds of issues. And we clearly don't want revisions of specifications submitted to OASIS, don't we? .. GEGL doesn't need integration into GIMP to be used as a testbed, in I am already using it as a testbed to develop my ideas for how to implement a layer tree structure. .. I've sketched an XML model which I'll try to implement a renderer for next week. The code sample is a jpg with an svg layer with a proceduraly generated drop-shadow as a group layer. We can use clones (instead of referencing gegl.svg twice), then all directed acyclic graphs using just sources, filters, and composer nodes can be expressed (thus making the graph equivalent of multiple output or 2 inputs the only capability not supported. image layers layer x='128' y='128' layer x='15' y='15' composite-op='under' opacity='0.6' filter class='gaussian-blur' radius='20'/ filter class='set-luminance' value='0.0'/ layer src='gegl.svg'/ /layer layer src='gegl.svg'/ /layer layer src='carstack.jpg'/ /layers /image Any comments or suggestions? /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ CREATE mailing list CREATE@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/create
Re: [CREATE] OpenRaster
On 8/8/06, Jon Phillips [EMAIL PROTECTED] wrote: On Mon, 2006-08-07 at 20:47 +0400, Alexandre Prokoudine wrote: I read today more on blending options in PS (http://www.samspublishing.com/articles/printerfriendly.asp?p=26131rl=1) and I wonder If we want something similar in OpenRaster. I think this sounds like a natural thing to include in this format for operating on images. I'm sure as well we will find a great way to unearth even more blending modes, etc. In my current experiments in GEGL (which has serialization/parsing of XCF2 like XML now), I have not set any restriction on what filters/composers (compositing modes) can be used. I probably already use more such modes than photoshop support. The bigger question is which compositing modes should be in a baseline specification for OpenRaster, the classic over operator is the only one that is 100% mandatory. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ CREATE mailing list CREATE@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/create
