Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[jwaters]

I like the direction MJ 9 is heading with the addition of an Image library.  Consolidating all media into a single manager application is what I've been wanting forever.

I'm assuming this functionality is not complete, but I have many questions regarding the image tagging and slideshow viewing.

Apparently, MJ writes data (tags) into JPG's with certain information.  Right now (assuming because it's a beta), you can write a comment, artist, album, track -- Obviously fields that are for music, not photos.  I will assume that when finished, this will be changed to photo-relevant fields (caption, subject, location, keywords, camera, etc). Also, will these fields be customizable and/or exportable?

My 2nd question is what standard/format is used to tag the jpeg's?  The industry standard is IPTC.  An IPTC tag allows just about all the data you would want to store in a image file - and it will be compatible with most  other photo viewing/editing applications.

IPTC tags are very similar to ID3 tags, and It would be AWESOME to see MJ adapt their ID3 tag management features for use with IPTC tags on jpg's!!!!

Once the image library is built and all images are tagged, you can find/filter/sort images by any data that is in the database.  Now that you've found some images, on to the slideshow....

Features that I would like to see in the slideshow which don't appear to be in MJ9:

1.  Overlay text on the slides (with a keyboard shortcut to toggle it on/off).

2.  Ability to pick which text goes into the overlay (caption, subject, date, etc.)

JW

[Matt]

Thanks jwaters.

You can add and edit library fields now.  Look under Options -> Tree & View

About IPTC, it's not really flexible enough for what we need to do. (store anything the user wants in the tag)  So, we created our own, XML based JPEG tagging system that writes to an open APPID block, just as IPTC does.  We'll publish our specs (and possibly code) once things settle down with version 9.  It's really a pretty slick system, and if you don't like it, you can easily remove the tags.

About the slideshow features, we'll see what we can do. (it never hurts to remind us once in a while until it's the way you want it)

Thanks again.

[jwaters]

Matt - Thanks for the quick response!  Well, you said a couple of words i like very much:  XML, and published specs!

I've been searching for a solution to tag my photos for over two years, and sort of settled on IPTC because it's all that's been available.  I agree that it's not completely flexible, and at one point, I even considered writing my own XML tags into the comment field, but that proved to be way too complicated.

My concern with the MJ custom tag was that I wouldn't be able to use/access the tagged info outside MJ. For example, one of my ultimate goals is to get my entire image library onto the web in a database driven ASP site.

What i LOVE about the MJ solution is that you have a very nice interface for mass updating tags on many files.  Thanks for pointing out the library fields customization.  This opens up huge new potential for my use of MJ!

If I can access this info outside of MJ, I will feel good about using this as my final solution.  What about exporting my image library to a text file -- is that possible?

Oh, and yes - please, please, please add the slideshow text overlay onto the requested feature list.


JW

[Matt]

Play with "Export" in the File menu.  If you use .MPL (Media Jukebox Playlist) it'll dump pretty much everything to an XML file.

Other output formats are available as well.

[michel]

So, we created our own, XML based JPEG tagging system

Nice idea.

However you would check what jpeg 2000 emergent standard defines as metadata format. I only know it uses also XML so may be you could/should be compliant.

Because I am not very confident that JRiver proposal will be accepted by the photografic industry even if it is freely published (in fact, I think it will be completely ignored). There is already a standardization group (jpeg.org) working with hundred of companies (some of them so big as Adobe) around jpeg and jpeg 2000.

[JimH]

Michel,
We looked around and asked around before we did it.  We needed something we could extend.  We couldn't find anything.

If you know something specific we should consider, we would be glad to take a look at it.

As you know, standards don't become standards because of standards bodies.  Users decide which ones win.

Jim

[michel]

As you know, standards don't become standards because of standards bodies.  Users decide which ones win.

In this case, the users don't care. They buy a digital camera, rarely a digital album software (it comes with the digital camera) and STOP. Moreover, only a little minority uses tags.

I am almost sure there is already a jpeg.org draft to define metadata format for jpeg 2000 (I read it somewhere a few months ago). Really you would check again because if I am right I don't imagine one second that:

Canon, Nikon, Olympus,...
Adobe (Photoshop), Ulead,...
and dozen others manufacturers/software makers

will accept to use your format.

But it is your money/work so you are free to try. On my side I am not going to put a lot of information inside any tags before there are several software able to read it, except if I can export it in a "standard" format, such as CSV, in order to be able to reimport it with another software. And also to be able to import a CSV file in order not to re-type the metadata of existing pictures (I have 9000+).

[NoCodeUK]

I would have thought XML was a better alternative to whatever the Jpeg committee can come up with seeing as XML is set to become the lingua-franca of everything PC.  Think Open Office - they use XML for their file format, Word will use XML in the next release (it already does for a lot of things).  XML is the future in that sense and so therefore I would imagine that every piece of software will be able to read JRiver tags so long as they read XML and that shouldn't be a problem...


Adam

P.S. Did any of that make sense

[Matt]

Don't make too much of this.

We're not trying to take over the world with our tagging -- it's like 500 lines of code.

However, it does what it's designed to do perfectly -- it's fast, flexible, and unintrusive.

[michel]

I would have thought XML was a better alternative to whatever the Jpeg committee can come up with seeing

I am almost sure jpeg.org adopted XML.

We're not trying to take over the world with our tagging -- it's like 500 lines of code.

In this case, it is not a big risk for JRiver, indeed.

However, it does what it's designed to do perfectly -- it's fast, flexible, and unintrusive.

I have really no doubt about that.

But is it not a risk for the user to tag long-term archiving files with a non over the world system (as you say) ?

[jwaters]

Good point Matt.  I'm sure no one on your team has any grand visions of defining the new picture tagging standard.

I, for one, am very excited about what's been done so far -- (although I think there's still much to be desired from an image cataloging standpoint)

I have seriously been searching for an image cataloging program that would allow me to tag files for years.  Three years ago, I built an Access database for tracking picture info, and it worken well for a few months and about 1000 pictures -- as it grew, it started becoming impossible to maintining my database, worrying about filenames/directories/drives matching, copying, editing, creating different formats form pictures became impossible to manage without storing data -inside- the image file.

After an exhaustive search for a program that would suit my needs, I had actually given up.  All the applications that read/write IPTC info had one major flaw or another, mostly revolving around the difficulty of mass updating/file renaming/etc.  Many did not do lossless rotates/edits, and often updating some fields seemed to erase others.  

Although not many average consumers are advanced enough today to tackle JPEG tagging, there has to be a HUGE untapped market if the right tools come along. Millions of people use digital cameras, and as their collections grow, there must be a major need for image cataloging for the masses.

Media jukebox has always been great at managing tags in MP3's, and I've always wondered why nobody could come up with an image management application that was just as easy & powerful for JPEGS.

Now, here's why I don't see any problem adopting MJ's system as a consumer:

1.  Tagged info CAN be exported.  As far as I can tell, just dump all your files in a playlist, and use the export feature.

2. When the future Jpeg standard comes out, it seems as if it would not be terribly difficuly to build support for it into a future version.  Perhaps a tool could be used to allow us to map our custom fields into a new 'standard' field.  Then erase the old MJ tag.

Here's what I wish the product did:

1. Supported IPTC tags (even read-only). Ideally, I would like to see support for IPTC AND custom tags, but I can live without it for now.

2. EXIF support.  Almost all current image management apps can read these tags that give you camera info. For example, I'd like to be able to sort by which digital camera from the treeview.

3. Slideshow text overlays


JW

[michel]

JW,

I am myself waiting for a picture tag solution since my first digital camera (almost 5 years ago). Until now I am using a conventional picture database software (Ulead PhotoAlbum). So, obviously, I am very interessed by this new feature of MJ. But in the same time I had some questions/concerns/comments (see my previous posts).

You are right, there is no problem to use MJ "system" if we can export the information to a "standard" format such as CSV since you can relatively easily to re-import the data in another software. But an XML export format is not so easy to use as neither Excel nor Thumb+, PhotoImpact,... are able to import it (at this time).

More important, we have also to be able to tag our existing files from an imported CSV file since I don't want manage a part of my files (9000+) with PhotoAlbum and the other part (the new photos) with MJ.

This way, I agree with you.

[JimH]

Here's what I wish the product did:

1. Supported IPTC tags (even read-only). Ideally, I would like to see support for IPTC AND custom tags, but I can live without it for now.

2. EXIF support.  Almost all current image management apps can read these tags that give you camera info. For example, I'd like to be able to sort by which digital camera from the treeview.

Both of these are very likely.  At least the read-only part.

[jwaters]

Michel -

I'm totally with you on not wanting to put time/effort into tagging files with a proprietary system, unless I can be SURE that I can at least extract/use this info elsewhere. With XML and JRiver's history of being very open with their system as far as SDK's, I'm not too worried.

The playlist export feature seems to be adequate currently (dumps into a ASCII delimited file).  This could be imported into any software that has an import feature.

I also have the same problem of getting my current picture info out of my database (mine's homegrown) and into MJ. Ideas, anyone?

[JimH]

I think we will work on reading other kinds of tags, but is your collection organized by directory at all?

MJ can fill the tag info (properties) from the directory/filename (and vice versa).

[jwaters]

Jim -

Yes, to some extent my collection is organized by directory.  Importing dir/file names into fields will help.  However, I have ALOT more data in my access database that I'd rather not retype.

If I had 9000 files, like Michel, this would be crucial. An import feature would go a long way toward putting people at ease with regards to switching to your new tagging system. For that matter, if importing fields was possible, we could get existing IPTC/EXIF data from another application and simply import it into MJ.

JW

[michel]

Jim, I have no information in directory/filename structure, except that all my picture filenames are based on the date of the picture (2002-10-23_15h12-54 for example). That would be nice to be able to fill a date tag automatically from the filename (otherwise I can do it in Excel and add it in an additional field of the CSV file; I should do it only one time, to switch to MJ).

As JW all others information are in the database but I can export it in a CSV file which includes (for each record) a field with the path of the corresponding picture file. So MJ is able to know which file to tag for each record.

You have to decide if the field names (1st record of CSV file) have to exist as custom fields before the import (no problem for me) or if MJ is able to create them automatically (automatic creation of new custom fields could be an import option also).

NB. Il you don't want introduce a specific import behaviour into MJ only for this first import case, you could offer an external little tool doing that. For example, translating a CSV file into a MPL file (then we can "tag from properties").

Again, sorry for my bad english and thanks to read me anyway.

[jwaters]

Most power users are capable of getting thier existing data (from any number of outside sources) into an ASCII delimited text file, including the path/filename and all custom properties of their images -- most all image management tools have such an export feature.

I would certainly be happy with an external tool for doing this one-time import... Does the SDK allow you to write data into file properties? If so, maybe someone could write an external solution. I'd be willing to help, although I'm quite a novice.

If JRiver decided to build an import feature into MJ, here's how I think this could work --- Under import Media, Put another checkbox below "Get information from Directory/Filename" called "Get information from external file" They would have to define the format of this file, and we could massage our exported data to fit this format.  Then, as it scans and finds files, it checks this file to see it there's a filename match, and if so, populates the properties.

Auto filed generation would be cool, or it could just ignor fields that did not already have a custom definition in MJ.

JW