Re: [Gimp-developer] jpeg-exif development summary
Date: Tue, 4 Jan 2005 09:53:01 -0800 From: "William Skaggs" <[EMAIL PROTECTED]> 2) The jpeg plug-in now pretty closely adheres to the instructions in the exif specifications concerning which fields should be altered by an image-editing program. There are a couple of fields remaining that I haven't yet figured out how to set properly. There is now a file called "exif-handling.txt" in devel-docs that summarizes my understanding, based on the exif specifications, of how an image editor is supposed to handle the exif data in a file. Of course we need not take the specifications as gospel (among other things, they specify that a proper EXIF file must have a file name in 8.3 format, ending in .JPG!), but they should serve as a good default. Adobe at least had an excuse with PPD files 10 years ago. There's no excuse for 8.3 any more. 4) When the exif specifies that an image is rotated, the plug-in pops up a query asking the user whether to rotate it into standard alignment. I thought it was better to ask rather than do it automatically, because there are probably a substantial number of existing images that have been edited without having their exif information properly updated (for example, by earlier versions of GIMP). When an image is saved with exif, the orientation is set to "top-left", as the exif specifications require. (See bug #121810) I'd suggest making this a preference. If someone's careful about maintaining their images (or hasn't edited them before), they'll get very annoyed by having to answer this question every time they open an EXIF file that's rotated. Wouldn't earlier versions of the GIMP have destroyed the EXIF data? 2) Exif is not relevant only to jpeg: it can appear in TIFF and Raw files, and there are draft standards for including it in PNG and other file types. I would like to extract the generic parts of the exif handling code for jpeg-exif.c and place it into a new library for generic file-handling code, libgimpfile, which we have discussed creating some time ago (see bug #139354). The file jpeg-exif.c will still however need to exist, because the exif specifications require some different fields for compressed (jpeg) vs uncompressed (tiff) exif files. FYI, Canon raw (.crw) files have an embedded JPEG file, but the EXIF information is stored in both the raw file and in a thumbnail (.thm) file with the same basename. The .thm file is actually a JPEG file with embedded EXIF data. -- Robert Krawitz <[EMAIL PROTECTED]> Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gimp Print --http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg-exif development summary
On Tue, Jan 04, 2005 at 11:00:29AM -0800, William Skaggs wrote: > Carol wrote: > > is the "proper EXIF file" requirement that the name ends in .JPG case > sensitive? > > Well, that was my point -- we're certainly not going to pay any > attention to such an absurd specification. > thank you for seeing stuff like this and responding correctly to it. it should really be a benefit to people who use TheGIMP or the gimp or GIMP or even just gimp if this software can handle this information correctly. carol ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg-exif development summary
Carol wrote: > is the "proper EXIF file" requirement that the name ends in .JPG case sensitive? Well, that was my point -- we're certainly not going to pay any attention to such an absurd specification. Best, -- 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] jpeg-exif development summary
On Tue, Jan 04, 2005 at 09:53:01AM -0800, William Skaggs wrote: >There is now a file called "exif-handling.txt" in devel-docs that >summarizes my understanding, based on the exif specifications, of >how an image editor is supposed to handle the exif data in a file. >Of course we need not take the specifications as gospel (among >other things, they specify that a proper EXIF file must have a file >name in 8.3 format, ending in .JPG!), but they should serve as a >good default. > is the "proper EXIF file" requirement that the name ends in .JPG case sensitive? carol ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] jpeg-exif development summary
Hi, I've been working on the jpeg plug-in, and would like to summarize developments and give a sense of where I would like to take it. (Please read to the end before deciding to react negatively :-) .) 1) First, because the code size has been exploding recently, it has been placed in a separate directory, plug-ins/jpeg, and split up into files jpeg.c, jpeg-load.c, jpeg-save.c, and jpeg-exif.c, the last of these containing newly written exif-handling code. 2) The jpeg plug-in now pretty closely adheres to the instructions in the exif specifications concerning which fields should be altered by an image-editing program. There are a couple of fields remaining that I haven't yet figured out how to set properly. There is now a file called "exif-handling.txt" in devel-docs that summarizes my understanding, based on the exif specifications, of how an image editor is supposed to handle the exif data in a file. Of course we need not take the specifications as gospel (among other things, they specify that a proper EXIF file must have a file name in 8.3 format, ending in .JPG!), but they should serve as a good default. 3) A few special pieces of information, which may be relevant to many different file types, are extracted from the exif data on loading, and placed in special parasites. Currently, the extracted items are: A) Artist: Ascii, name of the image creator, in parasite "gimp-artist". B) Copyright: Ascii, in "gimp-copyright". The format of this is a bit peculiar -- it consists of two null-terminated strings end-to-end, the first containing the *editor copyright*, and the second the *photographer copyright*. C) User Comment: in "jpeg-user-comment". This can contain arbitrary binary data, so it must be handled with care. D) Image Description: Ascii, in "gimp-comment". E) Colorspace: Can be "sRGB" or "uncalibrated", in "gimp-colorspace". With the exception of Colorspace, these are not mandatory fields, and don't exist in the majority of exif files. If a field does not exist, no parasite is created. When an image with exif is saved, if parasites with these names exist, their contents are inserted into the exif data. There are also a few exif fields relevant to color management, which the current code does not extract. It will be good to add this once we have a general color management solution in place. 4) When the exif specifies that an image is rotated, the plug-in pops up a query asking the user whether to rotate it into standard alignment. I thought it was better to ask rather than do it automatically, because there are probably a substantial number of existing images that have been edited without having their exif information properly updated (for example, by earlier versions of GIMP). When an image is saved with exif, the orientation is set to "top-left", as the exif specifications require. (See bug #121810) Where to go: 1) As Sven has pointed out (and I agree), putting information into a set of separate parasites is a Bad Thing To Do. Instead, the Right Thing To Do is to have a single "gimp-metadata" parasite containing all of the general metadata, and a set of functions for manipulating them. Once such a thing exists, it should be very easy to port the existing code to use it. Thus, the existing code should be thought of as essentially a stub for the correct code. In any case, the existing parasites are marked as non-persistent, so they will only stick around for the current session, and not be saved in xcf files. 2) Exif is not relevant only to jpeg: it can appear in TIFF and Raw files, and there are draft standards for including it in PNG and other file types. I would like to extract the generic parts of the exif handling code for jpeg-exif.c and place it into a new library for generic file-handling code, libgimpfile, which we have discussed creating some time ago (see bug #139354). The file jpeg-exif.c will still however need to exist, because the exif specifications require some different fields for compressed (jpeg) vs uncompressed (tiff) exif files. 3) I have created a very simple parasite browser plug-in, capable of listing image parasites, editing their contents if they are ascii, creating new ones, loading the contents of the file into one, or saving a parasite to a file. I would like to add this to cvs, partly because it is useful, partly for the assistance of developers who need to look at parasites, and partly as a placeholder for a more powerful metadata plug-in that is hoped to appear sometime during the current development cycle. (See bug #61499, #120563, tracking bug #118202, etc.) Of course none of this is written in stone. Best, -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdav
Re: [Gegl-developer] Re: [Gimp-developer] GEGL development/gimp integration
Hi Sven, Selon Sven Neumann <[EMAIL PROTECTED]>: > "Hal V. Engel" <[EMAIL PROTECTED]> writes: > > it appeared to me that this approach had been rejected, or at least > > discredited, at that time. At the very least there were sound reasons > > put forward that called this approach into question and the only > > arguments on the other side were that it made programming the color > > management stuff a little easier. But I am also aware that there were > > many involved in the earlier thread on this subject that did not seem > > to think there was an issue with this approach. > > I don't think we rejected this part. IIRC we said that it should be > optional and that we want to allow people to disable color management > entirely. Anyway, whatever we decide to do is just a matter of user > interface and doesn't affect the GEGL operators involved. The short summary of the entire discussion is something like this: We should allow a colour profile to be associated with an image if possible, and only apply it (that is, change the colorspace of an image) if explicitly requested. There will be issues with things which aren't colorspace dependent (like the color picker) as well as copying and pasting between images, which will cause problems, but for the moment the damage caused by these would be less than applying color profiles on load. However, we should have a default working colourspace, and the user should be able to convert to that colourspace on load. This should be configurable. There should also be an option to disable colour management altogether - in which case, we work in the default colourspace, don't do any conversion at all, and simply load and save the colour profile as a parasite attached to the image. My understanding was that the solution which Alastair Robinson was working on was to have a plug-in to apply a color profile, but also to have the idea of a (per-image) working colourspace, and a configurable (global) display colour profile and default working colourspace. That is, every image loaded which doesn't have an attached profile will be assumed to be in that default colourspace. If it has an attached profile, the user will be offered the choice of (1) applying the profile to get to the default colorspace, (2) working in the embedded profile's colorspace or (3) disabling color management for the image, in which case we work in the default colorspace, but don't apply the profile. Again, this is a synthesis of my understanding of that discussion, the archives are the best reference for what was said, though. Cheers, Dave. -- Dave Neary Lyon, France ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Color Management was GEGL development/gimp integration
Hi, "Hal V. Engel" <[EMAIL PROTECTED]> writes: > I didn't think we were talking about user interface issues. Rather > this is about how the image data is handled while it is being > manipulated by the GIMP. Specifically should there be a color space > transformation as part of loading the image and another when the > image is saved. Well, at this point we are rather talking about preparing the framework that we will need to implement color management. How exactly this is all wired up and presented to the user remains to be seen. Your feedback will certainly help with this. > I think I already did but not in great detail. My main point is that > the color space of the users image should ALWAYS be untouched unless > the user specifically asks for a transformation. There are a number > of cases where the image must go through a color space transformation > but only a limited set of these should affect the actual image data. If we don't convert the image at load time, all plug-ins that change colors would have to be aware of the color-space the image is in. Since this is not the case for the time being, it would probably be a bad idea to not convert the image. As soon as we go further down the road and have all plug-ins as GEGL ops, this will change. But for the time being, I don't see much choice but to convert everything to sRGB. Note that we are just talking about the first step here. Something that we can achieve in the next few months, without changing each and every piece of code in GIMP and it's plug-ins. Sven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
