Having pissed everyone off at this stage with what must seem like
either cluelessness or intransigence (let me assure ye that neither
impression was intended), I'm going to let the thread (and the debate)
die finally... I have been looking at this in a slightly different way
to the way that I
On Wed, 06 Feb 2002, [EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) wrote:
On Wed, Feb 06, 2002 at 02:17:21PM +0100, Raphael Quinet
[EMAIL PROTECTED] wrote:
EXIF data and simply copy the descriptions given in the EXIF standard.
Some of the fields will have to be discarded (or set read-only or
On , 7 Feb 2002, Sven Neumann wrote:
exactly. If there's a need to improve the current parasites, let's do
that now. I could imagine that a more hierachical structure might
help, but I'd like to see a real usage case before we consider doing
such a change. Is the EXIF data such a usage case?
On Thu, Feb 07, 2002 at 04:09:01PM +0100, Dave Neary [EMAIL PROTECTED] wrote:
This is untrue (or at least, true only by convention). There's a solid
argument
(your mail is horribly mis-formatted and very hard to read, btw)
that all metadata is plug-in independant, and therefore belongs in
On Thu, Feb 07, 2002 at 02:45:03PM +0100, Raphael Quinet [EMAIL PROTECTED] wrote:
not be saved in a new file (unless it is reconstructed by the
JPEG/EXIF plug-in) but it would be available after the image has been
loaded.
If it is valid after the image is modified, yes. Otherwise I think it
On Thu, 7 Feb 2002, Dave Neary wrote:
Marc Lehmann wrote:
There is no such thing as non-standard naming in this case. exif
doesn't provide a standard name, so you need to make one up. Wether
oyu make up one or 50 doesn't really matter, as long as it's
documented.
That's the major
On Tue, 5 Feb 2002, Dave Neary wrote:
Raphael wrote:
There are several reasons for using individual parasites for each
part of the EXIF data instead of using a single parasite including
the whole structure:
[snipped points]
Your points all have merit. My problem is now, and has
On Wed, 06 Feb 2002, Adam D. Moss wrote:
Raphael Quinet wrote:
The only thing that is missing is a standard list of names and types
for all parasites.
{docs|devel-docs}/parasites.txt
Err... Right. I knew that the file existed (I took a look at it the
last time we discussed the
Raphael Quinet wrote:
But it needs to be extended with all the names of the EXIF parasites.
So I will try to do that this week. Basically, I think that it would
be enough to use the name gimp-blah for each blah field of the
EXIF data and simply copy the descriptions given in the EXIF
On Wed, 06 Feb 2002, Dave Neary wrote:
Parasite naming is non-standard. Anyone can create a parasite with any
name they want. [...]
Where *is* the list of parasites? There are only (as you point out)
about 10 persistent parasites, and the list isn't maintained anywhere.
One possible
On Tue, 06 Feb 2002, Adam D. Moss wrote:
Raphael Quinet wrote:
But it needs to be extended with all the names of the EXIF parasites.
So I will try to do that this week. Basically, I think that it would
be enough to use the name gimp-blah for each blah field of the
EXIF data and
http://www.ecs.soton.ac.uk/~njl98r/chocbox1.png
http://www.ecs.soton.ac.uk/~njl98r/chocbox2.png
A potential UI for a textual metadata editor using Dublin Core's element
names (and of course internally it could use any parasite names that
were deemed fit, but since parasite names are arbitrary
On Wed, 2002-02-06 at 16:06, Raphael Quinet wrote:
Thanks. I will have a look at it as soon as possible. But as I wrote
previously and as Dave agreed, it would probably make more sense to
merge this code directly into the JPEG plug-in instead of requiring an
additional library.
As this
Nick Lamb wrote:
One thing I can't seem to find out (maybe I'm looking in the wrong
place)
is whether EXIF data is supposed to follow derived works or not.
Some
contributors to this thread seemed to feel that it was important
that
a Gimp image must always preserve the EXIF data, but this
Raphael wrote:
On Wed, 06 Feb 2002, Dave Neary wrote:
Where *is* the list of parasites? There are only (as you point
out)
about 10 persistent parasites, and the list isn't maintained
anywhere.
OK, so now the problem is clear: we need a way to enforce some
consistency for the names of
On Wed, 6 Feb 2002, Nick Lamb wrote:
http://www.ecs.soton.ac.uk/~njl98r/chocbox2.png
^^^
Looks very nice, but please, please call the last field Copyright
instead of Digital Rights Management.
Rockwlrs
On Wed, 6 Feb 2002, Dave Neary wrote:
If we go with the more generic metadata option, then we would have
the option of gimp-metadata-*. But that's minutiae at the moment.
Isn't the fact that it's a parasite metadata-y enough? I suppose it's
possible to attach a parasite to an image for
On Wed, Feb 06, 2002 at 02:11:28PM +0100, Dave Neary [EMAIL PROTECTED] wrote:
Parasite naming is non-standard. Anyone can create a parasite with any
name they want.
Untrue. Names beginning with gimp- are well-defined as belonging to the
core. The gimp itself must, at one point, know how to
On Wed, Feb 06, 2002 at 03:41:17PM +0100, Lutz Müller [EMAIL PROTECTED]
wrote:
It would be _really_ easy if you used the tag names for those parasites,
i.e. gimp-exif-FillOrder or gimp-exif-SpectralSensitivity.
while i am not strictly opposed, these names are very ugly. more
important,
Hi,
[EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) writes:
But parasites _is_ one metadata structure. I don't see why nesting etadata
structures inside each other is a good thing - to me it only complicates
things. parasites were created for metadata. If they don't work well
enough for that
Raphael Quinet wrote:
The basic idea is that each file plug-in that supports metadata can
convert the EXIF data (or other meta-data) to/from GIMP parasites.
[snip]
Note that it is important
that each individual item in the EXIF data is converted to a
separate
GIMP parasite instead of
On Tue, 5 Feb 2002, Dave Neary wrote:
Raphael Quinet wrote:
[...] Note that it is important
that each individual item in the EXIF data is converted to a
separate GIMP parasite instead of importing the whole EXIF data in
one big chunk because [...]
I'm not sure I agree with you
Raphael wrote:
On Tue, 5 Feb 2002, Dave Neary wrote:
Raphael Quinet wrote:
[...] Note that it is important
that each individual item in the EXIF data is converted to a
separate GIMP parasite instead of importing the whole EXIF data
in
one big chunk because [...]
I'm not
On Tue, 2002-02-05 at 19:08, Raphael Quinet wrote:
Hi Lutz!
On Tue, 5 Feb 2002, Lutz Müller wrote:
PS: It would be nice if this mailing list program could automatically cc
replies to anyone sending mails to this list while not being subscribed
(like me).
Does this mean that you
On 4 Feb 2002, at 14:08, Lutz Müller wrote:
I have written an EXIF library in plain C (libexif) and some GTK+
widgets for displaying and modifying EXIF data (libexif-gtk). Both
are available on http://libexif.sourceforge.net. I use them to display
EXIF tags in gphoto2 (command-line frontend)
Hi Lutz,
I have written an EXIF library in plain C (libexif) and some GTK+
widgets for displaying and modifying EXIF data (libexif-gtk). Both
are
available on http://libexif.sourceforge.net. I use them to display
EXIF
tags in gphoto2 (command-line frontend) and gtkam (GTK+ GUI).
Thereare a
On Mon, 2002-02-04 at 14:29, Dave Neary wrote:
Thereare a couple of other libraries which do pretty much the same
thing -
see the relevant bug numbers in bugzilla (not sure what they are right
now).
I haven't had a chance to look closely at this, but it looks good.
There is python stuff, a
Hi,
Lutz Müller [EMAIL PROTECTED] writes:
So I am the third person looking at it :-)
I just don't know how to handle the dependency on libexif(-gtk). You
know, libexif itself is quite small and could be included in gimp
(although I'd keep it separately), but libexif-gtk is getting bigger
On Mon, 04 Feb 2002, Lutz Müller wrote:
On Mon, 2002-02-04 at 15:04, Sven Neumann wrote:
if it solves our problems and works for non-JPEG images too, I don't
see any problem in adding such a dependency to gimp-1.3.
EXIF information is specific to JPEG files. Therefore, editing and
On Mon, 2002-02-04 at 14:29, Dave Neary wrote:
(...)
Just so that you get an impression of libexif-gtk, I put up a screenshot
of gexif, a frontend to libexif-gtk, on
http://helena.bawue.de:8080/~lutz/projects/libexif/index.html
I imagine this dialog being accessible either through some menu or
30 matches
Mail list logo
