Re: [Gimp-developer] jpeg-exif development summary
Hi, Selon Daniel Egger [EMAIL PROTECTED]: On 05.01.2005, at 18:27, Dave Neary wrote: Before people get high-horsey about this, consider that 90% of digital cameras have embedded DOS as their OS, and are thus unable to generate files which are not 8.3. I don't think it is pretty safe to assume that FAT support means that anything close to DOS could be the operating system of a camera; Excuse me, I was confusing the FAT filesystem and DOS, which is not a good thing to do. And the 8.3 requirement is also a FAT thing, not DOS. 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] jpeg-exif development summary
Hi, Robert L Krawitz [EMAIL PROTECTED] writes: Something that forces me to do an extra gratuitous step for loading every portrait I ever shoot is a massive pain in the butt however you slice it. Assuming your camera adds EXIF info, are you seriously telling me that you do not run 'exiftran -a -i' on each and every image you ever shoot and instead use GIMP to rotate them? Sven ___ 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
Sven Neumann ([EMAIL PROTECTED]) wrote: Robert L Krawitz [EMAIL PROTECTED] writes: I keep master copies untouched and rely on applications to show the implied rotation. You are aware that there's absolutely no good reason to do that? Rotation of JPEG images using exiftran or jpegtran is a lossless operation. iff the width and height is a multiple of 8 or 16 pixels (which usually is true for photos). jpegtran keeps the data intact for non-8-multiples but then the visible result is not exactly the expected rotation. Bye, Simon -- [EMAIL PROTECTED] http://simon.budig.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 development summary
Hi, William Skaggs [EMAIL PROTECTED] writes: A) Artist: Ascii, name of the image creator, in parasite gimp-artist. ASCII isn't a reasonable encoding for names. I strongly hope the EXIF spec doesn't define this as ASCII. 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*. The term string is meaningless unless an encoding is specified. 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. gimp-comment is UTF-8, not ASCII. 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) Fortunately this isn't really an issue for The GIMP since people owning a camera that adds rotation information will use tools such as exiftran to deal with it. GIMP shouldn't very often see images with an orientation tag other than top-left. So your approach is probably fine. 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. I don't think that a gimp-metadata parasite is the right thing to do. Instead we should continue to use the exif-data parasite. Plug-ins that need to deal with EXIF data can use libexif to extract the relevant informations. I don't see any point in preprocessing the EXIF data the way you are doing this now. What's the benefit of all this? Why introduce new parasites? 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. libgimpfile is about abstracting file handling and is supposed to wrap gnomevfs and similar libraries. It is not at all about handling exif data. It might turn out that we need a library that deals with metadata but the API of such a library needs to be carefully designed, so please hold back until that has happened. 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.) There's a parasite editor in gimp-perl already which can do all this. I don't think we need yet another implementation. We also have a more or less complete metadata editor that waits to be committed to CVS. I don't understand why you are ignoring the work of Raphael. IMO you two should work closely together instead of duplicating each other's work. IMO this metadata topic needs to be treated with more foresight. I am rather unhappy with the latest developments in CVS. I don't see how the latest changes take into account IPCT and XMP metadata and I think it's a bad idea to ignore this. I'd have welcomed the changes to be discussed here before any code is changed. Sven ___ 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
Robert L Krawitz ([EMAIL PROTECTED]) wrote: [Exif orientation tag] The obvious question is: if the rotation information isn't important, why does the camera even bother with it, as opposed to doing the rotation inside the camera? Why does EXIF even have a rotation tag if it's useless? Good question. Actually I have wondered quite a lot about that already. Why the fuck doesn't a camera with an orientation sensor store the Jpeg in the proper orientation (quite cheap from a computational POV, just shuffle some coefficients around) and stores an *absolute* orientation tag in EXIF. Storing a JPEG that looks wrong in 100% of all non-exif-aware image viewers is just stupid IMHO. One reason that comes to mind is to study the lighting after the fact; knowing what the original rotation was can be helpful in some cases. This is however not a good reason to store a tag relative to the image data. My best guess is some kind of vendor lock in (you need to use our proprietary tools to get properly oriented images from our camera) but of course using a common standard for this task is kind of nonsense as well :) So no, I don't see a good reason to not rotate the images already in the camera and e.g. store absolute information on the camera orientation. Bye, Simon -- [EMAIL PROTECTED] http://simon.budig.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 development summary
Hi, Robert L Krawitz [EMAIL PROTECTED] writes: My policy is to never muck with the original -- PERIOD. Yes, I could always make copies, but that would use more disk space. This is a standard photographic policy. You don't muck with your negatives. Well, that's your point of view then and you have to live with the consequences. The obvious question is: if the rotation information isn't important, why does the camera even bother with it, as opposed to doing the rotation inside the camera? Why does EXIF even have a rotation tag if it's useless? One reason that comes to mind is to study the lighting after the fact; knowing what the original rotation was can be helpful in some cases. You are completely right. The camera should do the orientation and EXIF should have an orientation flag that refers to the original orientation. Unfortunately early digital cameras were not able to do the rotation. Nowadays there's really no good reason for this behaviour. Sven ___ 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
There's a parasite editor in gimp-perl already which can do all this. I don't think we need yet another implementation. Unless somebody has ported this to Gtk2, and is maintaining it independantly, this statement is false for Gimp 1.2. It was removed from CVS (with no complaints) on 2004-05-07. I'd be happy to reintroduce it if somebody does do the work (or maybe even port it if I get interest). Happy GIMPing, Seth ___ 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
Robert L Krawitz ([EMAIL PROTECTED]) wrote: Date: Thu, 6 Jan 2005 18:36:50 +0100 From: Simon Budig [EMAIL PROTECTED] Robert L Krawitz ([EMAIL PROTECTED]) wrote: [Exif orientation tag] The obvious question is: if the rotation information isn't important, why does the camera even bother with it, as opposed to doing the rotation inside the camera? Why does EXIF even have a rotation tag if it's useless? Good question. Actually I have wondered quite a lot about that already. Why the fuck doesn't a camera with an orientation sensor store the Jpeg in the proper orientation (quite cheap from a computational POV, just shuffle some coefficients around) and stores an *absolute* orientation tag in EXIF. What is absolute orientation? Orientation by its very nature has to be relative to *something*? I presume from what you say below that you mean orientation of the camera. I don't want to lose those two bits of information. Point taken :-) I meant the orientation of the camera relative to the gravitation when the photo has been shot. From my glance at the Specs the Orientation tag stores The image orientation viewed in terms of rows of columns and the default value is The 0th row is at the visual top of the image, and the 0th column is at the visual left-hand side. So the Orientation-Tag is about the relation between the visual representation of the image and the organisation of the image data - at least this is my understanding of the specs. It is *not* about the physical orientation of the camera. Storing the orientation of the camera relative to the image data stored doesn't make much sense and just happens to kind of work for exif aware applications, because the camera abuses the ORIENTATION tag. Bye, Simon -- [EMAIL PROTECTED] http://simon.budig.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 development summary
From: Sven Neumann [EMAIL PROTECTED] Date: Thu, 06 Jan 2005 18:49:17 +0100 Robert L Krawitz [EMAIL PROTECTED] writes: My policy is to never muck with the original -- PERIOD. Yes, I could always make copies, but that would use more disk space. This is a standard photographic policy. You don't muck with your negatives. Well, that's your point of view then and you have to live with the consequences. I should think any serious photographer would take the point of view that you never mess with your negatives... Do you have any other suggestion for preserving the rotation information? The obvious question is: if the rotation information isn't important, why does the camera even bother with it, as opposed to doing the rotation inside the camera? Why does EXIF even have a rotation tag if it's useless? One reason that comes to mind is to study the lighting after the fact; knowing what the original rotation was can be helpful in some cases. You are completely right. The camera should do the orientation and EXIF should have an orientation flag that refers to the original orientation. Unfortunately early digital cameras were not able to do the rotation. Nowadays there's really no good reason for this behaviour. That's all well and good, but why force your viewpoint on other people? ___ 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
Hi Simon, Simon Budig wrote: Storing the orientation of the camera relative to the image data stored doesn't make much sense and just happens to kind of work for exif aware applications, because the camera abuses the ORIENTATION tag. The ORIENTATION tag provides enough flexibility to cope with situations other than just Portrait or Landscape; the typical camera's use of the ORIENTATION tag isn't so much an abuse of it, as a special case. FWIW though, my old HP PhotoSmart 618 does indeed rotate the image data before writing to the card, and ignores the ORIENTATION tag - so it has been done! (It also has a Coldfire processor, and uses Digita as its OS...) All the best, -- Alastair M. Robinson ___ 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
Sven wrote: A) Artist: Ascii, name of the image creator, in parasite gimp-artist. ASCII isn't a reasonable encoding for names. I strongly hope the EXIF spec doesn't define this as ASCII. The spec defines it as ASCII. Before you get too outraged, please bear in mind that the EXIF spec was created in Japan, where they were certainly aware of the significance of what they were doing. (It was, however, derived from the TIFF spec for the fields that the two share, and that is probably the source of the ASCII specification.) 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*. The term string is meaningless unless an encoding is specified. As I wrote, it's again ASCII. 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. gimp-comment is UTF-8, not ASCII. Okay, so gimp-comment should go into the User Comment field. There's a parasite editor in gimp-perl already which can do all this. I don't think we need yet another implementation. That's fine, it's available from the registry if anybody wants it. We also have a more or less complete metadata editor that waits to be committed to CVS. I don't understand why you are ignoring the work of Raphael. IMO you two should work closely together instead of duplicating each other's work. I agree! I am not at all ignoring Raphael's work -- if it was accessible, I would be interfacing with it instead of using temporary hacks. I don't actually think that the code I have added will duplicate Raphael's work, though -- most of it is devoted to making sure that exif data, if it exists for an image, is updated as required by the specs when the image is saved as a jpeg file. That is the responsibility of the jpeg plugin, not of a metadata editor. A metadata library might facilitate it, but the jpeg plugin still needs to take responsibility for making it happen. IMO this metadata topic needs to be treated with more foresight. I am rather unhappy with the latest developments in CVS. I don't see how the latest changes take into account IPCT and XMP metadata and I think it's a bad idea to ignore this. I'd have welcomed the changes to be discussed here before any code is changed. The only important thing in the code I added is that it makes the jpeg plug-in follow the exif specifications when it saves a file with exif data. Everything else is simply a stub, easily altered to fit any reasonable metadata-handling scheme that we come up with. I only bothered putting things into parasites because I have found that implementing a bad solution tends to provoke the appearance of a better solution, whereas a void does not necessarily provoke the appearance of anything. That code took about 10 minutes to write, and shouldn't take much longer to change. It might turn out that we need a library that deals with metadata but the API of such a library needs to be carefully designed, so please hold back until that has happened. This statement gives the essence of what has been holding us back. It might turn out . . . means that there is no concrete sense of what is needed. But how can an API be carefully designed without a concrete sense of what is needed? It isn't possible. The only way to get anywhere is to experiment, and when something doesn't work, change it. It's not like we're working with core code here that will break GIMP if it's imperfect. 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
Hi William ;), ASCII isn't a reasonable encoding for names. I strongly hope the EXIF spec doesn't define this as ASCII. The spec defines it as ASCII. Before you get too outraged, please bear in mind that the EXIF spec was created in Japan, where they were certainly aware of the significance of what they were doing. I'm afraid they weren't :(. I didn't know that EXIF came out from Japan, shame on them to make a spec with ASCII strings when nowadays it should be UTF-8. In what year was the spec defined? regards, -- David Gmez Jabber ID: [EMAIL PROTECTED] ___ 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
Hi, Robert L Krawitz [EMAIL PROTECTED] writes: That's all well and good, but why force your viewpoint on other people? I am not doing that. I just stated that Bill's approach at dealing with the orientation tag is in my opinion the right thing to do. Sven ___ 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
Hi, William Skaggs [EMAIL PROTECTED] writes: ASCII isn't a reasonable encoding for names. I strongly hope the EXIF spec doesn't define this as ASCII. The spec defines it as ASCII. Before you get too outraged, please bear in mind that the EXIF spec was created in Japan, where they were certainly aware of the significance of what they were doing. (It was, however, derived from the TIFF spec for the fields that the two share, and that is probably the source of the ASCII specification.) If the spec says it's ASCII, then we have no choice but keeping it ASCII. That of course means that there isn't much point in allowing anyone to edit this field since conversion to ASCII will fail for almost all strings that a user may enter. It appears that the best we can do about strings in EXIF data is not to touch them. We also have a more or less complete metadata editor that waits to be committed to CVS. I don't understand why you are ignoring the work of Raphael. IMO you two should work closely together instead of duplicating each other's work. I agree! I am not at all ignoring Raphael's work -- if it was accessible, I would be interfacing with it instead of using temporary hacks. But isn't it accessible from http://wilber.gimp.org/~raphael/metadata/ ? This statement gives the essence of what has been holding us back. It might turn out . . . means that there is no concrete sense of what is needed. But how can an API be carefully designed without a concrete sense of what is needed? It isn't possible. The only way to get anywhere is to experiment, and when something doesn't work, change it. It's not like we're working with core code here that will break GIMP if it's imperfect. Well, another way is to make a list of what we need and design an API. I don't think a lot of experiments are needed to get a first design proposal written down. Sven ___ 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
Hi, Sven Neumann wrote: Robert L Krawitz [EMAIL PROTECTED] writes: Something that forces me to do an extra gratuitous step for loading every portrait I ever shoot is a massive pain in the butt however you slice it. Assuming your camera adds EXIF info, are you seriously telling me that you do not run 'exiftran -a -i' on each and every image you ever shoot and instead use GIMP to rotate them? A what? I didn't know the tool existed. Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] CV: http://dneary.free.fr/CV/ ___ 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
William Skaggs wrote: Sven wrote: But isn't it accessible from http://wilber.gimp.org/~raphael/metadata/ ? No, that doesn't exist any more. And I don't think it ever had the source code anyway -- but I may be wrong about that. There seems to be at least a bit of source code: http://wilber.gimp.org/~raphael/metadata/src/ HTH, Michael -- The GIMP http://www.gimp.org | IRC: irc://irc.gimp.org/gimp Wiki http://wiki.gimp.org | .de: http://gimpforum.de Plug-ins http://registry.gimp.org | ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
