Re: [Gimp-developer] Re: Re: Color Management was GEGL development/gimp integration
Hi, Gerhard Gauling [EMAIL PROTECTED] writes: Sven Neumann wrote: -displayprofile should be adjusted _once_ systemwide (every time changeable by systemwide color preferences independant from the GIMP, as used by (e.g.)scribus [1], inkscape [2], sodipodi[3] wine e.g. for Photoshop and maaybeee by commercial apps available for *nix like Page Stream [4], Cenon [5], Viva Designer [6]) with an monitor profile (like the one of l-prof or adobe-gamma etc.), there for it would be a little overwhelming to have this choice again in the opening file dialog, if the profile doesn't fits the working color space. Yes, ideally it would be configured systemwide. Not once, but once per monitor. But unless a standard exists for system-wide color management configuration, we don't have much choice but to implement our own configuration. If you can point me to such a standard, we will of course consider to adopt it. Sven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Color Management was GEGL development/gimp integration
Hi, Hal V. Engel [EMAIL PROTECTED] writes: - default cmyk-profile (is later used to convert RGB-CMYK) I guess that this is for the printer? Since all of my printers are logically RGB devices (the drivers expect RGB input) I am not sure how useful this is to me but for others it might have it's uses. But perhaps we need to understand what this will be used for before including it. I am not sure what Stefan added this for in the first place but we will need a CMYK profile to be able to implement a useful CMYK color selector. We already have such a color selector but at the moment it uses a rather naive approach of converting between CMYK and RGB. When you are in the printer dialog in GIMP you have the ability to add a new logical printer and use that to name a collection of settings you wish to remember for future use. This is the ideal place for printer profiles to be specified. So the user should be able to set the default profile and rendering intents for each logical printer along with all of the other settings for the driver. This would be a way better setup than how this is handled in photoshop and would be a great way to simplify and facilitate the management this part of a CM work flow. We will let the print plug-in deal with this. Ideally the print plug-in would not be part of GIMP. Instead give the user the choice to pick his/her preferred print plug-in. Sven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Re: Color Management was GEGL development/gimp integration
Sven Neumann wrote: - display profile should be adjusted _once_ systemwide (every time changeble by systemwide color preferences indepenant from the GIMP, as used by (e.g.)scribus [1], inkscape [2], sodipodi[3] wine e.g. for Photoshop and maaybeee by commercial apps available for *nix like Page Stream [4], Cenon [5], Viva Designer [6]) with an monitor profile (like the one of l-prof or adobe-gamma etc.), there for it would be overwhelming to have this choice again in the opening file dialog, if the profile doesn't fits the working color space. regards Gerhard [1] http://www.scribus.org.uk/ [2] http://www.inkscape.org [3] http://www.sodipodi.com/ [4] http://www.grasshopperllc.com/ [5] [6] http://www.vivaip.de/ ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg-exif continued
Sven wrote: It's just an argument, not a requirement. Simply something that might be worth keeping in mind. Is this really only relevant to file plug-ins? A metadata editor would need to use these functions as well, wouldn't it? Raphael's plan, which makes sense to me, is that the metadata editor and metadata accessor functions will work exclusively with XMP, and that file plug-ins will translate between XMP and other metadata formats (IPTC, EXIF, DICOM, etc) on loading or saving, using interface functions supplied by the metadata system. So the interface functions xxx_metadata_store_exif() and xxx_metadata_generate_exif() only come into play when loading or saving a file with exif data. Fortunately the Adobe XMP specification completely defines the translation between EXIF data and XMP data, so the EXIF-XMP-EXIF round trip can be done without losing any information. Hmm, so if I open an image, do some color corrections, but do not rotate it, the orientation tag is supposed to change? I can hardly believe that. But if you say that's what the spec says... It *is* what the spec says, and it seems to me that the only reasonable assumption is that if the user looks at the image before saving it, what the user sees is what the user wants. I admit that for non-interactive use this might not always be the most desireable thing, and perhaps it is worth thinking about whether that should (or could) be handled differently. -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Re: Color Management was GEGL development/gimp integration
On Sat, 15 Jan 2005 23:42:55 +0100, Gerhard Gaußling If you apply a conversion to the file there will be a loss of color information, so it's necessary, that we avoid unneeded conversions to the original file. For some filters and operations to be correct, the image data needs to be in a color space with linear light. (e.g. not gamma corrected for CRT display devices). Operations that need linear light to be correct: gaussian blurs smudge anti aliased brush strokes soften brightness / contrast adjustments resampling (scaling an image up/down, rotating etc.) To avoid extra conversions whenever such a filter is applied to an image, having a standard working space that has linear light will decrease the total number of conversions needed. Doing the custom conversion and countermeasures to account for gamma in all these operations will introduce quantification whenever such an operation is performed, less conversions are better, and a consistent high range internal working space is the path to the lowest number of conversions whenever any of the above listed operations are done. This is why I am advocating that gimp/GEGL should prefer to work, save and load in a preferred working color space. For multiple loads/edits of a project the conversion to a preferred internal working space already have happened when you load an image using gimps own file format. other image file formats are not suited as intermediate formats for saving an image that is being edited (for the same reasons that you shouldn't use lossy compression,. compression through generations/multiple unneeded conversions degrades your image) When exporting from gimps internal file format to display / printer / other file format with embedded icc profile, the image data shouldn't be touched by gimp again. /Øyvind K. -- Software patents hinder progress | http://swpat.ffii.org/ Web : http://pippin.gimp.org/ ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] short question about reading gimp color curve files (for avisynth port)
hi i got one question about gimp color curve files: i know if a pair of numbers contains 2 -1s that it is to be ignored but what if only the first coordinate is -1? what should i do with this pair? (for now i ignore it too, but i gues that isn't completely right thx in advance - Get your FREE email account at Asheville.com. http://mail.asheville.com ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
