Image aspect generation.

Description

Using Guise Mesh () is working well to generate image galleries, but the problem is that even with scaled images (), the image files will still be too big for many connections for a large gallery page to download them all to show as previews. We need a way to generate image previews, but some general way that fits into the Guise Mummy system.

Environment

None

Activity

Show:
Garret Wilson
January 18, 2021, 10:18 PM
Edited

There remains the decision of how to refer to artifacts that have aspects. A grammar discussion says that there is a word "aspectual" which is rare and obsolete, although it is still used as a grammatical term. The discussion also mentions a synonym "faceted", but I had considered "facet" and felt that it conveyed more of a sense of "part of a whole" rather than "viewpoint". So I will go with "aspect" as a "predefined viewpoint", a middle ground between (or combination of) "facet" and "perspective". The grammatical discussion I just mentions also points out that:

aspect has the Latin root aspectus, or "to look at".

Garret Wilson
January 25, 2021, 3:57 PM

We need to define and configure the image aspects. Ideally and maybe in the long term we could be completely flexible like this:

But that requires quite a bit of setup just for something useful. It would be nice just to "turn on preview generation". In addition for this particular syntax we don't have a good way in Confound to retrieve a map, I don't think.

Instead to get things started quickly and provide for future expansion, we could have some predefined image aspects, probably preview and thumbnail, with default settings. There could be a single mummy.image.enabledAspects set that by default is empty. A user would enabled preview generation like this:

Then if the user needed to override the preview image size, they could do something like this:

Note that instead of a map we're using an anonymous object for aspects in the TURF, with the aspect identifiers as property handles. It still doesn't feel ideal. A map would be semantically more accurate. And enabledAspects would more accurately be enabledAspectIds. I'll give it some more thought.

Garret Wilson
January 26, 2021, 2:30 PM
Edited

Another approach would be to use the URF ID facility to list and define aspects at the same time:

If you wanted to use the defaults, you could just reference the ones you use:

You could even define them elsewhere in the configuration file, to be used in that same configuration or in some child configuration, for example.

Note that above a different aspect is defined but not used. The same aspect could be defined separately as well; TURF processing would automatically merge them in.

This is the more "natural" approach for URF, but we would have to update Confound to get the configuration form mummy.image.aspects.preview.scaleMaxLength to be able to lookup an object with an ID inside a list/set of objects. For the collection itself (mummy.image.aspects), it appears that we can have them returned as a collection of Confound "sections" with the existing implementation, but it doesn't appear that the aspect IDs (important) would currently be retained. I also wonder if the ArtifactAspect#preview form is too verbose, when many users would expect simply preview.

And lastly there is a more general issue that I just realized that may affect configurations: if a base configuration sets some list mummy.image.aspects to (ArtifactAspect#preview, ArtifactAspect#thumbnail) but a child configuration changed this to just (ArtifactAspect#preview), a configuration query would still return mummy.image.aspects.thumbnail.scaleMaxLength (if defined on the parent configuration) because of fallback, although mummy.image.aspects would still only return (ArtifactAspect#preview).

Garret Wilson
January 28, 2021, 2:40 PM
Edited

I think we have to be pragmatic here. We also have to remember that ultimately the interface to the user is the configuration, not the (T)URF. So the primary focus should be on making this configurable, while making sure TURF supports that as naturally as possible.

Thus I'm leaning towards mummy.image.withAspects as the setting. "enabledAspects" is too clunky and "enabled" is overused as to be ambiguous ("enabled in what way"?). "hasAspects" implies more of a test. "withAspects" is more prescriptive, something we would use in a builder or in manipulating a value object using a fluent API. (I don't know how common it is to use fluent terms in a configuration; maybe this is an innovation. Let's see how it works.)

And to change an aspect setting, we can use "aspects" with the aspect ID, e.g. mummy.image.aspects.preview.scaleMaxLength: This could be stored in TURF in a couple of ways:

Or probably more semantically appropriate:

There is always the decision of singular or plural for the "collections", i.e. mummy.image.aspects.preview.scaleMaxLength or mummy.image.aspect.preview.scaleMaxLength. I almost went with mummy.image.aspect.preview.scaleMaxLength, but I think mummy.image.aspects.preview.scaleMaxLength is clearer that this is the point that the aspects are being defined, even though it could be confused with "withAspects".

It's not perfect but it may work.

Garret Wilson
January 30, 2021, 4:38 PM
Edited

There is always the decision of singular or plural for the "collections", i.e. mummy.image.aspects.preview.scaleMaxLength or mummy.image.aspect.preview.scaleMaxLength. I almost went with mummy.image.aspect.preview.scaleMaxLength, but I think mummy.image.aspects.preview.scaleMaxLength is clearer that this is the point that the aspects are being defined, even though it could be confused with "withAspects".

When actually developing this, I found myself actually typing the form mummy.image.aspect.preview.scaleMaxLength}}—with the singular form—so perhaps that is more natural for the configuration key form. But it doesn't make as much sense in the configuration file, although I realize now that we are using the singular with the {{image and page sections. I'll switch to the singular and see how that goes.

I think the singular form seems more appropriate as a configuration key, because settings are thought of as "noun.setting=value". So if we identify the noun, we use "noun.adjective=value" or "noun.adjective.adjective=value". In this case we are setting the "scaleMaxLength". Which one? Of the "aspect". Which aspect? The preview aspect. Which preview aspect? Of the image. So …image.aspect.preview.scaleMaxLength. I suppose we aren't so much talking about a hierarchy of resources and subresources as we would be in RESTful API or in an URF graph. So here again I suppose the configuration model takes precedence over the underlying implementation.

Fixed

Assignee

Garret Wilson

Reporter

Garret Wilson

Labels

None

Epic Link

Components

Fix versions

Priority

Critical