Re: [Gimp-developer] suggestions
On Mon, Jun 25, 2012 at 8:22 AM, wanderer wrote: > Here are the suggestions: > > 1- When you are using the scale or rotate tool and try to insert a guide, it > doesn't close the tool. You mean, the suggestion is to _not_ close thew tool? :) > 2- add the option to snap guides at the border and/or center of layers > bounds. Makes sense to me > 3 - add the option to autocrop layers to their limits (the same thing like > when you do 'alpha to selection' then 'layers -> crop to selection') > whenever you change it. To autocrop in which cases? Transformation tools already have that. > 4 - add a checkbox button in the scale tool for scale from center. Maybe add > also a keyboard shortcut for it. This is already in works and will be available in the new unified transform tool, except it will be called differently. See http://gui.gimp.org/index.php/Transformation_tool_specification#pivot for reference. Alexandre Prokoudine http://libregraphicsworld.org ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] suggestions
> > 2- add the option to snap guides at the border and/or center of layers > bounds. Relative snapping/positioning has been on my mind a lot! A lot of times when making banners or brochures, I just want one layer aligned at the same horizontal or vertical position or with same height or width. I don't need grids or any guides. In many of my designs, only the relative positioning of layers matters. Currently, I do this by creating guides and then snapping both layers to it, appropriately. This is quite strenuous to repeat every time I need such a facility. How about "*snap to layer edges*", which creates guides at all 4 edges of all layers. (See [1] ) These "Layer-Guides" could be in a different colour to differentiate from user-defined guides. Could also configure which edges we would like to snap to. If these Layer-Guides get visually confusing with other guides and the grid, then we can display the guide(s) momentarily when a layer is scaled or moved to snap to it(them). That is, show the guides only *during the snap *. [1] https://dl.dropbox.com/u/28366148/relative-guides.jpg On Mon, Jun 25, 2012 at 10:13 AM, Alexandre Prokoudine < alexandre.prokoud...@gmail.com> wrote: > On Mon, Jun 25, 2012 at 8:22 AM, wanderer wrote: > > > Here are the suggestions: > > > > 1- When you are using the scale or rotate tool and try to insert a > guide, it > > doesn't close the tool. > > You mean, the suggestion is to _not_ close thew tool? :) > > > 2- add the option to snap guides at the border and/or center of layers > > bounds. > > Makes sense to me > > > 3 - add the option to autocrop layers to their limits (the same thing > like > > when you do 'alpha to selection' then 'layers -> crop to selection') > > whenever you change it. > > To autocrop in which cases? Transformation tools already have that. > > > 4 - add a checkbox button in the scale tool for scale from center. Maybe > add > > also a keyboard shortcut for it. > > This is already in works and will be available in the new unified > transform tool, except it will be called differently. See > http://gui.gimp.org/index.php/Transformation_tool_specification#pivot > for reference. > > Alexandre Prokoudine > http://libregraphicsworld.org > ___ > gimp-developer-list mailing list > gimp-developer-list@gnome.org > https://mail.gnome.org/mailman/listinfo/gimp-developer-list > -- * * *Regards, * *Srihari Sriraman * ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] suggestions
* mailrea...@juno.com [03-27-16 13:30]: > It would be nice if the website said how much free space is required to > download the program and to run it, and what other things might be > useful to use with it and where they can be found and how big they are. They are but you apparently are not familiar enough with your chosen system to determine them. You don't even mention what operating system you use, but one might hazard a pretty accurate guess. > It would also be nice if people could see good reasons not to comment, > as one user has posted online (I think at answers.yahoo.com), that GIMP > is "not as good as Photoshop". But "nice" is unreasonable :) -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.orgopenSUSE Community Memberfacebook/ptilopteri http://wahoo.no-ip.orgPhoto Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535@ http://linuxcounter.net ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] suggestions
Actually, I'm on Linux, and I don't see the file size listed either. I don't personally care much, because I know that GIMP is damn small compared to most high-powered graphics applications, but still I can see that some folks may care the first time they download from the website. If anything, the file size should be listed as a benefit to using GIMP. :) > It would also be nice if people could see good reasons not to comment, > as one user has posted online (I think at answers.yahoo.com), that GIMP > is "not as good as Photoshop". We're not anti-Photoshop, we are pro-GIMP. :) People can have their opinions, and we should either cheerfully accept them, or post friendly suggestions on how to do the Photoshop-like things they desire in GIMP to convince them otherwise. I've found that anything else would be a waste of (everyone's) time. For some, nothing but Photoshop will work for their graphics needs. It's no use arguing with them, because they have already made up their mind, and it's more important to think they are correct than it is to learn new things and expand your graphics tool-set. However if you can post a tutorial or links to show how the same effects can be done in GIMP, it will go a long way to get others around to seeing what an excellent tool GIMP is for pro-grade graphics work. My 2p. -C - On Sun, Mar 27, 2016 at 6:55 PM, Paka wrote: > * mailrea...@juno.com [03-27-16 13:30]: > > It would be nice if the website said how much free space is required to > > download the program and to run it, and what other things might be > > useful to use with it and where they can be found and how big they are. > > They are but you apparently are not familiar enough with your chosen > system to determine them. You don't even mention what operating system > you use, but one might hazard a pretty accurate guess. > > > It would also be nice if people could see good reasons not to comment, > > as one user has posted online (I think at answers.yahoo.com), that GIMP > > is "not as good as Photoshop". > > But "nice" is unreasonable :) > > -- > (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri > http://en.opensuse.orgopenSUSE Community Memberfacebook/ptilopteri > http://wahoo.no-ip.orgPhoto Album: http://wahoo.no-ip.org/gallery2 > Registered Linux User #207535@ http://linuxcounter.net > ___ > gimp-developer-list mailing list > List address:gimp-developer-list@gnome.org > List membership: > https://mail.gnome.org/mailman/listinfo/gimp-developer-list > List archives: https://mail.gnome.org/archives/gimp-developer-list > ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] suggestions
On Sun, Mar 27, 2016 at 8:22 PM, mailreader wrote: > It would also be nice if people could see good reasons not to comment, > as one user has posted online (I think at answers.yahoo.com), that GIMP > is "not as good as Photoshop". What do you expect us to do about it? Alex ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] suggestions
I recommend this small change to the current download page: www.opendesignstudio.org/gimp/samples/gimp_download_file_size.png On Sun, Mar 27, 2016 at 7:44 PM, C R wrote: > Actually, I'm on Linux, and I don't see the file size listed either. > I don't personally care much, because I know that GIMP is damn small > compared to most high-powered graphics applications, but still I can see > that some folks may care the first time they download from the website. > > If anything, the file size should be listed as a benefit to using GIMP. :) > > > It would also be nice if people could see good reasons not to comment, > > as one user has posted online (I think at answers.yahoo.com), that GIMP > > is "not as good as Photoshop". > > We're not anti-Photoshop, we are pro-GIMP. :) People can have their > opinions, and we should either cheerfully accept them, or post friendly > suggestions on how to do the Photoshop-like things they desire in GIMP to > convince them otherwise. I've found that anything else would be a waste of > (everyone's) time. For some, nothing but Photoshop will work for their > graphics needs. It's no use arguing with them, because they have already > made up their mind, and it's more important to think they are correct than > it is to learn new things and expand your graphics tool-set. However if you > can post a tutorial or links to show how the same effects can be done in > GIMP, it will go a long way to get others around to seeing what an > excellent tool GIMP is for pro-grade graphics work. > > My 2p. > -C > > - > > > > On Sun, Mar 27, 2016 at 6:55 PM, Paka wrote: > >> * mailrea...@juno.com [03-27-16 13:30]: >> > It would be nice if the website said how much free space is required to >> > download the program and to run it, and what other things might be >> > useful to use with it and where they can be found and how big they are. >> >> They are but you apparently are not familiar enough with your chosen >> system to determine them. You don't even mention what operating system >> you use, but one might hazard a pretty accurate guess. >> >> > It would also be nice if people could see good reasons not to comment, >> > as one user has posted online (I think at answers.yahoo.com), that GIMP >> > is "not as good as Photoshop". >> >> But "nice" is unreasonable :) >> >> -- >> (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri >> http://en.opensuse.orgopenSUSE Community Member >> facebook/ptilopteri >> http://wahoo.no-ip.orgPhoto Album: >> http://wahoo.no-ip.org/gallery2 >> Registered Linux User #207535@ >> http://linuxcounter.net >> ___ >> gimp-developer-list mailing list >> List address:gimp-developer-list@gnome.org >> List membership: >> https://mail.gnome.org/mailman/listinfo/gimp-developer-list >> List archives: https://mail.gnome.org/archives/gimp-developer-list >> > > ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] suggestions
> > It would also be nice if people could see good reasons not to comment, > > as one user has posted online (I think at answers.yahoo.com), that GIMP > > is "not as good as Photoshop". > > What do you expect us to do about it? > > Alex > On answers.yahoo.com, it seems to me that anyone from the community could just post a better answer. ;) It's not really something to bother devs about though. More a community outreach sort of thing. :) -C > ___ > gimp-developer-list mailing list > List address:gimp-developer-list@gnome.org > List membership: > https://mail.gnome.org/mailman/listinfo/gimp-developer-list > List archives: https://mail.gnome.org/archives/gimp-developer-list > ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] suggestions
On 03/27/2016 02:44 PM, C R wrote: I've found that anything else would be a waste of (everyone's) time. For some, nothing but Photoshop will work for their graphics needs. It's no use arguing with them, because they have already made up their mind, and it's more important to think they are correct than it is to learn new things and expand your graphics tool-set. Putting the serious limitations of 8-bit editing to one side, even high bit depth GIMP 2.9/2.10 lacks critically important components of the workflows of (lacking statistics, at least some) professional photographers currently using PhotoShop. For example, for at least some professional photographers, their workflow depends on: * The ability to edit in RGB working color spaces other than sRGB. * The ability to easily record and replay repetitive steps ("macros"). Without this ability, any degree of complexity in a high volume workflows means "high volume" isn't a realistic possibility unless you can figure out how to make the workday longer, in which case you are facing repetitive stress syndrome from typing in the same steps over and over, no doubt accompanied by mind-boggling amounts of tedious boredom. * The ability to use adjustment layers. Without adjustment layers (or nodes which might even be better) for operations like Curves, Levels, Channel Mixer, etc the user canNOT go back and tweak intermediate results. However if you can post a tutorial or links to show how the same effects can be done in GIMP, it will go a long way to get others around to seeing what an excellent tool GIMP is for pro-grade graphics work. I am speaking specifically of photographic editing. I can't speak to graphics editing. In your estimation, is it the case that a pro-grade graphics workflow: * Doesn't ever require editing in RGB working spaces other than sRGB? * Doesn't ever require involve performing the same sequence of steps over and over again. * Wouldn't be made considerably more efficient by having adjustment layers? Best, Elle ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] suggestions
Totally agree with you. Color management would definitely be a priority for high-end photo editing software. Also, I would think that nondestructive editing would be high on the list (Photoshop's "Smart Objects"). If I am not mistaken, Alex has already mentioned adjustment layers numerous times in past as a requirement/missing feature in GIMP. On Mon, Apr 4, 2016 at 9:56 AM, Elle Stone wrote: > On 03/27/2016 02:44 PM, C R wrote: > >> I've found that anything else would be a waste of >> (everyone's) time. For some, nothing but Photoshop will work for their >> graphics needs. It's no use arguing with them, because they have already >> made up their mind, and it's more important to think they are correct than >> it is to learn new things and expand your graphics tool-set. >> > > Putting the serious limitations of 8-bit editing to one side, even high > bit depth GIMP 2.9/2.10 lacks critically important components of the > workflows of (lacking statistics, at least some) professional photographers > currently using PhotoShop. > > For example, for at least some professional photographers, their workflow > depends on: > > * The ability to edit in RGB working color spaces other than sRGB. > > * The ability to easily record and replay repetitive steps ("macros"). > Without this ability, any degree of complexity in a high volume > workflows means "high volume" isn't a realistic possibility unless you can > figure out how to make the workday longer, in which case you are facing > repetitive stress syndrome from typing in the same steps over and over, no > doubt accompanied by mind-boggling amounts of tedious boredom. > > * The ability to use adjustment layers. > Without adjustment layers (or nodes which might even be better) for > operations like Curves, Levels, Channel Mixer, etc the user canNOT go back > and tweak intermediate results. > > However if you >> can post a tutorial or links to show how the same effects can be done in >> GIMP, it will go a long way to get others around to seeing what an >> excellent tool GIMP is for pro-grade graphics work. >> > > I am speaking specifically of photographic editing. I can't speak to > graphics editing. In your estimation, is it the case that a pro-grade > graphics workflow: > > * Doesn't ever require editing in RGB working spaces other than sRGB? > > * Doesn't ever require involve performing the same sequence of steps over > and over again. > > * Wouldn't be made considerably more efficient by having adjustment layers? > > Best, > Elle > > ___ > gimp-developer-list mailing list > List address:gimp-developer-list@gnome.org > List membership: > https://mail.gnome.org/mailman/listinfo/gimp-developer-list > List archives: https://mail.gnome.org/archives/gimp-developer-list > ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] suggestions
On Mon, Apr 4, 2016 at 4:19 PM, Partha Bagchi wrote: > Also, I would think that nondestructive > editing would be high on the list (Photoshop's "Smart Objects"). > > If I am not mistaken, Alex has already mentioned adjustment layers numerous > times in past as a requirement/missing feature in GIMP. One of the primary reason some of us have has as motivation for working on GEGL and its integration in GIMP for more than a decade is not high bit depth support, but non-destructive editing features like "adjustment layers" and "smart objects". As has been communicated repeatedly; GIMP-2.10 and 3.0 are planned to have feature parity with GIMP-2.8, and let the integration of GEGL as well as GEGL itself mature with that - before experimenting with more non-destructive features; non destructive user experiences with GEGL are - and have been - experimented with outside the GIMP code base. /pippin ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] suggestions
On 04/04/2016 12:28 PM, Øyvind Kolås wrote: One of the primary reason some of us have has as motivation for working on GEGL and its integration in GIMP for more than a decade is not high bit depth support, but non-destructive editing features like "adjustment layers" and "smart objects". As has been communicated repeatedly; GIMP-2.10 and 3.0 are planned to have feature parity with GIMP-2.8, and let the integration of GEGL as well as GEGL itself mature with that - before experimenting with more non-destructive features; non destructive user experiences with GEGL are - and have been - experimented with outside the GIMP code base. This is a very interesting statement. Nondestructive editing is important. But what about the ability to edit in color spaces other than sRGB? Is this less or more of a priority than nondestructive editing? Perhaps most of the people who currently use GIMP are satisfied with sRGB. I rather suspect there's a lot of people who would love to use high bit depth GIMP, who absolutely have no intention of doing all their editing the sRGB color space. What is a necessary feature in an image editor of course varies from person to person. Given a choice between PhotoShop and today's high bit depth GIMP, I choose GIMP, no hesitation. But that's because: 1. I get around the "sRGB only" issue by patching and building a modified copy of GIMP that is "Rec2020 only". 2. PhotoShop wasn't (and I'm told still isn't) really equipped to handle linear gamma image editing because of the quantization used for the Curves and Levels UI (this applies to 16-bit integer editing, I'm not sure what's going on with 32f editing in PhotoShop). 3. PhotoShop doesn't have GIMP's incredibly useful LCH blend modes. 4. I'm not a professional and don't have a high volume workflow. So not having macros and adjustment layers doesn't stand nearly as much in my way as it would if I had deadlines to meet. 5. Any chance that I would ever switch back to PhotoShop ended with Adobe's Creative Cloud: * I find the idea that the artist's own work should be locked into a proprietary file format such as PhotoShop's PSD to be extremely distasteful. Adobe's move to the cloud has made this issue of who controls access to the artist's work crucially important. * The Creative Cloud license agreement is onerous and one-sided (http://macperformanceguide.com/blog/2013/20130508_1a-Adobe-legal-agreement.html). * Once the artist stops paying the subscription fee, she loses access to the software that unlocks the proprietary PSD format that contains her creative work (https://forums.adobe.com/thread/1206477?start=0&tstart=0). Reason number 5 above is why it seems to me that it's very important that GIMP be a viable alternative for would-be PhotoShop Creative Cloud refugees. I understand that there are not enough GIMP developers to make changes in GIMP happen quickly. I understand that it might be years before GIMP has macros and adjustment layers. What I don't understand is why the ability to edit images in the RGB working space of the user's choice seems to be a low-priority item. Best, Elle ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] suggestions
I will say that it would be nice to have a recommended hardware to run GIMP. I know this is Free and Open Source Software and you can pretty much run it one anything as well as we are not Photoshop and are not worried about sails and making sure that the customer is running the best hardware to run GIMP on. But GIMP is getting bigger, more complicated, able to perform harder tasks and therefore does have hardware requirements. I was on a old netbook testing out my theme I was making to make sure it worked OK in Windows, and just changing the theme was a nightmare. I have been on other computers that were a bit nicer trying to do other things and GIMP was running sluggish. I don't think that GIMP has to be a conservative as Photoshop and recommend at least two/three year old hardware. But there is a logical limit to the hardware people can run and still use GIMP relatively smoothly. Maybe there could be a note saying something like: GIMP can run on pretty much all hardware but here are our recommendations. That way people who have never used GIMP understand that they might be able to run it but they might not have the best experience and it's their hardwares fault not GIMP's. I don't know what hardware to recommend but I do think that we should recommend something. On Apr 4, 2016 12:28 PM, "Øyvind Kolås" wrote: On Mon, Apr 4, 2016 at 4:19 PM, Partha Bagchi wrote: > Also, I would think that nondestructive > editing would be high on the list (Photoshop's "Smart Objects"). > > If I am not mistaken, Alex has already mentioned adjustment layers numerous > times in past as a requirement/missing feature in GIMP. One of the primary reason some of us have has as motivation for working on GEGL and its integration in GIMP for more than a decade is not high bit depth support, but non-destructive editing features like "adjustment layers" and "smart objects". As has been communicated repeatedly; GIMP-2.10 and 3.0 are planned to have feature parity with GIMP-2.8, and let the integration of GEGL as well as GEGL itself mature with that - before experimenting with more non-destructive features; non destructive user experiences with GEGL are - and have been - experimented with outside the GIMP code base. /pippin ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] suggestions
On 04/04/2016 01:54 PM, C R wrote: On Mon, Apr 4, 2016 at 2:56 PM, Elle Stone mailto:ellest...@ninedegreesbelow.com>> wrote: Putting the serious limitations of 8-bit editing to one side, even high bit depth GIMP 2.9/2.10 lacks critically important components of the workflows of (lacking statistics, at least some) professional photographers currently using PhotoShop. Hi Elle. :) I feel like we've had this discussion before... but, well if that's true, here goes again. ;) For example, for at least some professional photographers, their workflow depends on: * The ability to edit in RGB working color spaces other than sRGB. I'm sure if they require something other than sRGB, they will want Photoshop (at the moment). Of course, that is a self-imposed limitation. Suggesting that professional results can only be gotten outside sRGB is untrue. "Professional results" and "self-imposed limitation" are two very different concepts here. Yes, people can and do acheive professional results editing in sRGB. That doesn't mean *all* professional and personal goals that a photographer might have can be met using sRGB. I have never once had anyone squint at my model photos and say "Heeeyyy... that's JUST sRGB, how unprofessional!" Maybe they were just being polite though... Many people produce fantastic and professional results using sRGB for all their editing. The fact remains that the adequacy of sRGB depends entirely on one's editing goals and style: 1. For someone editing mostly for CMYK reproduction for mass printing, I suspect sRGB is usually a good color space to work in, though this area is completely outside my own experience. Likewise for digital artists whose intended display space is sRGB, I suspect sRGB is a good color space to paint in (and when the Rec.2020 devices start hitting the market?). 2. Someone making "as close as possible" photographs of artwork will need to use a larger color space than sRGB unless they only photographs very low-gamut artwork. If the artwork photographs are to be made into prints on fine art photographic paper, again, sRGB is too small except for low-gamut artwork. 3. If someone wants to prepare camera images for a Rec.2020 or other display device with a color gamut larger than sRGB, then sRGB is too small unless the photographer only photographs low-gamut scenes. Of course the alternative is photographing more colorful scenes and then throwing all the lovely colors that exceed sRGB right out the window. 4. Likewise with preparing camera images for printing on high end printers using high quality photographic paper - you either throw printable colors away or you edit in an RGB working space large enough to adequately hold the colors you captured with your camera. Yes there are still camera-captured colors that will be problematic, but that's part of dealing with camera input profiles and part of dealing with soft proofing. 5. Even when editing low-gamut images or else sRGB images produced in-camera, depending on your editing goals switching to a larger color space can be advantageous as anything other than mild edits sends RGB colors to the edge of the very small sRGB color gamut. 6. White balancing an sRGB camera jpeg that was shot with the wrong in-camera white balance is much easier to do in a larger RGB color space (http://ninedegreesbelow.com/photography/white-balancing-camera-jpegs.html). 7. Of course if you only shoot sRGB camera jpegs that were properly color-balanced "in camera", and you process them "gently", you aren't going to have a problem with out of gamut colors. But if you only shoot sRGB camera jpegs, there's a whole realm of image editing possibilities that you can't easily perform on this kind of image, that instead require starting with the raw file. Personally I prefer to begin editing with a scene-referred image rendered from a raw file, and for most scenes (unless I only point my camera at low-gamut scenes) this requires using an RGB working space that is larger than sRGB. The problem with sRGB is that the sRGB color gamut is very small (http://ninedegreesbelow.com/photography/srgb-versus-photographic-colors.html). I once made some sample photographs to see what real world colors are outside the sRGB color gamut and was surprised to find that even crayons scribbled somewhat heavily on white paper produce colors outside the sRGB color gamut. A nice bright yellow or red flower? completely outside the sRGB color gamut (http://ninedegreesbelow.com/photography/icc-profile-conversion-clipped-colors-examples.html, especially see http://ninedegreesbelow.com/photography/icc-profiles/clipped-colors/red-flower-clipping-prophoto-to-srgb.jpg). Having said all of the above, of course where you point the camera is every bit as (or more) important as what you do with the resulting image, and shooting raw is not a guarantee of producing anything worth looking. Ditto
Re: [Gimp-developer] suggestions
> > I'm sure if they require something other than sRGB, they will want >> Photoshop (at the moment). >> Of course, that is a self-imposed limitation. Suggesting that >> professional results can only be gotten outside sRGB is untrue. >> > > "Professional results" and "self-imposed limitation" are two very > different concepts here. Yes, people can and do acheive professional > results editing in sRGB. That doesn't mean *all* professional and personal > goals that a photographer might have can be met using sRGB. > > In particular, if their professional goal mandated using something other than sRGB gamut (or linear light), then yes I guess so. To me that's a bit like saying I can't work in a 32bit OS because my professional goals include 64bit machine instructions. ;) I'm sure there's a difference, I'm also sure I couldn't tell you what the difference is unless they were side-by-side. I'm also certain other people care way more than I do. :) Let me be clear: I look forward to having the extra features in GIMP, available to those who want/need them. When Photoshop switched to 16bit colour, I stayed with the default 8bit. To this day I'm glad, because I the extra space it takes wasn't worth it for me. ymmv. :) 16 bit/channel colour is a big deal to some people. I'm happy to say that GIMP will support the feature for those who care more than I do about it. I have never once had anyone squint at my model photos and say >> "Heeeyyy... that's JUST sRGB, how unprofessional!" Maybe they were just >> being polite though... >> > > Many people produce fantastic and professional results using sRGB for all > their editing. The fact remains that the adequacy of sRGB depends entirely > on one's editing goals and style: > > > 1. For someone editing mostly for CMYK reproduction for mass printing, I > suspect sRGB is usually a good color space to work in, though this area is > completely outside my own experience. Likewise for digital artists whose > intended display space is sRGB, I suspect sRGB is a good color space to > paint in (and when the Rec.2020 devices start hitting the market?). > This plus web is *most* of the graphics industry. CMYK is often not what's required. I never once had a printing company tell me they wanted a FOGRA27 document. As sad as it is, most people just stick with what the default is. :) 2. Someone making "as close as possible" photographs of artwork will need > to use a larger color space than sRGB unless they only photographs very > low-gamut artwork. If the artwork photographs are to be made into prints on > fine art photographic paper, again, sRGB is too small except for low-gamut > artwork. > This is where my experience falls right off the edge. I have no such special requirements, but again would be happy to have them in GIMP for those people who do need them. > 3. If someone wants to prepare camera images for a Rec.2020 or other > display device with a color gamut larger than sRGB, then sRGB is too small > unless the photographer only photographs low-gamut scenes. Of course the > alternative is photographing more colorful scenes and then throwing all the > lovely colors that exceed sRGB right out the window. > Again, not sure I could tell the difference unless I saw the results side-by-side on the speciality hardware it takes to display them. > 4. Likewise with preparing camera images for printing on high end printers > using high quality photographic paper - you either throw printable colors > away or you edit in an RGB working space large enough to adequately hold > the colors you captured with your camera. Yes there are still > camera-captured colors that will be problematic, but that's part of dealing > with camera input profiles and part of dealing with soft proofing. > I mean, it will never be perfect. At some point you have to draw a line and say "this is good enough". For my purposes, GIMP well exceeds that line. I have pretty high demands as well, they just don't involve swapping colour spaces all that much. :) > 5. Even when editing low-gamut images or else sRGB images produced > in-camera, depending on your editing goals switching to a larger color > space can be advantageous as anything other than mild edits sends RGB > colors to the edge of the very small sRGB color gamut. > True. I've also seen some really wicked things done in Krita with HDR painting. I can see there are advantages to working in a larger colour space as well. It's nothing I need to be subscribing to Photoshop for though. 6. White balancing an sRGB camera jpeg that was shot with the wrong > in-camera white balance is much easier to do in a larger RGB color space ( > http://ninedegreesbelow.com/photography/white-balancing-camera-jpegs.html > ). > Also true. I tend to just take time to get my exposure correct, so there is very little editing to do. I used to process RAW files, these days I can't be bothered as no one notices the difference (including myself). Good lighting is a must for good pi
Re: [Gimp-developer] suggestions
4 апр. 2016 г. 20:10 пользователь "Elle Stone" написал: > But what about the ability to edit in color spaces other than sRGB? Is this less or more of a priority than nondestructive editing? We've had this conversation before. This is how http://wiki.gimp.org/wiki/Roadmap got adjusted to specifically mention that. At your request :) Alex ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] suggestions
On 04/05/2016 04:07 AM, Alexandre Prokoudine wrote: 4 апр. 2016 г. 20:10 пользователь "Elle Stone" написал: But what about the ability to edit in color spaces other than sRGB? Is this less or more of a priority than nondestructive editing? We've had this conversation before. This is how http://wiki.gimp.org/wiki/Roadmap got adjusted to specifically mention that. At your request :) I do appreciate that editing in color spaces other than sRGB is now on the official Roadmap. However, it's on the Roadmap for "Future GIMP". GIMP 2.10 will be an "sRGB only image editor". GIMP 3.0 is mostly about porting to GTK3 and I understand why porting to GTK3 is a high-priority task. As for GIMP 3.2, quoting from the Roadmap: "The focus of this release is going to be on non-destructive editing. Note that both adjustment layers and layer effects/styles are the terminology currently used in requests by users. We haven't yet assessed, how exactly non-destructive editing is going to be implemented." "Future GIMP" is some indefinite version of GIMP that come after the release of GIMP 2.10, GIMP 3.0, and GIMP 3.2. Looking at the timeline for past GIMP releases: 1.2: Dec 2000 2.0: Mar 2004 2.2: Dec 2004 2.4: Oct 2007 2.6: Oct 2008 2.8: May 2012 2.10: ? (high bit depth editing) 3.0: ? (port to GTK3) 3.2: ? (nondestructive editing) Future GIMP: ??? (support for editing in working spaces other than sRGB) If the past is predictive of the future, it could be several or many years before "Future GIMP" gets here and GIMP finally provides for editing in RGB working spaces other than sRGB. sRGB was invented in the 1990s to fit the color gamut of consumer-grade monitors. sRGB has the same primaries as Rec.709, which dates back to 1990 (https://en.wikipedia.org/wiki/Rec._709). Unless the devs give a higher priority to support for editing in RGB working spaces other than sRGB, it looks like Rec.2020 devices (https://en.wikipedia.org/wiki/Rec._2020) will hit the shelves before GIMP supports editing in RGB working spaces other than sRGB. It's already the case that photographic printers and various high-end display devices (televisions and monitors) have color gamuts that exceed the sRGB color gamut. When shooting raw, it's already the case that digital cameras produce reasonably accurate colors that exceed the sRGB color gamut. Even when shooting jpegs, most digital cameras allow to save in the AdobeRGB color space, and if you think those extra greens and blue-greens don't make a difference, you are just kidding yourself. Color-producing/reproducing technology has moved past sRGB. This is a major reason why editing in RGB working spaces other than sRGB should be a high-priority item instead of being deferred to some indefinite "Future GIMP". Best, Elle ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] suggestions
On 04/05/2016 11:59 AM, Elle Stone wrote: timeline for past GIMP releases: https://en.wikipedia.org/wiki/GIMP_version_history ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] suggestions
5 апр. 2016 г. 18:57 пользователь "Elle Stone" написал: > I do appreciate that editing in color spaces other than sRGB is now on the official Roadmap. However, it's on the Roadmap for "Future GIMP". Anything in that section can be moved to e.g. 3.2 provided there is a developer working on any of the features listed there. At some point, the unified transform tool was there too. Then Mikael came, and now it's a v2.10 feature. Alex ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] suggestions
Hi, On 4.4.2016 at 3:56 PM Elle Stone wrote: On 03/27/2016 02:44 PM, C R wrote: * The ability to edit in RGB working color spaces other than sRGB. I'm for this, too. sRGB is from the 1990's and made for the web. Life goes on. Modern monitors aim to get as much AdobeRGB coverage as possible and that's not the end yet. If we aim to provide state-of-the-art technology we should not stick to sRGB, but be open for flexible solutions. See https://bugzilla.gnome.org/show_bug.cgi?id=737778 for instance. As Alex says, it takes just one developer to work on it. I think we can start with the above mentioned bug report and go on from that. * The ability to easily record and replay repetitive steps ("macros"). Yes, that's already part of the roadmap and part of our product vision. * The ability to use adjustment layers. Yes, that's already part of the roadmap. I'm wondering why so many people stick with adjustments layers, nodes and smart objects as if they were the only possible ways for non-destructive editing. I sometimes think because they know nothing else, it's so common, looks cool or because 'PS does it so.' Let's not stick to what Adobe did because it was suitable for PS. I might be wrong, but to me adjustment layers and smart objects seem an attempt to get nondestructive editing into a software that wasn't designed for that while keeping backwards compatibility. Let's find better ways that suit GIMP and support intense users' workflows best. Think of filter brushes, intelligent masks or masks like in Darktable etc. For such a crucial function we won't get out of doing UI testing with users. But one thing we really have to keep in mind with adjustment layers and smart objects is to find an appropriate conversion in the PSD importer and exporter. Greetings Sven ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] suggestions
On 04/05/2016 02:10 PM, Sven Claussner wrote: Hi, On 4.4.2016 at 3:56 PM Elle Stone wrote: On 03/27/2016 02:44 PM, C R wrote: * The ability to edit in RGB working color spaces other than sRGB. I'm for this, too. sRGB is from the 1990's and made for the web. Life goes on. Modern monitors aim to get as much AdobeRGB coverage as possible and that's not the end yet. If we aim to provide state-of-the-art technology we should not stick to sRGB, but be open for flexible solutions. See https://bugzilla.gnome.org/show_bug.cgi?id=737778 for instance. As Alex says, it takes just one developer to work on it. I think we can start with the above mentioned bug report and go on from that. Some of the specific code-related information in that particular bug report is out of date, not surprising as I posted the bug report in December 2014. The general issues remain. The specific locations of the hard-coded parameters haven't changed too much (GEGL has fewer such locations). But the specific functions that call on the hard-coded parameters have changed a bit. I started a branch of this current thread to ask some specific questions regarding a couple of babl functions that might be useful for conveying RGB color space information from GIMP to babl, and also about the idea of coding in a selection of well-behaved RGB working spaces: https://mail.gnome.org/archives/gimp-developer-list/2016-April/msg00049.html Best, Elle ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] suggestions
Hi Elle, On 5.4.2016 at 10:55 PM Elle Stone wrote: On 04/05/2016 02:10 PM, Sven Claussner wrote: Hi, On 4.4.2016 at 3:56 PM Elle Stone wrote: On 03/27/2016 02:44 PM, C R wrote: * The ability to edit in RGB working color spaces other than sRGB. I'm for this, too. sRGB is from the 1990's and made for the web. Life goes on. Modern monitors aim to get as much AdobeRGB coverage as possible and that's not the end yet. If we aim to provide state-of-the-art technology we should not stick to sRGB, but be open for flexible solutions. See https://bugzilla.gnome.org/show_bug.cgi?id=737778 for instance. As Alex says, it takes just one developer to work on it. I think we can start with the above mentioned bug report and go on from that. Some of the specific code-related information in that particular bug report is out of date, not surprising as I posted the bug report in December 2014. The general issues remain. The specific locations of the hard-coded parameters haven't changed too much (GEGL has fewer such locations). But the specific functions that call on the hard-coded parameters have changed a bit. @Pippin, Mitch: what are your thoughts on this topic? I started a branch of this current thread to ask some specific questions regarding a couple of babl functions that might be useful for conveying RGB color space information from GIMP to babl, and also about the idea of coding in a selection of well-behaved RGB working spaces: https://mail.gnome.org/archives/gimp-developer-list/2016-April/msg00049.html I've seen it. It looks like it accidentally landed in the suggestions thread by just using the 'Answer' function of your mail client. As it has now evolved too far from the original poster's topic I suggest to have it as a new top level topic. But please - do not repeat what was already said in one of those many sRGB postings before - stay brief or add a short summary to your postings. I hope you don't get me wrong. Well-thought postings are welcome, but the longer the text the less people read it. Developers love coding ;-) Greetings Sven ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] suggestions
On 04/04/2016 05:36 PM, C R wrote: Only so many hours in the day. For RAW processing Darktable works fine. Back when I switched from Photoshop, RAW editing was still done via plugin, and if you were serious about it, you'd do it in Adobe Lightroom. Back when I switched from PhotoShop, I had already realized that the free/libre dcraw from the command line did a better job than ACR. As my workflow starts with a scene-referred rendition, whatever extras Lightroom might have provided were irrelevant. Of course today's free/libre interpolation algorithms are considerably advanced beyond what dcraw provides. When the deal is "free" it's hard to take such opinions seriously. Yes, I've heard a lot of ranting too. It sounds more and more like noise when they show you pretty grim portfolio pieces done in Photoshop. As if doing something in their editor of choice automatically made them more professional somehow. As the GIMP vision statement seems to imply that supporting advanced workflows is central to the goals for GIMP, it's hard for me to understand why the ability to edit in GIMP using RGB working spaces other than sRGB isn't already part of the code. On the topic of nodes though, have you tried Natron? No. I haven't had the time, though it's on the "to do" list. Have you tried PhotoFlow? I believe PhotoFlow uses nodes. It's a non-destructive raw processor/image editor that also runs as a GIMP plug-in. I can (and do) patch and build versions of GIMP that work in Rec.2020 or other working space(s) of my choice. Most people can't or won't do this. How hard was the patching? Is it really one or the other only? Keeping the patches up to date with babl/GEGL/GIMP from git is tedious. Yes, it's really one or the other because in babl/GEGL/GIMP code the RGB values for Y and XYZ are hard-coded to sRGB instead of using colorant values from a user-chosen RGB working space. Partha very kindly provides builds for my patched GIMP for Windows (http://www.partha.com/). But for Linux you have to compile it yourself (http://ninedegreesbelow.com/photography/patch-gimp-in-prefix-for-artists.html). I've been using my patched high bit depth GIMP a lot in the last year. So obviously I enjoy using GIMP, and also I like the results I'm getting. Otherwise I wouldn't be here pestering the devs (yet again) about adding full support for editing in working spaces other than sRGB. Have you tried the development build? I keep up with babl/GEGL/GIMP from git in a "default GIMP" prefix that I use for filing bug reports. For actual editing I use my patched version of babl/GEGL/GIMP compiled in a separate prefix. I update the patches every month or so. In development build (gimp-edge) Image > Precision > Linear Light The other option is "Perceptual Gamma (sRGB)" Those would be the "babl flips" that allow the devs to decide whether any given editing operation should be done on linear gamma RGB or on perceptually uniform RGB, with "perceptually uniform" hard-coded to be the only approximately perceptually uniform sRGB TRC. The babl flips really could be very useful, especially if all editing operations provided the user with a choice between linearized and perceptually uniform RGB. But for now the babl flips are still a bit of an impediment as sometimes the default "linear vs perceptual" choice is not radiometrically correct. For example Curves and Levels by default are done on perceptually uniform RGB, which unfortunately produces radiometrically *in*correct results. Not sure if this is what you are after, but I thought of you when I saw the feature. :) Note also up to 64bit precision now. GIMP's 64-bit precision option is to allow for importing from/exporting to 64-bit precision files such as FITS files. All internal GEGL processing is done at 32-bit floating point precision. The only thing you accomplish by choosing to *edit* at 64-bit precision is that you'll very quickly fill your available RAM and GIMP will slow way down. Best, Elle ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] suggestions
On 04/06/2016 12:30 AM, Sven Claussner wrote: Hi Elle, Hi Sven, On 5.4.2016 at 10:55 PM Elle Stone wrote: I started a branch of this current thread to ask some specific questions regarding a couple of babl functions that might be useful for conveying RGB color space information from GIMP to babl, and also about the idea of coding in a selection of well-behaved RGB working spaces: https://mail.gnome.org/archives/gimp-developer-list/2016-April/msg00049.html I've seen it. It looks like it accidentally landed in the suggestions thread by just using the 'Answer' function of your mail client. As it has now evolved too far from the original poster's topic I suggest to have it as a new top level topic. I started a new thread per your suggestion: https://mail.gnome.org/archives/gimp-developer-list/2016-April/msg00053.html Best, Elle ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list