Re: [Gimp-developer] Option to save images without embedded ICC profile
On 04/03/10 21:22, Jason Simanek wrote: ... elision by patrick... 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? No, now I get it completely. If it's a situation where you want managed and unmanaged to match, Safari is your enemy. Thanks! Patrick ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] remove layer should not force you to last selected layer
On Fri, 2010-03-05 at 20:22 +0100, Martin Nordholts wrote: On 03/05/2010 03:20 AM, Luiz Felipe Moraes Pereira wrote: Hi again, the original discussion is in the link below: https://bugzilla.gnome.org/show_bug.cgi?id=611758 I was advised to present this idea here, what do you think? Also I do not mind much about not having a selected layer after the deletion of a layer. But the forced viewer scroll down( or up ), depending of the last selected layer is a problem. To me, having the layers dialog scroll to a seemingly random place after deleting a layer is a clear usability problem. A user should not have to worry about what layer that was previously selected when deleting a layer. Perhaps the problem is just the scrolling then. GIMP could continue to select the previously selected layer, but it wouldn't have to scroll that layer into sight. It could instead just leave the list-view as it is. Sven ___ 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?
Hi, On Fri, 2010-03-05 at 07:34 +, Omari Stephens wrote: Finally, to respond to your question on the bug, we need some way to embed an actual sRGB profile into an image. Can't we just embed the lcms built-in sRGB profile? That sounds like a totally straight-forward solution. But I might have missed something. Is there a particular reason why we need the profile to exist as a file? Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] remove layer should not force you to last selected layer
On Saturday 06 March 2010 14:56:21 Sven Neumann wrote: To me, having the layers dialog scroll to a seemingly random place after deleting a layer is a clear usability problem. A user should not have to worry about what layer that was previously selected when deleting a layer. Perhaps the problem is just the scrolling then. GIMP could continue to select the previously selected layer, but it wouldn't have to scroll that layer into sight. It could instead just leave the list-view as it is. Please no. Only thing worse than selecting random(for those of us that do not remember wha layer it was that they clicked at last) item and scrolling to it is selecting the random item and not making it apparent that this was done. --Alexia ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] remove layer should not force you to last selected layer
On Sat, 2010-03-06 at 13:56 +0100, Sven Neumann wrote: On Fri, 2010-03-05 at 20:22 +0100, Martin Nordholts wrote: On 03/05/2010 03:20 AM, Luiz Felipe Moraes Pereira wrote: Hi again, the original discussion is in the link below: https://bugzilla.gnome.org/show_bug.cgi?id=611758 I was advised to present this idea here, what do you think? Also I do not mind much about not having a selected layer after the deletion of a layer. But the forced viewer scroll down( or up ), depending of the last selected layer is a problem. To me, having the layers dialog scroll to a seemingly random place after deleting a layer is a clear usability problem. A user should not have to worry about what layer that was previously selected when deleting a layer. Perhaps the problem is just the scrolling then. GIMP could continue to select the previously selected layer, but it wouldn't have to scroll that layer into sight. It could instead just leave the list-view as it is. Nope, the problem here is that we are using a mechanism that is actually meant for selecting a layer once you deleted the last channel. The MRU list of layers doesn't really make sense to use when we are dealing with layers only, since the obviously expected behavior when deleting a list/tree element is to select a neighboring element. Everybody please calm down, I plan to change things here anyway, the refactoring of the image's item trees is not over yet. stay tuned, --mitch ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [PATCH] OpenRaster: optimize PNG saving
On 02/27/2010 03:14 PM, Jon Nordby wrote: Sets lower compression and disables interlacing. On a 5 layer image of 4500x6000px this gives an order of magnitude better save-times, with 50% increase in file size. Hi Jon Sorry for the late follow-up and thanks for maintaining the ORA plug-in. 50% increase in file size is pretty significant, maybe the compression ratio should be exposed in a UI? @@ -85,7 +85,7 @@ def save_ora(img, drawable, filename, raw_filename): def store_layer(img, drawable, path): tmp = os.path.join(tempdir, 'tmp.png') - pdb['file-png-save-defaults'](img, drawable, tmp, 'tmp.png') + pdb['file-png-save'](img, drawable, tmp, 'tmp.png', 0, 2, 1, 1, 1, 1, 1) It would be nice to make 0, 2, 1, 1, 1, 1, 1 immediately interpretable, for example by commenting or using local variables like so: embed_profile = 1 function(1, # save_comment embed_profile) BR, Martin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [PATCH] OpenRaster: optimize PNG saving
On Sat, 2010-03-06 at 15:30 +0100, Martin Nordholts wrote: On 02/27/2010 03:14 PM, Jon Nordby wrote: Sets lower compression and disables interlacing. On a 5 layer image of 4500x6000px this gives an order of magnitude better save-times, with 50% increase in file size. Hi Jon Sorry for the late follow-up and thanks for maintaining the ORA plug-in. 50% increase in file size is pretty significant, maybe the compression ratio should be exposed in a UI? IMO 50% increase in file size is not much for a file format that is meant for archival and exchange of images. It's not that people are likely to use OpenRaster files on web-pages or the like. Being able to save quickly seems much more important than file-size here. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [PATCH] OpenRaster: optimize PNG saving
On Sat, 2010-03-06 at 16:35 +0100, Sven Neumann wrote: [...] IMO 50% increase in file size is not much for a file format that is meant for archival and exchange of images. Archival - it'd mean an extra 20 gigabytes to back up for one of my old books archives for example. Interchange - the difference between 100 megabytes and 150 megabytes for an image seems at the least noticeable to me, and that's for an 8bit per channel grayscale image. (I'd be using 16 bits if the tools I had supported it a little better) It's not that people are likely to use OpenRaster files on web-pages or the like. Being able to save quickly seems much more important than file-size here. I don't mind waiting 10 minutes to save a file for archiving, especially as GIMP lets me do other things in the meantime. My vote here is for exposing it in the UI, as with export to PNG, as it's clearly different for different people. Liam -- Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ Pictures from old books: http://fromoldbooks.org/ Ankh: irc.sorcery.net irc.gnome.org www.advogato.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
