RSS/Atom feed Twitter
Site is read-only, email is disabled

jpeg-exif development summary

This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.

This is a read-only list on gimpusers.com so this discussion thread is read-only, too.

50 of 50 messages available
Toggle history

Please log in to manage your subscriptions.

jpeg-exif development summary William Skaggs 04 Jan 18:53
  jpeg-exif development summary Carol Spears 04 Jan 19:52
  jpeg-exif development summary Robert L Krawitz 05 Jan 05:12
   jpeg-exif development summary Dave Neary 05 Jan 18:27
    jpeg-exif development summary Carol Spears 05 Jan 18:58
    jpeg-exif development summary Daniel Egger 05 Jan 22:15
     jpeg-exif development summary Carol Spears 05 Jan 22:37
      jpeg-exif development summary Daniel Egger 05 Jan 23:08
       jpeg-exif development summary Robert L Krawitz 05 Jan 23:35
     jpeg-exif development summary Dave Neary 06 Jan 09:57
    jpeg-exif development summary Robert L Krawitz 06 Jan 02:14
  jpeg-exif development summary Sven Neumann 06 Jan 17:53
   jpeg-exif development summary Robert L Krawitz 06 Jan 18:20
    jpeg-exif development summary Simon Budig 06 Jan 18:36
     jpeg-exif development summary Robert L Krawitz 06 Jan 18:48
      jpeg-exif development summary Simon Budig 06 Jan 19:12
       jpeg-exif development summary Alastair M. Robinson 06 Jan 20:02
    jpeg-exif development summary Sven Neumann 06 Jan 18:49
     jpeg-exif development summary Robert L Krawitz 06 Jan 19:20
      jpeg-exif development summary Sven Neumann 06 Jan 21:21
   jpeg-exif development summary Seth Burgess 06 Jan 19:02
jpeg-exif development summary William Skaggs 04 Jan 20:00
  jpeg-exif development summary Carol Spears 04 Jan 21:46
jpeg-exif development summary William Skaggs 05 Jan 16:47
  jpeg-exif development summary Alan Horkan 05 Jan 21:14
  jpeg-exif development summary Robert L Krawitz 06 Jan 02:18
   jpeg-exif development summary Sven Neumann 06 Jan 16:34
    jpeg-exif development summary Robert L Krawitz 06 Jan 16:44
     jpeg-exif development summary Sven Neumann 06 Jan 17:29
      jpeg-exif development summary Simon Budig 06 Jan 17:50
    jpeg-exif development summary David Neary 06 Jan 22:28
  jpeg-exif development summary Raphaël Quinet 19 Jan 14:39
jpeg-exif development summary William Skaggs 06 Jan 20:20
  jpeg-exif development summary David Gómez 06 Jan 20:40
  jpeg-exif development summary Sven Neumann 06 Jan 21:28
   jpeg-exif development summary Akkana Peck 08 Jan 20:24
    jpeg-exif development summary Robert L Krawitz 08 Jan 22:40
     jpeg-exif development summary Hal V. Engel 08 Jan 23:09
      jpeg-exif development summary Robert L Krawitz 09 Jan 00:56
    jpeg-exif development summary Sven Neumann 08 Jan 22:48
    jpeg-exif development summary Jakub Steiner 10 Jan 16:52
     jpeg-exif development summary Daniel Egger 10 Jan 17:44
      jpeg-exif development summary Robert L Krawitz 11 Jan 04:41
       jpeg-exif development summary Sven Neumann 11 Jan 10:27
jpeg-exif development summary William Skaggs 06 Jan 23:27
  jpeg-exif development summary Michael Schumacher 06 Jan 23:50
   jpeg-exif development summary Dave Neary 07 Jan 14:34
    jpeg-exif development summary Sven Neumann 08 Jan 13:57
jpeg-exif development summary William Skaggs 07 Jan 00:45
jpeg-exif development summary shaneyfelt@juno.com 08 Jan 21:19
William Skaggs
2005-01-04 18:53:01 UTC (about 19 years ago)

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.ucdavis.edu

Carol Spears
2005-01-04 19:52:46 UTC (about 19 years ago)

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

William Skaggs
2005-01-04 20:00:29 UTC (about 19 years ago)

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

Carol Spears
2005-01-04 21:46:29 UTC (about 19 years ago)

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

Robert L Krawitz
2005-01-05 05:12:59 UTC (about 19 years ago)

jpeg-exif development summary

Date: Tue, 4 Jan 2005 09:53:01 -0800 From: "William Skaggs"

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.

William Skaggs
2005-01-05 16:47:10 UTC (about 19 years ago)

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

Dave Neary
2005-01-05 18:27:16 UTC (about 19 years ago)

jpeg-exif development summary

Hi,

Selon Robert L Krawitz :

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.

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.

Cheers,
Dave.

--
Dave Neary
Lyon, France

Carol Spears
2005-01-05 18:58:58 UTC (about 19 years ago)

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

Alan Horkan
2005-01-05 21:14:57 UTC (about 19 years ago)

jpeg-exif development summary

On Wed, 5 Jan 2005, William Skaggs wrote:

Date: Wed, 5 Jan 2005 07:47:10 -0800 From: William Skaggs
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.

Daniel Egger
2005-01-05 22:15:06 UTC (about 19 years ago)

jpeg-exif development summary

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. I haven't yet disassembled one of my cameras but I bet each of them is either powered by a DSP (from TI maybe) or a powerful but very powerefficient RISC design (PowerPC, ARM, SPARC, ... you name it) or a custom design with any of the above included.

BTW: Implementing FAT12/16 is so simple that one can take a course in university to learn it.

Servus, Daniel

Carol Spears
2005-01-05 22:37:39 UTC (about 19 years ago)

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

Daniel Egger
2005-01-05 23:08:33 UTC (about 19 years ago)

jpeg-exif development summary

On 05.01.2005, at 22:37, Carol Spears wrote:

canon rebel uses DOS.

Possibly only as a bootloader or datashifter.

According to http://www.alexbernstein.com/wiki/CanonDigitalRebelHacking the camera has three different processors and it is more than unlikely that the 80186 compatible processor is used for much more than filesystem handling and starting a different operating system or delegating the work to dedicated ASICs.

Servus, Daniel

Robert L Krawitz
2005-01-05 23:35:01 UTC (about 19 years ago)

jpeg-exif development summary

From: Daniel Egger
Date: Wed, 5 Jan 2005 23:08:33 +0100

> canon rebel uses DOS.

Possibly only as a bootloader or datashifter.

According to http://www.alexbernstein.com/wiki/CanonDigitalRebelHacking the camera has three different processors and it is more than unlikely that the 80186 compatible processor is used for much more than filesystem handling and starting a different operating system or delegating the work to dedicated ASICs.

I would guess the latter -- delegating the work to dedicated ASIC's. Generating JPEG's from raw files is a very specialized task that's very compute-intensive in some ways but which could probably be implemented quite cheaply in hardware.

Robert L Krawitz
2005-01-06 02:14:36 UTC (about 19 years ago)

jpeg-exif development summary

Date: Wed, 5 Jan 2005 18:27:16 +0100 From: Dave Neary

Selon Robert L Krawitz : > 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.

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.

There's nothing wrong with digital cameras *creating* 8.3 files. The problem is the *requirement* that EXIF files have 8.3 names. This makes me concerned that some EXIF programs will gratuitously enforce this requirement. There are PPD-using applications that choke on non-conformant file names (or complain if the *PCFileName attribute is missing or ill-formed).

Robert L Krawitz
2005-01-06 02:18:00 UTC (about 19 years ago)

jpeg-exif development summary

Date: Wed, 5 Jan 2005 07:47:10 -0800 From: "William Skaggs"

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).

Dave Neary
2005-01-06 09:57:01 UTC (about 19 years ago)

jpeg-exif development summary

Hi,

Selon Daniel Egger :

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

Sven Neumann
2005-01-06 16:34:54 UTC (about 19 years ago)

jpeg-exif development summary

Hi,

Robert L Krawitz 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

Robert L Krawitz
2005-01-06 16:44:23 UTC (about 19 years ago)

jpeg-exif development summary

From: Sven Neumann
Date: Thu, 06 Jan 2005 16:34:54 +0100

Robert L Krawitz 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?

I keep master copies untouched and rely on applications to show the implied rotation.

Sven Neumann
2005-01-06 17:29:29 UTC (about 19 years ago)

jpeg-exif development summary

Hi,

Robert L Krawitz 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.

Sven

Simon Budig
2005-01-06 17:50:46 UTC (about 19 years ago)

jpeg-exif development summary

Sven Neumann (sven@gimp.org) wrote:

Robert L Krawitz 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

Sven Neumann
2005-01-06 17:53:35 UTC (about 19 years ago)

jpeg-exif development summary

Hi,

"William Skaggs" 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

Robert L Krawitz
2005-01-06 18:20:17 UTC (about 19 years ago)

jpeg-exif development summary

From: Sven Neumann
Date: Thu, 06 Jan 2005 17:53:35 +0100

"William Skaggs" writes:

> 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.

I don't buy this. I simply copy images off the camera and leave them alone.

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.

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.

Simon Budig
2005-01-06 18:36:50 UTC (about 19 years ago)

jpeg-exif development summary

Robert L Krawitz (rlk@alum.mit.edu) 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

Robert L Krawitz
2005-01-06 18:48:54 UTC (about 19 years ago)

jpeg-exif development summary

Date: Thu, 6 Jan 2005 18:36:50 +0100 From: Simon Budig

Robert L Krawitz (rlk@alum.mit.edu) 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.

Sven Neumann
2005-01-06 18:49:17 UTC (about 19 years ago)

jpeg-exif development summary

Hi,

Robert L Krawitz 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

Seth Burgess
2005-01-06 19:02:00 UTC (about 19 years ago)

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

Simon Budig
2005-01-06 19:12:15 UTC (about 19 years ago)

jpeg-exif development summary

Robert L Krawitz (rlk@alum.mit.edu) wrote:

Date: Thu, 6 Jan 2005 18:36:50 +0100 From: Simon Budig

Robert L Krawitz (rlk@alum.mit.edu) 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

Robert L Krawitz
2005-01-06 19:20:21 UTC (about 19 years ago)

jpeg-exif development summary

From: Sven Neumann
Date: Thu, 06 Jan 2005 18:49:17 +0100

Robert L Krawitz 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?

Alastair M. Robinson
2005-01-06 20:02:03 UTC (about 19 years ago)

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

William Skaggs
2005-01-06 20:20:52 UTC (about 19 years ago)

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

David Gómez
2005-01-06 20:40:37 UTC (about 19 years ago)

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,

Sven Neumann
2005-01-06 21:21:42 UTC (about 19 years ago)

jpeg-exif development summary

Hi,

Robert L Krawitz 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

Sven Neumann
2005-01-06 21:28:14 UTC (about 19 years ago)

jpeg-exif development summary

Hi,

"William Skaggs" 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

David Neary
2005-01-06 22:28:39 UTC (about 19 years ago)

jpeg-exif development summary

Hi,

Sven Neumann wrote:

Robert L Krawitz 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.

William Skaggs
2005-01-06 23:27:54 UTC (about 19 years ago)

jpeg-exif development summary

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.

Best, -- Bill


______________ ______________ ______________ ______________ Sent via the CNPRC Email system at primate.ucdavis.edu

Michael Schumacher
2005-01-06 23:50:55 UTC (about 19 years ago)

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

William Skaggs
2005-01-07 00:45:46 UTC (about 19 years ago)

jpeg-exif development summary

Michael Schumacher wote:

There seems to be at least a bit of source code: http://wilber.gimp.org/~raphael/metadata/src/

Hmm. I was getting "Error 500" when I tried to access it two hours ago. Thank you.

Best, -- Bill


______________ ______________ ______________ ______________ Sent via the CNPRC Email system at primate.ucdavis.edu

Dave Neary
2005-01-07 14:34:12 UTC (about 19 years ago)

jpeg-exif development summary

Hi,

Selon Michael Schumacher :

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

Sven Neumann
2005-01-08 13:57:49 UTC (about 19 years ago)

jpeg-exif development summary

Hi,

Dave Neary writes:

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.

Which is why it should be brought up here instead of sneaked into CVS w/o any previous discussion.

Actually, no code should be committed to CVS at the moment until we have made up a roadmap that outlines what we want to achieve with GIMP 2.4.

Sven

Akkana Peck
2005-01-08 20:24:49 UTC (about 19 years ago)

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

shaneyfelt@juno.com
2005-01-08 21:19:35 UTC (about 19 years ago)

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

____________________

Robert L Krawitz
2005-01-08 22:40:25 UTC (about 19 years ago)

jpeg-exif development summary

Date: Sat, 8 Jan 2005 11:24:49 -0800 From: Akkana Peck

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.

Sven Neumann
2005-01-08 22:48:06 UTC (about 19 years ago)

jpeg-exif development summary

Hi,

Akkana Peck 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

Hal V. Engel
2005-01-08 23:09:29 UTC (about 19 years ago)

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

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 L Krawitz
2005-01-09 00:56:05 UTC (about 19 years ago)

jpeg-exif development summary

From: "Hal V. Engel"
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=ModelFeaturesAct&fcategoryid=139&modelid=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!

Jakub Steiner
2005-01-10 16:52:58 UTC (about 19 years ago)

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

Daniel Egger
2005-01-10 17:44:41 UTC (about 19 years ago)

jpeg-exif development summary

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.

Servus,
Daniel

Robert L Krawitz
2005-01-11 04:41:18 UTC (about 19 years ago)

jpeg-exif development summary

From: Daniel Egger
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!).

Sven Neumann
2005-01-11 10:27:38 UTC (about 19 years ago)

jpeg-exif development summary

Hi,

Robert L Krawitz 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

Raphaël Quinet
2005-01-19 14:39:25 UTC (about 19 years ago)

jpeg-exif development summary

On Wed, 5 Jan 2005 07:47:10 -0800, "William Skaggs" 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