[Gimp-developer] Help with a Gimp 2.10 question
Hello! I have a question I hope you could answer me. Recently a nice proyect have been proposed to me. I will participate as a teacher in a special course a spanish University will offer next year. The course is tittled Management Specialist of photographic funds and it will be instruct about old photograhs management and treatment. I will be in charge of the graphical restoring part of the course, and I will use Gimp to teach students. The thing is the course it will be higly professional and it will be nice to use 16bit chanels colors to work with the scanned photos. The photos will be retouched belongs a real photographic found and will be digitalized and included in the official public database, so a great accuracy is mandatory. I know the next Gimp version will brings us a great 16bit and some more color modes. It will be great that the new version will be out before the course starts. The question is ¿When it is planned to be released the 2.10 Gimp version? The course will starts over september 2013, but the agenda must be closed over april 2013, so if I want to use Gimp I need the 16bit channels feature before april. It will be great to use Gimp, cause the course is a great opportunity to popularize its use, but if 2.10 Gimp version will be released after april, I think I must have to use other software like Photivo, Darktable or similar who can work with more bit per channel. What do you think? It will be possible to use Gimp in the course? Will 2.10 be published at time? Any information and suggestion will be appreciated. ;) Thank you and excuse my poor english. ;) jEsuSdA 8) ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Help with a Gimp 2.10 question
On Tue, Dec 18, 2012 at 3:46 PM, jEsuSdA 8) wrote: The question is ¿When it is planned to be released the 2.10 Gimp version? At this point in time any estimation of 210 release involving dates (including even years) would be a deliberate lie :) The last thing I heard from mitch is that GEGL transition is only ca. 20% done. This is the single most important factor for a new stable release. The course will starts over september 2013, but the agenda must be closed over april 2013, so if I want to use Gimp I need the 16bit channels feature before april. Personally, and this is just a speculation, I think we'll be lucky if we'll have 2.9.0 by April 2013. Alexandre Prokoudine http://libregraphicsworld.org ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
[Gimp-developer] Flip Tool (Gimp 2.9) [BUG]
Hi cool devs! I found a bug with the flip tool (Shift+F). If I flip horizontally this image i'll get buggy results: http://i.imgur.com/rXQbf.png Image source - http://dl.dropbox.com/u/26887202/blender/ee.png Linux 64 bit, gimp 2.9 git. Thanks. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Help with a Gimp 2.10 question
On Tue, Dec 18, 2012 at 4:09 PM, jEsuSdA 8) wrote: Personally, and this is just a speculation, I think we'll be lucky if we'll have 2.9.0 by April 2013. 2.9 will brings the new 16bit, 32bit, etc. color modes? Yes, 2.9, whenever it's out, will bring 16/32 float/integer modes. I'd rather call it precision level, though :) People usually mean a different thing when they say color mode (e.g. native work in LAB color space). 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] Flip Tool (Gimp 2.9) [BUG]
On Tue, Dec 18, 2012 at 4:25 PM, Paul Geraskin wrote: Hi cool devs! I found a bug with the flip tool (Shift+F). If I flip horizontally this image i'll get buggy results: http://i.imgur.com/rXQbf.png Image source - http://dl.dropbox.com/u/26887202/blender/ee.png Linux 64 bit, gimp 2.9 git. Confirmed. This is most likely related to unfinished work on GEGL by Nicolas. 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] Help with a Gimp 2.10 question
El 18/12/12 13:27, Alexandre Prokoudine escribió: On Tue, Dec 18, 2012 at 4:09 PM, jEsuSdA 8) wrote: Personally, and this is just a speculation, I think we'll be lucky if we'll have 2.9.0 by April 2013. 2.9 will brings the new 16bit, 32bit, etc. color modes? Yes, 2.9, whenever it's out, will bring 16/32 float/integer modes. Thank you, Alex. ;) I'd rather call it precision level, though :) People usually mean a different thing when they say color mode (e.g. native work in LAB color space). I think I have done a very bad translation. In spanish we should call it profundidad de color, but color deep does not looks like so well, so I used color modes. I will take your precision level suggestion. ;) Salu2 de jEsuSdA 8) ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Flip Tool (Gimp 2.9) [BUG]
Indeed: Shoot me so I don't have to do it myself ;) ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Help with a Gimp 2.10 question
On Tue, Dec 18, 2012 at 02:04:09PM +0100, jEsuSdA 8) wrote: 2.9 will brings the new 16bit, 32bit, etc. color modes? Yes, 2.9, whenever it's out, will bring 16/32 float/integer modes. Thank you, Alex. ;) I think I have done a very bad translation. In spanish we should call it profundidad de color, but color deep does not looks like so well, so I used color modes. I will take your precision level suggestion. ;) Color depth is the normal term in English. -- Matthew Miller mat...@mattdm.org http://mattdm.org/ ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Flip Tool (Gimp 2.9) [BUG]
On Tue, Dec 18, 2012 at 5:57 PM, Nicolas Robidoux wrote: Indeed: Shoot me so I don't have to do it myself ;) Where's the fun in that? :) 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] Help with a Gimp 2.10 question
El 18/12/12 14:57, Matthew Miller escribió: Color depth is the normal term in English. Thank You Matthew... my english is so terrifying, hahaha. ;) ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Flip Tool (Gimp 2.9) [BUG]
Actually, it's almost certainly not me: Bug is there using bleeding edge git GIMP together GEGL with the last commit made before I jumped back in, namely fa80fb559b66ab80f5e6f63edb621e642f006862, dated 2012-11-13 Also, the reflection self-tests done with gegl from xml come out good. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Help with a Gimp 2.10 question
On Tue, Dec 18, 2012 at 04:38:01PM +0100, jEsuSdA 8) wrote: Color depth is the normal term in English. Thank You Matthew... my english is so terrifying, hahaha. ;) Well, it's better than my Spanish by a long shot! -- Matthew Miller mat...@mattdm.org http://mattdm.org/ ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Help with a Gimp 2.10 question
* jEsuSdA 8) lis...@jesusda.com [12-18-12 11:39]: Hi Gez! Great opinion and nice data. As I suppose, maybe Photivo will be the chosed. Darktable will be fine, but there are no Windows version at the moment. Being crippled by windows is not the end. You can always install a linux distro into a virtualbox (all free apps) and run photivo/darktable there. -- (paka)Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.orgPhoto Album: http://wahoo.no-ip.org/gallery2 http://en.opensuse.org openSUSE Community Member Registered Linux User #207535@ http://linuxcounter.net ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
[Gimp-developer] Exposure Operation
Hi all, I post this at the gimp-dev list cause I think more people read here and this is closely related to the progression of the Gimp Application itself, even if the core of all is GEGL. Being excited about the new high-bit depth capability I wrote an exposure operation. It is somehow inspired by the equal-named photoshop operation. A short explanation for anyone not that familiar with the use of it: This operation is mainly important for manipulating hdr images, i.e. floating point images containing values 1. Working with such images, most of the well-known operations (e.g. curves) doesn't work at all or at least don't really make sense as they are based on the assumption the image is in an absolute 0..1/black-white domain. The exposure operation has three components, that are applied in the following order: Exposure: a multiplier, the usual way to manipulate a hdr images' brightness. This is implemented as a relative change, i.e.in a logarithmic way (like f-stops) Offset: a constant value added, this can be used to shift the black-level Gamma: gamma-correction. In this case used to influence the mid-range values To summarize the components of the operation: out_val = in_val * (2^exposure) out_val +=offset (clamp value to 0.0 because might have become negative) out_val = out_val^(1/gamma) Some more reading: http://www.earthboundlight.com/phototips/photoshop-cs2-exposure-adjustments.html http://www.francois-tarlier.com/blog/exposureoffsetgamma-photoshop-tool-to-shaders/ This is one of my first things in gegl, so some questions came up, also some issues ihmo worth a discussion: As result values are not clamped in the positive direction, some thoughts about the parametersthat are worth thinking about: Gamma parameter is restricted to a range of 0.01 to 10 for now.Some confusion came up about gamma calculation, cause I am sure gamma is pow(value, 1/gamma), but e.g.gegl:gamma operation use it without the inversion, also some other applications. Gain is not restricted for now, but cause it's exponential values get pretty high, soon exceeding MAX_FLOAT. In Photoshop, pixel values seem to be generally clamped to a value of 20 (or is just the palette no able to display more?) which seem a little bit to restricted to me. Especially in case of sunny day images (e.g. HDRI Sphere for cgi rendering). With negative offset values, negative pixel values may occur. This is normally not wanted and in some cases the reason certain filters are not suited well for hdr images. Values are getting clamped at 0.0 atm, but I cannot say that I am glad with that. Any suggestions on that? For my own interest I implemented this thing both as a gegl meta-operation and as a GeglOperationPointFilter operation. Apart from the fact, that doing things like pow(2, value) is already kinda wicked in a GEGL graph, I was really asking myself if the meta operation makes any senseat all speed-wise. Because this contains 5 to 6 nodes (without i/o). Next thing for me is to make the main code use vectorization. Codeis here: http://pastebin.com/xYQYYXqX http://pastebin.com/Rq5HWhbF thanks for your interest Felix(aka. kjaft) ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Flip Tool (Gimp 2.9) [BUG]
On Tue, 2012-12-18 at 16:25 +0400, Paul Geraskin wrote: Hi cool devs! I found a bug with the flip tool (Shift+F). If I flip horizontally this image i'll get buggy results: http://i.imgur.com/rXQbf.png Image source - http://dl.dropbox.com/u/26887202/blender/ee.png Linux 64 bit, gimp 2.9 git. Thanks Paul, please file a bug about this, and attach the example image. --mitch ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Help with a Gimp 2.10 question
El 18/12/12 14:28, Paka escribió: * jEsuSdA 8)lis...@jesusda.com [12-18-12 11:39]: Hi Gez! Great opinion and nice data. As I suppose, maybe Photivo will be the chosed. Darktable will be fine, but there are no Windows version at the moment. Being crippled by windows is not the end. You can always install a linux distro into a virtualbox (all free apps) and run photivo/darktable there. +1 Pascal de Bruijn used to compile a custom Ubuntu LiveCD with bleeding edge Darktable. I'm not sure if he still does, and I don't know is they also include GIMP, Photivo or any other photo processing/retouching application. Fedora has a custom design spin with graphics software and there are other distros with liveCDs with plenty of graphics packages. I'd avoid windows. Although it's a system with a huge userbase (this also applies to free software for graphics), the performance and DE experience is generally inferior than gnu/linux's. Apart from that, most of the windows installs you'll find are 32 bit, which is likely to be insufficient for high resolution image processing. Gez. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Exposure Operation
This looks good. The meta-op isn't really the right way to do things like this, so feel free to trash that. As for the point filter, you should make a git commit, and then use git format-patch to make a patch. Then, you can get your patch included in GEGL by either bothering people on irc to review the patch (that's the fastest), or filing a bug report. The gamma value thing is just a matter of convention - if you apply a gamma of x, then applying a gamma of 1/x will undo the change. I'm not sure which is preferred (avoiding taking the reciprocal should have slightly more numerical precision, and avoid dividing by zero.) You might want to discuss vectorizing your ops with mitch or pippin before you put a lot of work into it. If it decreases portability, it might be better to leave the code as is and hope the compiler autovectorizes. If you have any questions/comments, feel free to hop on IRC and ask. -- drawoc On Tue, Dec 18, 2012 at 3:03 PM, Felix Ulber f.ul...@web.de wrote: Hi all, I post this at the gimp-dev list cause I think more people read here and this is closely related to the progression of the Gimp Application itself, even if the core of all is GEGL. Being excited about the new high-bit depth capability I wrote an exposure operation. It is somehow inspired by the equal-named photoshop operation. A short explanation for anyone not that familiar with the use of it: This operation is mainly important for manipulating hdr images, i.e. floating point images containing values 1. Working with such images, most of the well-known operations (e.g. curves) doesn't work at all or at least don't really make sense as they are based on the assumption the image is in an absolute 0..1/black-white domain. The exposure operation has three components, that are applied in the following order: Exposure: a multiplier, the usual way to manipulate a hdr images' brightness. This is implemented as a relative change, i.e. in a logarithmic way (like f-stops) Offset: a constant value added, this can be used to shift the black-level Gamma: gamma-correction. In this case used to influence the mid-range values To summarize the components of the operation: out_val = in_val * (2^exposure) out_val += offset (clamp value to 0.0 because might have become negative) out_val = out_val^(1/gamma) Some more reading: http://www.earthboundlight.com/phototips/photoshop-cs2-exposure-adjustments.html http://www.francois-tarlier.com/blog/exposureoffsetgamma-photoshop-tool-to-shaders/ This is one of my first things in gegl, so some questions came up, also some issues ihmo worth a discussion: As result values are not clamped in the positive direction, some thoughts about the parameters that are worth thinking about: Gamma parameter is restricted to a range of 0.01 to 10 for now. Some confusion came up about gamma calculation, cause I am sure gamma is pow(value, 1/gamma), but e.g. gegl:gamma operation use it without the inversion, also some other applications. Gain is not restricted for now, but cause it's exponential values get pretty high, soon exceeding MAX_FLOAT. In Photoshop, pixel values seem to be generally clamped to a value of 20 (or is just the palette no able to display more?) which seem a little bit to restricted to me. Especially in case of sunny day images (e.g. HDRI Sphere for cgi rendering). With negative offset values, negative pixel values may occur. This is normally not wanted and in some cases the reason certain filters are not suited well for hdr images. Values are getting clamped at 0.0 atm, but I cannot say that I am glad with that. Any suggestions on that? For my own interest I implemented this thing both as a gegl meta-operation and as a GeglOperationPointFilter operation. Apart from the fact, that doing things like pow(2, value) is already kinda wicked in a GEGL graph, I was really asking myself if the meta operation makes any sense at all speed-wise. Because this contains 5 to 6 nodes (without i/o). Next thing for me is to make the main code use vectorization. Code is here: http://pastebin.com/xYQYYXqX http://pastebin.com/Rq5HWhbF thanks for your interest Felix (aka. kjaft) ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
