Re: [Gimp-developer] Possible approach for some non-sRGB GEGL/GIMP color workflows
On 05/24/2014 01:26 PM, Øyvind Kolås wrote: I've been thinking about how different color-space aware workflows could work in our future GEGL powered GIMP. In particular about the on-going theme of how to deal with slight HDR images, that have a gamut including colors that are slightly outside the 0.0-1.0 range for linear sRGB. I'm not sure what you mean by 'slight HDR images, that have a gamut including colors that are slightly outside the 0.0-1.0 range for linear sRGB'. Converting a display-referred ProPhotoRGB image that has colors that exceed the very small bounded sRGB color gamut, from ProPhotoRGB to unbounded mode sRGB, doesn't create a slight HDR image. The dynamic range of the display-referred ProPhotoRGB image colors doesn't change when the image is converted to unbounded mode sRGB. Just the chromaticities used to encode the RGB data change. In the unbounded mode sRGB color space the relationship between channel values and intensity is broken. The resulting image is neither display-referred nor magically made into high dynamic range scene-referred. See Unbounded mode sRGB is neither display-referred nor scene-referred, http://ninedegreesbelow.com/gimpgit/unbounded-srgb-display-scene-bounded.html The primary goal will still be adapting channel displays; histograms etc. to encompass/translate to show the 0.0 and 1.0 values; in relation to a defined target/output profile. A hybrid linear-centric approach might also work well. Is the target/output profile to which you are referring the *source* profile, meaning the ICC profile that the image was in before it gets forcibly converted to unbounded mode sRGB? Or is the target/output profile the ICC profile to which the user intends to eventually convert the image, such as perhaps a printer profile? What do you mean by hybrid linear-centric approach? If we on import linearise the data (using the RGB primaries of the source color space), and then scale values down based on the magnitude of the most intense primary, and pretend that the resulting data is RGBA float; there will neither be cross component contamination nor out-of-ui-range values. If you are talking about scaling the data so that any possible color in the source color space would fit into the very small bounded sRGB color gamut, that a pretty large scale factor for ProPhotoRGB. I have not done actual experiments - to see the impact doing this would have on the visual result, I did an experiment. I downloaded Bruce Lindbloom's RGB16Million test image (http://brucelindbloom.com/index.html?RGB16Million.html), bumped the precision to 32-bit floating point, assigned the regular gamma=1.80 ProPhotoRGB ICC profile, and converted the image to linear gamma ProPhotoRGB. Then I set Preferences/Color Management/Mode of operation to Print simulation, set the Print simulation profile to a linear gamma sRGB profile, and chose Mark out of gamut colors. Then I used Levels and moved the Output lower and upper sliders to 33.00 and 67.00, which just made the out of gamut colors disappear. The image was very desaturated with the dynamic range cut to a third. Repeating the same procedure with actual images likewise produces extremely desaturated colors. And the channel data is *still rearranged*. If you don't want to rearrange the channel data and you do want the image to be in the unbounded mode sRGB color space, you can *assign* the sRGB profile, in which case the channel data is preserved and the colors are completely wrongly interpreted. it gives up some aspect of color management - Why should people who use GIMP be expected to give up any aspect of color management? The whole point of a color-managed workflow is to be able to see the image colors to the extent that the monitor profile's color gamut allows. but deal correctly with the tone-response curves. Could you explain what you mean? I suspect the dominant side effect will be a slight loss in luminance. If there is code you would like tested or an experiment with images that you'd like to see done, but you don't have time to do the testing yourself, let me know and I'll try to do the testing for you. 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] Getting contributors via OpenHatch
Hi, On Wed, May 28, 2014 at 4:37 AM, scl scl.gp...@gmail.com wrote: Hi, lately somebody committed to [OpenHatch] spoke to me in IRC whether we at GIMP want to work with OpenHatch to gain more contributors. OpenHatch defines itself as 'a non-profit organization with the goals of lowering the barriers to entry into open source community and increasing diversity'. That's all fine, but I don't understand this barrier thing. There are already absolutely *NO* barrier to contribute to GIMP. Unless you count the quality barrier, but we are able to accompany new developers to improve to meet all quality requirements, if they are really motivated. I have a hard time seeing how another project in-between, as an additional layer, could do anything to improve things. But I may be wrong. They also teach the next generation of students on colleges how to participate in open source communities, so 'Hello, next GSOC students'. I personally think it's a great chance to get some open problems solved: To push the things a bit forward: - Can we mark some more trivial and gnome-love bugs? This would be good. - Is anybody willing to mentor some students or give a classroom presentation and if yes in which topic/area? What is this exactly about? Classroom? Are we speaking about physical classrooms? Like in university? In any case, I am now in Paris, and I am never against sharing the Free Software contribution love and lead some new developers towards us. - Are there any topics we've been putting off, neglecting or just plain avoiding? - IMHO the GEGL ports and Windows bugs need some care. Obviously. But that's always the same problem: we can't force people to work on fields they don't care about. I have myself done quite a few Windows bugs out of boredom. And I would likely do more in the future. But I definitely won't do it my priority ever, for the simple reason I have *nearly never* used Windows in nearly 10 years. The real solution is to find Windows developers who are interested in GIMP, not asking existing dev to care about an OS they don't use. This is the other way around. :-D If we have this, we can update [GIMP's and GEGL's pages there]. I'm cross-posting this message to the GIMP and GEGL developer lists, because I think also GEGL could benefit from it. Well I don't really mind people trying things. I am sceptical on using third party platform, but who knows? Maybe we'll have nice surprise. As long as it does not interfere with usual simple contribution process. Jehan Kind regards, Sven [OpenHatch]: https://openhatch.org/ [GIMP's and GEGL's pages there]: https://openhatch.org/projects/GIMP https://openhatch.org/projects/Gegl ___ 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] GIMP 2.8 on OS X fixes
Hi Sven, Am 27.05.2014 um 05:24 schrieb scl scl.gp...@gmail.com: Hi Simone, an honest thank you for your efforts. In my build I'm also patching gtk-mac-integration so this might be of your interest. The patches are in /build/osx/patches of the build-osx branch. 0002-Improve-internationalization-of-App-menu-and-other-s.patch: The current App menu implementation assumes that the application's name is at the end of the 'Hide' and 'Quit' menu item in all languages. This is grammatically incorrect for some languages, such as German. The patch inserts placeholders for the app name and fixes the translations where necessary. Fix references to the internationalization table (GtkOSXApplication) to ensure these strings are recognized at runtime. Fix broken encoding in the ro, ru, uk languages. Add language pt_BR (Brazilian Portuguese). Thank you. I’ve already included those changes in my forked version. BTW, if you convert the *strings files from UTF-16 to UTF-8 encoding, git will handle these as text and not as binary. And it will be easier to manipulate those files in shell scripts with sed, grep, cut, tr and other commands. Cocoa itself handles UTF-8 and UTF-16 encoded strings files interchangeable. 0003-Keep-separators-between-placeholders.patch: Keeps menu separators between menu placeholders. It fixes the issue that some separators got lost in the menus, for instance the one between File/Send as e-mail and File/Properties etc. yep, already done. Regards Simone ___ 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] Gimp-Perl version 2.30_05 now on CPAN
Dear Gimp Developers, The latest dev version of Gimp-Perl (2.30_05) is now on CPAN. You can take a look here: http://search.cpan.org/~etj/Gimp-2.30_05/ It has: * an autosave script (not installed by default – examples/autosave2) – will save open, changed files in its own directory, and reopen them on GIMP startup; if installed, will start as soon as GIMP starts up * a plugin registry viewer, installed by default – Filters/Browse Plug-in Registry * a Perl console, installed by default – Filters/Perl/Console This is a candidate to be released on CPAN as 2.31, so any bugs you find, please report them (look in README for how). Known problem: the test suite fails (and other problems may occur) in locales where floating point numbers are written with “,” not “.”. A fix is in the works. Currently only tested on Linux, but I would be very interested if someone would try it on Windows (take a look at README.win32 for possible ideas). Let me know what you think. All the best, Ed J ___ 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] Fwd: Gimp Registry Future
Hi Sven (and GIMP developers), 'GIMP is easily user-extendable, by ‘one-click’ installation of plug-ins.' is a part of our product-vision and as far as I remember there have already been many ideas on this topic, dating back to 2003. And now it is possible, as of Gimp-Perl 2.30_05 (http://search.cpan.org/~etj/Gimp-2.30_05/). Please take a look at http://wiki.gimp.org/index.php/Hacking:Plugin_registry which has been updated with observations from making the Gimp-Perl registry viewer (which also allows installing, currently only of script-fu scripts), and ideas for the future. Best regards, Ed J Gimp-Perl guy ___ 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
