Image type/description/category

[hoijui]

As of now, one can add 0 to many images, referenced with a (repo-)path or URL each.

image = "img/this-thing.png"

There is no way of telling of which nature these images are, or which (if any) fits into a specific context. Images may be:

• a logo
• a technical illustration of the machine
• a photo that shows a technical detail of the machine
• a photo that shows a problem with the machine
• a photo that shows the whole machine in in a specific use-scenario
• a general photo of the machine, useful for marketing or a web-shop
• ...

These are not really interchangeable, and to tell from just the image data which is which, is pretty hard and unreliable.

Therefore, I propose to add some kind of category system, with a set of predefined (in our standard) categories, potentially allowing the users to use custom ones. An image may be in multiple categories, or in none.

In TOML, it may look like this

[[image]]
path = "img/this-thing.png"
categories = [
  "marketing",
  "shop",
]

In the FabCity Hamburg INTERFACER project, the idea is to use OKH as the OSH project meta-data standard. This though, would be an additional requirement there.

This is very much related to OPEN-NEXT/OKH-LOSH_copy#43.

Summary

Instead of just a path/UR to an image file, an image (TOML) could be a composite type, with sub values:

• location (path/URL) [required]
• category (main|logo|photo|...) OR tags [required|optional?]
• description (String) [optional]

And of course we would have the same change in RDF.

[hoijui]

This is obviously more complex TOML code, which is the main drawback. -> needs to be discussed!

Are there maybe alternative solutions?

[cryptix]

This is obviously more complex TOML code

I'd say it's still simpler then having a bunch o predefined keys like this:

image_shop="shop.png"
image_schematic="shop.png"

I also like the list category system. Potentially I think, it would work for attributes like the viewing angle/side, too.

Additionally, also to help with OPEN-NEXT/OKH-LOSH_copy#43, it might help to have an extra (optional) description="The widget flying through air".

[hoijui]

+1 on optional description!

[moedn]

from my perspective:

• the image(s) is/are intended to give a brief impression of the device; this is also what's previewed on LOSH after all
• ↑ this should be a note/comment in the specs, so people know the intention behind the picture
• +1 for optional caption instead of categories (e.g. caption_image1=xxx)

[hoijui]

the thing is, that there are different kinds of images, useful for different things, and I think multiple of these make sense for OKH in practice, or say, for consumers of the OKH data. This is actually how this issue came to be, as dyne/FCHH/INTERFACER/FCOS came up with this need. I do not think, that a single image per project is good enough. for example, think of the projects on the OSEG Wiki: Most of them have a kind of logo, where one can identify the project easily with the image being small, next to many other project images. On the other hand, If one looks at a single project, one would rather want to see a photo of the finished product in large, to have a quick idea what this is about and see some details. This same photo though, is not useful in small, next to many other small photos of projects. This can not be solved with a caption/description (instead of category/tags).

[hoijui]

In the meeting we had this morning, @moedn and me came to the conclusion, that this makes sense. We will support both the old way of specifying images:

image = "img/this-thing.png"

and the new way:

[[image]]
location = "img/this-thing.png"
category = "photo"
description = "This shows the front of the finished machine with a gold finish"

In the new way (composed object vs literal), we will support:

• location (required) for a repo-relative path or web-URL
• category (optional) as a single string, chosen from a predefined, closed set of categories (yet to be defined)
• description (optional) as a free-form text describing the image, which might e used as caption or alt-text

To come up with the categories for images, we will consult with dyne.org, but any comments here from anyone are very welcome too!

[hoijui]

image category/tag examples (just to start the though process for everyone):

• main
• preview
• overview
• wire-frame
• logo
• 16px
• 32px
• 64px
• 128px
• 256px
• photo
• schematics
• pcb
• tech-drawing
• sewing-pattern
• artistic
• specs
• front
• back
• top
• bottom
• left
• right
• animated
• diagram
• packaging
• team

[hoijui]

My current view:

The technically most flexible and capable solution would be, to support these two properties simultaneously:

1. slots: any of a predefined (by OKH) set of values. An image could fill multiple slots, but each slot can be filled at most once. This is useful for things like the project-icon, or the left-side view of the 3D model.

   examples:

   • logo
   • icon-main
   • icon-main-bw (black&white)
   • social (social media preview)
   • organization-logo
   • organization-logo-bw (too much?)
   • symbol (see Icon vs Symbol below)
   • photo-thing-main
   • photo-packaging
   • model-from-left
   • model-from-right
   • model-from-top
   • model-from-bottom
   • model-from-front
   • model-from-back
   • model-3d
   • model-main
   • ... (TODO: Revise this list)

2. tags: a number of predefined+self-defined values. An image could have 0 to many tags attached. Each tag could be used by multiple images.

   examples:

   • photo
   • icon
   • logo
   • model
   • art(istic)
   • diagram
   • color
   • b&w
   • screenshot
   • ... (TODO: Revise this list)

Examples

[[image]]
path = "res/assets/media/img/main-photo.png"
slots = [
  "photo-thing-main",
]
tags = [
  "photo",
  "color",
]

[[image]]
url = "https://bla.com/logo.png"
slots = [
  "organization-logo",
]
tags = [
  "logo",
  "color",
]

[[image]]
path = "res/media/img/icon.svg"
slots = [
  "icon-main",
]
tags = [
  "icon",
  "color",
]

[[image]]
path = "res/media/img/icon-bw.svg"
slots = [
  "icon-main-bw",
]
tags = [
  "icon",
  "b&w",
]

[[image]]
path = "res/assets/media/img/screenshot-1.png"
slots = [
]
tags = [
  "screenshot",
  "color",
]

[[image]]
path = "res/assets/media/img/screenshot-2.png"
slots = [
]
tags = [
  "screenshot",
  "color",
]

[[image]]
path = "res/assets/media/img/model.png"
slots = [
  "model-3d",
]
tags = [
  "model",
  "color",
]

Icon vs Symbol

(source: flaticon.com)

An icon is a simple image that represents a real thing. For example, a shopping cart icon.

A symbol is a simple image whose meaning must be learned. For example, most traffic signage is made of symbols. A "no parking" sing with a P crossed out with red needs to be learned to be understood.

[moedn]

sounds reasonable :ok_hand:

but I also want to point out that this clearly exceeds my expertise^^ please feel free to take decisions &/ consult people knowledgeable in this field (e.g. Basti for web development). would be cool to use standardized wordings & lists for slots & tags

[hoijui]

agreed!

I will continue this discussion here, but you need not follow it. I just write stuff to document the process.

tags I expect to be standard. slots... I confess, I made up myself. I did digress from categories, because with categories, multiple images can be in the same category, while each image would have at most 1 category. here though, we want the opposite: each "slot" can be filled at most once. a thesaurus search for alternatives to "slot" (filtering out the obviously non-fitting), leads to:

• slot
• channel
• position
• slit
• hole
• socket

I would consider slot or socket to be the best fitting.

Others must have the same requirements, and it should be possible to find what they use ...

I wound the HTML element <slot>, which is basically a placeholder in an HTML element, supposed to be replaced with something else by some templating engine (some software):

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/slot https://developer.mozilla.org/en-US/docs/Web/CSS/::slotted

Apart from the replacing, we have the same "filling in (at most) once" logic.