Gallery shell migration G1->G2 for BIG galleries, algorithm optimization for most recent etc.
valqk
I'm Anton Blajev,
a second year Public Relations student in Technical University of
Sofia.
I've had some problems with gallery recently and I have some ideas to
solve them and to contribute to it.
I have a Gallery1 with a big amount of photos (about 5k) and a hosting
that is SUEXEC-ed and have some memory and time limits. That forces me
to some restrictions of a memory and time execution I can use in php.
Where my idea to apply for SOC came from?
>From a problem.
Here is a brief story...
I've installed Gallery2 and tryed to migrate G1 to G2 with the web
module tool and I wasn't able to (I've never saw the continue link,
and imagine how many times I'll have to click continue, when 1 photo
is 4MB and there are 5k photos and the memoory limit is standart
8M...).
1. So, that's why I think it'd be nice to write a shell php script
that will migrate all albums from G1 to G2 without any 1000 annoying
'continue' clicks.
2. A few hours later, I saw that 'most recent', 'most viewed', 'random
images' links have problems with very big amount of picutres(at least
in G1). I've made some debbuging I've noticed, that they are loading
ALL pictures and the info about it from ALL albums, after that they
are calculating whatever you want to show. Well, when we have 5k of
images, the memory that will consume is hm.... quite a lot! I think
this could be optimized by listing for example first 10 images from
each album, or first XX images as defined in the configuration.
3. It'd be good if the code of the gallery2 is reviewed and some
places in the code (like described before) be fixed or at least
pointed out as a problem.
Well, that's my ideas, what do you think?
valiant
> I've installed Gallery2 and tryed to migrate G1 to G2 with the web
> module tool and I wasn't able to (I've never saw the continue link,
> and imagine how many times I'll have to click continue, when 1 photo
> is 4MB and there are 5k photos and the memoory limit is standart
> 8M...).
FYI: Image files are not read into memory when importing from G1.
So it doesn't matter whether a file is 1 MB or 50 MB in size.
That doesn't have anything to do with the PHP memory limit.
Unless you use GD as your image toolkit and want G2 to generate
thumbnails during the import of course. :)
That having said, a memory limit of 8 MB is really low and you'll
likely run into this limit very quickly.
> 1. So, that's why I think it'd be nice to write a shell php script
> that will migrate all albums from G1 to G2 without any 1000 annoying
> 'continue' clicks.
I guess that could be useful for some users and ISPs.
> 2. A few hours later, I saw that 'most recent', 'most viewed', 'random
> images' links have problems with very big amount of picutres(at least
> in G1). I've made some debbuging I've noticed, that they are loading
> ALL pictures and the info about it from ALL albums, after that they
> are calculating whatever you want to show. Well, when we have 5k of
> images, the memory that will consume is hm.... quite a lot! I think
> this could be optimized by listing for example first 10 images from
> each album, or first XX images as defined in the configuration.
G2 doesn't do this / doesn't need such a fix.
Would you prefer working on G1 during SoC? Please contact tim_j, the
G1 developer / maintainer. Although he didn't say that he's mentoring
during this SoC, I guess there's a good possibility that he'd do it if
anyone is asking him. You can reach him through irc.freenode.net
#gallery, gallery-devel email or in the forums.
> 3. It'd be good if the code of the gallery2 is reviewed and some
> places in the code (like described before) be fixed or at least
> pointed out as a problem.
Do you have anything specific in mind?
Cheers,
- Andy
valqk
while I was reading your answer last night,
I've remembered a feature, that I've wanted to implement two years
ago, but
I've totally forget about it.
So, here's the idea, I'd love to implement it!!!
One album can link to many - so called one to many.
We create an album called 2007_birthday_John.
We have organized our albums by some criterias:
we have the following albums:
1. Friends
2. 2007
3. Holidays
4. Party
in which album we would put the 2007_birthday_John album?
Well, at the moment we can put it only in one, but It woould be
fantastic to be able
to put the album to show up in 'Friends', '2007', 'Party' and maybe a
holiday....
that will be just great!
what do you think about this idea?
valiant написа:
> Hi Anton,
>
> > I've installed Gallery2 and tryed to migrate G1 to G2 with the web
> > module tool and I wasn't able to (I've never saw the continue link,
> > and imagine how many times I'll have to click continue, when 1 photo
> > is 4MB and there are 5k photos and the memoory limit is standart
> > 8M...).
>
> FYI: Image files are not read into memory when importing from G1.
> So it doesn't matter whether a file is 1 MB or 50 MB in size.
> That doesn't have anything to do with the PHP memory limit.
It's strange, I've never got continue link, but anyway, I'll debug it.
>
> Unless you use GD as your image toolkit and want G2 to generate
> thumbnails during the import of course. :)
I'm using ImageMagick, and unselected thumbnail generation.
anyway.
>
> That having said, a memory limit of 8 MB is really low and you'll
> likely run into this limit very quickly.
>
>
> > 1. So, that's why I think it'd be nice to write a shell php script
> > that will migrate all albums from G1 to G2 without any 1000 annoying
> > 'continue' clicks.
>
> I guess that could be useful for some users and ISPs.
So, you like the idea?
>
> > 2. A few hours later, I saw that 'most recent', 'most viewed', 'random
> > images' links have problems with very big amount of picutres(at least
> > in G1). I've made some debbuging I've noticed, that they are loading
> > ALL pictures and the info about it from ALL albums, after that they
> > are calculating whatever you want to show. Well, when we have 5k of
> > images, the memory that will consume is hm.... quite a lot! I think
> > this could be optimized by listing for example first 10 images from
> > each album, or first XX images as defined in the configuration.
>
> G2 doesn't do this / doesn't need such a fix.
> Would you prefer working on G1 during SoC? Please contact tim_j, the
> G1 developer / maintainer. Although he didn't say that he's mentoring
> during this SoC, I guess there's a good possibility that he'd do it if
> anyone is asking him. You can reach him through irc.freenode.net
> #gallery, gallery-devel email or in the forums.
I'll contact him today asap. Thanks for the info.
>
> > 3. It'd be good if the code of the gallery2 is reviewed and some
> > places in the code (like described before) be fixed or at least
> > pointed out as a problem.
>
> Do you have anything specific in mind?
Nothing special in mind, but it'd be good to test G2 with a lot of
conent I thought.
>
> Cheers,
> - Andy
valiant
G2 organizes items / albums in a hierarchical manners, in a tree.
What you propose sounds like a relational view. You organize things by
category / keyword / tag and an album can be mapped to 1 or more
parent-albums.
We like the idea, that's why there's already a task for it:
See: http://sourceforge.net/pm/task.php?func=detailtask&project_task_id=112247&group_id=7130&group_project_id=14056
There are already some similar features in G2:
- keywords / keyword album module
- tags / the new user-contributed tags module with dynamic albums
based on tags.
But I like your idea very much (hence the existing task). Tags and
keywords are just one solution. I'd like to see a built-in feature of
G2 that allows users to organize their albums relationally, as an
alternative to hierarchically.
- Andy
valqk
I saw you've added the idea to the task list,
so may I apply for SoC with this feature?
On Mar 23, 6:19 pm, "valiant" <andy...@gmail.com> wrote:
> @one to many albums:
> G2 organizes items / albums in a hierarchical manners, in a tree.
>
> What you propose sounds like a relational view. You organize things by
> category / keyword / tag and an album can be mapped to 1 or more
> parent-albums.
>
> We like the idea, that's why there's already a task for it:
> See:http://sourceforge.net/pm/task.php?func=detailtask&project_task_id=11...