All forums > ThumbsPlus v7-v9 Questions

Save My database! (making it smaller)

<< < (2/3) > >>

Daan van Rooijen:
> Thanks, but Jpeg Compress is useless. Compressing to 50% saves around 1 MB:

That really doesn't make any sense.. I think either that function is broken in v9 or it can't handle a maxed out 2GB database (or, could it be that your Temp folder has no room left for a 2 GB file?).

Maybe, as an experiment, you could make a new database with 120x120 JPG Q88 thumbnails and let TP9 run overnight to thumbnail all those 300K+ files. Then see how big the database has become. I think it will be just a 1/4th or so of what you have now.
   
> Regarding Thumbnail size regardless of whether it is a new database or I rebuild thumbnails any size over 120 is cropped. I've no idea how you can make good large thumbnails.

The only times where I've seen that is when the images themselves are very small (icon files for instance) or when TP can't create a thumbnail, and instead assigns a generic thumbnail obtained from the program that is assigned to their filetype.

Oh wait! I think I know what the problem is. I think you're only referring to their display size, which is expressed as a percentage and which you can access from the bar above the thumbnail listing. But that has no bearing on how large the actual thumbnails in your database are. In Options | Preferences | Thumbnails you can define the width and height at which your (new or remade) thumbnails will actually be generated and stored in the database.

Greatly Perturbed:
Thanks for your continuing help. I guess the compression option is broken.

> Maybe, as an experiment, you could make a new database with 120x120 JPG Q88 thumbnails and let TP9 run overnight to thumbnail all those 300K+ files. Then see how big the database has become. I think it will be just a 1/4th or so of what you have now.
I'm pretty sure I tried that and it maxed out long before completing the tree. I'm beginning to think that the number of keywords automatically generated is also greatly impacting on the size.
 
> Oh wait! I think I know what the problem is. I think you're only referring to their display size, which is expressed as a percentage and which you can access from the bar above the thumbnail listing. But that has no bearing on how large the actual thumbnails in your database are. In Options | Preferences | Thumbnails you can define the width and height at which your (new or remade) thumbnails will actually be generated and stored in the database.

Yes, that's the setting I have used and reused and anything over 120 gets cropped. I've tried different display settings as well but that hasn't made a difference regarding whether the image shows up cropped or not.

Greatly Perturbed:
> Maybe, as an experiment, you could make a new database with 120x120 JPG Q88 thumbnails and let TP9 run overnight to thumbnail all those 300K+ files. Then see how big the database has become. I think it will be just a 1/4th or so of what you have now.
>    

I've recreated the database with 120x120 jpeg Q80. The size is smaller but still 1.95 GB. I'd like to use it but is there any way to transfer my saved searches, galleries and user fields?

Daan van Rooijen:
> I've recreated the database with 120x120 jpeg Q80. The size is smaller but still 1.95 GB.

I'd expected the compression to make a bigger difference.. too bad.

> I'd like to use it but is there any way to transfer my saved searches, galleries and user fields?

No, I'm afraid not..

But I still don't understand why you couldn't jpg-compress the thumbnails in your existing database. It would be great if you could get that to work because that would preserve all your searches, user fields, etc.

There are two more things that I'd try. The first is this:

[*]Make a copy of your original database and open that copy in TP9
[*]Remove the thumbnails for a number of folders that are less important than others (for instance because the images in them have no keywords and aren't part of galleries, etc)
[*]Run 'Compact and Repair' to purge them, making the database smaller
[*]Then try the JPG Compress conversion again.
[/list]

If that doesn't work:


[*]Open that same copy of the database again. Take note of its exact size in bytes.
[*]Use Options | Preferences | Thumbnails to change the thumbnail settings to 120x120 JPG Q80.
[*]Re-make the thumbnails for several large folders that already have thumbnails.
[*]See if that has lowered the filesize of the database (even if just a little).
[*]If not, run Compact & Repair and see if that helps decrease the size.
[*]If it has, keep on remaking your current thumbnails until all have been remade. (you may have to run Compact & Repair intermittently but I don't think so)
[/list]

With some luck that should change all your thumbnails to 120x120 whilst preserving searches, user fields, etc and still staying just below the 2 GB limit.

Greatly Perturbed:
> But I still don't understand why you couldn't jpg-compress the thumbnails in your existing database. It would be great if you could get that to work because that would preserve all your searches, user fields, etc.

I don't think it works. I removed around 6% of the thumbnails, ran compact and repair, did the compress and this was the result:

The database compact and repair process succeeded.
  Old size: 1,973,600,256 bytes
  New size: 1,973,600,256 bytes
  Compressed by: 0.0 %

Changing the thumbnail size as per your second suggestion just quickly expands the size to where it won't remake any new thumbnails. It seems pretty hopeless.

Navigation

[0] Message Index

[#] Next page

[*] Previous page