The invention relates to automatically verifying the possibility of rendering a lighting atmosphere from an abstract description, for example from a lighting atmosphere specified in XML (Extensible Markup Language) independent of a specific lighting infrastructure and of a room layout.
Current lighting systems in commercial environments and homes have a rather fixed setup. Light systems in theatres and discos have lots of dynamics, but this is mostly programmed and the scripts are specific for the light system. In future light systems for commercial and home environments, light atmospheres may be created from scripts which describe the static and dynamic elements of a lighting atmosphere, created by a variety of colored and white light units, but are independent of the specific lighting infrastructure. These scripts should cover a wide range of possible lighting systems. Thus, these scripts must describe a certain lighting atmosphere in an abstract way in order to be useable with a plurality of different lighting systems. An abstract description of a lighting atmosphere may be for example made in XML (Extensible Markup Language). The term “abstract” means independent of a specific lighting system or infrastructure, i.e. the light units, and independent of a specific room or building layout.
The system independent light script or abstract description of a lighting atmosphere can be automatically rendered to a target environment. For a set of locations in the target environment, the desired light effects and light settings have to be created. This can be done by splitting up the light script into parts that are related to semantic areas (locations in the target environment). Light units in the semantic areas are selected to realize the effects and control values for these lamps have to be determined. In the step of automatically rendering a lighting atmosphere to a target environment, it would be helpful to verify whether the rendering in a specific target environment is possible or not.
It is an object of the invention to provide an automatic verification of the possibility of rendering a lighting atmosphere from an abstract description, particularly in order to obtain an early feedback on rendering a lighting atmosphere in a certain lighting environment.
The object is solved by the independent claim(s). Further embodiments are shown by the dependent claim(s).
A basic idea of the invention is to create for each addressable light unit of a light infrastructure a so called light infrastructure capability that generally describes the effect, measures the maximum possible effect and relates the effect to a location in a semantic area of a target environment. A light infrastructure capability may help to detect in an early stage of rendering a certain lighting atmosphere from an abstract description whether rendering is possible or not. Individual light infrastructure capabilities may be clustered together, based on the light effect they generate, for example ambient, spot light or wall wash, and based on the location in the semantic areas. This allows creating light infrastructure capabilities for parts of semantic areas of a lighting infrastructure. Furthermore, light infrastructure capabilities may be clustered towards the semantic areas, so that they describe the lighting possibilities in the semantic areas. Thus, a light infrastructure capability may be used in the process of automatically rendering a certain lighting atmosphere from an abstract description in order to describe the lighting possibilities in semantic areas and makes it possible to give an early feedback of the possibility of rendering the certain lighting atmosphere in a certain lighting infrastructure. The concept of light infrastructure capabilities as described herein is closely connected with the concept of light element templates as described in the European patent application no. 06127084.9 of the applicant. In general, a light element template contains an indication of the possibilities of the lighting infrastructure at a certain semantic location, for example in a shop or a home in which the lighting infrastructure is provided. Thus, a light element template is a higher abstraction level of the possibilities in a lighting infrastructure than the light infrastructure capabilities which are more closely related to the individual lighting possibilities in a lighting infrastructure such as the light type, intensity range, the light effect and location of light effects of a specific light unit of a lighting infrastructure.
In the following, some important terms used herein are explained.
The term “lighting atmosphere” as used herein means a combination of different lighting parameters such as intensities of different spectral components of lighting, the colors or spectral components contained in a lighting, the color gradient or the like.
The term “abstract description” of a lighting atmosphere means a description of the atmosphere at a higher level of abstraction than a description of settings of the intensity, color or like of every individual lighting device or unit of a lighting infrastructure. It means for example the description of the type of a lighting such as “diffuse ambient lighting”, “focused accent lighting”, or “wall washing” and the description of certain lighting parameters such as the intensity, color, or color gradient at certain semantic locations at certain semantic times, for example “blue with low intensity in the morning at the cash register” or “dark red with medium intensity at dinner time in the whole shopping area”. Furthermore, “abstract description” herein means an essentially lighting system independent lighting atmosphere description.
The term “semantic location” or “semantic time” means a description of a location or time such a “cash register” in a shop or “lunch time” in contrast to a concrete description of a location with coordinates.
It should be understood that the abstract description of a lighting atmosphere does not comprise concrete information about a specific instance of a lighting infrastructure such as the number and locations of the used lighting units or devices and their colors and available intensities.
The term “lighting infrastructure” means a concrete implementation of a lighting system in a specific environment or room, for example a specific instance of a lighting system applied to a certain shop, hotel lobby, or restaurant. The term “lighting infrastructure” comprises a complex system for illumination, particularly containing several lighting units, for example a plurality of LEDs (light emitting diodes) or other lighting devices such as halogen bulbs. Typically, such a lighting infrastructure applies several tens to hundreds of these lighting devices so that the composition of a certain lighting atmosphere by individually controlling the characteristics of each single lighting device would require computerized lighting control equipment.
According to an embodiment of the invention, a method for automatically verifying the possibility of rendering a lighting atmosphere from an abstract description is provided, wherein the method comprises the following characteristic features:
By receiving and processing the light infrastructure capabilities, it is possible to give an early feedback in the process of automatically rendering a desired lighting atmosphere from an abstract description. The light infrastructure capabilities allow for automatically processing light unit specific features during the rendering process.
According to a further embodiment of the invention, the method may further comprise the step of automatically creating a light infrastructure capability for every individually addressable light unit of the lighting infrastructure. Particularly, a light infrastructure capability for an individually addressable light unit may be created by a light unit controller of the light infrastructure which provides a description of its control interface and announces the controlled light units. A light infrastructure capability for an individually addressable light unit may also be created by means of a calibration, particularly a dark room calibration, where the effect of specific control sets is executed on the light unit and the effect of the controlled light unit is measured by cameras and/or sensors.
According to a further embodiment of the invention, the step of automatically processing the received light infrastructure capabilities comprises clustering several light infrastructure capabilities into larger groups of light infrastructure capabilities according to certain criteria. By clustering light infrastructure capabilities, the number of light infrastructure capabilities to be automatically processed may be decreased. For clustering, one or more of the following criteria may be used:
According to a further embodiment of the invention, the step of automatically processing the received light infrastructure capabilities may comprise
The light element templates may be created as described and disclosed in detail in the European patent application no. 06127084.9 of the applicant. The usage of light element templates makes the automatic processing of the light infrastructure capabilities easier since only a comparison step is required in order to determine whether a light effect described in the abstract description may be rendered in the target lighting environment.
According to a further embodiment of the invention, the method may comprise the further step of automatically making information on available light units of the lighting infrastructure and their capabilities available in a network environment by means of a service and device discovery mechanism.
According to an embodiment of the invention, the method may further comprise the steps of
This embodiment is useful for home lighting and obtaining lighting atmospheres over a communication network such as the internet. The client may be a personal computer at home, for example accessing a website offering lighting atmospheres for buying. A user may select a desired lighting atmosphere on the website. Next, the personal computer of the user may transmit the infrastructure capabilities of the home lighting infrastructure to the server, for example after the user has clicked on a certain button of the website. The infrastructure capabilities may either entered manually in the personal computer or automatically by communicating with the light units of the home lighting infrastructure assuming the light units and the personal computer are connected via a home network, for example a LAN (Local Area Network) or WLAN (wireless LAN) or PAN (Personal Area Network). The client may also retrieve the light infrastructure capabilities which may be stored in a lighting controller of the lighting infrastructure or in each light unit. On the server, the received infrastructure capabilities may then be automatically processed, particularly by clustering several light infrastructure capabilities, creating light element templates from the clustered light infrastructure capabilities, and finally comparing the created light element templates with the light elements of the abstract description of the selected lighting atmosphere. Afterwards, the processing result may be transmitted from the server to the client. Finally, the result of the processing, i.e. whether rendering the selected lighting atmosphere from the abstract description is possible or not, may be displayed on the monitor of the personal computer of the client. Thus, a user may quickly and reliably determine whether a desired lighting atmosphere offered for buying may be rendered with her/his own home lighting infrastructure.
According to a further embodiment of the invention, the light infrastructure capabilities may be electronically received over a network connection with a lighting controller of a lighting infrastructure.
According to a further embodiment of the invention, a computer program is provided, wherein the computer program may be enabled to carry out the method according to the invention when executed by a computer.
According to an embodiment of the invention, a record carrier such as a CD-ROM, DVD, memory card, floppy disk or similar storage medium may be provided for storing a computer program according to the invention.
A further embodiment of the invention provides a computer which may be programmed to perform a method according to the invention. The computer may comprise an interface for communication with a lighting infrastructure. The communication may be for example performed over wire line or wireless communication connections between the interface and the lighting infrastructure. In case of wireless communication connections, the interface may comprise a radio frequency (RF) communication module such as a WLAN and/or Bluetooth® and/or ZigBee module which may establish a communication connection with respective counterparts of the lighting infrastructure.
According to a further embodiment of the invention, a system for automatically verifying the possibility of rendering a lighting atmosphere from an abstract description is provided, wherein the system comprises the following features:
According to an embodiment of the invention the system may comprise
According to an embodiment of the invention, the verification module may be implemented as a computer program executed by a computer.
According to a further embodiment of the invention, the computer may comprise a communication module comprising the receiving means.
These and other aspects of the invention will be apparent from and elucidated with reference to the embodiment(s) described hereinafter.
The invention will be described in more detail hereinafter with reference to exemplary embodiments. However, the invention is not limited to these exemplary embodiments.
In the following description, the terms “lighting device”, “lighting unit”, “light unit”, and “lamp” are used as synonyms. These terms mean herein any kind of electrically controllable lighting device such as a semiconductor-based illumination unit such as a LED, a halogen bulb, a fluorescent lamp, a light bulb. Furthermore, (functional) similar or identical elements in the drawings may be denoted with the same reference numerals.
An overview of a flow of a method for composing a lighting atmosphere from an abstract description for a shop is depicted in
An example of an XML file containing such an abstract atmosphere description is shown in
As already indicated, the mapping process 18 receives a target light “scene” from the rendering process 16. In order to calculate the lamp settings 24 required to generate light that approximates the target 22 as close as possible, the mapping process 18 needs to know which lamps contribute in what way to the lighting of a certain physical location. This is done by introducing sensors, which can measure the effects of a lighting device or lamp, respectively, in the environment. Typical sensors are photodiodes adapted for measuring the lighting intensity, but also cameras (still picture, video) may be considered as specific examples of such sensors.
As indicated above, abstract descriptions of lighting atmospheres will become possible in the future, both in professional (e.g. shop) as well as in the consumer domain. In both domains, it would be desirable to know beforehand how well such an abstract description of a light atmosphere can be rendered in a specific shop or home lighting infrastructure.
For instance, if a light designer at the head quarters of a shop chain wants to make a new light atmosphere for the shop chain, it is important that this light designer gets feedback on how well the atmosphere can be rendered in the shops of the shop chain.
This can be done by communicating the information of the lighting infrastructure (available light units, their characteristics and location) for all shops in the chain to the light designer. However, this method has large disadvantages. The amount of light sources can be very large, up to thousands of light sources per shop. This implies that simply communicating what kind of light units are available does not scale and will ‘overwhelm’ the light designer. Furthermore, the location of light units in the shop is not relevant to the light designer, but merely what the semantic location (e.g. entrance) of the light effect is. This requires transferring a detailed shop layout of every shop in the chain towards the light designer at the shop's head quarter (HQ), which again does not scale.
In the consumer domain, end-users that purchase an abstract light atmosphere of course want to be sure that such a light atmosphere can be rendered in their home, with its specific layout and lighting infrastructure. However, such an end-user is usually not an expert in lighting design and lighting systems. Consequently, it needs to be possible to verify in advance whether such a light atmosphere can be rendered. Impossibilities and limitations in the rendering need to be communicated to the consumer in an understandable way.
According to the present invention, a mechanism that enables verification of how well a light atmosphere can be rendered in a specific shop chain or home in a scalable and meaningful way is proposed as will be explained in the following in detail.
In
In order to give an early feedback of whether a certain lighting atmosphere may be rendered in this lighting system, a light management system has to find or create knowledge on the lighting infrastructure. In order to make an early feedback possible, light infrastructure capabilities are created for every individually addressable light unit.
A light infrastructure capability is created for each individually addressable light unit of the lighting system and describes the light type, intensity range, light effects and location of the effects on the environment. This can be done in (a combination of) several ways:
For the semantic area 52, the three TL's 30, 32, and 34 form a single light unit 50 with a single light infrastructure capability LiCap A1. For the semantic area 54, the spot lights 40, 42, and 44 and TL's 36 and 38 are clustered first to light infrastructure capabilities LiCap S and LiCap A4, respectively. Then the light infrastructure capabilities of these light units 36, 38, 40, 42, 44 are clustered to one light infrastructure capability LiCap A for the semantic area 54. This light infrastructure capability results in a lighting possibility for the area 54. The wall washers 46 and 48 are individually addressable. They are of the same type and have an effect in adjacent locations of an area 56. They are clustered into another light infrastructure capability LiCap W which describes an RGB Wallwash effect with top-bottom gradient possibilities.
From these lighting infrastructure capabilities or possibilities LiCap A1, LiCap A and LiCap W, light element templates LT1, LT2, and LT3, respectively, may be created as described in the European patent application no. 06127084.9 of the applicant. These light element templates may then be further processed by a light management system which renders the lighting atmosphere from the abstract description. A light element template is an indication of the possibilities of the lighting infrastructure at a certain (semantic) location in the shop or home. For every type of light effect, a different light element template will be created. In the following, the light element templates and their function is explained in detail.
The lighting possibilities for the different areas 1 to 7 in e.g. a shop can be ‘summarized’ according to the type of light that the light units can generate. This is performed by processing the light infrastructure capabilities of the light units as described above with regard to
In the above listed data for the different areas in the shop instance, the area selector is an indication of the semantic area in the shop or home. It may consist of one or more area types. For example, the area selector AT2/AT5 refers to all areas with type AT 5, which are a subarea of the areas with type AT2
By organizing and grouping this summarized lighting infrastructure information by the area selector, light element templates may be generated. All light element templates for the shop instance of
LightElementTemplate1
Area selector=AT1
LightType=Ambient
LightType=Architectural/wallwash
LightElementTemplate2
Area selector=AT2
LightType=Ambient
LightType=Task
LightType=Architectural/wallwash
LightElementTemplate3
Area selector=AT3
LightType=Ambient
LightElementTemplate4
Area selector=AT1/AT4
LightType=Accent
LightElementTemplate5
Area selector=AT2/AT5
LightType=Accent
LightElementTemplate6
Area selector=AT3/AT1
LightType=Ambient
LightType=Architectural/wallwash
The light element templates for the area selectors AT4 and AT5 are removed, as these do not occur ‘individually’ in the shop, but only in the combination AT1/AT4 and AT2/AT5.
As explained with reference to
LightElement1
Areaselector=AT1
LightType=Ambient
LightElement2
AreaSelector=AT5
LightType=Architectural/wallwash
LightType=accent
By comparing the light elements of the atmosphere description with the light element templates created from the light infrastructure capabilities as described above, it can be verified quickly and automatically whether it is possible to render the light elements in the specific shop or home. In the example, it is immediately clear that wall washing in areas with an area selector that ends with AT5 is not possible. If rendering is not possible, feedback can be provided for example at a semantic level, like displaying a message like “it is not possible to create a wall wash effect in the area with area type 5” in the light designer's computer monitor.
Finally,
The light infrastructure capabilities of the light infrastructure of the individual shops 70, 72 and 74 are collected and can be clustered to light infrastructure capabilities of groups of lamps by the local clustering modules 80, 82 and 84.
At the shop chain HQ, an atmosphere designer creates lighting atmospheres for the shops of the chain using a design tool 62. The design tool 62 receives the shop definitions as additional input to the designer's inputs for designing the lighting atmosphere. The verification system 60 comprises a collection and clustering module 68 for collecting the (clustered) light infrastructure capabilities from the lighting systems 70, 72 and 74 of the different shops of the chain, a light element template generator 69 for creating the light element templates for the lighting systems 70, 72 and 74 from their (clustered) light infrastructure capabilities, a calculation module 66 for calculating the aggregated light element templates for the chain of shops with lighting systems 70, 72 and 74 and a verification tool 64
The collection and clustering module 68 receives the light infrastructure capabilities of the different lighting systems 70, 72 and 74. For every lighting system, it clusters them further into light infrastructure capabilities of groups of lights, according to one or more of the earlier mentioned criteria. The light element template generator 69 uses the light infrastructure capabilities of the individual lighting systems to derive light element templates of the lighting systems 70, 72 and 74
When the designer has finished designing a certain lighting atmosphere and created the abstract description of the lighting atmosphere which may be automatically created by the design tool 62, she/he may initiate the verification process according to the invention by clicking for example on a verification button of the design tool 62. The design tool 62 then triggers the verification tool 64 which receives the abstract description from the design tool 62 and either
The verification tool 64 then indicates how well the atmosphere may be rendered in all shops or in the shops individually. The result of the verification is displayed on a monitor of the designer's computer so that the designer may next decide whether the abstract atmosphere description is transmitted to the lighting systems 70, 72 and 74 of the different shops of the chain.
As already indicated, this invention can also be used by consumers that intend to buy light atmospheres for e.g. their home. In that case, the light atmosphere is verified against the light element templates created from the light infrastructure capabilities of the home in question. If the light atmosphere is not realizable for certain area selectors, feedback to the user should be provided in a clear and concrete way. This implies that for rendering issues, the most specific area selector where the rendering issue occurs should be provided to the user. In the earlier example, where the light element for AT5 was conflicting with the light element templates of area selectors AT5 and AT2/AT5, the indication to the user should be that wall washing is not possible in area AT2/AT5. Actually, for lighting designers, the problem is indicated in the light design, for example by the verification module 64 executed by the light designer's computer as shown in
The invention can be applied to all situations where abstract light atmospheres are being made for a multitude of lighting infrastructures and/or room layouts. Target environments may be for example commercial environments (shops, hotels), home environments, outdoors lighting, and further complex lighting infrastructures.
In the situation that a light atmosphere cannot be realized by a certain lighting infrastructure, advice can also be given on what type of light units to add in which semantic area(s) in the shop/home, for example by displaying a respective user's help on a computer monitor.
At least some of the functionality of the invention such as the process of verification may be performed by hard- or software. In case of an implementation in software, a single or multiple standard microprocessors or microcontrollers configuration may be used. The invention might be implemented by single or multiple algorithms.
It should be noted that the word “comprise” does not exclude other elements or steps, and that the word “a” or “an” does not exclude a plurality. Furthermore, any reference signs in the claims shall not be construed as limiting the scope of the invention.
Number | Date | Country | Kind |
---|---|---|---|
07107415 | May 2007 | EP | regional |
Filing Document | Filing Date | Country | Kind | 371c Date |
---|---|---|---|---|
PCT/IB2008/051624 | 4/28/2008 | WO | 00 | 10/30/2009 |
Publishing Document | Publishing Date | Country | Kind |
---|---|---|---|
WO2008/135894 | 11/13/2008 | WO | A |
Number | Name | Date | Kind |
---|---|---|---|
5969485 | Hunt | Oct 1999 | A |
6466234 | Pyle et al. | Oct 2002 | B1 |
7202613 | Morgan et al. | Apr 2007 | B2 |
7348736 | Piepgras et al. | Mar 2008 | B2 |
7914172 | Nagara et al. | Mar 2011 | B2 |
8026673 | Lys | Sep 2011 | B2 |
20020180973 | MacKinnon et al. | Dec 2002 | A1 |
20030040813 | Gonzales et al. | Feb 2003 | A1 |
20050116667 | Mueller et al. | Jun 2005 | A1 |
20050248299 | Chemel et al. | Nov 2005 | A1 |
Number | Date | Country |
---|---|---|
2008078286 | Jul 2008 | WO |
Number | Date | Country | |
---|---|---|---|
20100134050 A1 | Jun 2010 | US |