Separation of Data and Meta-Data
|
ladyslipper98201
Joined: 2003-03-06
Posts: 26 |
Posted: Fri, 2003-10-03 07:01
|
|
First off I'd just like to say that I really like Gallery. Nice work. I just installed g2 and after jumping through a few hoops got it going. It looks nice and clean! I have a few questions (quick ones first, longer ones second): What happend to the rotate feature? Is there a design doc that specifies your plan on implementing the separation of data - the original pics - from the meta data - comments, thumbnails, etc? I like in g1 how you can click the image 2 times to arrive at the full image. It appears that you have gone with a dropdown resolution box in g2. Any particular reason? If I feel inclined to spend some time implementing a feature what is the best way to go about it? Should I outline my feature here or in the devel mailing list? Basically this is the feature I want - I already implemented something like it for g1. I store my pictures on a drive accessible to my linux server. I take a set of pictures with my camera sometimes several hundred in a day. I would like to tell g2 the name of the directory where these pictures exist. G2 would create an album based off the directory name and symlink all images in the directory and generate the meta data for the images (thumbnail, 640x480) in a different spot. So images would be in /mnt/pictures/2003-08-08-oregon and then metaimages would be in /usr/local/apps/g2/data/2003-08-08-oregon and metadata would be stored in the database according to your schema. Thanks for the read!! |
|
Posts: 7994
It's still there. Select the "edit image" dropdown action under an image.
Not yet. In a nutshell, all the metadata is in the database and all the images are on the filesystem. All derivative files (like thumbnails, resizes) are stored on the filesystem.
The dropdown fit more cleanly into Ross's UI (Ross designed the new G2 ui). However, all of the image navigation (ie the album and item pages) are separated into something called a "layout". Right now we're using the "matrix" layout and it uses dropdowns. However, we can (and will) write lots of new layouts that can display the albums and images in different ways. Stay tuned.
Here is probably better.
Right now G2 expects to manage the images itself. However, unlike G1 it won't clutter up your data directory with lots of other .dat, .lock, thumbnail, resize, etc files. The only thing that'll be in the data directory is your original images. We don't have plans to implement a symlinking scheme because it won't be portable to other operating systems (namely Windows).
Creating a symlinking scheme in G2 will be a little trickier than in G1 since we have a more rigidly defined object model that separates out the various different types of files that we can manage. But since G2 does a very clean job of managing your images, might not be easier to just let G2 own those files for you instead?
Posts: 26
Thank you for the reply!
Ok I think I described the feature poorly, I really just described my implementation of it in g1. In g2 what I really would like to do is implement what I'll call mass import. I would like to point g2 to my images and have it create an album for each subdirectory with the name of the subdirectory, all images under the subdirectory would be added to that album.
I also think that I should be able to tell gallery where the images for a certain album are stored. For instance if I put 10% of my images on dvd and always have that dvd mounted then I'd like to be able to tell g2 that is where the images are without having g2 copy all the images from that source and take up more space on my disk. I don't really care where g2 puts the derivative files.
The other feature that I might be interested in implementing would be the export feature. Where I could export album(s) to cdrom and be able to browse those albums entirely without g2, php or a webserver running. Basically everything would be staticly exported to html pages.
Posts: 47
There is an offline feature available here:
http://gallery.menalto.com/modules.php?op=modload&name=GalleryDocs&file=index&page=gallery1-admin.offline.php
It's not always a one-step process, but what you describe can be done.
Posts: 26
Oh i didn't realize that was in g1. I'll have to give it a try and see how it works.
Thanks for the pointer. I was talking about implementing the feature for g2 though but trying the current g1 process out would give me ideas on how to improve it for g2.
Posts: 26
So I thought I had done this before but I took your word for it that I just missed the feature. There must be some kind of bug because when I clicked edit image I get a page that says "Edit Movie". The file extension is .jpg. Any ideas?
Posts: 26
Dammit... spoke too soon. It is futher barried in the UI. I had to go into edit image and then click the image settings. Weird that the movie edit thing would appear as the default.
Posts: 7994
That was a bug. I checked in a fix for it a day or two back, but then I overhauled that whole view about 20 minutes ago so in 4-5 hours when the anonymous CVS servers update you can see the cool new stuff with the edit-thumbnail capability.
As for the export-to-static concept -- we do have that in G1 and we will also have it in G2 but it's not a top priority which means it almost definitely won't be in G2.0. Maybe it'll be in G2.1
Posts: 26
Alright so what about the mass import feature?
Posts: 7994
Yep, we'll definitely do something like that. G2 currently lets you do a mass import into a single album from a single directory, but it would not be too difficult to extend that. We may not extend it in G2.0, however, as there are bigger issues that we need to tackle first.
This will be a little harder to implement. It's not impossible, but it will be very challenging to get it right. Gallery expects that all of its data files are
stored inside its own managed tree where it has permissions to manipulate the files and move them around, etc. Storing those files elsewhere will
require us to create a new level of indirection around all files so that it'll be able to tell which files it actually owns and which ones are stored elsewhere. I've heard this request before and it's on my long-range list, but don't expect it in any of the early releases of G2.
Posts: 1
Is it not the case that we discuss workflow issues here?
From my point of view, I would like to be able to do the following:
- Take the compact flash card of my camera and place the images on my hard drive in a folder named something good (one or more folders). For example it could be the name of the "roll" itself, or the names of the sessions during which the images were taken.
- Some of the folders might already have had images in them, and some folders might have been created.
- I run some kind of upload mechanism (today, I do rsync + private scripts which people can get if they want + gallery remote in perl, after adding galleries manually)
- After this, I would like to sort the images, and possibly I want to have them in multiple folders at the same time. I might for example want to have folders per person, per location, per event. So if I go to Rome twice and take pictures of the same person, the picture will be visible in multiple galleries.
[Extra feature, part of the workflow:]
- I also would like to expand the notion of "picture owner" and add "person on the photo". Anyone can "suggest" who is on the photo (and give email address to that person). The person is nudged, and if the photo is with him/her, that is acknowledged and recorded. For privacy reasons it is even better if that person really say "Yes, it is ok to have a photo of me here". Finding all photots of a special person is then easy.
-------------
http://alexandria.paf.se/
Posts: 7994
paf, all of what you suggest will be easy to add to G2 as a separate module. G2's design makes it easy to add custom metadata and wizards to the system. However, that takes time and we still have other core features to implement so it's doubtful that we'll get this into G2.0. But since the module API is fairly firm, there's nothing to stop you or anybody else from beginning serious work on a workflow module.