Re: [Gimp-developer] jpeg-exif development summary
We should be able to automaticaly detect when a file has been rotated without updating the exif data most of the time. Exif stores the image width and height a couple of times. Cant we just check if the width/height in the exif match the widht/height of the actual image? The only cases this wont catch is bottom-right orientation (should be very rare) and cameras with square sensors(are there any?). If the width/height tags are getting molested by the gimp, then we could fall back to comparing against the aspect ratio of the embedded preview when there is one. On a more practical note, gimp seems to completely throw away any exif data when saving as a jpg(tested in 1.3,24, and 2.2.2). Perhaps this is less of a problem than it has been made out to be (or perhaps I have weird cvs versions of gimp installed). Jay Cox [EMAIL PROTECTED] O ___ 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 Jay, Jay Cox wrote: On a more practical note, gimp seems to completely throw away any exif data when saving as a jpg(tested in 1.3,24, and 2.2.2). Perhaps this is less of a problem than it has been made out to be (or perhaps I have weird cvs versions of gimp installed). You need libexif installed before exif data will be saved. Perhaps this dependency will go away with Bill's new stuff, but I think he uses it too. Cheers, 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
David Neary wrote: You need libexif installed before exif data will be saved. Perhaps this dependency will go away with Bill's new stuff, but I think he uses it too. Reimplementing libexif in gimp wouldn't be too wise, would it? 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
Re: [Gimp-developer] jpeg-exif development summary
Michael Schumacher wrote: Reimplementing libexif in gimp wouldn't be too wise, would it? Libexif is a lot cruftier than it needs to be but I don't have any ambition to reimplement it. -- 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 Thu, 20 Jan 2005 05:21:37 GMT, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: [re-formatted to include proper quoting] Alastair M. Robinson wrote: Robert L Krawitz wrote: Raphael's proposal sounds right on the money to me. It comes down to a question of what's most annoying: (1) having to rotate manually an unknown, but possibly quite small number of existing images, on a one-off basis, or (2) having to dismiss (or find a way of permanently disabling) an extra dialog for every existing and future image that has the relevant EXIF flag set. (3) somebody write a command-line tool that will just strip the flag from all the images in a directory (for those who have been using bad versions to fix all their images), along with option (1) above, keeping the kludge out of gimp, while providing the service. Fortunately, there are already several command-line tools available for that, as well as several GUI tools that have some kind of batch mode. One example of such a command-line tool is Jhead. You can either use the option jhead -autorot to rotate the image and clear the EXIF Orientation tag, or use the option jhead -norot to clear the EXIF Orientation tag without rotating the image, assuming that some broken program has already rotated the image without updating the EXIF info. I have also seen some shell scripts that use the command-line exif program to change the value of the Orientation tag directly. So there are already many ways to fix the JPEG files with EXIF info that have been incorrectly handled by some programs (such as GIMP 2.2, but hopefully not 2.4). Although I think that option (1) above should be the default instead of (2), I think that (2) can still be useful in some cases. Some of the EXIF-aware image editors that I looked at are also offering an option to ignore the EXIF Orientation tag (this is never the default, though). Bill has already written the code for asking the user, so let's not throw that away. So the default should be to open the images with the correct orientation without asking, and there should be an option in the preferences (gimprc) that allows the user to ignore the EXIF Orientation tag or to be asked every time. The threshold for adding new options to the gimprc should be high, but I think that this one deserves it. -Raphaël ___ 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 Wed, 5 Jan 2005 07:47:10 -0800, William Skaggs [EMAIL PROTECTED] wrote: Robert Krawitz wrote: [William Skaggs wrote:] 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'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? That would be a reasonable thing to do: Rotate images if exif says so?: _Always _Never _Ask each time. But we have a high threshold nowadays for adding new preferences, so this is something that probably won't happen until it's clear that a lot of people want it. Thanks Bill for updating the code and adding a comment in bug #121810. Although I am a bit late to the party, here are my 2 cents: I think that the jpeg plug-in should automatically rotate the image when opening it without marking it as dirty. The default setting should be to do that automatically without asking, both for interactive and non-interactive mode. Let me try to explain why... Many of the arguments posted here in the last two weeks imply that the image is modified by rotating it. This should not be the case: the result of opening the file should show the image with the correct orientation, which is exactly what is implied by the EXIF specs. In fact, if the IJG JPEG library had been EXIF-aware, I bet that it would have included an optional API to do that automatically and the decompressor would have filled the output bitmap column-by-column instead of line-by-line if necessary. A program using that API would not even have to be aware of how the blocks were arranged in the file. This is similar to a program reading a BMP file without having to know that the scanlines are stored from bottom to top instead of from top to bottom. While working on my metadata editor a few months ago, I tested several EXIF-aware programs (image viewers or editors) and I asked others to do the same and tell me how the metadata was presented, etc. Although this was not the main purpose of these tests, I saw that most (all?) image viewers or editors supporting EXIF are opening the images with the correct orientation. Some of them offer the option to ignore the rotation flag, but the default option is always to display the rotated image. I think that the GIMP should do the same and the default option should be to use the correct orientation without asking. So the JPEG plug-in should open the image and rotate it before giving it to the GIMP (as if the underlying library was already doing it) so that it is not marked dirty. Of course there could also be the option to ignore the rotation or to ask the user what to do for each image, but this should not be the default (IMHO). With this configuration, the user can open an image and see it correctly. The file on disk is not modified until the user decides to save it (which could be in a different file format). For a while, I thought that another solution would be to provide a rotated view of the canvas when displaying the image (as suggested in bug #55367 for a different purpose) but that would not really help if the image is then saved to another file format. I also have a separate improvement proposal related to how the dirty flag could be set on the image. See my next message... -Raphaël ___ 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 Raphael, glad to hear from you. Although I am a bit late to the party, here are my 2 cents: I think that the jpeg plug-in should automatically rotate the image when opening it without marking it as dirty. The default setting should be to do that automatically without asking, both for interactive and non-interactive mode. Let me try to explain why... In an ideal world I agree that this would be the right answer. What concerns me is that in this less-than-ideal world, many people are likely to have images with incorrect exif data, including anybody who edited a rotated exif jpeg in GIMP 2.0 or 2.2 and then resaved it as jpeg. It's hard to get a fix on how large a population this is, but I bet if we impose a solution on them that rotates their images without giving them any way to prevent it, we'll be subjecting ourselves to some angry bug reports. 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
Date: Wed, 19 Jan 2005 09:32:15 -0800 From: William Skaggs [EMAIL PROTECTED] Hi Raphael, glad to hear from you. Although I am a bit late to the party, here are my 2 cents: I think that the jpeg plug-in should automatically rotate the image when opening it without marking it as dirty. The default setting should be to do that automatically without asking, both for interactive and non-interactive mode. Let me try to explain why... In an ideal world I agree that this would be the right answer. What concerns me is that in this less-than-ideal world, many people are likely to have images with incorrect exif data, including anybody who edited a rotated exif jpeg in GIMP 2.0 or 2.2 and then resaved it as jpeg. It's hard to get a fix on how large a population this is, but I bet if we impose a solution on them that rotates their images without giving them any way to prevent it, we'll be subjecting ourselves to some angry bug reports. Won't they have (already be having) exactly the same problem with any other EXIF-aware viewer or editor? Raphael's proposal sounds right on the money to me. -- 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
Hi Robert, Robert L Krawitz wrote: Won't they have (already be having) exactly the same problem with any other EXIF-aware viewer or editor? I doubt anyone who's encountered this issue opening files in other programs will have twigged that GIMP caused it :) Raphael's proposal sounds right on the money to me. It comes down to a question of what's most annoying: (1) having to rotate manually an unknown, but possibly quite small number of existing images, on a one-off basis, or (2) having to dismiss (or find a way of permanently disabling) an extra dialog for every existing and future image that has the relevant EXIF flag set. I'd opt for (1) every time. I could live with (2), if and only if there's a bug-me-not option to get rid of it. 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
Date: Thu, 20 Jan 2005 01:32:44 + From: Alastair M. Robinson [EMAIL PROTECTED] Hi Robert, Robert L Krawitz wrote: Won't they have (already be having) exactly the same problem with any other EXIF-aware viewer or editor? I doubt anyone who's encountered this issue opening files in other programs will have twigged that GIMP caused it :) Probably not, but with correct EXIF behavior it should behave the same as any other EXIF-aware apps. -- 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
] Raphael's proposal sounds right on the money to me. ] ]It comes down to a question of what's most annoying: ](1) having to rotate manually an unknown, but possibly quite small ]number of existing images, on a one-off basis, or ](2) having to dismiss (or find a way of permanently disabling) an extra ]dialog for every existing and future image that has the relevant EXIF ]flag set. (3) somebody write a command-line tool that will just strip the flag from all the images in a directory (for those who have been using bad versions to fix all their images), along with option (1) above, keeping the kludge out of gimp, while providing the service. _-T ___ Speed up your surfing with Juno SpeedBand. Now includes pop-up blocker! Only $14.95/month -visit http://www.juno.com/surf to sign up today! ___ 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: There's a good reason *right there* not to trust software that does any transformation on a master file. I'm not accusing the authors of exiftran of being sloppy, but the possibility of a latent bug does exist (and it's much greater than the possibility of a latent bug in cp or the like -- and when I do backups, I do verify them carefully, and use quality memory and the like!). Don't you realize that you are continously repeating yourself and that this getting rather off-topic? 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
On Sat, 2005-01-08 at 11:24 -0800, Akkana Peck wrote: Sven Neumann writes: 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? Add another voice to all the others saying No, I leave my originals untouched, and only edit copies. In fact, I don't think I'd ever met anyone who regularly ran exiftran on every archived original, until this discussion. Exiftran isn't even installed by default on any linux distro I've used. Is it commonly found on mac and windows machines? I don't think it matters whether one uses exiftran, jpegtran or gthumb to do the lossless JFIF rotation. Being explicitly told by the software that the action is lossless, I don't see a reason why to tilt my head every time I want to browse my photos or keep duplicates just because of this. Unless I'm being told untruth about the losslessness (soundss great, doesn't it?), the metaphor of not messing around with negatives isn't appropriate. cheers -- Jakub Steiner [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
From: Daniel Egger [EMAIL PROTECTED] Date: Mon, 10 Jan 2005 17:44:41 +0100 On 10.01.2005, at 16:52, Jakub Steiner wrote: Unless I'm being told untruth about the losslessness (soundss great, doesn't it?), the metaphor of not messing around with negatives isn't appropriate. It depends very much on how clever the tools are regarding the EXIF information; if an image is rotated the EXIF information must be at least passed trhough to the new file if not even changed appropriately. Gthumb for one application (have the authors fixed this?) truncated the EXIF data when doing a lossless transformation so this was very much for the trashcan I for one have been bitten seriously by this and since then keep the images as an umodified original from the camera except for the filename. There's a good reason *right there* not to trust software that does any transformation on a master file. I'm not accusing the authors of exiftran of being sloppy, but the possibility of a latent bug does exist (and it's much greater than the possibility of a latent bug in cp or the like -- and when I do backups, I do verify them carefully, and use quality memory and the like!). -- 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
Sven Neumann writes: 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? Add another voice to all the others saying No, I leave my originals untouched, and only edit copies. In fact, I don't think I'd ever met anyone who regularly ran exiftran on every archived original, until this discussion. Exiftran isn't even installed by default on any linux distro I've used. Is it commonly found on mac and windows machines? (in another message) Sven Neumann writes: 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 It's a bummer that it's not something like UTF-8 (and quite odd, if the spec came from Japan), but editing ASCII is still useful for quite a large number of people. What do modern cameras sold in Japan save in the EXIF fields? ...Akkana ___ 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
]It's a bummer that it's not something like UTF-8 (and quite odd, ]if the spec came from Japan), but editing ASCII is still useful ]for quite a large number of people. ] ]What do modern cameras sold in Japan save in the EXIF fields? Japan has a romanized alphabet that's corresponds to their characters. Other languages like Chinese have a more difficult problem because some dialects have no standard romanized phonetic system. I wouldn't go to any extra effort to keep multibyte systems from working with data that's supposed to be ASCII, nor would I add any special functionality to support multibyte characters. Basically, do the straightforward implementation of the spec, with one exception: I would, as a user, expect my programs to be able to handle any filename, and blame any failure to do so on the image editing tool rather than the spec. At the same time, any default filename generated should be within the 8.3 standard. _-T ___ Speed up your surfing with Juno SpeedBand. Now includes pop-up blocker! Only $14.95/month -visit http://www.juno.com/surf to sign up today! ___ 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
Date: Sat, 8 Jan 2005 11:24:49 -0800 From: Akkana Peck [EMAIL PROTECTED] Sven Neumann writes: 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? Add another voice to all the others saying No, I leave my originals untouched, and only edit copies. Unfortunately, thus far you and I are the only ones taking this position. I can't speak for every single photographer in the world, but as a matter of general principle, you don't mess with your negatives. The one thing I do to them is chmod 400 so I don't accidentally write over them. However, I use kimdaba (which is EXIF-aware) to index them. If I want to edit a particular image, I'll read it into the GIMP (which I can do from right-click in kimdaba), save it elsewhere (that's why the chmod 400), and then start editing it. If a particular application isn't EXIF-aware, tough on it. The ones I care about are kimdaba, the GIMP, and Photoprint, when it's ready (which one of the Gimp-Print developers is working on). Having to dismiss a completely irrelevant warning every time I want to edit a digital photograph is simply annoying. -- 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
Hi, Akkana Peck [EMAIL PROTECTED] writes: It's a bummer that it's not something like UTF-8 (and quite odd, if the spec came from Japan), but editing ASCII is still useful for quite a large number of people. It would require unreasonable effort to create an entry that restricts editing to ASCII and for almost all languages it would be rather useless also. We should restrict ourselves to only displaying these fields. 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
On Saturday 08 January 2005 13:40, Robert L Krawitz wrote: Date: Sat, 8 Jan 2005 11:24:49 -0800 From: Akkana Peck [EMAIL PROTECTED] Sven Neumann writes: 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? Add another voice to all the others saying No, I leave my originals untouched, and only edit copies. Unfortunately, thus far you and I are the only ones taking this position. You can add me to the list. I also leave my originals alone. As you say this is just good photographic practice. I have negatives that are almost 70 years old that are in nearly new condition that I got from my fathers photo collection before he died and I have my own collection of negatives and slides that goes back about 45 years. All have been carefully stored and are only touched to make copies (digital now days). My brother is a professional photographer and he also leaves his digital originals alone and only edits copies. I am sure that there are others on this list that also agree but have not said so on the list. In any case I don't see any reason to not do the same with digital originals. I can't speak for every single photographer in the world, but as a matter of general principle, you don't mess with your negatives. The one thing I do to them is chmod 400 so I don't accidentally write over them. However, I use kimdaba (which is EXIF-aware) to index them. If I want to edit a particular image, I'll read it into the GIMP (which I can do from right-click in kimdaba), save it elsewhere (that's why the chmod 400), and then start editing it. If a particular application isn't EXIF-aware, tough on it. The ones I care about are kimdaba, the GIMP, and Photoprint, when it's ready (which one of the Gimp-Print developers is working on). Having to dismiss a completely irrelevant warning every time I want to edit a digital photograph is simply annoying. -- 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 -- Hal V. Engel pgpG26jiDBqoc.pgp Description: PGP signature
Re: [Gimp-developer] jpeg-exif development summary
From: Hal V. Engel [EMAIL PROTECTED] Date: Sat, 8 Jan 2005 14:09:29 -0800 You can add me to the list. I also leave my originals alone. As you=20 say this is just good photographic practice. I have negatives that=20 are almost 70 years old that are in nearly new condition that I got=20 from my fathers photo collection before he died and I have my own=20 collection of negatives and slides that goes back about 45 years. All=20 have been carefully stored and are only touched to make=20 copies (digital now days). My brother is a professional=20 photographer and he also leaves his digital originals alone and only=20 edits copies. I am sure that there are others on this list that also=20 agree but have not said so on the list. In any case I don't see any=20 reason to not do the same with digital originals.=20 It occurred to me that there's another reason not to change so much as a single bit of images: the ability to verify that an original is indeed an original. Some cameras, such as the Canon EOS 1D Mark II, are capable of signing the image, so that it can be verified that the image is unmodified. See http://consumer.usa.canon.com/ir/controller?act=ModelFeaturesActfcategoryid=139modelid=9808#f3. Changing the image in the slightest -- including a lossless rotation -- would destroy this signature. Someone with this camera who needs to be able to verify photographs (perhaps because they're being used as evidence in court) could not use exiftran. Someone may want to preserve that signature, while still editing the photograph and saving it under a different name. The basic point here is that changes to the original digital file are *irreversible*, no matter how minor one thinks they may be. Photographers don't like making even the smallest irreversible changes to their master images, for good reason. I've given a specific reason, in addition to the general reason. Please don't do anything that makes life difficult for photographers who wish to perfectly preserve their originals! -- 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
Hi, Selon Michael Schumacher [EMAIL PROTECTED]: 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/ When that's ready to commit, it may well supercede part of what Bill has done, but I'm in favour of this code (which works, and does something which is often requested) going into CVS. An awful lot of the code in CVS is going to be replaced and has been like that for year - we should not wait for a module which is in the works, when there is code written already which gives people features now. We're not talking about someone duplicating effort, since the effort is already done. I thought it was amusing that someone said to Bill that storing metadata in lots of little parasites is not the right thing - 2 years ago, people told me exactly the opposite. 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, 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
Re: [Gimp-developer] jpeg-exif development summary
Robert Krawitz wrote: 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? That would be a reasonable thing to do: Rotate images if exif says so?: _Always _Never _Ask each time. But we have a high threshold nowadays for adding new preferences, so this is something that probably won't happen until it's clear that a lot of people want it. The other thing: GIMP has preserved exif data in jpeg files since 1.3, by passing it through without alteration. This means if you have opened an exif jpeg file in 2.0 or 2.2, edited it, and saved the result as jpeg, it will have exif, but the exif will no longer accurately describe the file in all respects. In particular, the exif will still indicate the image as rotated even if you have transformed it in GIMP. (Of course the most important information is all the camera settings, and there is never any reason to update that, so passing the exif through unchanged was vastly better than simply deleting it.) 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 Wed, Jan 05, 2005 at 06:27:16PM +0100, 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. what are the 10% of the digital cameras that do not have embedded DOS and what is it that they use? 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
On Wed, 5 Jan 2005, William Skaggs wrote: Date: Wed, 5 Jan 2005 07:47:10 -0800 From: William Skaggs [EMAIL PROTECTED] To: gimp-developer@lists.xcf.berkeley.edu Cc: @mail.primate.ucdavis.edu Subject: Re: [Gimp-developer] jpeg-exif development summary Robert Krawitz wrote: 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? That would be a reasonable thing to do: Rotate images if exif says so?: _Always _Never _Ask each time. But we have a high threshold nowadays for adding new preferences, so this is something that probably won't happen until it's clear that a lot of people want it. I hope you will consider that the simplest thing to do is to follow the specification and try to do things in such a way that in the long run there should be no need for a prompt or a preference? I do realise thatrotating the view without rotating the image itself is making things complicated but perhaps it would be possible to have the importer take care of the rotation and the exporter rotating back as needed, and still preserving all EXIF metadata? - Alan H. ___ 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 Wed, Jan 05, 2005 at 10:15:06PM +0100, Daniel Egger wrote: 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; for one DOS has too many limitation with regards to linear addressing of memory to be useful for such a device and second you'll have a hard time finding a DOS implementation outside of x86 CPUs and believe it or not but those tend to be the worst choice of processor for battery powered devices. canon rebel uses DOS. 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
Date: Wed, 5 Jan 2005 07:47:10 -0800 From: William Skaggs [EMAIL PROTECTED] Robert Krawitz wrote: 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? That would be a reasonable thing to do: Rotate images if exif says so?: _Always _Never _Ask each time. But we have a high threshold nowadays for adding new preferences, so this is something that probably won't happen until it's clear that a lot of people want it. 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. Another way of handling this would be to show the message, but have a check box Don't show this message again. Firefox has this for a lot of the security warnings (like warning you if you fill in a form that's posted over the net). -- 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 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
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 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
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
