Re: [Gimp-developer] Isn't this behaviour unintuative?
On 06/26/2011 09:22 AM, Jeremy Morton wrote: The thing is, if I go about it a different way and export another file to overwrite that file, I'm using the export function. Each time I then press ctrl+E, I'm overwriting that file again and again, without even a prompt. I don't see a meaningful difference between this workflow, and that of importing/editing/exporting. Yes, it's going to take some getting used to. However, the HUGE benefit of the new Export functionality is that you will not have to repeatedly specify/confirm the settings of the file format you wish to save to. In the old version hitting Save was very general-purpose. As a result you would have to confirm two or sometimes three (Are you sure you want to overwrite that file?) dialog windows to save a file. For someone like a web developer/designer, especially working through iterations on one design project, the new approach is a big time-saver. Now if only the Save for Web dialog would remember the destination folder from save to save Jason Simanek ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Fwd: Re: Isn't this behaviour unintuative?
On 06/26/2011 09:31 AM, SorinN wrote: He doesn't know that Ctrl + Shift + E bring to you the Export Dialog where you can choose your different filename AND / OR different extension. I have to admit, I'm constantly getting tripped-up by that. Is there any reason that the FIRST time you hit Ctrl + E couldn't do the same thing as Ctrl + Shift + E rather than _nothing_? Or at least bring up a dialog asking the user if that is what they'd like to do? ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] file-psd-save plug-in should embed a color profile
On Fri, May 6, 2011 at 10:39 AM, Mukund Sivaraman m...@banu.com wrote: Verify this file has a proper sRGB profile: https://mukund.org/tmp/PDI-sRGB.psd Just opened this file in Adobe Photoshop CS4 for OSX and can confirm that the sRGB color profile seems to have been embedded in the file. -Jason Simanek ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] file-psd-save plug-in should embed a color profile
On Fri, May 6, 2011 at 9:13 AM, Joao S. O. Bueno gwid...@mpc.com.br wrote: I think that an important next step is to get people to indepently test the files generated with this patch working, to see if its working fine. I say that since most GIMP developers won't have easy access to a Photoshop to test the generated files. I have access to Photoshop CS4 at work. Would I need to install the developer branch of Gimp to test? Or I could test files created by somebody else. -Jason Simanek ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] scanner support should be File-Acquire
I personally think File Import Scan or File Import from Device Scanner would make the most sense. 'Acquire' isn't really a common word that I hear being used in association with images, graphics, typesetting, etc. Not in the U.S.A. anyway (for the U.S. perspective on word choice, if anyone cares). 'Acquire' is certainly used regularly over here, but not in this context in my experience. I was a little thrown off by the use of 'Create' in the Gimp menu myself, as a professional graphic designer. It took me a bit to figure it out. 'Create' to me suggests that the children of that menu all refer to making new documents. Using Photoshop every day for 15 years has perhaps tainted the validity of my opinion. -Jason Simanek On Wed, Aug 25, 2010 at 1:23 AM, Jim Michaels jmich...@yahoo.com wrote: newbies who are using GIMP are always asking where is the scanner support. why? because they can't find it. File-Create is not intuitive, nor does it imply anything about scanners. File-Acquire would be more appropriate. maybe even File-Scanners if you want to be obvious (which is even better!). but I can tell you from a thought process and human usability standpoint that grouping it under File-Create makes no rational, reasoning sense. at least keep the scanner stuff separate and make it obvious that it's for scanners. scanners are I think a very important part of any imaging tool, and deserve direct access, and even warrant a button. Jim Michaels jmich...@yahoo.com j...@jimscomputerrepairandwebdesign.com http://JimsComputerRepairandWebDesign.com http://JesusnJim.com (my personal site, has software) http://DoLifeComputers.JesusnJim.com (group which I lead) --- Computer memory/disk size measurements: [KB KiB] [MB MiB] [GB GiB] [TB TiB] [10^3B=1000B=1KB][10^6B=100B=1MB][10^9B=10B=1GB][10^12B=1B=1TB] [2^10B=1024B=1KiB][2^20B=1048576B=1MiB][2^30B=1073741824B=1GiB][2^40B=1099511627776B=1TiB] Note: disk size is measured in MB, GB, or TB, not in MiB, GiB, or TiB. computer memory (RAM) is measured in MiB and GiB. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp UX: Paste
On Thu, Jun 3, 2010 at 8:21 AM, peter sikking pe...@mmiworks.net wrote: Gino D wrote: as I said yesterday, this new-layer-from-clipboard workflow needs attention too. user efficiency (speed!) and flexibility are important here. one aspect (as Gino points out) is default placement of the paste on the new layer. I've already switched my keyboard shortcut Ctrl+V to be associated with 'paste as new layer' rather than the 'pasted selection' that is default. This works almost right but... but in the majority of cases it will be in the 'wrong' position and it needs to be moved to be 'right'. Paste to new layer currently pastes the copied pixels in the top-left. I think Gino suggested that it be changed to 'centered'. It sounds like you are saying it should be pasted to the exact location where it was copied from. I agree. The pasted pixels should end up exactly where I copied them from. sounds like the solution is actually to have the new layer appear with the paste anchored in the default position, but with a selection around it active (same shape as used for floating paste) and the upcoming combined transform tool as active tool for moving, sizing and deforming. Not sure about this. I actually think the selection should be removed. When you copy/paste text in a text editor the pasted result is just text, not 'selected' text. Besides, if the pasted result is on a new layer there should be no need for a selection. The entire layer is dedicated to the previously selected pixels, so you should be able to manipulate the layer without the need for the initial selection. -Jason Simanek ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp UX: Paste
Gino, On 06/02/2010 06:12 AM, Gino D wrote: 2010/6/2 Jason Simanekjsima...@gmail.com: A new layer is non-destructive. Why is there a need for this other type of layer? The name 'floating selection' isn't even accurate. This is a collection of pixels. It is not a selection. A selection is an ephemeral mask not a collection of specific pixels. Until some time ago, I also doubt the usefulness of this kind of layer. Recently, however, I discovered that the floating selections can be really handy, especially when they are put into action within the scripts. Thanks for pointing out the usefulness of floating selections for scripting/plugins. That makes a lot of sense. But if that is the only usefulness for this special type of layer I think it should be a special behavior that can be employed by script and plugin writers, not the default in the GUI. What Gino just told me is that the floating selections are a special type of layer whose special properties can only be perceived or employed by scripts. How would a normal mouse-user derive any usefulness from the qualities of this special layer? In this case it seems the interest in making Gimp scriptable has overridden the interest in making Gimp's UI intuitive. -Jason Simanek ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Gimp UX: Paste
Hi, Has there been any discussion about doing away with the 'floating selection' quasi-layer that occurs after copy/pasting in Gimp? I don't mean to compare the Gimp to Photoshop, but it seems like this is a place where Photoshop does the right thing: when graphics are copy/pasted a new layer is created. In my experience the floating selection quasi-layer has little or no usefulness. A new layer is non-destructive. Why is there a need for this other type of layer? The name 'floating selection' isn't even accurate. This is a collection of pixels. It is not a selection. A selection is an ephemeral mask not a collection of specific pixels. What would be best, I think, is that a new layer would automatically be created after pasting and that this new layer, rather than appearing at the top of the layer stack, would be created directly above the currently active layer. While I'm at it I also recommend that layer boundaries should be disposed of. They only add confusion. A layer should be apparently without dimension and should be masked only by the canvas. The current way of doing things is confusing. If a boundary smaller than the canvas is desired a layer mask should be used. Currently I am confused about the relationship between layer boundaries and layer masks. They seem to be the same thing. Thanks for listening. If a discussion about these issues has already taken place, please provide URLs to those discussions. I have no intention of reopening discussions that have already been resolved. Jason Simanek ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Color space support
On 05/07/2010 06:13 AM, Cristian Secară wrote: On Fri, 7 May 2010 12:24:19 +0200 (CEST), Easyword wrote: - GIMP supports only RGB color space This is a limitation, which prevents the use of the software in professional use. You may use GIMP to create graphics for professionals, but you may not receive any professional graphics. It depends what „professional” for you means. I am working in television/video area, where all graphics are in RGB (sometimes with additional key channel (alpha)). For me the CYMK color space is of no use (and I get in trouble when someone gives some color specifications in non-RGB values). As a professional graphic designer I think that there's a real lack of understanding about color spaces among graphic designers. I know lots of designers that do color corrections in Photoshop with an image in CMYK color mode. In fact they do everything in CMYK mode if they open Photoshop at all. Unless you are creating a graphic that is intended to specifically match a printed color, this method of working in CMYK is unnecessary and ill advised. The belief that working with photographs in CMYK mode is 'professional' and more color accurate is wrong. An image should only be translated to CMYK mode once it's finished and ready to go to press. And that translation needs to happen in a color managed process. The CMYK mode in Photoshop is merely an estimation of the CMYK color space. It understands the gamut of CMYK but the representation of those colors on the screen is an estimation dependent on a calibrated display and fully color managed workflow. After all, your display renders colors in RGB. It's much more important to work in a color managed environment. I've worked with many, many 'professional' designers that have very little or no understanding of color profiles or color management. I've even seen them discard the color profiles of images when they open them in Photoshop. That was actually the recommended practice at a magazine I worked at. Unbelievable. Don't believe it? I still can't believe it. Of course, this is all anecdotal. I don't mean to start a flame war. My point is that Gimp is not Photoshop. A lot of folks give Gimp a try and frequently criticize Gimp for not being a complete clone of Photoshop. Granted, Photoshop is a great tool in many ways and a good ruler for Gimp to measure itself against. But assuming that Photoshop is infallible and that every aspect of it is sacrosanct is a mistake. The developers are addressing aspects of Gimp that they find useful and interesting. The CMYK color mode is complex I'm sure, mostly due to all of the color estimation that is needed to display the mode on screen (as mentioned above). Alexia is right. This is building things from scratch. And we do have the Separation plugin to export to CMYK. But no, Gimp does not have the safety blanket of CMYK color mode to give graphic designers the assurance that their colors look right (even if the accuracy of those colors is an estimation dependent on a color managed and calibrated display). Gimp CAN be used to create professional graphics. You can also make professional graphics with printed photos, rubylith, paste, pens, ink, lead type and paper. Both of these approaches are dependent on the creator having a certain level of knowledge about the printing process. The trouble that most contemporary designers have when it comes to creating professional graphics with the Gimp (and Inkscape, Scribus, etc.) is due to their lack of knowledge. That's not an insult. They're just used to working with a lot of programs that handle most of the technical details that graphic designers and prepress workers needed to know in the past. These open source programs, as great as they are, just aren't entirely to that point yet. One of the big reasons that they aren't to that point is because they are developed by very smart people that only need the program to take the project to a certain point. The other reason is that most of the developers are not professional graphic designers. Along with that, most professional graphic designers know very little about programming. If graphic designers want great open source tools that meet their needs, they're going to have to start contributing to the projects. That's what I've been trying to do. You got to put your money (or time and effort) where your mouth is. Thanks for listening. -Jason Simanek ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Color space support
On Fri, May 7, 2010 at 1:49 PM, Chris Mohler cr33...@gmail.com wrote: As long as they insist on CMYK artwork, CMYK mode is a necessary evil. I guess I thought Separate+ handled that necessary evil. But I don't use it myself, so it might be pretty sketchy. But this has all been discussed in depth on this list, and once gegl is fully integrated we'll have all the tools needed for a managed workflow, and also the necessary evil of CMYK mode :) Yes, indeed. Thanks, Peter, for the URL of your post discussing the plan for addressing CMYK and other color mode outputs. That sounds beautiful. -Jason Simanek ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [Fwd: GTK+ 2.20.0 released]
On 03/25/2010 01:00 AM, saulgo...@flashingtwelve.brickfilms.com wrote: The mnemonics are unrelated to GIMP's keyboard shortcuts (which will still be visible in the menus, unless the user has specified otherwise in his gtkrc). Wait. I thought they were using the word 'mnemonics' to mean what is commonly called 'shortcuts'. I see now that what was meant by 'mnemonics' was the underlined letters in menu items. As I understand it, these underlined letters are only useful if you are navigating the menus via keyboard. Well, making those visible only when navigating the menus by keyboard makes sense. Pardon my confusion. The UI-world use of the words 'mnemonic' and 'shortcut' seem confusing to me, since the functionality of the two in this case is very similar. I would call that a misuse of the word 'mnemonic'. But this isn't a debate about language use. Advanced users will learn to avail themselves of such optional conveniences without requiring prompting from talking paperclips or animated walkthroughs, and the neophytes are better off not being confronted with the additional complications. I don't think that philosophy applies to the presence of keyboard shortcuts next to the names of menu items. These subtle bits of additional information are a different species than talking paperclips. One is helpful but not intrusive. The other is condescending and intrusive when on by default. In my experience 'neophytes' or non-expert users don't even notice that the shortcuts are there. I have people at work that supposedly work on computers every day that don't know the keyboard shortcuts for copy/paste. For some it seems the GUI is filled with lots of small details that they don't comprehend, so they just ignore those details and continue working to the highest level of efficiency that they are capable. -Jason Simanek ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [Fwd: GTK+ 2.20.0 released]
On 03/24/2010 03:21 PM, Karl Günter Wünsch wrote: On Wednesday 24 March 2010, Alexandre Prokoudine wrote: On 3/24/10, Karl Günter Wünsch wrote: This is ludicrous - how would anyone trying to use the keyboard learn the different mnemonics available? This is default behaviour on Windows. Which is the first thing I disable on any Windows installation I do and the users are happy about that. The shortcuts should definitely be shown while using the mouse. Who came up with this idea? I know this isn't the GTK+ mailing list, but seriously, how is this an improvement? Were the drop down menus getting too wide with the included shortcuts? Were they interfering with legibility? Why are they trying to fix problems that don't exist? What percentage of users navigate the menus via keyboard? To me beginners use the mouse to navigate the menus. Experts use keyboard shortcuts. People that are unable to use the mouse use the keyboard to navigate the menus until they learn the shortcuts. It is very awkward for me to learn the keyboard shortcuts if they aren't visible during mouse navigation. I never use the keyboard to navigate the menus. Just my two cents. -Jason Simanek ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP distributing sRGB profiles: license issues?
On 03/10/2010 02:37 AM, Sven Neumann wrote: Some file formats, such as PNG for example, allow to tag the file to be in a particular well-known color space. The color profile is not embedded then, it is assumed to be well-defined. Instead of distributing the profile with the image file, there is just a flag saying this data should be interpreted as sRGB. Ah, so the color problems I am having with images created by Gimp are due to the PNG files being 'tagged' as sRGB. The color profile isn't embedded to the image, it's just specified and, since it's a well known color profile, any program that attempts to display the image will do so as though the PNG had an embedded sRGB profile. Thanks for pointing that out. To summarize: Tagging is great because it specifies a color profile without increasing the image file size. Assuming that the destination system applies the correct profile. Embedding is great because you have greater flexibility for an endless variety of custom color profiles. The end result of the two is the same though: the image will be color managed. -- As for gballard's recommendation for not including color profiles in web images: He's only saying that because his ultimate goal is color consistency across all platforms/browsers. I, as a professional web designer, think he's right when it comes to page element images that are intended to match colors defined in HTML or CSS. Otherwise all of the Safari users that visit your site are going to doubt your design capabilities. For photographs I think it's fine to include color profiles. Browsers that don't color manage are going to show you the same limited gamut either way, but browsers that DO color manage will display an enhanced image with a wider gamut of colors. Progressive enhancement. You do have to also keep in mind that profiled/tagged sRGB and un-profiled/un-tagged RGB images will display differently in color managed browsers/environments. The assumption that Gimp currently makes (for historical reasons, explained by Sven previously) about 'assigning sRGB color profile' being the same as 'having no color profile' is misleading. -Jason Simanek ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP distributing sRGB profiles: license issues?
On Wed, Mar 10, 2010 at 11:31 AM, Alexia Death alexiade...@gmail.com wrote: Problem is not serving different content. Problem is making content that works for those, and ultimately for all browsers. So your suggestion misses the point. The point is need to create images that are not color managed or rather are managed as browser sees fit. Right. I don't think client sniffing is very efficient and probably more complicated than needed. The 'progressive enhancement' approach is much more pragmatic and one that is employed with other web development features like CSS and JavaScript. There are times when you have to work with the lowest common denominator (web page image elements that need to match HTML and CSS colors) and others where progressive enhancement allows you to provide additional features/functionality without negatively affecting visitors that aren't using the latest browsers (photographs with color profiles). -Jason Simanek ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Option to save images without embedded ICC profile
On 03/04/2010 02:14 AM, Sven Neumann wrote: The point of the current behavior is that you need to make an assumption if no profile is attached to an image. Otherwise you could not even display this image. Without a color profile or an assumption about the meaning of the RGB values it's just numbers. It's really unfortunate that the one color space that Gimp actually uses is sRGB, which has a fairly limited gamut (as I understand it). Of course, since it's the default color space of computer displays, sRGB makes perfect historical sense. But if it were instead something like Adobe RGB, Gimp would probably be pretty respectable as long as it color managed the transition from whatever original color space an image was in to the native wide-gamut RGB. And the export would work the same. In that situation the wide-gamut RGB would most likely be able to preserve all/most existing color variations in any image. Sven, thanks for explaining the reality of color management in Gimp. Is somebody on the team already working on this or in this direction? Is there anything a non-programmer can do to contribute to this color management problem? Or is it just a matter of waiting for the developers to move all of Gimp over to GEGL's way of doing things? -Jason Simanek ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Option to save images without embedded ICC profile
On 03/04/2010 05:58 PM, Patrick Horgan wrote: On 03/03/10 11:19, Jason Simanek wrote: That's not true in my experience. Yes, sRGB should be as good as NOT having a profile since sRGB is the ASSUMED color space on most computersy. But Gimp still adds a color profile to the image: an sRGB color profile. This still causes all of the color mismatch problems on websites thoroughly described on the gballard.net site mentioned above. Now I'm confused I thought gballard said the opposite. Here's how it works: 1 Web Browsers That Don't Support Color Management With these browsers images that do or don't include color profiles is irrelevant because they can't do anything with them anyway. The colors are just displayed as whatever RGB color space is available, most likely some form of unmanaged sRGB. 2 Safari (Browsers that ONLY color manage images with color profiles, not colors defined in HTML or CSS) If a color profile is included with an image Safari uses color management to adjust the colors to the computer's display color space. If a color profile is not included it acts like #1. Also, as far as colors defined in HTML and CSS, it acts like #1. 3 Firefox 3.2+/3.5+ by default (Browsers that color manage images with color profiles. Images without color profiles are also managed assuming the sRGB color profile. PLUS: Colors defined in HTML and CSS are managed with assuming the sRGB color profile. What this means for web designers/developers: A #1 isn't a problem unless you want color managed photos that look beautiful on your website. Otherwise, #1 is the way web browsers have generally worked until recently. B #2 is the wrong way to do color management on the web. It's a nice effort and photos certainly look beautiful, but this approach causes big problems for web designers that want to use images for page elements that are intended to exactly match and blend with colors on the web page that are defined in HTML or CSS. This approach forces web developers to NEVER include color profiles on images that are part of a website's design, otherwise the page elements won't match the colors defined in HTML/CSS. At least not in Safari. It'll look perfect everywhere else. C #3 is the right way to do color management. It makes color profiled photographs look as close to the creator's intentions as possible on any computer system that is color managed. But it also allows web designers to use color management to make their page element images look as good as intended while still matching the HTML/CSS colors that are also part of the web page. Thanks to browser type #2 I can only use color profiles on images that are not intended to be a part of the web site's design. If I do include color profiles on those images, every time I bring up the site in Safari it will look like my page elements don't match the flat colors defined in my site's HTML/CSS. So the color mismatch I'm concerned about really only happens in Safari, but mismatches like that are not acceptable. Did that resolve your confusion? Or just add to it? -Jason Simanek ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Option to save images without embedded ICC profile
Hello, Apparently I was supposed to discuss any potential new features with the developer mailing list prior to filing a bug. Sven Neumann pointed this out to me. Thanks Sven. https://bugzilla.gnome.org/show_bug.cgi?id=610944 For web designers it is essential to have the option to either include or exclude color profiles on images that are created with Gimp. It would be great to have a checkbox on the save/export dialog or the Save for Web plugin dialog that would allow you to exclude the color profile. Sven suggested I just 'unset the color profile' on the image, but the option doesn't seem to exist. I'm running Gimp 2.6.7 on Ubuntu Karmic 9.10. Under File Image Mode I have the options 'Assign Color Profile' and 'Convert Color Profile'. Neither of these gives me the option to 'unset the color profile'. If the option isn't available next to these color profile options, what is the next logical place for that option to be located? Adding it to the Save for Web plugin (why else would you NOT want a color profile included?) makes sense to me because that is the least destructive way to do such a thing. This is in line with your recent changes to 'Save' being non-destructive and 'Export' representing the act of saving images to 'destructive' formats/settings. I think this is similar to the act of switching from RGB colorspace to indexed colors. Sure, you can do it on the document itself, but suggesting that that is the best approach is disregarding the real world workflow of producing images for the web. On the other hand, is it possible that Ubuntu has mucked up something here? Scribus likes to point the finger at Ubuntu a lot. This option to 'unset the color profile' might exist, but doesn't on Ubuntu for some reason? I apologize if I'm missing something obvious, but I've looked all over and the online manual doesn't mention this and I can't even find a blogger talking about the subject. All of the literature just assumes that color management and including color profiles in images is always the desired route. It SHOULD be, but this isn't a perfect world and the web certainly has a long way to go before all browsers support color profiles consistently. Your patience and guidance is much appreciated. Sincerely, Jason Simanek ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Option to save images without embedded ICC profile
Hope my message didn't add too much of a stir. yahvuu's proposal does indeed encompass the small feature that I was requesting as well as other features that sound excellent. On Wed, Mar 3, 2010 at 12:14 PM, Jay Smith j...@jaysmith.com wrote: Here is a great reference site exactly on this subject http://www.gballard.net/psd/go_live_page_profile/embeddedJPEGprofiles.html For people like me, I recommend reading it thoroughly AND following all his links. It does go on a bit, but there are many pearls in it. Too bad he does not seem to talk about Gimp, but the content is still great. For the issues that I'm concerned with (I'm a professional web designer/developer) skip to the part titled ANOTHER PROBLEM with Embedding ICC Profiles: on the gballard.net page linked to by Jay Smith. That's problem I'm dealing with that forces me to open certain Gimp-created images in Photoshop in order to strip out the color profile. Gballard doesn't mention that Firefox, when its color management is enabled, actually does website color management correctly, since it applies color profiles to both images and HMTL/CSS-defined colors. But that really doesn't affect the discussion as it pertains to Gimp. And besides, Firefox's color management is not enabled by default. Sven says: You assign the sRGB profile. That is equivalent to un-setting the color profile. That's not true in my experience. Yes, sRGB should be as good as NOT having a profile since sRGB is the ASSUMED color space on most computersy. But Gimp still adds a color profile to the image: an sRGB color profile. This still causes all of the color mismatch problems on websites thoroughly described on the gballard.net site mentioned above. -Jason Simanek ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Option to save images without embedded ICC profile
Below is a response I wrote, but accidentally only sent to Sven. -JS On Wed, Mar 3, 2010 at 1:42 PM, Sven Neumann s...@gimp.org wrote: On Thu, 2010-03-04 at 06:22 +1100, Graeme Gill wrote: Sven Neumann wrote: You assign the sRGB profile. That is equivalent to un-setting the color profile. If it actually does this, it's being highly un-intuitive. Assigning an sRGB profile would normally be expected to tag a file with sRGB, not at all the same thing as having no assigned profile. Untagged files are assumed to be sRGB [. . .] This is surely far from ideal, but that's the current situation and it is not likely to change before everything is fully ported to GEGL. I agree with Graeme. I will have to check if what you are saying is true. I don't actually believe that I tried that because what you described as the result of an action that is titled 'Assign Color Profile' doesn't make any sense. That's pretty much lying to the user and assuming the difference is irrelevant. Not to mention, if that function was properly titled I wouldn't have started this conversation. I understand that color management is complicated and probably not worth completely implementing until Gimp fully employs GEGL, but I think changing the menu so that File Image Mode Assign Color Profile sRGB ACTUALLY applies the selected sRGB color profile to the image and something like File Image Mode Remove Color Profile would discard any color profile associated with the image would be a simple change that would be a huge improvement to Gimp's user interface. Thanks for pointing this behavior out. -Jason Simanek ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
