Personal Video Database

English => Support => Topic started by: AimHere on February 03, 2010, 09:41:13 pm

Title: Question re: database and image files
Post by: AimHere on February 03, 2010, 09:41:13 pm
Hi,

Since I started using PVD, I've always enabled the "Store images in database file" option in Preferences, so that the various images (posters, screenshots, actors, etc.) are embedded in the database, rather than stored separately on disk.

Because of this, my database is becoming pretty huge (around 500 megabytes at last count). I'd consider unchecking the above option and using the default method, but I'm concerned about how PVD references images that are stored separately.

My main question is, are image files referred to internally with absolute pathnames (e.g. something like "C:\PVD Files\Images\Movies\Star Wars.jpg") or relative ones (assuming the database is in "C:\PVD Files" then the image path becomes "Images\Movies\Star Wars.jpg")? It makes a difference if the database file itself is ever moved (say, from the C: drive to the F: drive); this would break any relative pathnames.

I'm assuming the app does use absolute pathnames, just want to verify.

As long as I'm at it: would there be any programmatic way to change embedded images to separate files for a given database? Preferably something that would extract the images to separate folders depending on their purpose (e.g. "Posters", "Screenshots", "Actors", etc.)?

Aimhere
Title: Re: Question re: database and image files
Post by: rick.ca on February 03, 2010, 11:21:07 pm
Quote
Because of this, my database is becoming pretty huge (around 500 megabytes at last count). I'd consider unchecking the above option and using the default method, but I'm concerned about how PVD references images that are stored separately.

I don't think this is a good idea. There's no reason to be concerned about the size of your database due to the images that are being added to it. The images will take up as much room in the file system as they do inside the database. And I don't know for sure, but I suspect Firebird can manage them more efficiently than the file system. They're certainly a lot "safer" inside the database.

The only good reason I can think of for saving images outside the database is that you regularly need to access them with another application. If, for example, you are a serious collector of movie related art, you may want to be able to open images in an image editor to touch them up, make the sizes consistent, etc. If you do such things only occasionally, you're better off leaving the images in the database—they can be exported and re-imported as the need arises. And, we might hope that someday an external image editor and/or viewer can be specified so this is done automatically.
Title: Re: Question re: database and image files
Post by: nostra on February 09, 2010, 12:46:17 pm
Quote
I'd consider unchecking the above option and using the default method

The default method is actually the one you are using now  ::)

Quote
My main question is, are image files referred to internally with absolute pathnames (e.g. something like "C:\PVD Files\Images\Movies\Star Wars.jpg") or relative ones (assuming the database is in "C:\PVD Files" then the image path becomes "Images\Movies\Star Wars.jpg")? It makes a difference if the database file itself is ever moved (say, from the C: drive to the F: drive); this would break any relative pathnames.

All paths are stored having 2 values:
1. a path relative to the database file
2. absolute path
If one path does not exist PVD takes another one.

Quote
As long as I'm at it: would there be any programmatic way to change embedded images to separate files for a given database? Preferably something that would extract the images to separate folders depending on their purpose (e.g. "Posters", "Screenshots", "Actors", etc.)?


It will be done automatically when you switch the option. Target folders are configurable in preferences.
Title: Re: Question re: database and image files
Post by: AimHere on February 16, 2010, 06:24:23 pm
Thanks for the answers. I'll just keep on embedding the images in the database then.  :)

Aimhere