Better thumbnails

[manez]

Currently, the thumnbails generated on ingest end up wonky if the original aspect ratio is too far from that of the thumbnail area. No idea how challenging that may be to fix, but it's a minor improvement worth noting.

[daniel-dgi]

This is a great issue. Currently the thumbnails are just a resizing of the image using CSS. Shameful, i know, but I had deadlines. Ideally, the sync machinery will call out to imagemagick a la https://github.com/daniel-dgi/fcrepo-camel-workshop/blob/master/06-ThumbnailGenerator.xml . It should also be added as a PCDM file with the ThumbnailImage use from https://github.com/duraspace/pcdm/blob/master/pcdm-ext/use.rdf

Would be a great place for someone to dive right into Camel and PCDM.

[ruebot]

@daniel-dgi 👍 -- possible newbie ticket too, right?

[daniel-dgi]

Newbie ticket if you're a developer, for sure.

[sprklinginfo]

@daniel-dgi try to get my head around on camel ... for fcrepo-camel-workshop link you put above, do you have presentation slides that I can check? or anything useful to check out for the 'camel on islandora land'? Something other than 'camel in action' book as probably I don't have time to go through a huge book 😄

[dmoses]

@sprklinginfo ... I'm wondering if you'd hook into Drupal's image style configs? They are here: http://localhost:8000/admin/config/media/image-styles and it would provide a flexible method for users to define their thumbnail sizes, etc.
I may be full of beans.

[daniel-dgi]

@sprklinginfo https://docs.google.com/a/fedora-commons.org/presentation/d/1uy1Yes_GmZAFuhc0u74FPHu0ALjWLsf9ffsxRW1I8CE/edit?usp=sharing

I'll have to figure out best thing to do with perms on that in the morning. For now, you should have an invite for read permissions on that.

At some point in time, we'll have to talk PCDM in order to add a file. Which means we'll have to talk LDP too :) http://islandora.ca/sites/default/files/images/It%E2%80%99s%20Dangerous%20to%20Go%20it%20Alone.pdf

[sprklinginfo]

@daniel-dgi Thanks! I will check out both slides.
@dmoses Sounds like a good idea.
@manez when you said "original aspect ratio is too far from that of the thumbnail area", Do you mean the original image is too big? It would be great if I can see a screenshot for that "wonky" thumbnail.

[manez]

Check out this example: http://future.islandora.ca/node/6

Thumbnails are being forced into a certain aspect ratio, regardless of the original, so a long thing image becomes short and squat.

[DiegoPino]

@sprklinginfo, currently the thumbnail is being build from the medium size and the height and width values (css, image is not resized) are being set here https://github.com/Islandora-Labs/islandora/blob/7.x-2.x/drupal/islandora_medium_size_service/include/islandora_medium_size_service.inc#L39-L45

My 2 Cents, i believe the size should be removed there,
as @dmoses correctly states, going the drupal way, this should/could be configured using the image-styles config page. To apply this you need to go to drupal land and enforce an 'image_style' instead of setting height and width. From there, it's up to defining a correct style using the admin and/or theming using templates. I hope this helps.

[daniel-dgi]

I'm torn here. Ideally we'd be doing image processing through services in the middle layer, putting them in Fedora, and then having those get pushed asynchronously to Drupal as files.

It certainly would be easy to latch onto Drupal image styles, though. Is there a way we can get at the info stored in the db so we can let the user input config through a UI and use it to do processing outside of Drupal-land?

[manez]

Philosophically, do the thumbnails need to be in Fedora? Are they part of preservation, or just a tool for display?

[ruebot]

I don't think they need to be in Fedora. It'd be nice to have them in Drupal, which then opens up the possibility of CDNs for our web deliverable derivatives. Scalability is the name of the game IMO 😄

[daniel-dgi]

@ruebot but there's a difference between being served and being preserved. I don't think anyone's gonna argue against serving thumbnails through a CDN. But do we want to hold onto a copy for folks in Fedora?

Personally, I wouldn't bother so long as there's a way of reasonably regenerating them without incurring too much overhead. But PCDM does account for thumbnails through the 'Use' ontology, so I guess it's up for debate with the preservationists out there.

As developers, we should take into account what our backup plan is if thumbnails get borked. If you lose 1000000 thumbnails, is that a load you want to put on the drupal server? Maybe it's faster than pulling 1000000 thumbnails out of Fedora? So many questions....

[ruebot]

@daniel-dgi yeah, you're right. When I think about this in terms of a upgradation, which I going to be the great majority of implementations, we'll be bringing over those datastreams. So, yeah. We put derivatives in Fedora... or maybe allow a configuration option?

[dmoses]

Re: where to store derivatives. I think there was a reason why we chose to store all the content in Fedora. There are probably still good reasons to do so. If we've not tested performance for fedora4 vs drupal we should create a ticket to do so. The things that worry me are not so much the public content, but those materials that will have security policies that may have portions displayed or not. I don't know how to achieve that without it all being in fedora with a security policy applied.

Re: the TN and other derivates ... predictability would be really useful.

At the moment when you manually add a thumbnail to a Basic Image object for example, it doesn't prefix the filename with the UUID or rewrite the file name. If I want to do field rewriting in a Drupal view with the medium sized derivative I can:
<img src="http://localhost:8000/sites/default/files/[UUID]_MEDIUM_SIZE.jpeg" />
and it would be useful to have the same pattern applied to the TN or other derivatives? eg.
<img src="http://localhost:8000/sites/default/files/[UUID]_TN.jpeg" />
Otherwise I think the sites/default/files directory is going to get pretty ugly, pretty fast and creating sensible views may be harder?

dm

[DiegoPino]

@ruebot, @daniel-dgi, @manez and @dmoses . I agree having the derivatives (or some of them) is a need at the fedora side, but we come back to a more generic issue: derivative workflow definition based on drupal content type -> rdf:type? Will we be passing parameters for this from drupal (in that case we could even read the image_styles defined there as parameters?) or will all derivatives been defined directly at camel side with common config files? Also the drupal permissions will be translated directly to fedora right? That is the idea of using drupal for all?

Also, which fields go through a derivative process and if this will be exposed via UI a drupal? If you look, e.g at islandora 1.x, we are storing collection thumbnails on fedora, even when most of them are the same folder icon (waste of resources). I see no need for having that in islandora 2. Also, e.g, collection/image navigation is so theme based, that it would be nice to have drupal manage those at certain extend/even override.

I also have so many questions….

For now i would vote for having, in case of thumbnails, a derivative, as big and as little as possible on fedora maybe, to serve multiple purposes, so that reconstructing the thumbnail could be a quick drupal task based on that, even css based, if needed.

[sprklinginfo]

@ruebot, @daniel-dgi, @manez, @dmoses and @DiegoPino : Before we make a decision whether we should have a thumbnail derivative in Fedora or not, since the Thumbnail field in 'Basic Image' content type is a image field, it can natively leverage Drupal 'Image Style' capability with following steps:. 1) remove 'height' and 'width' lines from https://github.com/Islandora-Labs/islandora/blob/7.x-2.x/drupal/islandora_medium_size_service/include/islandora_medium_size_service.inc#L39-L45. so there will be no height and weight attr in tag; 2) create a custom image style called 'islandora_tn' on 'admin/config/media/image-styles' > Choose Effect 'scale' with width 150px and height 150px, don't check 'allow upcaling' option. This image style is telling Drupal to scale an image to max width and height with respect to original aspect ratio. 3) Go to 'admin/structure/types/manage/islandora-basic-image/display' page, Click gear icon beside 'Thumbnail' image field, change Image style dropdown list from None (Original image) to our custom 'islandora_tn' . I tried with the cheese burger image manez mentioned for a basic image object, the thumbnail image is displayed with 'islandora_tn' image style ( 88 x 150) which is the correct original aspect ratio.

[daniel-dgi]

@sprklinginfo that seems fair enough. It satisfies the ticket and will buy us all time so we can continue this discussion. Sounds like something we should chat about IRL on the call tomorrow.

Any objections from others?

[DiegoPino]

@sprklinginfo++, i think this is the way to go for now. If possible, http://www.drupalfoo.com/drupal-7-creating-image-style-programatically-module and assign also programatically to the field.

[dmoses]

is an actual TN derivative going to get generated? CSS scaling a 2Mb doesn't make a bunch of sense, but not sure what the original intention was.

[daniel-dgi]

@dmoses to my knowledge, using drupal image styles creates a new image and saves it as a file.

[ruebot]

@daniel-dgi @sprklinginfo adding to agenda.

[sprklinginfo]

@daniel-dgi @ruebot @DiegoPino : It is said that one of "Islandora sync" functionalities is to generate derivatives. use 'medium-size' image as an example, could you please point me where the codes are used to create it? Thx!

[DiegoPino]

@sprklinginfo, for how i understand the routes we have in camel, i think right now we are passing back the original resource from fedora directly to drupal, to tn and medium size fields, not doing derivatives.

I think we should address #69, if we document at a fine level, including routes, languages used, input/output, messages and their transformations used by those and the whole workflow, it could be easier for new people (and not so new) to understand the current architecture. I know it's a big job.

[sprklinginfo]

@DiegoPino +1. A fine diagram will be great!

[daniel-dgi]

@DiegoPino is correct. We're just dumping back to drupal and sidestepping the whole issue. #69 will be a great launching point for the conversations we need to have about all of this.

[ruebot]

See also #179

[dannylamb]

Closing D7 related tickets.