Exact photometrics in GDTF - EULUMDAT
Add support for IES/LDT files.
Yes that would be very cool,
Here it is vital that there is some contract in place for the type of IES/LDT files used. Ie. which zoom level, focused or defocused, with or without frost or any beam shapers. This needs to be specified in some non-mode-specific form. Extra tricky for fixtures that swap optics, although GDTF does not understand that at all I believe?
Here it is vital that there is some contract in place for the type of IES/LDT files used. Ie. which zoom level, focused or defocused, with or without frost or any beam shapers. This needs to be specified in some non-mode-specific form.
This is a good point.
Extra tricky for fixtures that swap optics, although GDTF does not understand that at all I believe?
Yes, this is something we should consider. Any other important consideration from your point of view Lars? The width of the field (cone agles)? Resolution/steps of the angles?
Adding another feedback from another visualizer:
In fact, the IES or LDT files are all I need. What is often missing with some manufacturers are photometric files of the accessories, e.g. if there are filters for the lenses. That is very important in my opinion, because many customers first want to test different concepts in the Visualizer.
There's lots to think about when making IES/LDT files and we come across a lot of troubled files, but I don't think it's really relevant to GDTF. One thing could possibly be related to multi-aperture fixtures though. From our point of view it would have been best if the IES/LDT was made using only one aperture, especially for asymmetrically shaped fixtures.
Current things being considered:
-
- IES or LDT? Allow to provide both.
-
- internal IES/LDT structure? This is defined by each of these formats
-
- recommended practices (e.g. step size)? As per point 2, this is covered by the format specification. It is up to the manufacturer to provide LDT with for example step size of 0.1° if the minimal beam angle of the device is for example 1°, rather then using step size of 1° which could fail to provide any data in the 1° beam angle
- number of LDT files for dynamic (variable) zoom fixtures: Do at least minimum, 50% and maximum beam angle
- "Circumstances of the measurement"? Yes, we should describe what was the state of the device for this particular IES/LDT file. What if the settings cannot be defined by control and is only present via presets (menu)?
- link "active" channel sets (and their values) (for example zoom, dimmer, colors). Practically, these measurements should always be taken with an open beam, but this allows for further future usage, for example to provide IES/LDT with inserted frost. MacroDMX, CustomName or CustomCommands (MVR) can be used for this.
- provide a description field for each IES/LDT file. It may be useful to describe the IES/LDT files for the user to mention specific feature, property or settings this is aiming at.
- if fixture doesn't have dynamic zoom, link single IES/LDT to beam geometry(s). If it contains dynamic zoom, link it to particular channel sets of Zoom attribute.
- Think of priorities if multiple channel sets provide measurements (zoom and frost)?
Examples cases:
a) fixture with single beam and fixed zoom - link a single photometrics file to the beam geometry - example: LEDBeam 100
b) fixture with multiple beams and fixed zoom - link one photometrics file to each beam geometry - not perfect example, but it conveys the idea of totally different beams: DigitalSpot 3500 DT
c) fixture with variable zoom (doesn't matter how many lenses) - link photometric files to channels sets of the zoom attribute - there should be at least one photometric file at the widest zoom, but recommended to attach photometrics to min/mid/max zoom - no linking of photometric files to the beam geometry. If exists, the channel sets linked files are to overwrite the geometry linked photometric definition - example of single beam fixture: Forte - example of multiple virtual beam fixture: megaPointe - the beam switching happens on DMX, thus channels sets of respective channel functions (Beam mode/Spot mode) would have a photometric file attached
d) multipixel fixtures with fixed zoom: - either single photometric file for the pixel attached to the master pixel which is used for geometry references or - single photometric file attached to the parent of the pixel, with a photometric for the complete output. This would require attaching photometrics to an arbitrary geometry :exclamation: - multipixel fixtures with variable zoom - if there is no zoom attribute for individual pixel to attach photometrics to, so detailed multizoom photometric description would not be possible, unless the multiple photometrics files were linked to the beam geometry with information of what zoom they apply to - link photometric files to channels sets of the zoom attribute (there should be at least one photometric file at the widest zoom, but recommended to attach photometrics to min/mid/max zoom)
Fixtures with replace-able lenses can be dealt with in the same way as before, in current version of GDTF Spec, options are: - use virtual zoom attribute with channel sets describing the options - use multiple DMX Modes - multiple GDTF files
Could we have a node in the PhysicalDescriptions node dedicated to photometrics. And within this node have multiple nodes of collections of photometric files. Each collection would hold the photometric data for a beam with specific settings (mode, accessory, focus e.tc).
For instance we could have a collection for when a fixture is in beam mode, another for when it is in spot mode and another for the wash mode. This would allow for an expansion for accessories, frost, different power settings of the lamp etc.
Within each collection there would be a definition for at least the minimum zoom and the maximum zoom angles, or a single angle when the fixture has no zoom capability.
The zoom attribute value would then be used to pick out the correct definition to be used from the collection. There could be another attribute used to select the active collection.
Solved in https://github.com/mvrdevelopment/spec/pull/183