Re: [Gimp-user] ERROR: configuration_data.set10 got unknown keyword arguments "Description"
On Tue, May 3, 2022 at 2:20 AM Pei JIA via gimp-user-list wrote: > > Thank you very much... I made some progress, but there are still some *test > errors*: > > FAIL0.18s (exit status 255 or signal 127 > SIGinvalid)>>> MALLOC_PERTURB_=13 > BABL_PATH=..babl-0.1.92/builddir/extensions These parts of your error log indicate that there might be memory corruption/unititialized memory use problems. However, all the tests pass on my machines, also when run under valgrind which should report on the same type of issues as MALLOC_PERTURB_ does. /pippin ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] ERROR: configuration_data.set10 got unknown keyword arguments "Description"
This is a problem arising due to newer versions of meson failing on what earlier versions of meson considered OK. It is in babl master by this commit https://gitlab.gnome.org/GNOME/babl/-/commit/b05b2826365a7dbc6ca1bf0977b848055cd0cbb6 if you are building GIMP yourself it is likely best to build all of babl, GEGL and GIMP from the respective git tips. /pippin On Sat, Apr 30, 2022 at 5:42 AM Pei JIA via gimp-user-list wrote: > > Hi, all: > > I'm trying to build babl-0.1.92, under environment: > > > > > > > > > > > > *➜ ~ lsb_release -aNo LSB modules are available.Distributor ID: > UbuntuDescription: Ubuntu 22.04 LTSRelease: 22.04Codename: jammy➜ ~ gcc > --versiongcc (Ubuntu 11.2.0-19ubuntu1) 11.2.0Copyright (C) 2021 Free > Software Foundation, Inc.This is free software; see the source for copying > conditions. There is NOwarranty; not even for MERCHANTABILITY or FITNESS > FOR A PARTICULAR PURPOSE.* > > but failed with the ERROR mentioned in the title: > > *meson.build:58:5: ERROR: configuration_data.set10 got unknown keyword > arguments "Description"* > Can anybody give me a hand? Thank you > > > > > > > > > > > > > > > > > *➜ babl-0.1.92 meson --prefix /usr --buildtype=plain builddirThe Meson > build systemVersion: 0.62.1Source dir: ../babl-0.1.92Build dir: > ../babl-0.1.92/builddirBuild type: native buildProject name: > bablProject version: 0.1.92C compiler for the host machine: cc (gcc 11.2.0 > "cc (Ubuntu 11.2.0-19ubuntu1) 11.2.0")C linker for the host machine: cc > ld.bfd 2.38Host machine cpu family: x86_64Host machine cpu: x86_64Program > python3 found: YES (/usr/bin/python3)meson.build:58:5: ERROR: > configuration_data.set10 got unknown keyword arguments "Description"* > > > > Cheers > > -- > > Pei JIA, Ph.D. > > Email: jp4w...@gmail.com > cell in Canada:+1 778-863-5816 > cell in China: +86 186-8244-3503 > > Welcome to Vision Open > http://www.visionopen.com > ___ > gimp-user-list mailing list > List address:gimp-user-list@gnome.org > List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list > List archives: https://mail.gnome.org/archives/gimp-user-list ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] Image Compression
On Wed, Dec 2, 2020 at 4:59 PM Jason Amerson via gimp-user-list wrote: > I scanned in a magazine as JPEGs, 300 dpi and high compression, but > still each file is over a megabyte. When I create a PDF using these > files, it is over 250 MB. I was wondering if you could tell me how to > compress these files in GIMP so that the resulting PDF will be of > normal size. Your problem might be your PDF creation tool (unstated), rather than your input images. If the images are black and white (or grayscale) using TIFFs instead of JPEG might help - but PDF is also capable of embedding JPG images directly inside which your workflow has not done (unless you have roughly 250 pages...). /pippin ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] Orientations, Copyright Notices, metadata, and resized layers
On Wed, Sep 30, 2020 at 7:04 PM Ruben Safir wrote: > Hello > > I've been using the GIMP for decades at this point. It has been bothing > me that of late (and I am old so late can mean years :) ) that I rotate > the image 90% and it doesn't prent in the correct orientation on my > websites. This is getting to be a real PIA. With JPGs, you can't just > remove the EXIF data without reprocessing the entire image. I have > resorted to trying to edit the files in VIM and removing the EXIF data. > > But that has lead me another issue, and this is ration serious. It is > easier to so than tell: > > identify -verbose bike.jpg > Image: > Filename: bike.jpg > Format: JPEG (Joint Photographic Experts Group JFIF format) .. > Profiles: > Profile-exif: 19590 bytes > Profile-icc: 672 bytes > Profile-xmp: 3712 bytes > Properties: .. > exif:Model: Canon EOS REBEL T3 > exif:PhotographicSensitivity: 125 > exif:PixelXDimension: 4272 > exif:Software: GIMP 2.10.20 > icc:copyright: Public Domain > icc:description: GIMP built-in sRGB > icc:manufacturer: GIMP > icc:model: sRGB > > Is the GIMP declaring my images and Public Domain copyright? That would > be not cool. You seem to be spooked by identify's line reported as "icc:copyright: Public Domain", this is the copyright on the 672byte ICC profile embedded as part of the exif data (as indicated by the icc: prefix for the key). /pippin ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] Equations/Details of the Color Transformations
For most of these filters you find the code and innerloop; which ends up containing the most important bits of the formula in the sources for the GEGL operations, like gegl/operations/common/exposure.c and also in the folder gegl/operations/common-gpl3+ . However beware that the innerloop does not tell the whole story; as operations also constrain the type of pixel encodings they accept. For instance gegl:exposure ensures that the component values are linear, the math would be wrong if applied to 8bit sRGB data or floating point sRGB data. /pippin On Thu, Apr 16, 2020 at 9:34 PM Simone80 wrote: > > Hi All, > > I am interested in the color transformations of the tools like > brightness-contrast, hue-chroma, hue-saturation, saturation, exposure, color > balance, color temperature, ... > > Do you know where I can find the details of these tools, in particular the > mathematical equations behind them? > > Thank you in advance for your help. > > Simone > > -- > Simone80 (via www.gimpusers.com/forums) > ___ > gimp-user-list mailing list > List address:gimp-user-list@gnome.org > List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list > List archives: https://mail.gnome.org/archives/gimp-user-list ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] Converting from indexed to RGB modes; brush color off
On Sun, Dec 22, 2019 at 11:42 PM Gary Aitken wrote: > I don't know if this is intentional or not; I would have thought that if > the original color index map is not full, using a new color would add it > to the map, but apparently not. What you are suggesting; to add the directly chosen color of the paintbrush/pencil tool, if there is empty slots in the palette would not conflict with this and be a nice addition - filing an issue against GIMP in gitlab.gnome.org to keep it from being forgotten might be a good idea. It would have to be only the directly selected foreground color though and not its antialiased results with various background pixels which would be ohter colors implicity attempted to be inserted. Since the more complete port to babl/GEGL with 2.10 GIMP is no longer special casing INDEXED/GRAYSCALE mode from RGB. This meant as new features we gained anti-aliasing for the paintbrush in indexed mode, ability to blur and do other filters; as well as anti-aliased results when merging down layers/text-layers - this would quickly exhaust the free slots in the palette if all attempted to be used colors were added (checking if the current foreground color is part of the palette before starting a new stroke is also a more feasible code change than always dynamically growin the palette). /pippin ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] Disable check for new plugins at startup
On Wed, Dec 11, 2019 at 3:00 PM Bantha wrote: > we want to run GIMP in an isolated environment, without access to external > systems. So, when GIMP checks for newer versions of the installed modules and > plugins, it takes several minutes to wait for the timeout- > > Can I Speed up the startup in any way? GIMP won't be able to check anything > outside of our company LAN. GIMP is not going online looking for new versions of plug-ins, it is scanning the file system(s) for previously unknown plug-ins, in user and system paths. One reason this might be slow is if GIMP is installed on a slow network file system. ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] Unsupported color mode CMYK
On Fri, Nov 8, 2019 at 9:53 AM rich404 wrote: > It works very well, especially since the current Gimp roadmap relegates CMYK > support to a version Gimp 3.2 However to be fair > > quote > > Should a new developer join the team to specifically work on CMYK-related > features, we will do our best to help him/her to complete this project and get > it to our users as soon as possible. > > unquote > > Not holding my breath. For some interpretations of this dengerous oxygen deprivation, you can stop now. Support has been added to both babl and GEGL to handle CMYK images - which can be be used and tested on the commandline - and used in the experimental alternative GUIs for GEGL that are in git. If someone hooks this code up to GIMP I will be diverting some more of my already thinly stretched attention back to the CMYK code in babl and GEGL to make it fast as well. :) /pippin - https://pippin.gimp.org/ ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] Gimp macro recorder?
On Fri, Mar 29, 2019 at 7:21 PM Zbigniew via gimp-user-list wrote: > > Are there any plans to equip Gimp with macro recorder? I mean kind of tool > present, for example, in LightRoom, where every change applied to picture is > listed on the screen - and one can then copy a whole "procedure" with simple > - then apply that series of commands by - onto any > other picture, not being forced to start whole procedure all over again. > > And such recorded list of procedures/commands - and I mean literally every > procedure listed in GIMP's menus, be it internal command or installed script > - it should be possible to save it into ordinary text file, and then to use > it as a parameter in case of batch processing, I mean something like this > (parameters fictional, just example how do I see this): > > gimp -procedure recorded-commands.txt --no-gui *.jpg --output new/*.jpg > > Something like this should apply recorded actions - one after another - to > each *.jpg file found in current directory. I mean batch processing using > GIMP in ImageMagick's way. Correcting only one picture - while recording > actions during the process - then applying sequence of actions to whole set > of next pictures, using GIMP as command-line tool. > > GIMP has long history - but if I'm correct it still doesn't have such > ability until this day. Yes, I found some tools like BIMP, I found the tips > "learn Script-Fu language" - but actually why until now such obvious thing > requires learning special programming language? GIMP "knows" what have I > done while processing picture, so it should be able to list my actions like > this: > > sharpen 75% > automatic-white-balance > resize 10% down > some-script-action (applied) > wavelet-denoise <...parameters...> > draw-a-line using brush, color etc. GEGL - http://gegl.org/ was started to revamp GIMP with a new engine that can handle floating point raster images, as well as enable things like non-destructive editing, which is what you are describing. Non-destructive editing is the next thing on GIMPs roadmap, now after porting core to rely on GEGL apis, and the current cycle of porting from GTK2 to GTK3 is done. Non-destructive editing seem similar to scripting and macro recording and the existing GIMP framework for exposing actions for scripting languages. But actual non-destructive image editing belongs in the layer stack together with layer mode operations. The work on porting the functionality of gimp-2.6/2.8 to GEGL is quite complete with 2.10, but the only real feature GIMP has gained/exposed is working at higher bit-depth. There is another wrong direction some people are taking when considering action recorders for GIMP, the undo stack - but due to how it works in GIMP that is also not a fruit-ful way to do it. You can already use filters that have been ported to be GEGL operations from the commandline - see http://gegl.org/gegl-chain.html for examples on doing this the format uses to describe processing chains on the commandline is compatible with prototype user interfaces for testing GEGL features that are not yet complete or tested enough that GIMP developers want to start adopting them, like non-destructive editing, CMYK support and various other methods for more performant preview rendering, see https://www.patreon.com/posts/24123574 for details on this work as well as how you can support efforts to improve this. Since non-destructive editing is coming up on the GIMP roadmap, a planning session for further plans have been submitted for this years libre graphics meeting, https://libregraphicsmeeting.org/2019/schedule-fri-31-05/ . /Øyvind -pippin- Kolås - GEGL maintainer ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] display portion of 360 image
On Mon, Nov 5, 2018 at 7:04 PM bmike1 wrote: > > I got a 360 image but I want to display a portion of it as a standard image. > Is > there a way to do that with GIMP? Use GEGLs panorama-projection operation, which you can find under /Filters/Map/Panorama Projection. You can also do this - followed by its inverse on a duplicate of the panorama for doing touch ups of ground/sky or other parts of the panoarama. /pippin ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] Convert to profile error (babl and CLUTs)?
On Tue, Oct 16, 2018 at 3:10 PM Maciej wrote: > I'm using gimp 2.10 from flatpak on Ubuntu 16.04 > > When converting image to profile (for Canon Selphy CP1200) before print I got > error on the console: > > gimp_color_transform_new: error making format: CanSelphy_Can-Glossy-S01_1.icc: > profile contains perceptual luts and perceptual was explicitly asked for, babl > does not yet support CLUTs > > The ICC was made on Apple computer using X-Rite software. > > Does it mean that I cannot convert image and print it correctly using just > GIMP > for this particular profile? I use jpgicc and darktable for prints but > sometimes > Gimp is just the proper tool. The warning on the console is a report that GIMP asked babl to parse and interpret the profile; and babl is telling GIMP back that it cannot. As a result of babl returning nothing to GIMP, GIMP will instead use the slower but more complete lcms2 for conversions involving this ICC profile. ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] Mac OS
On Mon, May 7, 2018 at 8:41 AM, François Jouve wrote: > Le 03/05/2018 à 18:19, François Jouve a écrit : >> almost one week that gimp 2.10 is out and still no Mac OS package on >> gimp.org. Is there any problem ? >> Third party users are already distributing a mac version, so it seems >> doable (but I prefer using the official version). >> >> Any information on the release of the official MacOS version would be >> useful to many of us I think. > > Well, I guess there is no Mac users around there... > And no admin with any opinion or information about that ? > > The download page says "Please check back later" and that's what I do, but I > would have prefered something like "Please come back on 2018/MM/DD" and it > will be there. Or even "Please come back on 2019/MM/DD" if it is so > difficult to build :) There is few, windows users/developers as well as mac users/developers of GIMP. Most actual development and testing of GIMP by developers happens on Linux and this is the platform with the least amount of surprises, traditionally the GIMP project only used to release source code tarballs and it was up to operators of the software, or their own platform/distributions packagers to provide binary builds. A couple of volunteers with limited time; but expertise in building and debugging GTK and related applications on windows and macos are now providing binaries - when they find time. There is no company, corporation or management behind GIMP - and official binaries will appear when volunteers with diminishing spare time find the time to build, test and provide them - possible even 2.10.2 with a few extra fixes rather than straight up 2.10.0 now that it has been more than a week. With kind regards, pippin maintainer of GEGL ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] Image doesn't move smoothly
On Sat, Apr 21, 2018 at 8:52 PM, Steve Kinney wrote: >> Some caveats I noticed: >> >> - The size of the image canvas, layer in question, and current zoom level >> seem to have no impact on redraw times; only the actual size of the image >> window whose area is being redrawn. >> >> - Visual artifacts are most noticeable when moving the object upwards. >> >> - Using the Pan function (Spacebar) always results in smooth movement as it >> is not actually making changes to the image, just scrolling its position >> within the image window. >> >> >> I do notice that during the move operation all visual redraws originate from >> the upper-left of the moved object. Not necessarily a bad choice, but could >> the redraw perhaps originate from the cursor's current location within the >> image window, redrawing outwards? After all, when you're clicking and >> dragging something, the area around the cursor is generally what your vision >> is focused on Updating the display as quick as possible after receiving motion events, rather than rendering everything and updating at a low frame-rate, is a known feature - not a bug. Until things are fast enough to do 15fps of the entire viewport - for instance with GIMP integrating with and using the mipmap based preview-rendering infrastructure in GEGL, always waiting until we have a full "frame" to present will significantly increase latency leading to a worse user experience than presenting as much rendered content as soon as possible. /pippin ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] GIMP 2.10-RC1 Previews Loading Slowly
On Tue, Apr 17, 2018 at 5:47 PM, jkhan wrote: > So I'm working with scans of my film images and those TIF files are importing > as > 16 bit. Is there a way to change it to 32? In GIMP ones uses the menu under Image/Precision for changing the encoding used for storage of layer data. /pippin ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] GIMP 2.10-RC1 Previews Loading Slowly
On Sat, Apr 14, 2018 at 5:44 AM, Robert Bieber wrote: > I've had some similar issues working with large images, here's some things > I've found. First of all, if your image is in 16-bit precision, your > operations are going to be slow. GEGL is apparently optimized for 8-bit int > and 32-bit float, so paradoxically you'll actually get a much smoother > experience if you change the image precision to 32 bit floating point. > Trying to, That's gotten the new GIMP to be pretty usable for me. It's > still not as zippy as the 2.8 series was, but it's also crunching a lot more > data over 8-bit images. A perhaps more accurate description is that most operations are now performed on linear 32 bit floating point data, regardless of which precision pixels are stored with. Fast path conversions from storage formats of 8bpc and 32bit float have been around in babl for many years, but for most permutation of gray/rgb/alpha in 16bit precision, both float and integer no such short cuts existed and babl would roundtrip the data to 64bit floats. As of babl-0.1.46 released earlier this week most gaps for these pixel-formats have been filled with fast paths. There is still room for making the 16bit code paths faster with SIMD but GIMP-2.10rc2 should already be much better than 2.10rc1, for further details see also https://www.patreon.com/posts/babl-fast-path-18052156 /pippin - ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] Contribute with GEGL
On Mon, Jan 15, 2018 at 5:51 PM, felipeek2 wrote: > I would like to know how to contribute a new filter (operation) to GEGL. Do we > need to send a pull request? If someone could clarify what is the correct > procedure to do that, I'd be very grateful. Please open an issue in the gnome bugzilla for GEGL, and attach the git commits as a patch formatted with git commit messages included, the way this is done might change in the near future as GNOME which does the source code hosting for GIMP and GEGL migrate projects to use gitlab. /pippin - http://pippin.gimp.org/ ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] Shadows/Highlights
>> >On 01/02/2018 01:58 PM, Julie Bennett wrote: >> >>I'm relatively new to GIMP and Ubuntu. I am moving away from using >> >>photoshop/windows. I'm a life long photographer and have developed a work >> >>flow in photoshop. >> >>With learning the structure of GIMP, I'm of course wanting to recreate my >> >>work flow. >> >> >> >>The one feature of photoshop I have come to rely on heavily is the >> >>Shadows/Highlights function. It is extremely important to me. >> >>With it I can adjust and preserve the detail in shadow and highlight areas >> >>of an image to approximate what I actually saw. >> >>But, I can't seem to find something similar in Gimp. Can someone point me >> >>to the area of Gimp that may provide this? >> > >> >The Shadow Recovery script-fu plugin may be helpful: For GIMP operators running the very latest version of babl/GEGL/GIMP built from sources in git, there is also an operation available from under Tool/Gegl Operation menu called shadow-highlights, implemented for GNOME Photos based on the shadow-highlights in Darktable which itself was inspired by script-fu scripts. This will give live on-canvas previews as parameters are tuned. -- /pippin - http://pippin.gimp.org ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] Creating a new operation for GEGL
On Wed, Dec 27, 2017 at 6:04 AM, felipeek2 wrote: > Thank you very much for your help! The filter is working now. > > Is it possible to manually create/manage threads inside a GEGL operation? This > would improve our filter a bit. When opting out of threading, like outlined in prior response, you are free to manage threads; ideally using the multi- threading APIs of glib which are platform independent. The GeglBuffer API itself is written to be thread safe. /pippin - http://pippin.gimp.org/ ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] ANNOUNCE: GIMP 2.9.8 released
On Wed, Dec 13, 2017 at 7:18 AM, Tom Williams wrote: >> - OpenCL is now disabled by default. Depending on graphics cards and >> drivers, OpenCL acceleration is often slower than multi-threaded >> implementation, and can also sometimes be "glitchy". > I do have a question about OpenCL support. If it's disabled by default, > how does one enable it? There is a check-box in preferences under the 'System Resources' category, where the number of threads used can also be overriden. /pippin - https://pippin.gimp.org/ ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] Creating a new operation for GEGL
On Tue, Dec 5, 2017 at 4:50 PM, felipeek2 wrote: > Well, it turns out that we've decided to try to implement the filter in GEGL, > so > it would become easy to use with tools like GIMP, for example. Since GEGL is > open source, I've been trying to understand the code that is used to generate > new operations and understand how could I carry the filter to the platform. > > I've made some tests, and I figured out that the standard behavior of GEGL is > to > split the image in several tiles, which are usually rectangles, and process > all > these 'tiles' independently, even using different threads. With some > inspection > of the existing GEGL code is easy to, for example, make each thread processes > its own tile and return the result. However, for the specific filter I'm > implementing, this is not enough, since it is a recursive filter. > > The implementation I am using of the Domain Transform filter is a recursive > one, > in which each pixel will always depend on the value of the previous pixel, > already processed. That said, I could only process a tile if the previous tile > was already processed, which is a problem. Moreover, to generate good results, > the filter must be applied several consecutive times, and each time it must be > performed top->down, bottom-up, left-right and right-left, again > consecutively. > Since GEGL automatically divides the image into tiles and feed them to the > operation, I'm not sure how is the proper way to force the filter to be > executed > in several steps. > > With all these restrictions, I'm having some difficult to find out how can I > achieve that inside GEGL. I would be very grateful if someone could give me > some > hints or even show me a code where a recursive filter is implemented as a GEGL > operation. I didn't originally see your email, since it went to the gimp-user mailing-list rathern than to gimp-developer or gegl-developer. For an example of an operation that needs the full input to be available to be able to do processing, have a look at gegl:stretch-contrast https://git.gnome.org/browse/gegl/tree/operations/common/stretch-contrast.c Worth noting, in particular, is that it sets operation_class->threaded to FALSE to opt-out of base classs automated thread parallelization, and that it sets the methods get_required_for_output and get_cached_region to specify which areas (all) need to be computed for input buffers, and what extra data to compute when computing one sub-rectangle, (also all). /pippin - http://pippin.gimp.org/ ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] CMYK color editing
Sean Greenhlgh wrote: > I work in the print world. And wanted to know if you guys are planning > on adding CMYK color modes to the software. Open source and free > software is the future, and it would be really cool to get this going > and off the ground. If some designers started using it, we could get, > many, many users, using it. For printing of photos edited in GIMP we recommend adopting a color management workflow with late binding to CMYK by adopting PDF/X[1] worflows [2]. GIMP is already used successfully by many users with such workflows. For cases where late binding workflows are not possible the GIMP 2.10 series will hopefully gain both support for and good control over CMYK separation when exporting for instance to TIFF; integrating functionality that currently is possible with additional third party GIMP plug-ins. There might be future improvements to how GIMP deals non-RGB data in the 3.x series or beyond, probably including direct support for opening/importing CMYK files without a conversion to RGB - adding such capabilities should be more easily possible now that image processing is abstracted away and encapsulated in GEGL ops. When it comes to more radical departures from RGB, I've personally worked on, and have plans for continued work on code experiments with color that eventually might lead to CMYK being just one of possible sets of plate configuration for process inks / spot-colors / paints used for any simulated duo, tri, quad(or more)-tone print plate configuration for various colored substrates - using spectral characterisation along the lines of [3]. 1: https://en.wikipedia.org/wiki/PDF/X 2: https://www.scribus.net/svn/Scribus/trunk/Scribus/doc/en/pdfx3.html 3: http://www.color.org/CxF_test.xalter With regards, Øyvind Kolås -- http://pippin.gimp.org/ https://patreon.com/pippin ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] color managing slows gimp down?
On Fri, Mar 3, 2017 at 5:13 AM, Casey Connor wrote: > I notice that when I use a color managed display, the zooming in and out of > an image is very slow (maybe 500ms per increment). If I disable color > management, zooming is instantaneous. > > Is this normal/expected? > > Gimp 2.9.5, commit 86e101e322, Kubuntu 16.10. It is normal/known that passing the pixels for display through lcms2 for color management is slower than not doing it. How much slower probably also depend on the type of ICC profile used, if you are using a LUT based profile you could try making a matrix based profile for your display instead. (even if it turns out not to be faster now; it probably will be faster at some point in the future). /pippin - GEGL lead developer and maintainer - https://patreon.com/pippin ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
[Gimp-user] ANNOUNCE: GEGL-0.3.14 released
GEGL provides a node/graph based API and framework for cached, interactive non-destructive image processing. GEGLs data flow image processing graphs are used by GIMP and other software like gnome-photos, imgflo and iconographer. This release shortly after the previous one is to let gnome-photos depend on the gdkpixbuf fixes in it for its next release. Summary of changes: · changed gegl_buffer_set to accept mipmap level scaled rectangles, similar to gegl_buffer_get and gegl_buffer_iterator_new/_add Operations: · save-pixbuf: allocate less temporary memory · load-pixbuf: fix rowstride related crasher · ops made mipmap preview rendering capable: gblur-1d/gaussian blur, sinus, transform (rotate, scale, perspective etc), snn-mean · noise-perlin: remove unused random seed property · exposure: remove gamma property To build gegl-0.3.14 you will also need babl-0.1.24 This release of GEGL was brought to you through contributions from: Alexandre Prokoudine, Debarshi Ray, Dimitris Spingos (Δημήτρης Σπίγγος), Jordi Mas, Martin Srebotnjak and Øyvind Kolås Where to get GEGL: The latest versions of GEGL and babl can be fetched from: http://download.gimp.org/pub/gegl/0.3/gegl-0.3.14.tar.bz2 http://download.gimp.org/pub/babl/0.1/babl-0.1.24.tar.bz2 SHA256 sums of the released tarball: 09f5e2e6899697641d4660e3e274aed696f5bacc96ba389ac77674ee1156590a gegl-0.3.14.tar.bz2 More information about GEGL can be found at the GEGL website, http://gegl.org/ or by joining #gegl and #gimp on the GIMPnet IRC network. Happy hacking and image processing /Øyvind Kolås -– http://pippin.gimp.org/ http://patreon.com/pippin ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] GEGL - run C2g batch in command line
On Mon, Jan 23, 2017 at 10:55 AM, waldauf wrote: > Hello folks! > > Is there some way how to run Tools/GEGL/C2G convertion in command line like > batch? > > For example - I have 10 pictures which I want to convert with some params. > This > conversion takes a lot of time when you have to load picture into Gimp, set > C2G > params and convert. I would like to convert it trough night like batch > In recent GEGL releases there is an underdocumented commandline one-liner shorthand to avoid creating XML documents: For instance: gegl input.jpg -o output.png -- c2g radius=1300 samples=4 iterations=23 vignette will apply the c2g operation with the following paramteres, followed by the vignette filter with default parameters. To make this apply to multiple images one could for instance do: mkdir /tmp/out ; for a in *.jpg; do echo $a; gegl $a -o /tmp/out/$a.png -- gegl:c2g radius=1300 samples=4 iterations=90 ; done GEGL will complain if you specify properties not valid for a given operation and print the exisiting properties that can be assigned. If the gegl: prefix is avoided on an operation gegl tries with gegl: pre-pended. /pippin ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
[Gimp-user] GEGL-0.3.2
GEGL (Generic Graphics Library) is a graph based image processing framework. GEGL provides a graph based API and framework to do demand driven, cached, non destructive image editing of sparse storage of larger than RAM images - using CPU or GPU processing. Through babl it provides support for a wide, and extendable, range of color models and pixel storage formats for input and output. To build gegl-0.3.2 you will also need babl-0.1.14 and a recent version of glib, follow see the output of the configure script for details and optional dependencies. Changes in this release: • Operations: • new operations: libraw based raw loading op, tiff-save and tif-load, maze, sepia • ff-load and ff-save revived, with support from thegrid.io • apply-lens uses less memory, higher precision computation. • disable automatic threading on many ops where it fails • force more operations to prefer operating on linear RGB data for more accurate/physical processing. • Buffer: • implement abyss paremeter on gegl_buffer_copy and gegl_buffer_blit • Added start of a microraptor gui based image viewer/non destructive editor. • Optimizations to scaled blitting (speeds up most GEGL UIs a bit) This release brought to you through contribution from: Alexandre Prokoudine, André Tupinambá, Claude Paroz, Daniel Mustieles, Debarshi Ray, Dimitris Spingos, Elle Stone, Jehan, Jordi Mas, Marco Ciampa, Martin Blanchard, Martin Srebotnjak, Massimo Valentini, Michael Henning, Michael Natterer, Necdet Yücel, Pedro Albuquerque, Piotr Drąg, Roman Lebedev, Sven Neumann, Thomas Manni, Vilson Vieira, akash akya and Øyvind Kolås. Where to get GEGL: The latest versions of GEGL and it's hard dependencies babl and glib can be fetched from: http://download.gimp.org/pub/babl/0.1/babl-0.1.14.tar.bz2 http://download.gimp.org/pub/gegl/0.3/gegl-0.3.2.tar.bz2 SHA-1 sums of the released tarballs: 1e1e27a9a07da95e905d07816701b2efaf5611af babl-0.1.14.tar.bz2 c308b9994f9649bfbdf1bb63db6fbe0ba19632bd gegl-0.3.2.tar.bz2 Where to get more information about GEGL More information about GEGL can be found at the GEGL website, http://gegl.org/ or by joining #gegl and #gimp on the IRC network GIMPnet. Enjoy the goats /pippin ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] [Gimp-developer] What next after sourceforge.net?
On Fri, May 29, 2015 at 9:43 AM, Kevin Brubeck Unhammer wrote: > Is trademarking completely out of the question? I see not only Firefox, > but ImageMagick, Inkscape, GNOME, GNU and Linux in > https://en.wikipedia.org/wiki/List_of_trademarked_open-source_software – > Inkscape being of similar "size" to GIMP, does anyone know how much work > it cost them to register their trademark, and how much it costs them to > keep it? > > Reading through > https://www.softwarefreedom.org/resources/2008/foss-primer.html#x1-6k5 > it doesn't look too bad in terms of money. (The whole section on > trademarks there is worth reading.) > > Also, it seems you may in fact call it GIMP™ already, since you have > certain "unregistered rights" to the trademark just because GIMP has > been used by this project as a trademark in practice. (But "®" requires > registering.) > > If you have a trademark, but never object to anyone using it in > commercial/confusing settings, it might get lost. But you can avoid > having to explicitly say yes to every distro and similar "good usage" by > having a simple license like GNOME does: > https://wiki.gnome.org/action/show/FoundationBoard/Resources/LicensingGuidelines > See also https://www.gnome.org/logo-and-trademarks/ GIMP has existed for two decades in a decentralized ad-hoc manner without needing to incorporate as a legal person/entity in either the US or elsewhere. I hope it is possible for community based software projects to exist and to defend against bullying or misrepresentation without incorporating in various markets/territories. /pippin ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] [Gimp-developer] Time to fork BABL and GEGL
On Mon, Nov 17, 2014 at 11:56 PM, Simon Budig wrote: > If there were chromaticies for a given "userRGB" which are widely used > in a lot of real world applications, then it might make sense to support > them in a similiar way like we currently do for the sRGB primaries. Nah, we only need one unbounded PCS ;) – other linear RGB spaces, like linear adobeRGB, are a matrix transform away from linear bablRGB. There might however be some non-similar ways to optimize things, however many of those likely add decision overhead in scenarios like per scanline calls for partial tile conversions that cancel out the benefit over just doing a straight matrix transform. /pippin ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] Time to fork BABL and GEGL
On Sun, Nov 16, 2014 at 9:01 PM, Elle Stone wrote: > Do you understand that when I say that Multiply is a chromaticity-dependent > editing operation, I don't just mean the Multiply layer blend mode? that in > fact *all* editing operations that use multiplication or division are > chromaticity dependent, regardless of whether the colors are *in* gamut or > *out* of gamut with respect to the very small bounded sRGB color gamut? > > The exception to "all", of course, is when multiplying or dividing by black, > gray, or white. Yes I do understand that – The babl roadmap being incomplete/leaving room for interpretation is on purpose – what is stated there is the minimum roadmap bringing us towards a situation where such details makes sense to decide upon. Some operations we might change to not be chromaticity dependent in this way (for instance using CIE Lab or Lch) but for most of them the change will be using a babl-format specifiers like "target:RGBA" and "target:R'G'B'" instead of un-prefixed format specifiers like now, which in the future will be synonyms for "sRGB:RGBA" etc. > Somewhat switching gears, the revised babl roadmap > (https://git.gnome.org/browse/babl/tree/docs/roadmap.txt) says: The plan in roadmap hasn't really changed since mid-april[1], revisions to the file has been integrating various bits lost in the mailinglist threads. The last revisions was to add what has been stated before in gimp-developer about single-precision floating point and accumulated rounding errors – since the issue was brought up here. > "Once a format has been resolved using babl_format(babl, "bar:RGBA float") > the returned pointer would refer to the babl context that looked up "bar"'s > definition of bar. This . . . allows rigging up a situation where the user > has control over the RGB space used for chromaticity dependent operations." > > In light of the revised roadmap and the above list of chromaticity dependent > editing operations, I have two more questions. Again, I'm trying to > establish common ground for communication, or at least clarify where we > disagree. > > 1. Do you agree or disagree that for *all* chromaticity dependent editing > operations, the *user* should be in control of which RGB chromaticities are > used to perform the operation? That is the point of adding more, and named, RGB families to babl. Chromaticity dependent operations are the operations where we would use userRGB instead of bablRGB – effectively it being the way for the developer to say that for this operation the users chosen format should be used. using user:Y user:Y' user:R'G'B' and user:RGB would be different ways the op developer can request pixel formats based on this user choice; when the op developer knows it should (or should not) be linear of perceptual data. But also note that while in GIMPs use of babl/GEGL, there might only be one such user family of pixel formats controllable in one location of the UI, in the general flow based computing model of GEGL one might expect a single configured processing graph to have multiple userRGBs for photos coming from different sources. > 2. Do you agree or disagree that for chromaticity *in*depedent editing > operations (for example, and assuming linearized RGB: adding, scaling, > gaussian blur, etc), the same results (same XYZ values) are obtained whether > the operation is done in the user's chosen RGB working space or in unbounded > sRGB? I do; and if there wasn't any chromaticity dependent operations – a single "RGB family" like bablRGB would be sufficient – You convinced us to abandon that plan in april. If a GEGL graph contains multiple different userRGBs source buffers, chromaticity independent compositing operations compositing two buffers with different RGB chromaticities need to be converted to the same linear RGB. Initially this will be bablRGB; later – depending on profiling and time for doing it – we might end up making such compositing produce output in the same RGB family as the input buffer and convert the aux buffer to the same. 1: the only change in plans since then (and that changed occured before roadmap.txt was started), was abandoning the plan to do conversions between bablRGB and userRGBs in babl using LCMS2; and instead do those conversions directly ourselves in babl; a change without impact on how babl will be used by GEGL (and GIMP). /pippin ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] Time to fork BABL and GEGL
On Sat, Nov 15, 2014 at 8:01 PM, Elle Stone wrote: > This really is my last post on unbounded sRGB unless someone has a specific > question to ask. > > On 11/14/2014 11:47 AM, Øyvind Kolås wrote: >> >> I ask for an assumption of good faith, that the babl/GEGL developers >> know what they are doing and have incorporated your input from April >> on out how multiply and gamma produce undesirable results for values >> outside the 0.0-1.0 range working with unbounded sRGB. That we want to >> and will incorporate that in the color management model of GEGL. A >> model that differs from how traditional ICC based photo editors >> traditionally work, GEGL has both internal (babl) and external (ICC) >> color management; and you have correctly pointed out that the internal >> color management is lacking and needs to take more RGB spaces into >> account. > > I think it's important to clarify some of Pippin's misunderstandings that > are betrayed in the above quote: > > 1. Multiply and gamma slider adjustments are both highly chromaticity > dependent editing operations. What Kolås fails to acknowledge, and maybe > doesn't even understand, is that this is true regardless of whether the RGB > channel values are *in* or *out* of gamut with respect to the bounded sRGB > color space. The multiply compositing op; doesn't really have any sliders, and gamma adjustments are among the things that definetely would not end up using bablRGB; regardless of how far we get in specifying other working spaces. > 2. Given that multiply and gamma slider adjustments produce different > results in different RGB working spaces, only the *artist* has the right to > decide which results are better. Developers aren't in a position to make > this decision on behalf of users. > > 3. The fact that multiplying and making gamma slider adjustments on out of > gamut channel values produce absolutely *meaningless* results is just icing > on the badly baked cake that is unbounded sRGB. The artist's control over > her own RGB data is already removed as soon as her RGB data is converted to > unbounded sRGB without her consent. > > 4. The list of chromaticity dependent editing operations is much longer than > just multiply and gamma slider adjustments: > > * For editing performed on more or less perceptually uniform RGB data, > the list includes essentially *all* editing operations. > > * For editing performed on linear gamma RGB data, the list includes at > least the following operations (I haven't checked every single editing > operation made available through the GIMP UI): > > Channel data used as a blending layer > Channel data used for making selections > Colors/Alien Map HSL > Colors/Alien Map RGB > Colors/Auto stretch contrast > Colors/Auto stretch contrast HSV > Colors/Channel Mixer (try Margulis' "enhance green" formula) > Colors/Desaturate average > Colors/Desaturate lightness > Colors/Mono Mixer (except straight Luminosity-based B&W conversion) > Colors/Posterize > Colors/Threshold > Colors/Levels Gamma slider operations > Colors/Levels Red, Green, and Blue Input/Output sliders > Colors/Levels "Auto Pick" (used for white balancing images) > Filters/Artistic/Cartoon (this uses hard-coded Y values) > Filters/Edge Detect/Sobel > Filters/Enhance/Red Eye Removal > Filters/Noise/HSV Noise > Filters/Noise/RGB Noise > Filters/Artistic/Soft glow > Filters/Artistic/Vignette (any color except gray, white, black) > Layer blend Mode/Burn > Layer blend Mode/Color > Layer blend Mode/Darken only > Layer blend Mode/Difference > Layer blend Mode/Divide > Layer blend Mode/Dodge > Layer blend Mode/Hard light > Layer blend Mode/Hue > Layer blend Mode/Lighten only > Layer blend Mode/Multiply > Layer blend Mode/Overlay > Layer blend Mode/Screen > Layer blend Mode/Saturation > Layer blend Mode/Value > Paint tools depend on the working space chromaticities when using > the following blend Modes: Burn, Color, Darken only, Difference, Divide, > Dodge, Hard light, Hue, Lighten only, Multiply, Overlay, Saturation, Screen, > Soft light, Value. > > In other words, *most* editing operations are chromaticity dependent. This > means the *artist*, not the developer, is the only person who should choose > the RGB working space. > > 5. Putting aside color gamut limitations, the editing operations that are > chromat
Re: [Gimp-user] Time to fork BABL and GEGL
On Fri, Nov 14, 2014 at 4:24 PM, Elle Stone wrote: > My apologies, I don't understand what you are trying to say. Can you give > links to specific mailing list threads? Are you perhaps again saying that my > yellow flower image is a corner case and therefore it's OK to write an image > editor that makes it literally impossible for me to perform my envisioned > conversion to black and white? I was saying that one can construct a scene, that photographed with your camera, would yield the type of desired black and white - when done in sRGB or some other non sensor RGB space. So yes; for the purposes of black and white conversion and using a single channel for it - I still call that image a corner case. > * "backseat driver" > > * "half-knowledgeable filibusterer" (I'm only guessing that was directed at > me; perhaps I'm wrong) > > * suggesting on IRC that I'm "insulting GIMP" (which I have never done, GIMP > is my favorite RGB image editor) when really I'm questioning your > understanding of the requirements for proper RGB image editing > > * suggesting that because I agree that you are intelligent (obviously you > are), therefore I should stop trying to educate you about where your color > management theories took a wrong turn and are threatening to take GIMP with > them. You are quoting later venting of frustration with your later walls of text on the mailinglists questioning and demanding answers for every single little detail before details even exist. One of your quotes isn't even from IRC; and guess what, if you were on IRC I would have asked you questions there instead of venting frustration about your mailinglist posts. I ask for an assumption of good faith, that the babl/GEGL developers know what they are doing and have incorporated your input from April on out how multiply and gamma produce undesirable results for values outside the 0.0-1.0 range working with unbounded sRGB. That we want to and will incorporate that in the color management model of GEGL. A model that differs from how traditional ICC based photo editors traditionally work, GEGL has both internal (babl) and external (ICC) color management; and you have correctly pointed out that the internal color management is lacking and needs to take more RGB spaces into account. /pippin ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] Time to fork BABL and GEGL
On Fri, Nov 14, 2014 at 3:48 PM, Elle Stone >> but you >> refuse to spend time where the developers normally clear up >> misunderstandings, reach consensus and make plans; on IRC. > > As you well know, I did try discussing unbounded sRGB with you on IRC. On > IRC you felt free to issue personal insults. And you wasted time eliciting > general agreement from people who learned everything they know about "color > management" from you. If calling the examples you used for "corner cases", and that one can construct scenes favoring different RGB spaces for orthogonality between channels - not only the sensor space - a personal insult; I call it being direct. /pippin ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] Time to fork BABL and GEGL
On Fri, Nov 14, 2014 at 1:26 PM, Elle Stone > Really there is only one developer who's current stance on unbounded sRGB > seems a little unclear. Or there is one time-thief that continues to not understand what a PCS is in a color management system, what implementation details mean; which is allergic to implementation details involving anything relating to sRGB; that continues to argue over her own misunderstandings of the architecture. The writeup in the babl roadmap document is a summary of the ideas that have been around since LGM in Leipzig; which was in the beginning of April this year. You convinced us that we had to care about RGB spaces beyond sRGB; and we decided to incorporate that in the architecture with a concept of a "target-space"; this was in my eyes thus far your thus far last positive contribution. I have spent hundreds of hours more on babl/GEGL this year than I intended, most of them on unproductive arguments on mailinglists, a medium I not well suited for clearing up misunderstandings but you refuse to spend time where the developers normally clear up misunderstandings, reach consensus and make plans; on IRC. I wrote the babl roadmap when it became clear that playing in your preferred medium, on the mailinglist, answering your questions was more conductive to deepen misunderstandings than clear them up. Like the continued refusal to understand that converting to unbounded linear sRGB on import to the system would be an implementation detail and not neccesarily mean that any processing would necessarily happen in that format - as well as broader principles of software engineering and how one keeps working code working. /pippin ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] Time to fork BABL and GEGL
On Sun, Nov 9, 2014 at 12:23 PM, Elle Stone wrote: > if the other babl/GEGL/GIMP developers really are in agreement with Jon > Nordby (the babl roadmap leaves room for differing interpretations), then > there is no reason whatsoever for further discussion of forking babl and > GEGL to benefit GIMP. Misinterpreting is your choice. You still seem to have little trust that babl/GEGL/GIMP developers have the interests of users/colors or the future of their software in mind. babl/GEGL/GIMP developers have had rough consensus on this topic since march or april, and the roadmap is as detailed as it is not for the benefit of babl/GEGL developers but to contrast the endless and pointless email threads. If the hundreds of hours donated/devoted to the topic had been spent on actual development instead of disagreement about how the software should be developed, we would have a more capable stack already. /pippin ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] Grid Based Maps
On Fri, Aug 29, 2014 at 2:28 AM, Atredie wrote: > I am looking - so far unsuccessfully - for a program that will let me make > make and use grid based maps, like in a PnP RPG or old fashioned doodling on > quad graph paper. Being able to arrange geometric shapes (squares, > rectangles) > and icons without overwriting the grid would be a plus. > > I have tried gimp, but I can not even figure out how to shrink the paintbrish > blob to draw a simple, narrow, line. I was able to put up a grid, however, tiled http://www.mapeditor.org/ is a dedicated application for editing suce tile grids (for use as levels in games and similar) /Øyvind ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] GIMP move tool
On Fri, May 16, 2014 at 4:40 PM, Alexandre Prokoudine wrote: > On Fri, May 16, 2014 at 6:32 PM, Richard wrote: > >> Take Paths for example: Path objects do not have attached layer data, >> meaning that every time you adjust a path you have to re-stroke it onto a >> target surface. > > Oh, that. Øyvind might need to correct me, but basic stroking of > SVG-based paths is done in GEGL. "We have an op for that" :) The gegl:path op (or a similar one), is the foundation that seems natural to base vector layers on. The gegl:text op isn't as powerful as GIMPs text tool yet; but is other, and similar, rendering code that ideally would be migrated to a GEGL op. /Øyvind ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
[Gimp-user] Elaborating Export functionality
On Mon, Jan 13, 2014 at 7:31 PM, Andrew_Bridget wrote: > This is such a common task, there may be cause to have a Resize option > bundled with the Export command. Having to always perform them as two > separate steps is an annoyance, but the possibility of accidentally saving > the wrong resolution back to the XCF file is a danger. > > A question that asked late last year as I had a need to resize and keep > working on original. That's when I found the save for web had been reinstated > as 2.6. Part of the motivation for the save/export distinction in the first place is later being able to introduce such improvements to export workflows (as well as other neat things; like being able to choose between export presets, multiple named regions - and more). Without a clear conceptual internal seperation - such future improvements will be much harder. ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] Exporting files
On Fri, Jan 10, 2014 at 2:57 AM, Øyvind Kolås wrote: > On Thu, Jan 9, 2014 at 9:50 PM, EGoldman wrote: >> I had a point and shoot camera that only shot in Jpeg so after I did all my >> levels and curve and contrast changes, I would always export as Tiff file so >> I >> would have a negative/master file of my pic. >> >> I have just bought a Canon DSLR which I can now shoot in the Raw, my >> question >> is after I make my color corrections, how should I export the file so I have >> a >> negative/master? >> >> Any guidance would be so appreciated. Sorry, that email got sent off half way through the first sentence. I would suggest using either XCF - if GIMP is your primary program for doing things. If you are using GIMP 2.9 though; I would suggest converting your images after load to 32 bit floating point linear, and storing the "negatives" as EXR files; which is a well defined high-fidelity format that more software packages than GIMP is able to load. /pippin -- ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] Exporting files
I would suggest using either XCF On Thu, Jan 9, 2014 at 9:50 PM, EGoldman wrote: > I had a point and shoot camera that only shot in Jpeg so after I did all my > levels and curve and contrast changes, I would always export as Tiff file so I > would have a negative/master file of my pic. > > I have just bought a Canon DSLR which I can now shoot in the Raw, my question > is after I make my color corrections, how should I export the file so I have a > negative/master? > > Any guidance would be so appreciated. > > > -- > EGoldman (via www.gimpusers.com/forums) > ___ > gimp-user-list mailing list > List address:gimp-user-list@gnome.org > List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list > List archives: https://mail.gnome.org/archives/gimp-user-list -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] Histogramm -- values
On Tue, Nov 12, 2013 at 4:39 AM, Wolfgang Hugemann wrote: > ... > However, there seems to be no way to display the histogramm in terms of > brightness in Gimp (?). The "value" seems to be just max(R,G,B). But > luminance is generally caculated by > Y = 0.2126 R + 0.7152 G + 0.0722 B > see http://en.wikipedia.org/wiki/Luminance_%28relative%29. > > Wouldn't it make sense to offer this option? In my opinion, the (still) widespread use of value = max(max(r,g),b) is a remnant of 8bit image processing centric performance short-cuts. We would be better off by using luminance in most or all the cases where this approach is currently used. /pippin ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list
Re: [Gimp-user] gimpx? possible malicious software using Gimp name
On Mon, May 27, 2013 at 12:17 AM, Steve Kinney wrote: > On 05/26/2013 03:43 PM, Michael Schumacher wrote: > > On 26.05.2013 21:07, Steve Kinney wrote: > > > >> At present, the link to the Windows port on the Downloads page at > >> gimp.org is hidden behind a "show other downloads" link buried in > >> the middle of the page. > > > > You're not using a Windows platform, are you? > > Nope, left that nonsense behind ages ago. At the moment my main > workstation is running Mint 14 w/Cinnamon, see: > The reason for the question was that "show other downloads" is supposed to be for other platforms than the one you are browsing with ;) /Ø ___ gimp-user-list mailing list gimp-user-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-user-list
Re: [Gimp-user] Dark Theme for GIMP?
On Sat, May 11, 2013 at 2:52 AM, Jehan Pagès wrote: > Hi, > > on various websites, you can see screenshots of GIMP with dark themes. > Also I remember during LGM, it was said that GIMP at some point > (2.10?) would be released with a dark theme as a default. > GIMP 3.0 when GIMP moves to GTK3. GTK3 comes with default both dark and bright themes. The GTK3 branch might be good a place to look.. > Second question: the logics behind dark themes is apparently that they > would be less a disturbance than a bright theme when you are working, > if I remember LGM speech. Is that it? Is it better for the eyes too? I > always thought that black on white was basically better for the eyes. > Are there any actual studies explaining that dark UI are better for > users, which would explain our switch to a darker default theme? Or is > it all based on a feeling that dark themes are better? > A dark theme will sink further into the background, allowing the canvas and image to take a more prominent position. For GTK3 (and GNOME 3 apps) the choice of which theme will be appropriate is whether it is application focusing primarily on consuming or authoring visual content (image browser, editor, video player..) or not. For visual content centric applications color appearance is important, by making the context of the work be subdued and dark - negative impact of simultaneous contrast in the human visual system will be reduced. For text, the more paper like black on white might be preferable - though this would also depend on display technologies.. and viewing context. /Ø -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ gimp-user-list mailing list gimp-user-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-user-list
Re: [Gimp-user] GSOC 2013 Computational Photography Proposal
On Tue, Apr 16, 2013 at 2:26 PM, Siddharth wrote: > Yes, I did post it to blender. But they said - "All three proposals are > very cool, but quite more suitable for GIMP than for Blender". > Hence, I am applying here since these methods are currently missing in > GIMP. > > Yes, I have build GIMP from source code. > > How should I proceed further with my proposal? > The best way to proceed, is to pretend you already have been accepted, and to figure out what you need to do to get some of this into GIMP. Students that have already started and are seen as bug-fixers, as well as feature contributors to the code base are more likely to be accepted by us in GSOC, we want new contributors and care less about the actual features proposed. We expect students to at least have submitted a well formed git contribution as a patch in bugzilla before considering them. Help can be had both from searching google as well as asking us on IRC. /Ø -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ gimp-user-list mailing list gimp-user-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-user-list
Re: [Gimp-user] export vs save
On Wed, Feb 20, 2013 at 11:01 PM, Matthew Miller wrote: >> This is also the reason that core GIMP contributors consider this >> discussion to already be done and dealt with before it flared up and >> trolls are keeping it artificially alive. The self selected beta >> testers that are willing to use the development version and work out >> problems during active development have a larger influence on >> decisions. These are also the users it makes most sense for the >> developers to spend their volunteered time communicating with – since >> these users directly contribute to finding bugs and potential problems >> early. > > That doesn't appear to have been the case here. I brought this up during the > 2.7.x development series, and was told that it had already been decided. During the 2.7.x development a lot of changes were done to both the specification and implementation of the new way of dealing with save and export based on feedback from gimpers that were using the development version. The reactions to; and eventual acceptance from most; made core contributors aware that there would be a shit-storm – and that just like for the avantgarde, the general masses are likely to embrace the new way in the end. In particular knowing that these are necessary reorganization to enable even more powerful ways of working in the future. /Ø ___ gimp-user-list mailing list gimp-user-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-user-list
Re: [Gimp-user] export vs save
On Wed, Feb 20, 2013 at 8:26 PM, Matthew Miller wrote: > Someone a while ago had the suggestion of building "sidecar" files with the > entire undo history of an image. As storage space continues to increase, > that sounds like a very promising path providing best of all worlds. Part of the reason for this change, is to align the current UI with such capabilities that GIMP eventually will gain as part of the ongoing GEGL integration effort. As already mentioned many times in this thread and through the last decade; GIMP is moving towards a non-destructive editing mindset – interactions designers/architects involved, core developers and well informed users that closely have been following the development over the last decade are aware of this. When such changes have landed in a stable release; there has been a quite long period of feedback from the users that follow development more closely than the users that only use stable versions of GIMP. This is also the reason that core GIMP contributors consider this discussion to already be done and dealt with before it flared up and trolls are keeping it artificially alive. The self selected beta testers that are willing to use the development version and work out problems during active development have a larger influence on decisions. These are also the users it makes most sense for the developers to spend their volunteered time communicating with – since these users directly contribute to finding bugs and potential problems early. /Ø ___ gimp-user-list mailing list gimp-user-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-user-list
Re: [Gimp-user] import vs open
On Tue, Feb 19, 2013 at 4:06 AM, Chris Mohler wrote: > On Mon, Feb 18, 2013 at 1:15 PM, Liam R E Quin wrote: >> * File->Open filters to *.xcf* by default; attempting to open a non-xcf >> file brings up a message, "myfile.jpg is not an XCF file. Would you like >> to import it?" > > Current File-Open makes sense as it is, at least to me. After a > CTRL-O I don't want to have to reset the filter every time, or see a > dialog every time. Just treat it like an import - no need to add a > dialog (this covers right-click 'Edit with GIMP' also - would we have > to add another action: 'Import into GIMP' to skip the dialog? yuck.). > > As for File->Import, I don't understand why it would ever replace > anything - much less why the clean/dirty flag would be the toggle. > Maybe I'm missing something. We could end up in a scenario where Open means open as a new document, the current behavior, while import _could_ be what today is called "Open as Layer(s)" and will insert the imported file in the current composition. ;) /Ø -- «The future is already here. It's just not very evenly distributed» -- William Gibson ___ gimp-user-list mailing list gimp-user-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-user-list
Re: [Gimp-user] Unskewing images of flat rectangular objects in Gimp
On Mon, Feb 4, 2013 at 4:11 PM, Elmer Wix wrote: > I often use my digital camera to take pictures of flat, rectangular > objects, like framed paintings on a wall, book or album covers, or > pages of documents. Of course, I can't take these pictures straight > on and perfectly level, but that's OK. I know what the dimensions of > the objects are, so I can just correct the perspective in software. > > Does Gimp have any function like this? I found the perspective tool, > but that requires me to manually shift the perspective and eyeball > when I think a rectangular image is produced. That's not nearly as > convenient. The perspective tool has an inverse mode, if you align the grid lines from the wireframe preview with the lines desired to become horizontal/vertical and then do the transform you should end up with a rectified version of the quadliteral. /pippin -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ gimp-user-list mailing list gimp-user-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-user-list
Re: [Gimp-user] Save Export Complaints
On Wed, Sep 12, 2012 at 2:43 PM, maderios wrote: > I use .xcf files but my friends, my family members and most people, I think, > don't use .xcf. They need an image editor, not an xcf editor. > People will leave the world of free software to turn to proprietary. > Gimp is no longer the "universal Swiss army knife " of image editing, it's a > fact. GIMP has not lost any capability, all it has done is re-arrange some capabilities for greater consistency - as well as opening up for extending the capabilities of XCF - like storing undo history and more thing that make less sense for the external formats. For GIMP it is a good thing that people take changes personally - it means they care deeply about GIMP and how they use it, make it seem unlikely that they switch no matter how much venom they directed at the volunteers that spend their time actually making it happen. :) /Ø ___ gimp-user-list mailing list gimp-user-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-user-list
Re: [Gimp-user] HATE the new save vs. export behavior
On Tue, Aug 7, 2012 at 8:49 PM, Anoko wrote: > I do not see why this is solved. Someone who is not familair with GIMP, that > wants to store something as a png file, clicks save, finds it needs to > export, clicks export and has lost their layered data nevertheless, now > basically without a warning saying layers got lost. GIMP knows that your project only has been exported not saved, it will thus ask you to save later when you try to quit GIMP - giving you a chance to preserve the layer structure (higher bit depth, and more) that was discarded in the export to PNG. /Ø -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://twitter.com/hodefoting ___ gimp-user-list mailing list gimp-user-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-user-list
Re: [Gimp-user] Benchmarking Gimp/GEGL
On Sun, Apr 29, 2012 at 10:44 AM, Jernej Simončič wrote: > On Sun, 29 Apr 2012 03:31:26 +0200, Øyvind Kolås wrote: >> It also turns out that babl and GEGL on win32 seem to be compiled >> practically without optimization and without taking modern instruction >> sets into account, making any testing of them on windows >> unrepresentative of their actual performance. > > What are the recommended optimization flags? On win32, no idea, perhaps look at what compiler flags are being used on linux? This is signal processing code and everything from -ffast-math to -ftree-vectorize and probably more are important. /Ø -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ gimp-user-list mailing list gimp-user-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-user-list
Re: [Gimp-user] Benchmarking Gimp/GEGL
On Tue, Mar 20, 2012 at 11:26 PM, Partha Bagchi wrote: >>> >So, what kind of timing do you get with your OS? >>> >>> While some will find the information interesting, the timing others will >>> experience depends very little on the operating system being used. The >>> results will vary greatly based on the type of CPU and its clock speed, and >>> the type and speed of memory, and number of wait states. The type of video >>> card might also affect the results. >> >> and the user's speed in entering the commands. It also turns out that babl and GEGL on win32 seem to be compiled practically without optimization and without taking modern instruction sets into account, making any testing of them on windows unrepresentative of their actual performance. /Ø -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ gimp-user-list mailing list gimp-user-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-user-list
Re: [Gimp-user] Benchmarking Gimp/GEGL
On Tue, Mar 20, 2012 at 4:14 PM, László Boros wrote: > Hi everybody, > > I'm new on this list. > It would be a great thing to measure the performance with and without GEGL, > so with an older version of GIMP, and with the new one. But I don't really > know what things have been changed, so I'm not sure it would give a proper > answer. Measuring the performance of GIMP with and without GEGL does not really make sense yet, due to additional overheads of different kinds that are involved (many of which eventually will disappear when the transformation of GIMP is complete). One of these is the ping-pong dance going back and forth between 128 bits/pixel and 32bits/pixel for every thing that is done. /Ø -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ ___ gimp-user-list mailing list gimp-user-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-user-list
