Re: [Gimp-developer] EXIF information in JPEG files
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 part of the problem. If someone adds metadata that's > not documented, that's a problem. It's a problem because there's no > one place that someone can go and say that they have the definitive > list of parasites. That's fine if there are only a few, but if there > are many, tracking them becomes a chore. And more it leads to the > possibility of inconsistency. [snip] > > I think it's much easier to just look at the documentation rather > > than to run through header files until I can find what I need, > > hopefully with a sparse one-line comment, even. > > That's fine, when the documentation is accurate - if it lags behind > (and anyone who thinks it doesn't is living in a dreaml world) it > becomes at best redundant and at worst misleading. > > > parasites were created for metadata. If they don't work well > > enough for that parasites should be improved, rather than becoming a > > legacy layer. > > To handle something like what we're talking about, you'd need > something paralleling the PDB - a parasite database. And that seems > to me like overkill. While I think that the problems with inconsistancy are overrated -- mitch and sven seem to review every cvs commit and wouldn't reluctant to revert a commit that adds a parasite without adding it to devel-docs/parasites.txt -- I also don't see why adding a PDB-style self-documenting parasite registry would be bad either. The advantage would be that there would be one place to read about all the parasites, even those that are not included with the GIMP. Before a plug-in could attach a parasite, the parasite would have to be registered. The registration function would take three parameters: the name of the parasite, a blurb about what it does, and the format that the parasite is stored in. (UTF-8, 7-bit ASCII, string representation of a float, etc.) Perhaps even a custom format could be provided that calls a custom verification function. Since more than one plug-in might use a parasite, but all of them have to register the parasite, it's possible that the information registered can conflict. It seems best to make the second registration function fail should the formats be different, but if the blurb is different, it is probably best to silently ignore it. What do you think? Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] EXIF information in JPEG files
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 should not be attached at all. > appropriate for each file format to/from UTF-8 if necessary. Oh yes, oh yes! ;) -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: [Gimp-user] Opening Photoshop Files
Sven Neumann wrote: > Script-Fu is still adding layers while I write this and the count is > approaching 4000 layers of 16x16 pixels here. At the moment gimp uses > about 330MB of virtual memory (256MB physical RAM). The script has > (gimp-displays-flush) after (gimp-image-add-layer ...), so the layers > dialog is fighting to keep up with the amount of layers You could try duplicating an existing layer multiple times instead of creating new ones, so the copy-on-write code saves you memory. If your layer is 16x16 though, I imagine that the per-layer thumbs are taking more memory than the layer data! I think it'd still be a fair comparison if you closed the layers dialog -- an image with 1000s of layers is probably not expected to be managable sanely with what amounts to a list paradigm. -- Adam D. Moss. ,,^^[EMAIL PROTECTED]http://www.foxbox.org/ co:3 But not us (no never) no not us (no never) We are far too young and clever ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: [Gimp-user] Opening Photoshop Files
At 8:37 PM +0100 2/7/02, Sven Neumann wrote: >I hope do be able to complete the new text tool anytime soon and it >is supposed to give you even better rendering than gimp-freetype >combined with the features of GDynText. Will it still use FreeType for the actual rendering of the glyphs? And if not, then what? Leonard -- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] How's CVS-HEAD?
Luc NOVALES wrote: > > essai sorry for this spam, I hope to change the address for an internal filtering test. Luc. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: [Gimp-user] Opening Photoshop Files
Hi, "Branko Collin" <[EMAIL PROTECTED]> writes: > On 7 Feb 2002, at 9:29, Jon Winters wrote: > > > Went to an Adobe conference yesterday and they claim photoshop 6 has > > been tested with images up to 8000 layers. They said it can probably > > handle more but that is where they stopped testing. How many layers > > are we supporting? (heh... memory is cheap!) > > My GIMP crashed somewhere between the 300th and 400th 16x16 layer. I > could not see exactly which layer, because I kept stabbing the mouse > button quickly and after the 100th layer or so, the refresh of the > Layers dialog could not keep up with me. Script-Fu is still adding layers while I write this and the count is approaching 4000 layers of 16x16 pixels here. At the moment gimp uses about 330MB of virtual memory (256MB physical RAM). The script has (gimp-displays-flush) after (gimp-image-add-layer ...), so the layers dialog is fighting to keep up with the amount of layers and the scrollbar already shows that GTK+-1.2 has a problem with X coordinates being limited to 16bit. Let's see how far I can get, but I guess 8000 layers shouldn't be a problem with enough RAM and if you bring enough time. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] How's CVS-HEAD?
essai ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] How's CVS-HEAD?
On Thu, Feb 07, 2002 at 08:06:19PM +, Adam D. Moss wrote: > Sven Neumann wrote: > > > mct:~> gimp-1.3 > > > gimp-1.3: fatal error: Segmentation fault > > > gimp-1.3 (pid:9613): [E]xit, [H]alt, show [S]tack trace or [P]roceed: s > > > #0 0x40550924 in g_on_error_stack_trace (prg_name=0xb833 > > > "gimp-1.3") > > > #1 0x4055083e in g_on_error_query (prg_name=0xb833 "gimp-1.3") > > > #2 0x80816cd in gimp_eek (reason=0x819cea8 "fatal error", > > > #3 0x808162e in gimp_fatal_error (fmt=0x40676e90 "Segmentation fault") > > > #4 0x8081225 in gimp_sigfatal_handler (sig_num=11) at main.c:501 > > > #5 0x405c7858 in sigaction () from /lib/libc.so.6 > > > #6 0x40564428 in g_main_context_iterate (context=0x8243550, block=0, > > > #7 0x40564635 in g_main_context_pending (context=0x0) at gmain.c:2261 > > > #8 0x40129e8e in gtk_events_pending () at gtkmain.c:863 > > > #9 0x808e980 in user_install_continue_callback (widget=0x825e568, > > > > well, naturally I can't reproduce this here. I've removed my > > ~/.gimp-1.3 directory and was able to finish user installation w/o a > > problem. I can't see anything wrong with the code either: > > > > while (gtk_events_pending ()) > > gtk_main_iteration (); > > The crash is actually occurring inside gtk/glib-1.3 (joy!) but > I haven't de-toxed enough yet to look deeper. > > *looks deeper anyway* > > Ah cool, a glib rebuild from today's HEAD stops me crashing. > > Thanks, now I almost have a working gimp! (After the > current recompile, hopefully!) I doubt it's a gimp issue. Owen broke some main loop stuff for about a day in CVS. -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Re: [Gimp-user] Opening Photoshop Files
[EMAIL PROTECTED] (2002-02-07 at 2038.50 +0100): > > Went to an Adobe conference yesterday and they claim photoshop 6 has > > been tested with images up to 8000 layers. They said it can probably > My GIMP crashed somewhere between the 300th and 400th 16x16 layer. I I went up to 420 by hand (64 * 64 pix, and not big RAM usage, BTW), no crash and dialog updated (can I say Windows problem?). And now that some people seems to have a layer festish, maybe a script that adds 256 (or choose a number) per run could be done, so some people become happy. But also... how many layers are really useful? IOW, "my foo can do n^2 bars" vs "user just uses n". Of course, the fun factor is there, "this script goes up to n^n in one click". :P GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] How's CVS-HEAD?
Sven Neumann wrote: > > mct:~> gimp-1.3 > > gimp-1.3: fatal error: Segmentation fault > > gimp-1.3 (pid:9613): [E]xit, [H]alt, show [S]tack trace or [P]roceed: s > > #0 0x40550924 in g_on_error_stack_trace (prg_name=0xb833 > > "gimp-1.3") > > #1 0x4055083e in g_on_error_query (prg_name=0xb833 "gimp-1.3") > > #2 0x80816cd in gimp_eek (reason=0x819cea8 "fatal error", > > #3 0x808162e in gimp_fatal_error (fmt=0x40676e90 "Segmentation fault") > > #4 0x8081225 in gimp_sigfatal_handler (sig_num=11) at main.c:501 > > #5 0x405c7858 in sigaction () from /lib/libc.so.6 > > #6 0x40564428 in g_main_context_iterate (context=0x8243550, block=0, > > #7 0x40564635 in g_main_context_pending (context=0x0) at gmain.c:2261 > > #8 0x40129e8e in gtk_events_pending () at gtkmain.c:863 > > #9 0x808e980 in user_install_continue_callback (widget=0x825e568, > > well, naturally I can't reproduce this here. I've removed my > ~/.gimp-1.3 directory and was able to finish user installation w/o a > problem. I can't see anything wrong with the code either: > > while (gtk_events_pending ()) > gtk_main_iteration (); The crash is actually occurring inside gtk/glib-1.3 (joy!) but I haven't de-toxed enough yet to look deeper. *looks deeper anyway* Ah cool, a glib rebuild from today's HEAD stops me crashing. Thanks, now I almost have a working gimp! (After the current recompile, hopefully!) -- Adam D. Moss. ,,^^[EMAIL PROTECTED]http://www.foxbox.org/ co:3 But not us (no never) no not us (no never) We are far too young and clever ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: [Gimp-user] Opening Photoshop Files
Hi, Raphael Quinet <[EMAIL PROTECTED]> writes: > We need a big merge and re-write of GFig, GDynText, the FreeType > plug-in, the Path tool and the layers dialog in order to make all of > this possible. This is not a trivial task. I am not opposed to it > and I think that it would be a very good idea. Unfortunately, nothing > will happen until someone has the time (and skills) to implement these > nice features. I hope do be able to complete the new text tool anytime soon and it is supposed to give you even better rendering than gimp-freetype combined with the features of GDynText. Development on this tool has stalled a little but I'm planning to take up work on it soon. Let's see what we can do about the path tool. Simon started to hack on this, but I have no idea how far he's come. On the other hand we should probably decide on the feature-set for 1.4 soon and I don't think we should try to add sophisticated stuff like vector layers to 1.4 since it would probably delay the release too much. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: [Gimp-user] Opening Photoshop Files
On 7 Feb 2002, at 9:29, Jon Winters wrote: > Went to an Adobe conference yesterday and they claim photoshop 6 has > been tested with images up to 8000 layers. They said it can probably > handle more but that is where they stopped testing. How many layers > are we supporting? (heh... memory is cheap!) My GIMP crashed somewhere between the 300th and 400th 16x16 layer. I could not see exactly which layer, because I kept stabbing the mouse button quickly and after the 100th layer or so, the refresh of the Layers dialog could not keep up with me. -- branko collin [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] EXIF information in JPEG files
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 the > gimp- Why is metadata plug-in independent? > group. But there's nothing that forces people to honour any parasite > naming Yes there is, it's called rules and conventions. The gimp is not about bondage and discipline. > convention. I could write a plug-in that creates a parasite with a name > not starting with gimp- and uise it in the core, or with the name gimp- > and use it only in one plug-in. You could. You could also send the gimp process a kill signal at anytime. That doesn't make it correct, or right to do. > > one or 50 doesn't really matter, as long as it's documented. > > That's the major part of the problem. If someone adds metadata that's > not > documented, that's a problem. Yes. > It's a problem because there's no one > place > that someone can go and say that they have the definitivelist of > parasites. Sure, the documentation. > That's fine if there are only a few, but if there are many, tracking > them > becomes a chore. And more it leads to the possibility of > inconsistency. Another abstraction layer, of course, doesn't help getting rid of inconsistency. > Yes, it does. We would have one parasite, named something original > like > gimp-image-metadata, and in one header file somewhere we would have > the definition of the gimp-image-metadata structure, and the > prototypes of > the parsing functions.If someone added an extra bit of metadata and > forgot > to document it in the docs, well it's there in the code in the one > place where > all the fields supported in the metadata are - one place, definitive. So what does this buy us, apart from anothe rlevel of indiraction, to the current approach which also does all this? > > The parasites provide a namespace for this. Inventing > > yet-another-metadata-in-metadata-abstraction doesn't buy clarity. > > Perhaps not, but it buys consistency. You repeat this again and again. But people fail to see this. > That's fine, when the documentation is accurate - if it lags behind > anyone who thinks it doesn't is living in a dreaml world) it becomes > best redundant and at worst misleading. Adding yet another place where this has to be documented does not, in my eyes, improve the situation. > No, because the PNG developer has the definitive list of parasitres in > the image metadata definition. If he's adding a new bit of metadata > he's adding it there. And in that case, the duplication should be obvious. "the definitive list" and "adding new bit of metadata" contradict each other, at least in my mind. > If someone could convince me that there were a way to get a list of > all the parasites in use in the gimp (core and plug-ins) using the current > structure of things, then I'd probably go along. I just have this use grep ;) > vision of having a gimp-image-metadata-author in one plug-in, and > gimp-metadata-author in another, and gimp-image-author in another, If you mean that this should not happen, I agree. But how would the other approach help this? One author could add a author field and another an image-author field to the structure. Again, another level of abstraction doesn't help at all. Either one avoids these bugs, or not. > and so on. Possibly not for something as obvious as that, but you get > my point. Yes, but instead you should gice points on why another metadata layer would solve the existing problems. IMnsHO doing the same thing in a slightly different way only increases the places where problems occur. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: [Gimp-user] Opening Photoshop Files
On Thu, 07 Feb 2002, Jon Winters wrote: > Went to an Adobe conference yesterday and they claim photoshop 6 has been > tested with images up to 8000 layers. They said it can probably handle > more but that is where they stopped testing. How many layers are we > supporting? (heh... memory is cheap!) Is there a limit? Does anybody have a machine with more than 4 GB of RAM to do some serious testing? ;-) > The other biggie was limited support for _vector_ > stuff. Mainly type but you are also able to import layers from > Illustrator files. It would be kinda cool to pull in gfig elements and > keep them as vector layers when the image is saved as .xcf.gz > The vector layers would be rasterized as part of export to some other > image format. [...] > I've seen requests for some of this functionality before and I've also > seen gimp developers belly ache about it. I know Gimp is a bitmap > program... I also know Photoshop _used_to_be_ a bitmap program and now > their users have some really nice tools that I would like to see in the > Gimp some day. There are several wishlist items related to the support for vectors. Start with this one: http://bugzilla.gnome.org/show_bug.cgi?id=68915 ...and then follow the links to bug #61786, #6893 and #70499. Some time ago, I also thought that the GIMP was a bitmap program and should not mess with vectors, except for selections (paths). But now I have changed my mind. If you look at the commercial programs on the market today, most of the major paint programs have integrated more and mode vector functions: JASC's PaintShopPro, Adobe PhotoShop, the Corel suite, and probably others. We need a big merge and re-write of GFig, GDynText, the FreeType plug-in, the Path tool and the layers dialog in order to make all of this possible. This is not a trivial task. I am not opposed to it and I think that it would be a very good idea. Unfortunately, nothing will happen until someone has the time (and skills) to implement these nice features. > > Until then... Keep up the Good Work! GO WILBUR! GO WILBER! Wilber, not Wilbur! ;-) -Raphael ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: [Gimp-user] Opening Photoshop Files
Went to an Adobe conference yesterday and they claim photoshop 6 has been tested with images up to 8000 layers. They said it can probably handle more but that is where they stopped testing. How many layers are we supporting? (heh... memory is cheap!) There were also some very interesting new features in Photoshop 6 including a tool called the "extractor" that can do (good) clipping paths very very quickly. The demo was impressive but the image they started with was probably hand picked so it worked perfectly with the extractor every time. The other biggie was limited support for _vector_ stuff. Mainly type but you are also able to import layers from Illustrator files. It would be kinda cool to pull in gfig elements and keep them as vector layers when the image is saved as .xcf.gz The vector layers would be rasterized as part of export to some other image format. Another very interesting tool was the ability to export an image to SWF where each layer becomes a frame in the flash animation. The demonstration used something sorta like a gimp hose brush to spray some leaves in an "S" pattern. Then they did something to automatically break each leaf the brush sprayed into its own layer. When exported to .swf it generated the file along with a web page containing the HTML to embed the movie. When you played it the leaf moved across the movie following the S pattern. (simmilar to how we do .gif anims but this was going to .swf) I've seen requests for some of this functionality before and I've also seen gimp developers belly ache about it. I know Gimp is a bitmap program... I also know Photoshop _used_to_be_ a bitmap program and now their users have some really nice tools that I would like to see in the Gimp some day. I would code this stuff myself if I knew how... I'm learning... Some day I'll check something in. Until then... Keep up the Good Work! GO WILBUR! -- Jon Winters O 0 0 0 0 0 0 "History Will Prove us right" http://www.obscurasite.com/jon/ / \ / \ / \ / \ / \ / \ / \ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] EXIF information in JPEG files
Marc Lehmann wrote: > 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 deal with these. The > core also is: This is untrue (or at least, true only by convention). There's a solid argument that all metadata is plug-in independant, and therefore belongs in the gimp- group. But there's nothing that forces people to honour any parasite naming convention. I could write a plug-in that creates a parasite with a name not starting with gimp- and uise it in the core, or with the name gimp- and use it only in one plug-in. > > the aim of having a metadata editor at some stage, 50 or 60 pieces of > > metadata with (possibly) non-standard naming is complicated. > > 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 part of the problem. If someone adds metadata that's not documented, that's a problem. It's a problem because there's no one place that someone can go and say that they have the definitivelist of parasites. That's fine if there are only a few, but if there are many, tracking them becomes a chore. And more it leads to the possibility of inconsistency. > > You say that any piece of metadata can easily be accessed by name. The > > problem is going to be: What name? I think keeping stuff in one place > > offers consistency. > > Well, the everything-in-a-big-blob-approach doesn't help naming at all. At > one point you simply have to make up names to access the exif information. Yes, it does. We would have one parasite, named something original like gimp-image-metadata, and in one header file somewhere we would have the definition of the gimp-image-metadata structure, and the prototypes of the parsing functions.If someone added an extra bit of metadata and forgot to document it in the docs, well it's there in the code in the one place where all the fields supported in the metadata are - one place, definitive. > The parasites provide a namespace for this. Inventing > yet-another-metadata-in-metadata-abstraction doesn't buy clarity. Perhaps not, but it buys consistency. > I think it's much easier to just look at the documentation rather than to > run through header files until I can find what I need, hopefully with a > sparse one-line comment, even. That's fine, when the documentation is accurate - if it lags behind (and anyone who thinks it doesn't is living in a dreaml world) it becomes at best redundant and at worst misleading. > parasites were created for metadata. If they don't work well > enough for that parasites should be improved, rather than becoming a > legacy layer. To handle something like what we're talking about, you'd need something paralleling the PDB - a parasite database. And that seems to me like overkill. > > the TIFF plug-in, the PNG developer knows nothing about it - if I as a > > lazy developer didn't add it to the list of supported metadata he > > wouldn't know it existed. And let's say I as the PNG developer want to > > use the same data, but I call it a slightly different name - now we > > have two parasites which do the same thing. > > Your approach suffers exactly the same problem, btw. No, because the PNG developer has the definitive list of parasitres in the image metadata definition. If he's adding a new bit of metadata he's adding it there. And in that case, the duplication should be obvious. > And the most natural place for this is parasites, which exist only to hold > metadata. If their definition isn't clear enough then this is the problem > to solve. Adding yet another layer makes the situation worse, not better > ;) (I left in the wink just in case there was a subtlety there I missed :) ) If someone could convince me that there were a way to get a list of all the parasites in use in the gimp (core and plug-ins) using the current structure of things, then I'd probably go along. I just have this terrible vision of having a gimp-image-metadata-author in one plug-in, and gimp-metadata-author in another, and gimp-image-author in another, and so on. Possibly not for something as obvious as that, but you get my point. Cheers, Dave. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] EXIF information in JPEG files
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? Uh - it already *is* hierarchical: that's exactly what: gimp-* gimp-exif-* etc are! It's hierarchical by convention, and this isn't checked, sure. But it's quick and easy. Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] EXIF information in JPEG files
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 not
> > persistent) because they only make sense for the original file format
>
> It might hurt, but I think the best thing is to not attach these values at
> all, as there is no semantics attached to them until the core recognizes
> and modifies them properly on edits (at least for most values).
A large part of the EXIF data can be useful for other plug-ins, so it
would use the "gimp-*" namespace for the parasites the semantics of
each parasite would be known.
Other parts of the EXIF data are less interesting, usually because
they describe some properties of the file format that would be changed
when the image is saved into a new file (for example, "RowsPerStrip",
"SamplesPerPixel", "JPEGInterchangeFormatLength"). I think that we
should use non-persistent parasites for these parts. The data would
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.
Even if the core does not make use of this information, it could still
be displayed to the user by a "File->Properties" plug-in. The dialog
window created by this plug-in could provide several tabs that are
specific to some file formats. There would be at least one or two
tabs for the EXIF data, even for the non-persistent parts. I think
that it would be very interesting for the user to know a bit more
about the properties of the original file, even if these properties
are lost after the conversion to a flat RGB bitmap. Even tools such
as ImageMagick's identify do not always provide the information that I
am looking for, although I know that it is loaded and parsed by the
application.
> The biggest problem is the format inside parasites - i personally dislike
> gserialize (unused anyway), and strongly favour very simple decomposing,
> i.e. scalars ("single-valued string-thingy") where possible. So the more
> parasites the better ;)
I fully agree. All pieces of metadata can be decomposed to strings or
single numbers. Blocks of raw data should also be allowed for special
cases such as ICC color profiles, but only if these blocks are
following a well-specified format (including endianness and other
things that could cause problems on different platforms).
As Sven has already suggested, all text strings should use UTF-8
encoding. It would be up to each plug-in to convert whatever is
appropriate for each file format to/from UTF-8 if necessary.
Currently, even the usage of "gimp-comment" causes some problems
because some file formats (such as PNG) require ISO-8859-1 (Latin-1)
for the character set, some say that the comment should be encoded in
the user's current character set (how do you exchange files with
others, then?), some others require 7-bit ASCII and most of them do
not specify anything.
These strings should not have any constraints regarding their length
or format (single line or multiple lines of text). It should be up to
each plug-in to do the appropriate conversions if necessary.
On Wed, 06 Feb 2002, Sven Neumann <[EMAIL PROTECTED]> wrote:
> > And the most natural place for this is parasites, [...]
>
> 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?
No, all parts of the EXIF data can be stored in a flat list without
losing any information. There are some sub-structures such as the
GPSInfo, but that can easily be flattened as long as all parasites
start with the same prefix ("gimp-gps-latitude", "gimp-gps-longitude",
"gimp-gps-img-direction" and so on).
I had a look at some other file formats that can contain significant
amounts of metadata (PNG, TIFF, TGA) and I did not see anything that
would require more hierarchical structures. This is not completely
true because TIFF can be arbitrarily complex, but we will probably
never try to cover all sub-formats of the TIFF "standard".
-Raphael
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
