One Image Multiple Albums - No reUpload

[OmegaGOD]

Good Morning,
     I was wondering if it would be possible to upload an image once and then place that image in multiple albums. For example. If I have a picture of the sunset I would like to place it in two separate albums lets say California and Scenic without having to reUpload a second copy of the same image.

[Joachim Müller]

at the moment, this is not possible; this has been requested before, but we're reluctant to include this feature, because of this: what happens if you delete the pic in one album? What will happen to the pics (or links to it) in the other albums? This can only be solved be adding a lot of queries to coppermine code...

GauGau

[davetd02]

I'm going to go ahead and put another vote in for this feature.  It's probably the one biggest thing that's stopping me from using Coppermine for my personal and semi-pro work.

Basically, I think in terms of images.  And each image may have multiple uses or categories.  If I take a picture of a girl in front of a boat then I might want to include it in my "Travels" gallery and my "People" gallery.  Uploading (and maintaining the disk space, etc) each gallery seperately is silly.  It's the same image.  If I remove it from one gallery that just means that it's not in that gallery anymore, but the file is still on disk somewhere (hopefully).  The same way that Windows Shortcuts work.  This should be entirely invisible to the end user.  The end user should just click on my "People" gallery and then see the image and click on my "Travels" gallery and also see the image.

This would be a HUGE version 2.0 feature that would make Coppermine much more usable.  

I understand that this is tough to code, but it's pretty important!

Dave

[Tarique Sani]

I guess the best way to go about this would be give ability to add albums to categories based on keywords.

So if a user has a picture with keywords B/W and Monuments in a Album called Travels in Category X

Then he can add a keyword based album called "Monuments I have seen" and link it to the keyword "Monuments" in Category Y

And

Then he can add a keyword based album called "BW pics" and link it to the keyword "BW" in Category Z

To remove a picture from Keyword albums you would have to remove the keyword from the offending picture.

Of Course deleting the picture from the base album will delete it from everywhere.

Now that I have a plan - the question is - Who will bell the cat

[davetd02]

Hi Tarique,

Thanks for the tip.  That might actually be a decent solution.  I hadn't thought about doing it that way.  I might give that a try and see how it goes.  It makes sense on a logical level and I like the idea of having a base album where I can just put ALL of my pictures and then having categorized albums by keyword.  There might be some kinks (the order of things in the keyword albums), but it's worth a shot.

Thanks a lot for helping out!!!  Maybe you should just add that post to the FAQ!

Dave

[malc]

GauGau wrote:

at the moment, this is not possible; this has been requested before, but we're reluctant to include this feature, because of this: what happens if you delete the pic in one album? What will happen to the pics (or links to it) in the other albums? This can only be solved be adding a lot of queries to coppermine code...

Actually, not so!  This is not a particularly new problem, and has been solved in Unix for years!  However, non-Unix hosts may have problems with this solution:

What you do is simply make the "duplicates" hard links to the existing images.

Hard links have no precedence: each link is as good as any other.  So deleting a link does just that: the link is removed.  Deleting the *last* link frees the inode and so the space used by the file.

This works today with Coppermine, but it is clumsy: essentially, create a new album directory and link (i.e. ln) the main images files you want to duplicate into that (outside cpg); Batch add the new directory; (outside cpg) remove the newly created "thumbnail" and "standard" images, and link (ln) the thumbs and standard image files from the original image.

[ I *did* say it was clumsy! ]

Now, if you delete any one image from one album, it disappears from that album but remains in all the others.  Only when it is deleted from the last one is the space that image consumes freed up.

This *is* an important thing for me, given I have a need to showcase both individuals and events at which the individuals appear, and while keyword searching kinda works, it demands too much effort from the casual visitor to be worth while.  I'd rather have to expend the effort myself to make it easy to the visitor!

[omniscientdeveloper]

what happens if you delete the pic in one album? What will happen to the pics (or links to it) in the other albums? This can only be solved be adding a lot of queries to coppermine code...

Here's my sollution (kinda like what was stated above):

The best thing I think, is to just add a new entry to the db. This will allow the other albums to display the image....and to solve the delete problem. You can make it a FIFO type thingy. It'll delete only the record for that album, and if it's the last record (of that image) in the database THEN delete the file. This seems simple enough to code, which I could do...unless someone else has already started it...because I plan to use it. I would think that the db would have to be altered a bit to store an index type field of the parent record...like the categories. This can also be used to prevent it from showing the same image twice in the "last posted" and "random" features.

A suggested implimentation would be to add a new field to the upload page, so the user can paste the link to the image or displayimage.php page where the image is rendered. Code could see if the image has already been uploaded, by looking at the link, and do the proper action. If it hasn't then it could get the image from the location (link) and either store the link or image.

This would solve two problems, using links to upload pictures and allowing the same pic multiple times. Plus it's simple enough to code.

I'd be willing to take it on in two weeks, if no one else does.

[Joachim Müller]

maybe my posting wasn't that clear: of course you can have multiple links inside the db pointing to one file location, but consider these scenarios:

• the "original" pic (which has been added to the gallery in the first place and resides within an album structure that reflects the gallery's structure) is being deleted - what will happen to the links within other albums?
• coppermine features multi-users, user upload and a permission system (many request a more sophisticated permission management, with sub-groups etc.). What happens if the "original" album's permsiion settings change?[/list:u]Although the feature you request may be helpfull for you (and of course some others), it will make administration of coppermine more complicated for newbies.
  
  @malc: I agree that Lunix is the best platform for webservers, that it's most powerfull etc., but you can't deny the fact that a lot of coppermine users are running coppermine on Windows/IIS (like it or not - I disapprove of it as well!). That's why I vote against a platform-dependent solution.
  
  GauGau

[malc]

maybe my posting wasn't that clear: of course you can have multiple links inside the db pointing to one file location, but consider these scenarios:

• the "original" pic (which has been added to the gallery in the first place and resides within an album structure that reflects the gallery's structure) is being deleted - what will happen to the links within other albums?
• coppermine features multi-users, user upload and a permission system (many request a more sophisticated permission management, with sub-groups etc.). What happens if the "original" album's permsiion settings change?[/list:u]Although the feature you request may be helpfull for you (and of course some others), it will make administration of coppermine more complicated for newbies.
  

My reference to hard links was not intended as a OS-specific solution, just an observation that the problem is not new, and has been solved.

To clarify: there are two good ways to address this issue:

1.  The 'cleanest', but most expensive in terms of DB lookups, is to have a new DB table that links the tuple of (filename,reference count) to a key, and everywhere that the DB currently points at a file name, have it point at an entry in this new table.  When adding the files, entries are created with a reference count of 1; when creating duplicates, the reference count is incremented, and when deleting photos, the ref. count is decremented.  When ref=0, delete the physical files and the entry in the table.  This is precisely how hard links are managed in Unix.   However, every picture access involves an extra DB lookup.

2.  Less clean, but more efficient: borrow the "soft link" model (or that of the Windows 'shortcut' facility).  A picture "belongs" to a single, specific album, but soft links in other albums can point to it.  The drawbacks are as GauGau observed, but I don't think either represents a huge problem.  In the case where the target of the soft link disappears (because it was deleted), an attempt to access the link could either result in the link being silently deleted or a "pic not found" placeholder being substituted.  The permissions thing is, I think, not important in that *if* a pic was accessible at the time of the link being created, then the link creator could have simply downloaded and re-uploaded the pic.

Oh, and I suspect this facility (however implemented) would be *very* popular with many people: the ability to create entries in both "My Friends" and "My Parties" for the same pic is kinda attractive!

@malc: I agree that Lunix is the best platform for webservers, that it's most powerfull etc., but you can't deny the fact that a lot of coppermine users are running coppermine on Windows/IIS (like it or not - I disapprove of it as well!). That's why I vote against a platform-dependent solution.

My point had little to do with the virtues of the OS, and everything to do with the implementation of soft links vs hard links in Unix.  Still, I believe that NTFS implements 'Junctions', which are hard-links, although there are few, if any, tools to manipulate such things, and many tools will get confused by their (legal) presence!

But, as noted above, Unix links (soft and hard) illustrate the options...

[omniscientdeveloper]

what will happen to the links within other albums?

It'll delete only the record for that album, and if it's the last record (of that image) in the database THEN delete the file.

That'll solve the delete part, and adding an extra field shouldn't make it complicated enough. This doesn't affect user permissions at all. This will just allow multiple "permissions" for one file. It's more of a duhh factor, I think. If a person makes an image private and adds it to a public folder then "DUHH" they've effectively overidden the permissions on that file. (I think there will only be a small percentage of users that have problems with this concept though.)

What happens if the "original" album's permsiion settings change?

You now have two folders with two different permissions (possibly). They're seperate, since there are two entries in the database for the same image it doesn't effect the other.

Although the feature you request may be helpfull for you (and of course some others), it will make administration of coppermine more complicated for newbies.

I think this'll only cause problems if the implimentation is complex. That's why I suggested adding a textbox to the upload page (for links). If you do this, you don't have to change code anywhere else in coppermine, and it solves two problems again.

...just my opinion.   It's up to you though, I'm following the leader here.

[Carrasco]

I think there is a better solution:

1. Create a field in the cpg_pictures table called "Link" type Bolean

2. In the first upload the image is placed in the user's album and the field is filled with False

3. In the user's album, there's a option (dropdown list) to submit the picture to public categories. This option duplicates (symbolic link) the first record im the cpg_pictures table and marks the "Link" field with true.

4. Every time the image is deleted from different albuns the field "Link" is checked. If false only the record is removed (symbolic link), if true the image is deleted also.

Guess this aproach produces less code and gives the user the oportunity to submit the image to public theme categories.

Hope this helps the discussion.

Regards,

Carrasco

[Joachim Müller]

...just my opinion.   It's up to you though, I'm following the leader here.

hehe, I'm flattered, but I'm more or less some coppermine slave, not the leader :wink: ...

I think you have a good point - I think I'll be happy with the solution you proposed.

GauGau

[Tarique Sani]

OK put this feature on the coming soon list.

See a proof of concept at my site http://tariquesani.net  

Click on the Challenge album - this album actually has only 11 pictures BUT displays 13 pictures, the remaining two Aquarius and Men In Black are taken from Bodyscape and Family albums respectively.

The criteria to display is based on the usual in the album pictures and the pictures which share the same keyword as the album, does not entail any extra queries - just modification of  the existing ones at several places and of course there are some kinks which need to be irond out

P.S. Caution - some implied nudity in the link

[Carrasco]

The criteria to display is based on the usual in the album pictures and the pictures which share the same keyword as the album, does not entail any extra queries - just modification of  the existing ones at several places and of course there are some kinks which need to be irond out

Hi tarique, gaugau,

This approach might create some confusion if accidentally a keyword is typed that matches an existing album creating an unwanted reference!

The way i've suggested you'll have allways one record that is associated with the image in the table, and the other duplications are only refferences to the same image assigned to other albuns.

By the way, the optimal solution would be to create an intermediate reference table so the image data wouldn't be duplicated.

a table called [Reference] only needed to have the folowing fields:

     refID, AlbumID, PictureID, IsLink

By consulting the records contained in this table you would have all the info needed to manage all the references to the image.

Regards,

Carrasco

[Joachim Müller]

P.S. Caution - some implied nudity in the link

[off topic]there's nearly no need to put the "nudity warning signals" up - your most recent pics are some really high-quality "non-porn" pics; definitely nothing to be ashamed about (neither you nor your models); I especially like http://tariquesani.net/displayimage.php?pos=-560
[/off topic]

4. Every time the image is deleted from different albuns the field "Link" is checked. If false only the record is removed (symbolic link), if true the image is deleted also.

What will happen to the orphaned links if the "original" is deleted?

Gaugau

[Tarique Sani]

I especially like http://tariquesani.net/displayimage.php?pos=-560

Thank you  

4. Every time the image is deleted from different albuns the field "Link" is checked. If false only the record is removed (symbolic link), if true the image is deleted also.

What will happen to the orphaned links if the "original" is deleted?

It may be noted in this context that my system does not depend on symlinks. It is based on keyword of album matching one of the keywords in any picture.

[Carrasco]

What will happen to the orphaned links if the "original" is deleted?

Gaugau

Hi.

The solution is simple:
When you delete a record that has the flag "Link" set to false, it's easy to delete all the references of the same image from the table. The images automatically disappear from the other albums.

The main idea is to upload an image to the user's album, and to make references to it in the public albuns without duplicating image files.

Regards,

Carrasco

[theBurek]

Hi all!

I'm totally for this feature. And I agree with the references. hey, if we're using MySQL why not use it's references. Creating such a table which would contain links is really not as difficult as one may imagine. At least I don't think so. Then when you are displaying pics, you first do the normal querys that check for regular pics that belong to that specific album, then you go about checking the links table. If you add one more field, something like "KeepOriginalPermission" and "OriginalAlbumID" then you have also enabled the option of choosin permission. You can later check if this field is TRUE or FALSE, and then say:
 a) the field is TRUE
     I will need to check what permission apply for the original albm and apply them to this picture.
 b) the field is FALSE
     I do not need to worry, the user has already made whatever permissions he/she wants.

I think this solution is best, cause it's not in any way OS specific. I'm running on Windows/IIS and the thing works fine. Unlike some other galleries which I've installed up to 3:00 AM and still didn't work. And the main part is that it's so because of its simplicity. Let's keep it simple, and let the user do all the work by clicking, not typing ln -s (am I right on this one malc? ) ...

Right, hope it helps

regards,
theBurek

[Tarique Sani]

Well I am locking this thread.

This feature is being implemented and not using links - no point in confusing the readers any further