Add support for images

[Cyberuben]

Hi, I've quickly looked over the documentation and everything seems to look great. However, I know that programs such as DASLight allow you to set images for certain values. For example, my CS1000RGB laser has a pattern set for each 2 DMX values (0-1 pattern 1, 2-3 pattern 2). Would it be possible to add the ability to set and store small icons for this purpose? I'd suggest storing them in a folder that has the same name as the .json.

[FloEdelmann]

I'd probably rather extend the resource system that is currently only used for gobo images, see the documentation.

I think it's a good idea worth investigating, but I'll probably won't implement it myself. PRs welcome, though! I'll be happy to review and give feedback :)

[Cyberuben]

I think using the gobos spec like you said isn't really a bad idea, however, these don't seem to be exported when downloading the fixtures in ofl format, and I think this folder structure can get quite messy when loads of different patterns / gobos are defined from various manufacturers.

[FloEdelmann]

gobos don't seem to be exported when downloading the fixtures in ofl format

Indeed. That's worth implementing anyway, though.

this folder structure can get quite messy

I think the same is true when image subdirectories are scattered around the fixtures directory.

Do you have an idea for how to better structure the resources/gobos directory?
Or maybe only the resources/effect-images (or similar) directory first?

[Cyberuben]

I'd suggest just maintaining the structure like this:

/fixtures/<brand>/<model>.json
/fixtures/<brand>/<model>/<image>.<png | svg>

That way they are close to the fixture JSON file. Could even go with something like /fixtures/<brand>/<model>/fixture.json and keep the images in the same folder.

Are there any reasons you decided to store images in a /resources/ folder?

[FloEdelmann]

First, I didn't want to clutter the subfolders of fixtures/ with any other files, because quite some logic relies on the fact that all files in these directories are fixture files.

But more importantly; gobos can (and should) be reused across fixtures, so it doesn't make sense to store them near specific fixtures. I'd like to keep that advantage also for other images, because there will likely be product series with multiple fixtures featuring the same effects / images.

[Cyberuben]

I'm not sure if that logic will hold up. Each brand has their own types of gobos that might differ slightly from other manufacturers, some include colors and some are clear. I'd want to be able to represent that in an image. If you maintain the current folder structure, that means you'd possibly have tons of variations of 'almost the same' gobos, but they don't really fit with any of the implementations.

For my Laserworld CS1000RGB MKII, there are 128 patterns I can choose from, and I'm fairly sure that some of these are highly specific to this laser. If you'd ever want to implement a "pick and download" sort of method, I'd assume it would be more efficient to just add certain folders to a zip, without having to open all fixture definition files, scan for resources, and then bundle them separately. Might also cause conflicts if multiple people start on adding fixtures and they use the same filenames.

[FloEdelmann]

Each brand has their own types of gobos

At least reusing the gobos for multiple fixtures of the same manufacturer makes sense then. But actually even right now (with very few gobos in our library), there are two fixtures from different manufacturers that are using the same gobos: Showtec Phantom 50 LED Spot and Stairville MH-X50+.

you'd possibly have tons of variations of 'almost the same' gobos, but they don't really fit with any of the implementations

As a visualization for the lighting designer/operator, a nearly fitting gobo is better than none IMO. And having multiple similar but distinct gobos in that folder is totally okay.

Might also cause conflicts if multiple people start on adding fixtures and they use the same filenames.

Currently, gobos can only be added via pull requests (there's no GUI yet), so I don't see that as a problem.

---

gobos don't seem to be exported when downloading the fixtures in ofl format

I had a second look: Actually, the gobo images are bundled in the OFL export, they are just included in the JSON as a base64-encoded string. I'm fine with also adding the source SVGs / PNGs to the export ZIP, though.

[Cyberuben]

As a visualization for the lighting designer/operator, a nearly fitting gobo is better than none IMO. And having multiple similar but distinct gobos in that folder is totally okay.

I do agree with that statement, but I've seen you use aliases at other places in the repository, the same can be done here. Assume fixture A has a gobo that contains 3 circles in a triangle formation, you can just link to that from another fixture. If it doesn't exist, include it into your own fixture. At worst, you have duplicate icons, at best, you can reuse others.

Currently, gobos can only be added via pull requests (there's no GUI yet), so I don't see that as a problem.

I understand that, however, this means that if someone 'corrects' an image for a fixture, for example, adds colors, and another fixture doesn't have this anymore, you might 'break' the fixture definition for other fixtures.

Nonetheless, I think that maintaining one huge folder with gobos / patterns / other images will be very hard to do. GitHub won't show more than 1000 files in a single folder when browsing through the repo, so I think some additional folder structure won't be bad. We just have to agree on which?

[FloEdelmann]

Aliases work differently than you describe. Again, please see the docs.

you might 'break' the fixture definition for other fixtures

That's always the case with reused files 😅
So it should be part of the PR review process to also check for other usages of the resource file.

I think that maintaining one huge folder with gobos / patterns / other images will be very hard to do. GitHub won't show more than 1000 files in a single folder

Agreed, good point.

We just have to agree on which?

That could be different for the different resource types. Could you share some examples of the CS1000RGB laser pattern images from your original proposal?

---

For the gobo resources, I could imagine a structure based on the displayed shape:

Example:

• resources/gobos/
  • aliases/
    • qlcplus.json
  • circles/
    • 10-circles.json
    • 10-circles.svg
    • glass-red-10-circles.json
    • glass-red-10-circles.svg
  • spirals/
    • 3-fold-swirl.json
    • 3-fold-swirl.svg
    • dot-spiral.json
    • dot-spiral.svg
  • other/
    • biohazard.json
    • biohazard.svg
    • glass-raindrops-on-window.json
    • glass-raindrops-on-window.png
    • rose-petal.json
    • rose-petal.svg
    • triangle-hexagon-pattern.json
    • triangle-hexagon-pattern.svg

So the categorization would be highly subjective. But the current naming is, too. I don't quite like that the aliases folder is at the same level than the other "category" folders though.

However, while I'm open for PRs that work on this, I won't put any effort into this restructuring myself, as the current scheme works well enough right now.