-
Notifications
You must be signed in to change notification settings - Fork 64
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for images #1940
Comments
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 :) |
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 |
Indeed. That's worth implementing anyway, though.
I think the same is true when image subdirectories are scattered around the Do you have an idea for how to better structure the |
I'd suggest just maintaining the structure like this:
That way they are close to the fixture JSON file. Could even go with something like Are there any reasons you decided to store images in a |
First, I didn't want to clutter the subfolders of 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. |
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. |
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+.
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.
Currently, gobos can only be added via pull requests (there's no GUI yet), so I don't see that as a problem.
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. |
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.
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? |
Aliases work differently than you describe. Again, please see the docs.
That's always the case with reused files 😅
Agreed, good point.
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:
So the categorization would be highly subjective. But the current naming is, too. I don't quite like that the 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. |
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
.The text was updated successfully, but these errors were encountered: