Different thumbnail sizes per album? [Update: module attached]

In Gallery 2 I had two different types of albums. One was just the standard Matrix type with 4x4 small thumbnails, or whatever the default was. The other was for "story" albums, and had much larger thumbnails and only one column. It also displayed the description with the thumbnail, and the end result was nice for things like a project, where you show pictures of your progress along with details. The problem I'm having trying to duplicate this in Gallery 3 is that you can only have one theme, and all thumbnails are the same size. I'm pretty sure I could work around the one theme issue by having the theme check for a special tag or something on the album, but I don't know about the thumbnail issue. Is there any way to have different size thumbnails?

Yes, the sizes of albums thumbnails should be different from the photos thumbnails.
The sizes should have configuration

But I do not know a module for this

Regards

www.ajorge.net

So the way the graphics code works is that we have a series of "graphics rules" that we apply to an image when we want to rebuild it. For example, here's a rule:

mysql> select * from g3_graphics_rules\G
*************************** 1. row ***************************
         id: 1
     active: 1
       args: a:3:{s:5:"width";i:200;s:6:"height";i:200;s:6:"master";i:2;}
module_name: gallery
  operation: gallery_graphics::resize
   priority: 100
     target: thumb

This rule calls the "gallery_graphics::resize" function with width=200, height=200 and master=Image::AUTO. The priority of this rule is "100". If you look at a database that has watermarks, it looks like this:

mysql> select operation, priority, target from g3_graphics_rules;
+-----------------------------+----------+--------+
| operation                   | priority | target |
+-----------------------------+----------+--------+
| gallery_graphics::resize    |      100 | thumb  |
| gallery_graphics::resize    |      100 | resize |
| gallery_graphics::composite |     1000 | thumb  |
| gallery_graphics::composite |     1000 | resize |
+-----------------------------+----------+--------+

We execute the rules in priority order. So if we are regenerating a thumbnail we'd first run the resize to scale the image down, then we'd run composite to add in the watermark. Make sense?

What you want to do is create a new module that injects your own rule in there with a priority somewhere between 100 and 1000. Your new rule would apply only to "thumb" targets and would look up the album's id and figure out what size you want the thumbnail to be, then resize again to the right size. This is a little wasteful cause we're doing two resizes, but it'd work just fine.

Look at the graphics::add_rule() calls in modules/gallery/helpers/gallery_installer.php to see how you can add new rules in your custom module. Then look at modules/gallery/helpers/gallery_graphics.php to see how you can create your own rule functions.
---
Problems? Check gallery3/var/logs
bugs/feature req's | upgrade to the latest code | use git

Well, I spent a bunch of time trying to find a nice clean way to do this and got close a few times, but it looks like it's going to have to be a hack. My current solution involves adding my own rules and disabling the gallery resize ones, then watching for any changes and updating my rules/disabling the gallery resize rules if anything changes. (Installing my rule after the gallery one didn't work, because I would be passed the path to the resized image instead of the source.) Any time a resize request comes in I modify the params if necessary then pass it on to the core gallery resize. Like I said, not as clean as I'd like, but it actually seems to work pretty well.

I still need one core gallery change though, a way to get the parent id on a resize call. Right now I'm just adding it on to the rule options as "parent_id", but that seems kind of crappy. Ideally the resize function would be changed to pass the item, in addition to the input/output file paths and options. Either way it requires a change to core Gallery code, so I figured I'd get your opinion Bharat. If you think both those solutions suck and don't want to change anything that's fine too, I can always just keep it local to my gallery.

On a side note, I pushed the custom_albums module to my gallery_contrib fork and noticed it show up on gallerymodules.com. That seems bad since it won't work for anyone that downloads it now, but I didn't see any contact info on the site. Seems like it should only pull modules from the main gallery_contrib though, not peoples forks.

It should be gone now.
---
Problems? Check gallery3/var/logs
file a bug/feature ticket | upgrade to the latest code! | hacking G3? join us on IRC!

I would like to have larger thumbnail also, and I would like I could add any picture from my hard drive as a album cover (any proporcion also)

PP

Hm. I think we could make a similar change to that in the core code. I'd rather not overload the $options variable since that's specific to the graphics operation. But we could add a 4th param to every graphics operation to include the item. I'd rather specify the item instead of the parent, since you can derive the parent from the item, but not the other way around.

@ColinGS: would you like to make up a patch to graphics that adds $item as the 4th param and submit a pull req?
---
Problems? Check gallery3/var/logs
file a bug/feature ticket | upgrade to the latest code! | hacking G3? join us on IRC!

Yeah Bharat, passing it in as an arg would definitely be much cleaner, I was just trying to minimize the changes. I'll go ahead and add the extra param.

Since we expect others to look to the gallery_graphics functions as an example, let's make it consistent. Go ahead and add it to all of them. thanks!
---
Problems? Check gallery3/var/logs
file a bug/feature ticket | upgrade to the latest code! | hacking G3? join us on IRC!

ColinGS,
Care to make a codex page for this? If you need a hand let me know

Dave
____________________________________________
Blog & G2 || floridave - Gallery Team

If you have the latest from Git you don't need to modify your graphics.php, the change is already there. This should work with the square thumbs hack, I'm not sure if it will work with random album covers. I'm going to try and spend a little time doing a little more bug fixing this weekend and get it pulled into the Git repo (and write some docs).

Ok, I spent some time on this today and got something working. Unfortunately, it's kind of hacky again.

The thumbnail proportion was being calculated in the construct function for Theme_View. Unfortunately, album.php (the one I need to catch) sets the item on the view after it's constructed, which is too late for that case. As a workaround I overrode the render function in Theme_View and did the calculation there, since the item was set at that point. I added a function graphics helpers can implement called "thumb_size" that takes in an item and returns the thumbnail size, if it's an album with one, or zero otherwise. Then, I calculate the thumb proportion by checking if any modules want to override it, then using the default thumbnail size otherwise.

I tested it and it works, but like I said it's not the cleanest fix. Any opinion Bharat? I want to come up with something that can get pulled into the mainline.

  public function render($print=false, $renderer=false, $modifier=false) {
    // We override the render function so we have a point after the view is fully
    // initialized to calculate the thumbnail size.  There is no actual rendering
    // done here, that's just passed on to the parent.
    if ($this->page_type == "collection") {
      $thumb_size = 0;

      // Check if any of the modules defined the function thumb_size, which can
      // return a custom thumbnail size per album.
      foreach (module::active() as $module) {
        if ($module->name == "gallery") {
          continue;
        }
        $helper_class = "{$module->name}_graphics";
        if (method_exists($helper_class, "thumb_size")) {
          $thumb_size = call_user_func_array(
            array($helper_class, "thumb_size"),
            array($this->item));
        }
      }

      // If none of the modules overrode it, use the default gallery thumbnail size
      if ($thumb_size == 0) {
        $thumb_size = module::get_var("gallery", "thumb_size", 200);
      }

      // @TODO change the 200 to a theme supplied value when and if we come up with an
      // API to allow the theme to set defaults.
      $this->set_global("thumb_proportion", $thumb_size / 200);
    }

    return parent::render($print, $renderer, $modifier);
  }

Doing a flyby in the forums -- any thoughts on this approach ColinGS?
---
Problems? Check gallery3/var/logs
file a bug/feature ticket | upgrade to the latest code! | hacking G3? join us on IRC!

Yes, it takes the max dimension of the album thumb size. It's not really right. I guess the right fix there would be to modify Theme_View::thumb_proportion() to post an event and let individual modules return a value. That code would look like this:

public function thumb_proportion() {
  module::event("theme_thumb_size", $item, $thumb_size);
  if (!$thumb_size) {
    $thumb_size = module::get_var("gallery", "thumb_size", 200);
  }
  return $thumb_size / 200;
}

Let me know what you think.
---
Problems? Check gallery3/var/logs
file a bug/feature ticket | upgrade to the latest code! | hacking G3? join us on IRC!

Sorry just taking a look at this now. I'm looking at pull #32 and it looks like you're still overriding Theme_View::render() which should no longer be necessary -- you can just modify thumb_proportion() like I have above and then implement the theme_thumb_size event in your module's event handler.
---
Problems? Check gallery3/var/logs
file a bug/feature ticket | upgrade to the latest code! | hacking G3? join us on IRC!

ColinGS,
do you have a url to the pull request? or your git hub?

Dave
_____________________________________________
Blog & G2 || floridave - Gallery Team

Oh man this fell off my radar. I pushed my fix (ticket: https://sourceforge.net/apps/trac/gallery/ticket/1773)
---
Problems? Check gallery3/var/logs
file a bug/feature ticket | upgrade to the latest code! | hacking G3? join us on IRC!