Jordi Canton <[EMAIL PROTECTED]> writes:

> Actually the plugin is reading the profile attached as parasite. Last
> time I checked, only the TIFF files were abe to read/write the
> profiles as color parasites. There is no problem to read the color
> profile as parasite but the read/write color profile should also be
> implemented in the other file formats wich support embeebed color
> profiles (i.e. jpg)

I have added support for reading and writing embedded ICC profiles to
the JPEG plug-in a while ago. What's missing is integration with
GIMP's color management and that depends on some changes to the
plug-in API that are still pending.

>> 2. Default Profile Paths need to be implemented.  This should be user
>> modifiable.  On open source systems it should be set to
>> ~/.color/icc:/usr/share/color/icc by default and the user should only be able
>> to add additional locations to this path (not sure about the last part). On
>> open source systems The GIMP installation should create these directories if
>> they do not exist (? not sure about this).  On closed source systems the
>> system default locations should be used.  On Windows XP this would normally
>> be C:\windows\system32\spool\drivers\color.  I don't know what it is on a
>> Mac.   Medium to low priority.
> I agree, the use of directories to store the profiles provides an easy
> and quick way to select the different profiles.

I disagree somewhat. IMO there should be a configurable profile search
path similar to what we have for brushes, fonts etc. The user
shouldn't have to select ICC profiles by selecting files. Instead
there should be a profile selector. This widget would list all
available profiles, showing info such as the profile vendor, profile
intent and other meta information that can be extracted from ICC

Gimp-developer mailing list

Reply via email to