Re: [Gimp-developer] Proposal for a GIMP metadata viewer/editor (EXIF/IPTC/XMP/...)
On Tue, 17 Aug 2004 15:58:20 +0200, Raphaël Quinet <[EMAIL PROTECTED]> wrote: > As some of you may remember, I started working on a metadata/parasite > editor a long time ago (bug #61499, bug #56443, bug #94416) but lost > most of it in a disk crash during a backup (doh!). Since my new > digital camera is begging for better metadata support in the GIMP > (starting with the EXIF orientation tag, bug #121810) I re-started > that work from scratch and built a new metadata viewer and editor. [...] > http://wilber.gimp.org/~raphael/metadata/ > I would like some feedback about that, and any help about the open > issues mentioned in the page would be more than welcome. [...] > If I am heading in the wrong direction or if I have overlooked > something, please tell me. I don't want to waste my time doing the > wrong things if I don't get any feedback. Well, I didn't get much feedback through this list, but I would like to thank Sven and Jimmac who discussed some issues on #gimp and Alan who also sent me some suggestions. During the weekend, I rewrote the XMP parser and I modified the code of the metadata editor so that it works better when all metadata is stored in a single GIMP parasite, using accessor functions so that other plug-ins can get/set the metadata through the appropriate PDB calls. There are still several open issues, but there at least two things for which I would need some help as soon as possible so that I can continue and hopefully finish the implementation: XMP files for testing the parser and some suggestions on how to exchange structured properties through the PDB. * XMP files for testing the parser: the new parser should be able to handle most (hopefully all) files that conform to the XMP specs, including some annoying features such as properties with qualifiers, language alternatives, etc. However, I have only been able to test the parser with the examples given in the XMP specs and some test files that I found (such as the Creative Commons templates for Adobe products). I would be very interested in getting more test files, either as standalone *.xmp files or as XMP embedded into some image formats (JPEG, TIFF, PNG) or even PDF or Adobe Illustrator files. If you have access to a tool that can generate XMP metadata (such as Photoshop 7 or CS, Illustrator 10 or later, ...) then please send me some files or tell me where I can fetch them. I am very interested in files that have one or more of the following features: - containing a description, title or rights statement in multiple languages (please also tell me how your tool allows you to enter multiple languages such as en_US, fr_FR... and how to select which one becomes the default); - containing metadata converted from EXIF; note that I mean XMP files with "exif:" and "tiff:" schemas converted from EXIF, not just files with metadata in a raw EXIF block; - containing XMP Media Management metadata (e.g., xmpMM:History); - containing some properties with qualifiers, such as a list of authors in which one is labeled as "composer", the other as "lyricist", etc. (please also tell me how you can enter this). In all cases, please tell me the name and version of the tool used to create the image or the metadata because there have been some changes to the XMP specs and I want to be able to support both the old and new versions. For example, the "exif:Flash" property is defined as a structed type in the current XMP specs (on page 68) but is shown as a simple integer value in some examples so I would like to know what can be seen in XMP packets from various tools. You can send the files or the link to the files directly to me by email (do not send files to this list!) but be sure to include both "GIMP" and "metadata" in the subject if you want to get past my spam filter. ;-) * How to exchange structured properties through the PDB: as explained in http://wilber.gimp.org/~raphael/metadata/#Issues I don't know what is the best way to pass the metadata via the PDB. Simple types could be passed as STRING and structured types could be passed as STRINGARRAY, but the annoying thing is that the XMP specs allow any property to get optional qualifiers. I could just discard the qualifiers (I don't know if they are used often in practice) but that wouldn't be very nice. I could also pass XML fragments instead of simple strings, but that would force all scripts and plug-ins to be able to parse XML if they want to be able to get or set metadata. This would be very annoying for Script-Fu or Tiny-Fu. I also don't know what is the best way to pass the array of thumbnail images for the xmp:Thumbnails array. XMP says that it should be an array of structures containing width, height, format and image as a base 64 encoded string. It would be nicer to be able to pass one or several DRAWABLEs instead of big strings. That would probably require
Re: [Gimp-developer] Of time, brushes and inks
Joao S. O. Bueno wrote: Too much silence. I see problems here :-) Probably means most people agree with the issue, but that I am not the only one who find it a hard question to deal with. I had tought on an unclean alternative to have a higher time resolution on gdk/gtk+ events, that would be to have a core GIMP time object with higher resolution. Events would then be timed GIMP side whenever they are received. The upside: this would not depend on other projetcs to implement. The downside: if for some reason the events get delayed to be passed to the GIMP, they'd be misshandled. I'm not sure that you understand the problem -- we need the timestamp of when the physical event occurred, NOT when it was de-queued. X11 timestamps events because it is conceptually (and sometimes physically) much closer to the input hardware. The events then get serialized, (then sometimes buffered, wired, unbuffered), deserialised, queued, and eventually unqueued at leisure. The point is that we want the velocity of the physical event, not the velocity at which GIMP unqueues the event (!). Something relatively close to the hardware is the only thing that can with some reliability timestamp a physical event -- and as commented, the resolution of that timestamp is pretty lousy. So this either gets 'fixed' by X11 (which just can't make guarantees on timestamp resolution, so it wouldn't be a particularly reliable fix, but it would be nice) or we resort to some sort of digital time smoothing, which is what we have (and which can probably be improved upon, but is not a 'big hack'). --Adam -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 "Forget climbing trees and learning the tin whistle. Here is The Chineapple Punx guide to smashing the system with your runner beans, running riot with broccoli florets and reclaiming the streets with organic damsons." ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Of time, brushes and inks
Too much silence. I see problems here :-) Probably means most people agree with the issue, but that I am not the only one who find it a hard question to deal with. I had tought on an unclean alternative to have a higher time resolution on gdk/gtk+ events, that would be to have a core GIMP time object with higher resolution. Events would then be timed GIMP side whenever they are received. The upside: this would not depend on other projetcs to implement. The downside: if for some reason the events get delayed to be passed to the GIMP, they'd be misshandled. On Saturday 21 August 2004 01:57, Joao S. O. Bueno wrote: > Hi there, > > > I've been greping the code in search for a nice implementation for > enhancements described in bugs 143216 > (Airbrush does not take into account speed ) > and 150227 (PIPE_SELECT_VELOCITY unimplemented for painting with > brush pipes) > > Basically, both need the time information of a paint event in order > to give out interesting results. The one thing in the GIMP which > uses this time information is the ink tool. > > While a more imediate solution might be re-implementing > instantiating objects that are part of the ink tool operation in > other parts of the GIMP (that would have the bennefict of > functionality, while avoiding code duplication, but I guess the > relevand code would have to leave the .c files with an *ink* in > their name), while examining the time treatemnt in > app/paint/gimpink.c there is this comment circa line 248: > > /* The time resolution on X-based GDK motion events is bloody >* awful, hence the use of the smoothing function. Sadly > this * also means that there is always the chance of having an * > indeterminite velocity since this event and the previous * several > may still appear to issue at the same >* instant. -ADM >*/ > Meaning that the timing we currently have with the ink tool is > mostly a big hack and a lot of guessing. > > I think that both for the Ink tool and for a much nicer > implementation of the airbursh tool, and even a future eye-poping > implementation of bug 119240 ( Dynamic Brush stroke panel and/or > Dynamic path stroke), a clean code would need at least 1/100 of a > second resolution for mouse events. > > So, I am not intimate with GDK, but certain of you certainly > are...could we reimplement for a next generation GDK (one that will > be around for GIMP2.4/3.0) a new set of time resolutions for > events? > > Is that limited by X11? If so...maybe we can change/ask to change > things as deep in the X.org project, now in use in most desktop > GNU/Linux distributions. > > regards, > ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
