Lighting Operation Agency Service System Based on Performance Venue Environment Profiles
Patent Information
- Application Number
- KR1020260001516
- Authority / Receiving Office
- KR · KR
- Patent Type
- Patents
- Current Assignee / Owner
- Priority Date
- 2026-01-05
- Filing Date
- 2026-01-05
- Publication Date
- 2026-08-11
- Estimated Expiration
- 2046-01-05
Smart Images

Figure 112026001236611-PAT00004_ABST
Abstract
Description
Technology Field
[0001] The present invention relates to a lighting operation agency service system based on a performance venue environment profile. Background Technology
[0002] The performing arts industry is evolving into various forms such as plays, musicals, concerts, and live shows, and stage lighting functions as a key directorial element that determines audience immersion by conveying the atmosphere and emotions of the performance, clarifying scene transitions, and emphasizing characters and stage elements.
[0003] However, conventional performance lighting design and operation have largely relied on the lighting designer's experience and intuition, which has limited the ability to systematically analyze and incorporate vast amounts of performance content data—such as scripts, musical flow, actor movement, and scene composition—into the design. In particular, it has been difficult to establish a lighting plan that quantitatively reflects emotional changes by scene or the importance of each role throughout the entire performance run. Furthermore, the process of determining the optimal configuration and placement of lighting equipment under budget constraints has been problematic, as it has relied on repetitive manual work and trial and error.
[0004] Furthermore, when unexpected situations such as scene changes, additional performances, or special events occurred during a show, it was difficult to quickly and consistently modify existing lighting operation plans, placing a heavy burden on on-site response and making it challenging to maintain consistency in lighting quality. Moreover, the lack of systematic analysis of actual lighting operation results even after the performance ended presented a limitation in that lighting equipment usage history or audience reactions could not be effectively fed back into the design of future performances.
[0005] Due to these issues, performance production companies are struggling to ensure efficiency and objectivity in lighting design and operation, and there is a continuously increasing demand for an integrated lighting design and operation management system that can systematically define lighting requirements by role and scene by analyzing performance content based on data, automatically recommend the optimal lighting design considering the budget, and respond in real time to various changes that occur during the performance.
[0006] Meanwhile, the aforementioned background technology is technical information that the inventor possessed for the derivation of the present invention or acquired during the process of deriving the present invention, and it cannot necessarily be considered publicly known technology disclosed to the general public prior to the filing of the present invention. Prior art literature
[0007] Korean Registered Patent No. 102556702 The problem to be solved
[0008] The objective of the present invention is to provide a lighting operation agency service system based on a theater environment profile that can efficiently establish and manage customized lighting design and operation plans throughout the entire performance period.
[0009] The technical problems of the present invention are not limited to those mentioned above, and other unmentioned technical problems will be clearly understood by those skilled in the art from the description below. means of solving the problem
[0010] A lighting operation agency service system based on a performance venue environment profile according to one embodiment of the present invention may include a database that stores and manages unique environmental information of each performance venue to be managed in a standardized data format, and a management server that manages lighting design and operation plans for the entire performance cycle based on performance data and controls lighting consoles according to said operation plans.
[0011] According to one embodiment, the management server comprises: a data collection module that receives performance data including a performance script, music timeline, actor movement, and stage scene composition information provided by a performance production company terminal, structures the performance data by scene, and quantifies lighting pattern requirements based on emotions, atmosphere, and key actions for each scene; a needs mapping module that generates a role-specific lighting needs mapping matrix defining the attributes of lighting required for each role within the performance based on the lighting pattern requirements quantified by the data collection module; a lighting recommendation module that automatically recommends a plurality of lighting design packages including the type, quantity, and placement location of lighting equipment, considering the role-specific lighting needs mapping matrix generated by the needs mapping module and the performance budget included in the performance data received from the performance production company terminal; and an operation placement module that modifies an existing lighting operation plan received in real time and generates and provides a lighting rearrangement plan in response to unexpected situations, including scene changes, additional performances, and special events occurring during the performance period equipped with the lighting design packages recommended by the lighting recommendation module. and after each type of performance, it may include a management reporting module that collects and analyzes external input data, including usage log data and audience social media reactions, to evaluate lighting operations and automatically generates a report containing plans to improve the lighting configuration for the next performance.
[0012] According to one embodiment, the database may be characterized by constructing an environment profile for each performance venue that includes structural information of the performance venue (ceiling height, stage size), equipment information (type, status, DMX channel of lighting equipment owned), power information (total power capacity, outlet location), and installation condition information (location where lighting can be installed, light reflectance).
[0013] According to one embodiment, each role in the performance may be characterized in that, as a result of the needs mapping module classifying elements appearing in the performance into multiple role units including at least one of lead actor, supporting actor, ensemble, stage background, prop area, and instrument part based on the performance data structured by the data collection module, each role unit is defined as an independent lighting requirement unit that is subject to lighting control based on at least one of the narrative importance, frequency of appearance, range of movement, and emotional change per scene that the corresponding role performs in the performance.
[0014] According to one embodiment, the needs mapping module may be characterized by defining the lighting required for each role unit as a set of lighting attribute parameters including at least one of brightness, color, color temperature, illumination angle, focusing area, movement path, illumination time, and effect pattern, and mapping the set of lighting attribute parameters on a scene-by-scene basis to generate a lighting needs mapping matrix for each role.
[0015] According to one embodiment, the attributes of the lighting may include at least one of brightness, color, color temperature, illumination angle, focusing area, movement path, illumination time, and effect pattern for the lighting required for each role unit by the needs mapping module.
[0016] According to one embodiment, the lighting recommendation module can generate a plurality of lighting design combinations using the type, quantity, placement location, and usage frequency of lighting equipment per scene as variables, using the role-specific lighting needs mapping matrix and performance budget information as input values, generate a lighting design evaluation result by calculating at least one of budget suitability, lighting needs satisfaction, and equipment utilization efficiency as an evaluation indicator for each generated lighting design combination, and recommend a plurality of lighting design packages by utilizing artificial intelligence that performs learning or rule-based operations to automatically recommend a plurality of lighting design packages according to the lighting design evaluation result.
[0017] According to one embodiment, the operation placement module detects or receives scene change information, additional performance information, or special event occurrence information input during a performance in real time, compares and analyzes the change information with a previously stored lighting operation plan, and recalculates at least one of the activation sequence, placement position, or control parameter of lighting equipment in response to the changed scene or event, thereby generating and providing a modified lighting operation plan and a corresponding lighting relocation plan in real time.
[0018] According to one embodiment, the management reporting module may be characterized by analyzing external input data including lighting equipment usage log data, lighting control history, power usage information, and audience social media reaction data collected after the end of a performance, evaluating the effectiveness of lighting operation based on the difference between the actual lighting operation results and the lighting design package or lighting operation plan to generate a post-evaluation result, and outputting a report that automatically generates a plan for improving the lighting configuration for the next performance, including changes to the lighting equipment configuration, adjustments to lighting attributes, or improvements to the operation plan, based on the post-evaluation result.
[0019] According to one embodiment, the data collection module, when the scene-unit quantification task is delayed, the quantification time (t quan Number of scenes processed (n) quan By using the value divided by ), performance scale bias is reduced even when the total time becomes long due to a large number of scenes, and the number of items requiring correction (m quan Number of scenes processed (n) quan It is possible to determine whether to collect additional performance data by utilizing a data request judgment control algorithm characterized by being configured to distinguish between cases where the amount of computation is large and slow, and cases where the input data is missing and ambiguous and slow due to large corrections, using a value divided by ).
[0020] According to one embodiment, the data request judgment control algorithm may include a first element designed so that the calculated value increases as quantification proceeds at a slower speed than a standard, and a second element designed so that the calculated value increases as corrections occur frequently due to missing or ambiguous input performance data.
[0021] According to one embodiment, the first element is the time required for quantification (t quan Number of scenes processed (n) quan The result of dividing by ) based on the quantification time per scene (t limit Divided by ), and based on quantification time per scene (t limit Add 1 to the result divided by ), input it into the logarithmic function, and for the result of the logarithmic function, the time weight (w quan1 It can be characterized by being configured to multiply )
[0022] According to one embodiment, the second element is the number of items requiring correction (m quan Number of scenes processed (n) quan Add 1 to the result of the value divided by ), input it into the logarithmic function, and apply the correction weight (w) to the result of the logarithmic function quan2 It can be characterized by being configured to multiply )
[0023] A system for providing customized lighting design and operation services based on performance content data analysis according to another embodiment of the present invention may include a management server that manages lighting design and operation plans for the entire performance cycle based on performance data.
[0024] According to one embodiment, the management server comprises: a data collection module that receives performance data including a performance script, music timeline, actor movement, and stage scene composition information provided by a performance production company terminal, structures the performance data by scene, and quantifies lighting pattern requirements based on emotions, atmosphere, and key actions for each scene; a needs mapping module that generates a role-specific lighting needs mapping matrix defining the attributes of lighting required for each role within the performance based on the lighting pattern requirements quantified by the data collection module; a lighting recommendation module that automatically recommends a plurality of lighting design packages including the type, quantity, and placement location of lighting equipment, considering the role-specific lighting needs mapping matrix generated by the needs mapping module and the performance budget included in the performance data received from the performance production company terminal; and an operation placement module that modifies an existing lighting operation plan received in real time and generates and provides a lighting rearrangement plan in response to unexpected situations, including scene changes, additional performances, and special events occurring during the performance period equipped with the lighting design packages recommended by the lighting recommendation module. and after each type of performance, it may include a management reporting module that collects and analyzes external input data, including usage log data and audience social media reactions, to evaluate lighting operations and automatically generates a report containing plans to improve the lighting configuration for the next performance.
[0025] According to one embodiment, each role in the performance may be characterized in that, as a result of the needs mapping module classifying elements appearing in the performance into multiple role units including at least one of lead actor, supporting actor, ensemble, stage background, prop area, and instrument part based on the performance data structured by the data collection module, each role unit is defined as an independent lighting requirement unit that is subject to lighting control based on at least one of the narrative importance, frequency of appearance, range of movement, and emotional change per scene that the corresponding role performs in the performance.
[0026] According to one embodiment, the needs mapping module may be characterized by defining the lighting required for each role unit as a set of lighting attribute parameters including at least one of brightness, color, color temperature, illumination angle, focusing area, movement path, illumination time, and effect pattern, and mapping the set of lighting attribute parameters on a scene-by-scene basis to generate a lighting needs mapping matrix for each role.
[0027] According to one embodiment, the attributes of the lighting may include at least one of brightness, color, color temperature, illumination angle, focusing area, movement path, illumination time, and effect pattern for the lighting required for each role unit by the needs mapping module.
[0028] According to one embodiment, the lighting recommendation module can generate a plurality of lighting design combinations using the type, quantity, placement location, and usage frequency of lighting equipment per scene as variables, using the role-specific lighting needs mapping matrix and performance budget information as input values, generate a lighting design evaluation result by calculating at least one of budget suitability, lighting needs satisfaction, and equipment utilization efficiency as an evaluation indicator for each generated lighting design combination, and recommend a plurality of lighting design packages by utilizing artificial intelligence that performs learning or rule-based operations to automatically recommend a plurality of lighting design packages according to the lighting design evaluation result.
[0029] According to one embodiment, the operation placement module detects or receives scene change information, additional performance information, or special event occurrence information input during a performance in real time, compares and analyzes the change information with a previously stored lighting operation plan, and recalculates at least one of the activation sequence, placement position, or control parameter of lighting equipment in response to the changed scene or event, thereby generating and providing a modified lighting operation plan and a corresponding lighting relocation plan in real time.
[0030] According to one embodiment, the management reporting module may be characterized by analyzing external input data including lighting equipment usage log data, lighting control history, power usage information, and audience social media reaction data collected after the end of a performance, evaluating the effectiveness of lighting operation based on the difference between the actual lighting operation results and the lighting design package or lighting operation plan to generate a post-evaluation result, and outputting a report that automatically generates a plan for improving the lighting configuration for the next performance, including changes to the lighting equipment configuration, adjustments to lighting attributes, or improvements to the operation plan, based on the post-evaluation result.
[0031] According to one embodiment, the data collection module, when the scene-unit quantification task is delayed, the quantification time (t quan Number of scenes processed (n) quan By using the value divided by ), performance scale bias is reduced even when the total time becomes long due to a large number of scenes, and the number of items requiring correction (m quan Number of scenes processed (n) quan It is possible to determine whether to collect additional performance data by utilizing a data request judgment control algorithm characterized by being configured to distinguish between cases where the amount of computation is large and slow, and cases where the input data is missing and ambiguous and slow due to large corrections, using a value divided by ).
[0032] According to one embodiment, the data request judgment control algorithm may include a first element designed so that the calculated value increases as quantification proceeds at a slower speed than a standard, and a second element designed so that the calculated value increases as corrections occur frequently due to missing or ambiguous input performance data.
[0033] According to one embodiment, the first element is the time required for quantification (t quan Number of scenes processed (n) quan The result of dividing by ) based on the quantification time per scene (t limit Divided by ), and based on quantification time per scene (t limit Add 1 to the result divided by ), input it into the logarithmic function, and for the result of the logarithmic function, the time weight (w quan1 It can be characterized by being configured to multiply )
[0034] According to one embodiment, the second element is the number of items requiring correction (m quan Number of scenes processed (n) quan Add 1 to the result of the value divided by ), input it into the logarithmic function, and apply the correction weight (w) to the result of the logarithmic function quan2 It can be characterized by being configured to multiply )
[0035] A system for providing customized lighting operation services for each performance based on performance content and venue environment information according to another embodiment of the present invention may include a management server that manages lighting design and operation plans for the entire performance cycle based on performance data.
[0036] According to one embodiment, the management server comprises: a data collection module that receives performance data including a performance script, music timeline, actor movement, and stage scene composition information provided by a performance production company terminal, structures the performance data by scene, and quantifies lighting pattern requirements based on emotions, atmosphere, and key actions for each scene; a needs mapping module that generates a role-specific lighting needs mapping matrix defining the attributes of lighting required for each role within the performance based on the lighting pattern requirements quantified by the data collection module; a lighting recommendation module that automatically recommends a plurality of lighting design packages including the type, quantity, and placement location of lighting equipment, considering the role-specific lighting needs mapping matrix generated by the needs mapping module and the performance budget included in the performance data received from the performance production company terminal; and an operation placement module that modifies an existing lighting operation plan received in real time and generates and provides a lighting rearrangement plan in response to unexpected situations, including scene changes, additional performances, and special events occurring during the performance period equipped with the lighting design packages recommended by the lighting recommendation module. and after each type of performance, it may include a management reporting module that collects and analyzes external input data, including usage log data and audience social media reactions, to evaluate lighting operations and automatically generates a report containing plans to improve the lighting configuration for the next performance.
[0037] According to one embodiment, each role in the performance may be characterized in that, as a result of the needs mapping module classifying elements appearing in the performance into multiple role units including at least one of lead actor, supporting actor, ensemble, stage background, prop area, and instrument part based on the performance data structured by the data collection module, each role unit is defined as an independent lighting requirement unit that is subject to lighting control based on at least one of the narrative importance, frequency of appearance, range of movement, and emotional change per scene that the corresponding role performs in the performance.
[0038] According to one embodiment, the needs mapping module may be characterized by defining the lighting required for each role unit as a set of lighting attribute parameters including at least one of brightness, color, color temperature, illumination angle, focusing area, movement path, illumination time, and effect pattern, and mapping the set of lighting attribute parameters on a scene-by-scene basis to generate a lighting needs mapping matrix for each role.
[0039] According to one embodiment, the attributes of the lighting may include at least one of brightness, color, color temperature, illumination angle, focusing area, movement path, illumination time, and effect pattern for the lighting required for each role unit by the needs mapping module.
[0040] According to one embodiment, the lighting recommendation module can generate a plurality of lighting design combinations using the type, quantity, placement location, and usage frequency of lighting equipment per scene as variables, using the role-specific lighting needs mapping matrix and performance budget information as input values, generate a lighting design evaluation result by calculating at least one of budget suitability, lighting needs satisfaction, and equipment utilization efficiency as an evaluation indicator for each generated lighting design combination, and recommend a plurality of lighting design packages by utilizing artificial intelligence that performs learning or rule-based operations to automatically recommend a plurality of lighting design packages according to the lighting design evaluation result.
[0041] According to one embodiment, the operation placement module detects or receives scene change information, additional performance information, or special event occurrence information input during a performance in real time, compares and analyzes the change information with a previously stored lighting operation plan, and recalculates at least one of the activation sequence, placement position, or control parameter of lighting equipment in response to the changed scene or event, thereby generating and providing a modified lighting operation plan and a corresponding lighting relocation plan in real time.
[0042] According to one embodiment, the management reporting module may be characterized by analyzing external input data including lighting equipment usage log data, lighting control history, power usage information, and audience social media reaction data collected after the end of a performance, evaluating the effectiveness of lighting operation based on the difference between the actual lighting operation results and the lighting design package or lighting operation plan to generate a post-evaluation result, and outputting a report that automatically generates a plan for improving the lighting configuration for the next performance, including changes to the lighting equipment configuration, adjustments to lighting attributes, or improvements to the operation plan, based on the post-evaluation result.
[0043] According to one embodiment, the data collection module, when the scene-unit quantification task is delayed, the quantification time (t quan Number of scenes processed (n) quan By using the value divided by ), performance scale bias is reduced even when the total time becomes long due to a large number of scenes, and the number of items requiring correction (m quan Number of scenes processed (n) quan It is possible to determine whether to collect additional performance data by utilizing a data request judgment control algorithm characterized by being configured to distinguish between cases where the amount of computation is large and slow, and cases where the input data is missing and ambiguous and slow due to large corrections, using a value divided by ).
[0044] According to one embodiment, the data request judgment control algorithm may include a first element designed so that the calculated value increases as quantification proceeds at a slower speed than a standard, and a second element designed so that the calculated value increases as corrections occur frequently due to missing or ambiguous input performance data.
[0045] According to one embodiment, the first element is the time required for quantification (t quan Number of scenes processed (n) quan The result of dividing by ) based on the quantification time per scene (t limit Divided by ), and based on quantification time per scene (t limit Add 1 to the result divided by ), input it into the logarithmic function, and for the result of the logarithmic function, the time weight (w quan1 It can be characterized by being configured to multiply )
[0046] According to one embodiment, the second element is the number of items requiring correction (m quan Number of scenes processed (n) quan Add 1 to the result of the value divided by ), input it into the logarithmic function, and apply the correction weight (w) to the result of the logarithmic function quan2 It can be characterized by being configured to multiply )
[0047] A customized lighting design and operation service method based on performance content data analysis according to another embodiment of the present invention may include the step of managing lighting design and operation plans for the entire performance cycle based on collected performance data.
[0048] According to one embodiment, the managing step comprises: receiving performance data including a performance script, music timeline, actor movement, and stage scene composition information provided by a performance production company terminal, structuring the performance data by scene, and quantifying lighting pattern requirements based on emotions, atmosphere, and key actions for each scene; generating a role-specific lighting needs mapping matrix that defines the attributes of lighting required for each role within the performance based on the lighting pattern requirements quantified from the step of quantifying lighting pattern requirements; automatically recommending a plurality of lighting design packages including the type, quantity, and placement location of lighting equipment, considering the role-specific lighting needs mapping matrix generated by the step of generating the lighting needs mapping matrix and the performance budget included in the performance data received from the performance production company terminal; and modifying a previously received existing lighting operation plan in real time and generating and providing a lighting rearrangement plan in response to unexpected situations, including scene changes, additional performances, and special events occurring during the performance period equipped with the lighting design packages recommended by the step of automatically recommending the plurality of lighting design packages. and after each type of performance, it may include a step of collecting and analyzing external input data, including usage log data and audience social media reactions, to evaluate lighting operations and automatically generate a report containing plans to improve the lighting configuration for the next performance.
[0049] According to one embodiment, each role in the performance may be characterized in that, as a result of classifying elements appearing in the performance into multiple role units including at least one of lead actor, supporting actor, ensemble, stage background, prop area, and instrument part based on the performance data structured by the step of generating a lighting needs mapping matrix, for each role unit, the role is defined as an independent lighting requirement unit subject to lighting control based on at least one of the narrative importance, frequency of appearance, range of movement, and emotional change per scene that the role performs in the performance.
[0050] According to one embodiment, the step of generating the lighting needs mapping matrix may be characterized by defining the lighting required for each role unit as a set of lighting attribute parameters including at least one of brightness, color, color temperature, illumination angle, focusing area, movement path, illumination time, and effect pattern, and mapping the set of lighting attribute parameters on a scene-by-scene basis to generate the role-specific lighting needs mapping matrix.
[0051] According to one embodiment, the attributes of the lighting may include at least one of brightness, color, color temperature, illumination angle, focusing area, movement path, illumination time, and effect pattern for the lighting required for each role unit by the step of generating the lighting needs mapping matrix.
[0052] According to one embodiment, the step of automatically recommending a plurality of lighting design packages can be achieved by using artificial intelligence that performs learning or rule-based operations to automatically recommend a plurality of lighting design packages, using the role-specific lighting needs mapping matrix and performance budget information as input values to generate a plurality of lighting design combinations with the type, quantity, placement location, and usage frequency of lighting equipment as variables, and for each generated lighting design combination, generating a lighting design evaluation result by calculating at least one of budget suitability, lighting needs satisfaction, and equipment utilization efficiency as an evaluation indicator, and then recommending a plurality of lighting design packages.
[0053] According to one embodiment, the step of generating and providing the lighting relocation plan may involve detecting or receiving scene change information, additional performance information, or special event occurrence information input during a performance in real time, comparing and analyzing the change information with a previously stored lighting operation plan, and recalculating at least one of the activation sequence, placement position, or control parameter of the lighting equipment in response to the changed scene or event to generate and provide a modified lighting operation plan and a corresponding lighting relocation plan in real time.
[0054] According to one embodiment, the step of automatically generating the report may be characterized by analyzing external input data including lighting equipment usage log data, lighting control history, power usage information, and audience social media reaction data collected after the end of the performance, evaluating the effectiveness of lighting operation based on the difference between the actual lighting operation results and the lighting design package or lighting operation plan to generate a post-evaluation result, and outputting a report that automatically generates a plan for improving the lighting configuration for the next performance, including changes to the lighting equipment configuration, adjustments to lighting attributes, or improvements to the operation plan, based on the post-evaluation result.
[0055] According to one embodiment, the step of quantifying the lighting pattern requirement includes, when the scene-unit quantification work is delayed, the quantification time (t quan Number of scenes processed (n) quan By using the value divided by ), performance scale bias is reduced even when the total time becomes long due to a large number of scenes, and the number of items requiring correction (m quan Number of scenes processed (n) quan It is possible to determine whether to collect additional performance data by utilizing a data request judgment control algorithm characterized by being configured to distinguish between cases where the amount of computation is large and slow, and cases where the input data is missing and ambiguous and slow due to large corrections, using a value divided by ).
[0056] According to one embodiment, the data request judgment control algorithm may include a first element designed so that the calculated value increases as quantification proceeds at a slower speed than a standard, and a second element designed so that the calculated value increases as corrections occur frequently due to missing or ambiguous input performance data.
[0057] According to one embodiment, the first element is the time required for quantification (t quan Number of scenes processed (n) quan The result of dividing by ) based on the quantification time per scene (t limit Divided by ), and based on quantification time per scene (t limit Add 1 to the result divided by ), input it into the logarithmic function, and for the result of the logarithmic function, the time weight (w quan1 It can be characterized by being configured to multiply )
[0058] According to one embodiment, the second element is the number of items requiring correction (m quan Number of scenes processed (n) quan Add 1 to the result of the value divided by ), input it into the logarithmic function, and apply the correction weight (w) to the result of the logarithmic function quan2 It can be characterized by being configured to multiply )
[0059] A method for providing a customized lighting operation service for each performance based on performance content and venue environment information according to another embodiment of the present invention may include the step of managing lighting design and operation plans for the entire performance cycle based on collected performance data.
[0060] According to one embodiment, the managing step comprises: receiving performance data including a performance script, music timeline, actor movement, and stage scene composition information provided by a performance production company terminal, structuring the performance data by scene, and quantifying lighting pattern requirements based on emotions, atmosphere, and key actions for each scene; generating a role-specific lighting needs mapping matrix that defines the attributes of lighting required for each role within the performance based on the lighting pattern requirements quantified from the step of quantifying lighting pattern requirements; automatically recommending a plurality of lighting design packages including the type, quantity, and placement location of lighting equipment, considering the role-specific lighting needs mapping matrix generated by the step of generating the lighting needs mapping matrix and the performance budget included in the performance data received from the performance production company terminal; and modifying a previously received existing lighting operation plan in real time and generating and providing a lighting rearrangement plan in response to unexpected situations, including scene changes, additional performances, and special events occurring during the performance period equipped with the lighting design packages recommended by the step of automatically recommending the plurality of lighting design packages. and after each type of performance, it may include a step of collecting and analyzing external input data, including usage log data and audience social media reactions, to evaluate lighting operations and automatically generate a report containing plans to improve the lighting configuration for the next performance.
[0061] According to one embodiment, each role in the performance may be characterized in that, as a result of classifying elements appearing in the performance into multiple role units including at least one of lead actor, supporting actor, ensemble, stage background, prop area, and instrument part based on the performance data structured by the step of generating a lighting needs mapping matrix, for each role unit, the role is defined as an independent lighting requirement unit subject to lighting control based on at least one of the narrative importance, frequency of appearance, range of movement, and emotional change per scene that the role performs in the performance.
[0062] According to one embodiment, the step of generating the lighting needs mapping matrix may be characterized by defining the lighting required for each role unit as a set of lighting attribute parameters including at least one of brightness, color, color temperature, illumination angle, focusing area, movement path, illumination time, and effect pattern, and mapping the set of lighting attribute parameters on a scene-by-scene basis to generate the role-specific lighting needs mapping matrix.
[0063] According to one embodiment, the attributes of the lighting may include at least one of brightness, color, color temperature, illumination angle, focusing area, movement path, illumination time, and effect pattern for the lighting required for each role unit by the step of generating the lighting needs mapping matrix.
[0064] According to one embodiment, the step of automatically recommending a plurality of lighting design packages can be achieved by using artificial intelligence that performs learning or rule-based operations to automatically recommend a plurality of lighting design packages, using the role-specific lighting needs mapping matrix and performance budget information as input values to generate a plurality of lighting design combinations with the type, quantity, placement location, and usage frequency of lighting equipment as variables, and for each generated lighting design combination, generating a lighting design evaluation result by calculating at least one of budget suitability, lighting needs satisfaction, and equipment utilization efficiency as an evaluation indicator, and then recommending a plurality of lighting design packages.
[0065] According to one embodiment, the step of generating and providing the lighting relocation plan may involve detecting or receiving scene change information, additional performance information, or special event occurrence information input during a performance in real time, comparing and analyzing the change information with a previously stored lighting operation plan, and recalculating at least one of the activation sequence, placement position, or control parameter of the lighting equipment in response to the changed scene or event to generate and provide a modified lighting operation plan and a corresponding lighting relocation plan in real time.
[0066] According to one embodiment, the step of automatically generating the report may be characterized by analyzing external input data including lighting equipment usage log data, lighting control history, power usage information, and audience social media reaction data collected after the end of the performance, evaluating the effectiveness of lighting operation based on the difference between the actual lighting operation results and the lighting design package or lighting operation plan to generate a post-evaluation result, and outputting a report that automatically generates a plan for improving the lighting configuration for the next performance, including changes to the lighting equipment configuration, adjustments to lighting attributes, or improvements to the operation plan, based on the post-evaluation result.
[0067] According to one embodiment, the step of quantifying the lighting pattern requirement includes, when the scene-unit quantification work is delayed, the quantification time (t quan Number of scenes processed (n) quan By using the value divided by ), performance scale bias is reduced even when the total time becomes long due to a large number of scenes, and the number of items requiring correction (m quan Number of scenes processed (n) quan It is possible to determine whether to collect additional performance data by utilizing a data request judgment control algorithm characterized by being configured to distinguish between cases where the amount of computation is large and slow, and cases where the input data is missing and ambiguous and slow due to large corrections, using a value divided by ).
[0068] According to one embodiment, the data request judgment control algorithm may include a first element designed so that the calculated value increases as quantification proceeds at a slower speed than a standard, and a second element designed so that the calculated value increases as corrections occur frequently due to missing or ambiguous input performance data.
[0069] According to one embodiment, the first element is the time required for quantification (t quan Number of scenes processed (n) quan The result of dividing by ) based on the quantification time per scene (t limit Divided by ), and based on quantification time per scene (t limit Add 1 to the result divided by ), input it into the logarithmic function, and for the result of the logarithmic function, the time weight (w quan1 It can be characterized by being configured to multiply )
[0070] According to one embodiment, the second element is the number of items requiring correction (m quan Number of scenes processed (n) quan Add 1 to the result of the value divided by ), input it into the logarithmic function, and apply the correction weight (w) to the result of the logarithmic function quan2 It can be characterized by being configured to multiply ) Effects of the invention
[0071] According to one aspect of the present invention described above, the lighting operation agency service system based on a performance venue environment profile proposed by the present invention can provide customized lighting design that more precisely reflects the emotional flow and narrative of the performance.
[0072] In addition, by automatically recommending the type, quantity, and placement of lighting equipment based on a role-specific lighting needs mapping matrix and the performance budget, it is possible to reduce trial and error during the lighting design process and maximize the efficiency of lighting equipment utilization.
[0073] In addition, by recalculating lighting operation plans in real time and providing relocation plans for various changes that occur during the performance, the flexibility and stability of on-site operations can be improved.
[0074] The effects of the present invention are not limited to those mentioned above, and various effects may be included within the scope obvious to a person skilled in the art from the contents described below. Brief explanation of the drawing
[0075] FIG. 1 is a conceptual diagram of a lighting operation agency service system based on a performance venue environment profile according to one embodiment of the present invention. FIG. 2 is a conceptual diagram of a management server according to one embodiment of the present invention. FIG. 3 is a flowchart of a lighting operation agency service system based on a performance venue environment profile according to one embodiment of the present invention. FIGS. 4 to 20 are exemplary diagrams showing actual examples of theater lighting control according to one embodiment of the present invention. Specific details for implementing the invention
[0076] The following detailed description of the invention refers to the accompanying drawings, which illustrate specific embodiments in which the invention may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the invention. It should be understood that various embodiments of the invention are different but need not be mutually exclusive. For example, specific shapes, structures, and characteristics described herein may be implemented in other embodiments without departing from the spirit and scope of the invention in relation to one embodiment.
[0077] When it is stated that one component is "connected" or "contracted" to another component, it should be understood that while it may be directly connected or contracted to that other component, there may also be other components in between. Conversely, when it is stated that one component is "directly connected" or "directly contracted" to another component, it should be understood that there are no other components in between.
[0078] Furthermore, it should be understood that the location or arrangement of individual components within each disclosed embodiment may be changed without departing from the spirit and scope of the invention. Accordingly, the following detailed description is not intended to be taken in a limiting sense, and the scope of the invention is limited only by the appended claims, including all equivalents thereof, provided appropriately described. Similar reference numerals in the drawings refer to the same or similar functions across various aspects.
[0079] Hereinafter, preferred embodiments of the present invention will be described in more detail with reference to the drawings.
[0081] FIG. 1 is a conceptual diagram of a lighting operation agency service system based on a performance venue environment profile according to one embodiment of the present invention.
[0082] Referring to FIG. 1, a lighting operation agency service system based on a performance venue environment profile according to one embodiment of the present invention may include a management server (100) and a performance production company terminal (500).
[0083] The management server (100) receives and stores performance data input from the performance production company terminal (500), and can manage lighting design and lighting operation plans throughout the entire performance period based on the performance data.
[0084] The management server (100) can structure performance data in scenes and quantify lighting patterns required according to the emotions, atmosphere, and key actions of each scene, classify elements appearing in the performance into multiple role units such as lead actors, supporting actors, ensemble, stage background, prop area, and instrument part based on the structured performance data, and generate a role-specific lighting needs mapping matrix that maps lighting attributes required for each role unit.
[0085] In addition, the management server (100) can automatically generate and recommend multiple lighting design packages including the type, quantity, and placement location of lighting equipment by considering the lighting needs mapping matrix by role and performance budget information, and can modify the existing lighting operation plan in real time and generate and provide a lighting relocation plan when scene changes, additional performances, or special events occur during the performance.
[0086] In addition, the management server (100) can collect and analyze lighting equipment usage logs, lighting control history, power usage information, and audience social media reaction data after the performance ends to evaluate the effectiveness of lighting operation and automatically generate a management report including a plan to improve the lighting configuration for the next performance.
[0087] The performance production company terminal (500) is a user terminal used by a performance production company or a performance planner, and can receive performance data including a performance script, music timeline, actor movement information, stage scene composition information and performance budget information and transmit it to a management server (100).
[0088] The performance production company terminal (500) may be implemented as at least one of a PC, tablet, laptop, or mobile terminal and may include a user interface that provides registration, modification, verification of performance data and selection or feedback on lighting design packages.
[0089] The management server (100) and the performance production company terminal (500) may be a self-contained server or a cloud server for providing the service according to the present invention, or may be a peer-to-peer (P2P) set of distributed nodes.
[0090] The management server (100) can perform one or more of the operations, storage, reference, input / output, and control functions of a general computer, and may include an artificial neural network described later based on input data.
[0091] The processor may execute a program or control a management server (100). Program code executed by the processor may be stored in memory. The memory may store relevant information for performing a service according to the present invention or a program for implementing a method. The memory may be volatile memory or non-volatile memory.
[0092] The management server (100) can send data to an external device or receive data from an external device using a network.
[0093] The management server (100) can train an artificial neural network and can also use an artificial neural network that has been trained. The processor can train or execute an artificial neural network stored in memory, and the memory can store an artificial neural network that has been trained. The electronic device that trains the artificial neural network and the electronic device that uses it may be the same, but they may also be separate.
[0094] Artificial intelligence is a computer system that partially implements the functions of the human brain and is capable of learning, speculating, and making judgments on its own. As learning progresses, the probability of extracting the correct answer can increase. Artificial intelligence can be composed of learning and component technologies that utilize it. The learning aspect of AI is an algorithmic technology that classifies and learns features based on input data, while the component technologies may be techniques that utilize these learning algorithms to partially implement the functions of the human brain.
[0095] Artificial intelligence is a technology that facilitates the approach to problems where multiple probabilistic answers are possible, enabling it to logically and probabilistically infer optimal cycles, methods, and plans based on input data. AI inference techniques can include evaluating input data, optimization prediction, knowledge and probability-based reasoning, and preference-based planning.
[0096] Artificial neural networks are learning algorithms in the field of machine learning that programmatically implement the connections between neurons and synapses in the brain. By creating a neural network structure through programming and then training it, artificial neural networks can acquire desired functions. Although errors may exist, they can learn from massive datasets to produce appropriate output data from input data. They have the advantage of being able to obtain output data that has yielded statistically good results and are similar to human reasoning.
[0097] The management server (100) can infer individual characteristics and interests by analyzing consumers' online behavior data, social media activities, search history, etc., using an artificial intelligence algorithm built based on big data, and may include a number of pre-trained artificial neural networks for this purpose.
[0098] The network is a high-speed backbone network of a large-scale communication network capable of high-capacity, long-distance voice and data services, and may be a next-generation wired and wireless network for providing the Internet or high-speed multimedia services.
[0099] If the network is a mobile communication network, it may be a synchronous mobile communication network or an asynchronous mobile communication network. As an example of an asynchronous mobile communication network, a WCDMA (Wideband Code Division Multiple Access) network may be cited. In this case, although not shown in the drawing, the network may include an RNC (Radio Network Controller). Meanwhile, although a WCDMA network was given as an example, it may be a 3G LTE network, a 4G network, a next-generation communication network such as 5G, or other IP-based IP networks.
[0100] The management server (100) and the performance production company terminal (500) may include any terminal capable of exchanging data over a network, such as a desktop computer, laptop, tablet, or smartphone.
[0101] The management server (100) and the performance production company terminal (500) may include one or more of the computational function, storage function, reference function, input / output function, and control function of a computer to perform the service according to the present invention.
[0102] The management server (100) and the performance production company terminal (500) may access a website or install an application to receive the service according to the present invention. The management server (100) and the performance production company terminal (500) may exchange data through the website or the application.
[0103] The network is a high-speed backbone network of a large-scale communication network capable of high-capacity, long-distance voice and data services, and may be a next-generation wired and wireless network for providing the Internet or high-speed multimedia services.
[0104] If the network is a mobile communication network, it may be a synchronous mobile communication network or an asynchronous mobile communication network. As an example of an asynchronous mobile communication network, a WCDMA (Wideband Code Division Multiple Access) network may be cited. In this case, although not shown in the drawing, the network (300) may include an RNC (Radio Network Controller). Meanwhile, although a WCDMA network was given as an example, it may be a 3G LTE network, a 4G network, a 5G network, or other next-generation communication networks, or other IP-based IP networks.
[0105] The system (1) according to one embodiment of the present invention can improve the objectivity and efficiency of lighting design by automatically recommending the optimal configuration and arrangement of lighting equipment considering the performance budget, thereby breaking away from the conventional lighting design method that relies on the experience and intuition of a lighting designer.
[0107] FIG. 2 is a conceptual diagram of a management server according to one embodiment of the present invention.
[0108] Referring to FIG. 2, a management server (100) according to one embodiment of the present invention may include a data collection module (110), a needs mapping module (130), a lighting recommendation module (150), an operation deployment module (170), and a management reporting module (190).
[0109] The data collection module (110) receives performance data including a performance script, music timeline, actor movement, and stage scene composition information provided by the performance production company terminal (500), structures the performance data by scene, and can quantify lighting pattern requirements according to emotions, atmosphere, and key actions for each scene.
[0110] Meanwhile, the data collection module (110) may utilize a data request judgment control algorithm to determine whether to collect additional performance data based on the delay when the scene-unit quantification work is delayed.
[0111] The data request judgment control algorithm can receive the execution log and verification log of the data collection module (110) as input and output a judgment result indicating whether additional collection is necessary or unnecessary.
[0112] The data request judgment control algorithm can function as a judgment and control trigger because it is not a simple calculation, but can trigger a subsequent action of sending a request message to the performance production company terminal (500) for additional data requests depending on the result.
[0113] The data request judgment control algorithm is the quantification time (t quan Number of scenes processed (n) quan By using the value divided by ), it is possible to have a normalization effect that reduces performance scale bias even when the total time becomes long due to a large number of scenes.
[0114] In addition, the data request judgment control algorithm is the number of items requiring correction (m quan Number of scenes processed (n) quan By using the value divided by ), it is possible to distinguish between cases where it is slow simply because there is a large amount of computation and cases where it is slow because there is a lot of correction due to missing and ambiguous input data.
[0115] In existing methods, where operators or administrators manually check for missing data before deciding on additional requests, the judgment criteria can vary from person to person.
[0116] However, the data request judgment control algorithm of the data collection module (110) combines the quantification time (work indicator) and the correction frequency (quality indicator) into numerical values, so judgment can be performed consistently under the same conditions.
[0117] More specifically, the data request decision control algorithm can calculate two elements, add them together, and then compare whether the result of the agreement exceeds a reference value, log function 2, to determine whether to collect additional data.
[0118] The first element of the data request judgment control algorithm can be designed so that the output value increases as quantification proceeds at a speed slower than the standard.
[0119] More specifically, the first element is the time required for quantification (t quan Number of scenes processed (n) quan The result of dividing by ) based on the quantification time per scene (t limit Divided by ), and based on quantification time per scene (t limit Add 1 to the result divided by ), input it into the logarithmic function, and for the result of the logarithmic function, the time weight (w quan1 It can be characterized by being configured to multiply )
[0120] The second element of the data request judgment control algorithm can be designed so that the output value increases as corrections occur more frequently due to missing or ambiguous input performance data.
[0121] More specifically, the second factor is the number of items requiring correction (m quan Number of scenes processed (n) quan Add 1 to the result of the value divided by ), input it into the logarithmic function, and apply the correction weight (w) to the result of the logarithmic function quan2It can be characterized by being configured to multiply )
[0122] If the sum of the first and second elements designed with the configuration described above is greater than the result of logarithmic function 2, it is determined that additional collection is necessary, and a request message can be sent to the performance production company terminal (500) to perform additional collection of performance data.
[0123] Conversely, if the sum of the first and second elements is smaller than the result of the logarithmic function 2, it is determined that further collection is unnecessary, and quantification can be continued with the current data.
[0124] The data request judgment control algorithm determines the quantification time (t), a measurable time indicator, to determine the quantification delay. quan ) can be utilized, but if the performance scale differs, the time required for quantification (t quan Since comparison of ) is impossible, the number of processed scenes (n quan ) together with quantification time (t quan Number of scenes processed (n) quan It can be characterized by utilizing the value normalized by dividing by ).
[0125] In addition, to reflect the operational policy serving as a standard for determining quantification delay, the quantification time standard per scene (t) entered by the administrator limit Time required for quantification as ) (t quan Number of scenes processed (n) quan You can form a ratio relative to the standard by dividing the value divided by ).
[0126] Since data request judgment control algorithms find it difficult to reflect data incompleteness (missing or ambiguous) based on time alone, the number of items requiring correction recorded as verification rule failures (m quan Using ), the number of items requiring correction (m quan Number of scenes processed (n) quan It can be characterized by utilizing the value normalized by dividing by ).
[0127] The data request judgment control algorithm is the quantification time (t quan ), number of processed scenes (n quan ) and number of items requiring correction (m quan To mitigate over-sensitivity in judgment due to extreme values of ), a logarithmic function can be applied, and a composite score can be output by combining the two factors.
[0128] Finally, the data request judgment control algorithm can determine whether to collect additional data by comparing the output total score with the result of the reference value, log function 2, and determining whether additional collection is necessary or unnecessary as a binary output.
[0129] The data request decision control algorithm can utilize a logarithmic function in which the output increases as the input increases, but the rate of increase becomes progressively gentler, in order to mitigate the phenomenon where the score spikes excessively and results are skewed toward decisions requiring additional collection when extremely large delays or corrections occur.
[0130] As described in [Table 1] below and the above description, the data request judgment control algorithm may be characterized by being designed using functions such as logarithmic functions through examples of various tests, and may be characterized by being designed to reflect actual data distribution and experimental experience.
[0131] [Table 1]
[0132]
[0133] As shown in [Table 1] above, the data request judgment control algorithm utilizes a logarithmic function, thereby determining the quantification time (t quan ) Quantification time per scene standard (t limit If it is faster than ), the score may be output as low, if it is at the standard level, the score may be output as medium, even if it is twice as slow, the score may increase gradually, and even if it is very slow, it may not run wild.
[0134] The quantification time (t), which is each variable used in the data request judgment control algorithm. quan ), number of processed scenes (n quan ), number of items requiring correction (m quan ), based on quantified time per scene (t limit ), time weight(w quan1 ) and correction weights (w quan2 The characteristics of ) are as follows.
[0135] Time required for quantification (t quan ) may mean the total processing time taken for the data collection module (110) to perform scene structuring and lighting pattern requirement quantification processing for specific performance data, and the unit may be seconds (s).
[0136] The data collection module (110) can store the quantification start time as a log by calling the system time provided by the operating system or server runtime at the start of the quantification task when executing the quantification task, and can store the quantification end time in the same way at the end of the task.
[0137] Subsequently, the data collection module (110) can store the result of calculating the difference between the quantification end time and the quantification start time in the quantification work record, and the log can be loaded into a database (DB) in the form of performance ID, execution ID, start time, end time, and time taken.
[0138] Time required for quantification (t quan ) is not a fixed value, but can be set to a value measured by the above procedure for each execution.
[0139] In the data request decision control algorithm, since the decision to collect additional data can be made based on the time required for quantification, the time required for quantification (t quan ) can be used as the primary basis for the judgment.
[0140] For example, if the quantification start time is 12:00:00.000 and the quantification end time is 12:02:30.000, the quantification time (t quan ) can be derived by calculating 150 seconds.
[0141] This allows for the quantification of latency based on logs, clarifying the basis for judgment, instead of relying on human perception that it feels slow.
[0142] Number of processed scenes (n quan ) can mean the total number of scenes generated as a result of structuring performance data into scenes, and the unit can be used as count.
[0143] The data collection module (110) can generate a scene unit record or a scene list after performing scene division using a performance script or scene configuration information, and the number of scenes processed (n) is determined from the length of the list or the number of scene records loaded in the table. quan ) can be derived.
[0144] Number of processed scenes (n quan ) is a value that varies depending on the performance data input and can be derived as a value calculated at the time scene structuring is completed.
[0145] The larger the scale of the performance, the greater the total time required, which is the quantified time required (t quan As ) increases, the time required for quantification (t quan Number of scenes processed (n) quan The value divided by ) can create an average time per scene and correct for bias due to differences in scale.
[0146] For example, if 30 scene records are generated, the number of processed scenes (n quan ) can be derived as 30, and accordingly, compared to a method based only on total time, it can reduce unnecessary additional collection judgments in large performances.
[0147] Number of items requiring correction (m quan) may refer to the cumulative number of items determined to require additional verification or supplementation due to omissions, ambiguities, or conflicts in input data during quantification processing, and the unit may be count.
[0148] The data collection module (110) performs validation based on pre-set explicit rules during quantification, such as 'the actor's movement coordinates must exist within a specific time interval in the scene,' 'the music timeline interval must cover the scene time range,' and 'the scene transition point must not contradict the script transition,' and whenever the validation of the rule fails according to the result of the performance, the number of items requiring correction (m) quan It can be derived by counting ) by 1.
[0149] The data collection module (110) can store the performance ID, scene ID, failure type, time of occurrence, and related field name together whenever it records a pre-configured explicit rule-based verification.
[0150] The data collection module (110) can increase the cumulative count by counting one verification failure as one case based on pre-configured explicit rule-based verification, and at the end of the total quantification, sums the number of events recorded for the corresponding execution ID to determine the number of items requiring correction (m quan It can be set to ).
[0151] That is, the data collection module (110) has a number of items requiring correction (m) when starting the quantification execution. quan By setting ) to 0 and increasing it by 1 for each validation failure event, the number of items requiring correction (m quan ) can be derived.
[0152] The data request judgment control algorithm is the aforementioned quantification time (t quan Number of scenes processed (n) quanIf only the value divided by ) is used, it may be difficult to distinguish between cases where the performance is slow due to complexity and cases where it is slow due to extensive corrections caused by incomplete data, so the number of items requiring correction (m quan Number of scenes processed (n) quan It can be characterized by being designed to reflect data quality issues by using the value divided by ).
[0153] For example, if a total of 12 verification failure events are recorded out of 30 scenes, the number of items requiring correction (m quan ) can be set to 12, thereby reducing misjudgments based solely on time indicators and inducing additional collection only in cases where there are actually many omissions and ambiguities.
[0154] Quantification time per scene standard (t limit ) may refer to the standard value of the average quantified time per scene allowed by the manager, and the unit may be used as seconds / scene (s / scene).
[0155] Quantification time per scene standard (t limit ) can be derived by inputting by an administrator, and an input field for the allowable quantified time per scene can be provided on the settings screen of the management server (100), and the administrator inputs a number (e.g., 8, 10, 12, etc.) considering the performance type, rehearsal schedule, operational personnel, etc. to determine the quantified time standard per scene (t limit You can set ).
[0156] The management server (100) receives the quantification time standard per scene (t) from the settings screen. limit The input value of ) can be stored in the setting table for each performance ID.
[0157] Quantification time per scene standard (t limit ) can be set to an initial value of the system default (e.g., 10 seconds / scene), and can be modified by the administrator for each performance.
[0158] Since the allowable time is a policy within the site or management system, arbitrarily determining it may lead to disputes; therefore, it may be determined based on values explicitly entered by the operator or manager.
[0159] In other words, the data request judgment control algorithm is based on the quantified time standard per scene (t) for each site or performance. limit ) can be received and utilized differently; for example, since musical performances have many scene changes, the standard for quantified time per scene (t limit Set ) to 12, and for plays, the standard for quantified time per scene (t limit You can apply it by entering 8 for ).
[0160] Accordingly, compared to the method of embedding fixed standards in the code, performance-specific policies can be easily reflected.
[0161] Time weight (w quan1 ) and correction weights (w quan2 ) can refer to weighting factors that adjust the importance of the time term and the correction term, and the unit can be used as dimensionless.
[0162] Time weight (w quan1 ) and correction weights (w quan2 The derivation method of ) can be explained by classifying it as follows.
[0163] First, time weight (w) in the management server configuration screen as entered by the administrator quan1 ), correction weight (w quan2 ) input fields can be provided, and administrators can directly input values such as a range of 0.5 to 2.0.
[0164] Second, using a method derived from recorded data, cases requiring additional collection from past performance logs were selected as a sample, and the time required for quantification (t) in those cases was determined. quan Number of scenes processed (n) quan Whether the value divided by ) was mainly the problem or the number of items requiring correction (m quanNumber of scenes processed (n) quan A human verifies whether the value divided by ) was primarily the problem, and adjusts the time weight (w) according to that trend. quan1 ) or correction weight (w quan2 You can propose an adjustment value for ) (e.g., for projects with frequent correction issues, correction weights (w quan2 ) can be recommended as 1.3), and this can be reflected as a setting value.
[0165] Third, if the result comes out excessively as 1 in the operator's test run (rehearsal data) using a simple numerical adjustment method, the time weight (w quan1 ) or correction weight (w quan2 You can fine-tune it by lowering it in 0.1 increments and raising it in 0.1 increments if it comes out excessively 0.
[0166] Time weight (w quan1 The default value of ) is 1, correction weight(w quan2 The default value of ) can start at 1 and can be changed and saved per performance.
[0167] Since some sites may require a more sensitive assessment of time delays and others of data quality (correction), site policies can be reflected in the decision formula through weights. For example, if a problem arises due to a high number of correction events during rehearsal, the correction weight (w quan2 By setting ) to 1.5, the influence of the correction term can be reflected more significantly. Accordingly, compared to a uniform judgment, the same formula can be flexibly applied according to the performance environment.
[0168] As an example of numerical substitution and operation, the time weight (w quan1 ) is 1, correction weight(w quan2 ) is 1, quantification time per scene standard (t limit Based on the fact that ) is set to 10 seconds / scene, the following two examples will be explained.
[0169] In Example A, the time required for quantification (tquan ) is 180 seconds, number of processed scenes (n quan ) is 30 scenes, number of items requiring correction (m quan If ) is derived as 3 cases, the total score output by the data request judgment control algorithm can be approximately 0.565.
[0170] Since the output 0.565 is smaller than the result of the logarithmic function 2, it can be determined that further collection is unnecessary.
[0171] At this time, the data collection module (110) can process the quantification results to be transmitted to the needs mapping module without additional requests.
[0172] In Example B, the time required for quantification (t quan ) is 450 seconds, number of processed scenes (n quan ) is 30 scenes, number of items requiring correction (m quan If ) is derived as 12 cases, the total score output by the data request judgment control algorithm can be output as 1.252.
[0173] Since the output 1.252 is greater than the result of log function 2, it can be determined that additional collection is necessary.
[0174] At this time, the data collection module (110) can process the generation and transmission of a request message for additional provision of performance data to the performance production company terminal (500) based on the verified result obtained through pre-configured explicit rule-based verification.
[0175] The data collection module (110) can read the quantification start time using a system time function at the start of the quantification task and store it in a DB or log, and after the scene structuring process, aggregate the number of scene records to process the number of scenes (n). quan It can derive ), and if a verification rule failure occurs during quantification processing, one verified result is recorded in through pre-configured explicit rule-based verification, and the cumulative count is increased to the number of items requiring correction (m quan) can be derived.
[0176] In addition, at the end of quantification, the quantification end time is read using the system time function, and the quantification time (t) is calculated from the difference between the quantification start time and the quantification end time. quan ) can be derived, and the quantification time standard per scene (t) from the settings table can be derived. limit ), time weight(w quan1 ) and correction weights (w quan2 Can collect ).
[0177] Afterward, the data collection module (110) inputs the first element reflecting time and the second element reflecting correction into a logarithmic function to sum them, and then compares the summed result with the result of logarithmic function 2 to determine the additional collection value as 0 or 1.
[0178] The data collection module (110) can determine that additional collection is necessary when the total score is output as a value greater than the result of log function 2 and can request additional data from the performance production company terminal (500).
[0179] Conversely, if the data collection module (110) outputs a value smaller than the result of log function 2, it determines that additional collection is unnecessary and can transmit the quantified data to the next module, the needs mapping module (130).
[0180] The data request judgment control algorithm can output a single quantified score that allows for judgment based on a single criterion by multiplying the first and second elements by weights and summing them.
[0181] Specifically, it can be structured to determine whether the sum of the value calculated from the first element and the value calculated from the second element is greater or smaller than the result of logarithmic function 2, and if it exceeds the result of logarithmic function 2, it can be determined that additional collection is required.
[0182] Also, quantification time per scene standard (t limit ) can be set via administrator input, and the time weight (w quan1 ) and correction weights (w quan2 ) can be set to administrator input, adjustment based on historical data, or simple numerical adjustment, allowing for the reflection of operational policies by combining sensitivities.
[0183] The result of logarithmic function 2, which serves as the basis for dividing the total score calculated by adding the first and second elements, can also be changed by simple numerical adjustment according to the operation policy.
[0184] The data request judgment control algorithm can be repeatedly applied during the process in which performance data received from the performance production company terminal (500) is modified or additional data is submitted.
[0185] For example, if it is determined that additional collection is necessary as a result of performing quantification with the initial data, the data collection module (110) may request the performance production company terminal (500) to supplement missing or ambiguous items in the performance data, and if the performance production company terminal (500) supplements the performance data and retransmits it, the verification failure event is reduced, and the number of items requiring correction (m) quan ) or number of items requiring correction (m quan Number of scenes processed (n) quan The value divided by ) can be lowered, and quantification processing is also faster, so the time required for quantification (t quan Number of scenes processed (n) quan The value divided by ) can be lower.
[0186] As a result, even if the data request judgment control algorithm is reapplied in the same way, the overall score can be lowered below the result of log function 2, and the improvement loop can be implemented in such a way that additional collection becomes unnecessary.
[0187] The data request judgment control algorithm may include behavioral variability characteristics based on user input, where the values entered or adjusted by an operator or manager are based on the quantification time per scene (t limit ), time weight(w quan1 ) and correction weights (w quan2 These values can directly affect the judgment result.
[0188] Manager's quantified time per scene (t limit If you enter a small value for ), the value of the first element increases, making it easier to encounter situations where additional collection is required.
[0189] Also, the manager time weight (w quan1 If you input a large value for ), the weight of the first element increases, which may shift the judgment to be centered on time delay, and the correction weight (w quan2 If you input a large value for ), the weight of the second factor increases, and the judgment may shift to a focus on data quality.
[0190] For example, the time required for quantification in the same execution (t quan Number of scenes processed (n) quan When the value divided by ) is 12, the quantification time per scene standard (t limit If ) is 10, the likelihood of it being judged as exceeding the standard increases, and the quantification time standard per scene (t limit If ) is 15, the likelihood of it being judged as below the standard increases.
[0191] The above technical configurations and examples are sufficiently provided so that a person skilled in the art can easily implement the data request judgment control algorithm and variable definitions of the present invention. Although the present invention is not limited to specific examples and various modifications are possible within its scope, it can be confirmed that a person skilled in the art can obviously understand and realize them.
[0192] The needs mapping module (130) can generate a role-specific lighting needs mapping matrix that defines the attributes of lighting required for each role within the performance based on the lighting pattern requirements quantified from the data collection module (110).
[0193] Here, each role in the performance may be characterized as being defined as an independent lighting requirement unit subject to lighting control based on at least one of the narrative importance, frequency of appearance, range of movement, and emotional change per scene for each role unit, as a result of the needs mapping module (130) classifying elements appearing in the performance into multiple role units including at least one of lead actor, supporting actor, ensemble, stage background, prop area, and instrument part based on the performance data structured by the data collection module (110).
[0194] Additionally, the needs mapping module (130) may be characterized by defining the lighting required for each role unit as a set of lighting attribute parameters including at least one of brightness, color, color temperature, illumination angle, focusing area, movement path, illumination time, and effect pattern, and mapping the set of lighting attribute parameters on a scene-by-scene basis to generate a lighting needs mapping matrix for each role.
[0195] The above-described lighting attributes may include at least one of brightness, color, color temperature, illumination angle, focusing area, movement path, illumination time, and effect pattern for the lighting required for each role unit by the needs mapping module (130).
[0196] Meanwhile, the needs mapping module (130) may use a matrix normalization judgment algorithm to determine whether the lighting needs mapping matrix by role has been generated in accordance with normal procedures and scales by normalizing it based on time.
[0197] The matrix normalization decision algorithm simply uses the actual time taken (T matrix Rather than a method that looks only at absolute values, such as "a large value means slow," the number of scenes (N), which represents a different data scale for each performance, is not the only approach. s ), Number of role units (N r ), number of lighting attribute parameters (N a It can be characterized by being designed to reduce unnecessary false positives that may occur in large-scale performances by comparing based on the expected time reflecting ).
[0198] The needs mapping module (130) outputs a suitability score (S) through a matrix normalization judgment algorithm. matrix It can be used in judgment logic such as suitable, need for review, or unsuitable by comparing it with a threshold value, and if necessary, it can be used as a control condition to re-check the needs mapping results (missing, misclassified, attribute setting error, etc.) or to induce operator review before passing them to a subsequent step (lighting recommendation module).
[0199] The matrix normalization judgment algorithm is the actual time (T) taken for the needs mapping module (130) to generate the role-specific lighting needs mapping matrix. matrix Receives ) as input, and the number of scenes (N) representing the scale of the performance data s ), Number of role units (N r ), number of lighting attribute parameters (N a ) and unit expected time (τ matrix ), penalty size weight (w matrix It receives ) together as input values, and finally the fit score (S matrix Can output ).
[0200] More specifically, the matrix normalization determination algorithm first calculates the number of scenes (N) to calculate the typically expected time when creating a matrix for the corresponding performance scale. s ), Number of role units (N r ), number of lighting attribute parameters (N a ) and unit expected time (τmatrix You can utilize the product of ).
[0201] Next, to express the ratio of how many times the actual time is compared to the expected time, the actual time required (T matrix ) number of scenes (N s ), Number of role units (N r ), number of lighting attribute parameters (N a ) and unit expected time (τ matrix It can be divided by the product of ).
[0202] Next, to smooth out the excessive spikes in value when the multiplier increases, and to correlate the cases of being twice as slow with being twice as fast, the actual time required (T matrix ) number of scenes (N s ), Number of role units (N r ), number of lighting attribute parameters (N a ) and unit expected time (τ matrix The result of dividing by the product of ) can be input into the logarithmic function.
[0203] Finally, the penalty size weight (w) to the result input into the log function matrix After multiplying by ) and adding 1, the penalty increases as the deviation increases, and the reciprocal is taken to obtain the fitness score (S matrix It can be characterized by being configured to have a score that operates between 0 and 1.
[0204] The matrix normalization decision algorithm determines that the generation of the needs mapping matrix reflects a combination of scenes, roles, and attributes, and the throughput is approximately the number of scenes (N s ), Number of role units (N r ), number of lighting attribute parameters (N a It can be characterized by reflecting scale correction by reporting that it is proportional to the product of ).
[0205] The matrix normalization judgment algorithm is based on the number of scenes (N s ), Number of role units (N r ), number of lighting attribute parameters (Na The product of ) and unit expected time (τ matrix It can be characterized by being configured to generate expected time by multiplying by ).
[0206] In addition, the matrix normalization decision algorithm takes the actual time (T matrix It can be characterized by being configured to eliminate differences in scale between performances and compare them through the ratio of ) divided by the expected time.
[0207] The above-described matrix normalization decision algorithm takes the actual time (T matrix The ratio of ) divided by the expected time can be characterized by the use of a logarithmic function because the size range can be large, thereby making the increase smoother.
[0208] In addition, the matrix normalization decision algorithm can be characterized by being configured to utilize the magnitude of deviation as the center for simple judgment by removing direction using the absolute value of the result of the logarithmic function.
[0209] In addition, the matrix normalization decision algorithm is composed of an inverse structure so that the fit score (S) is close to 1 when the deviation is 0 and approaches 0 as the deviation increases. matrix It can be designed to output ) and configured to be used for threshold comparison judgment.
[0210] The matrix normalization judgment algorithm can be characterized by using a logarithmic function and an absolute value together so that cases of being twice as slow and twice as fast are penalized to the same degree, and cases of being excessively fast as well as slow are reflected in the score.
[0211] In other words, the logarithmic function smooths out multiple differences, the use of absolute values eliminates fast or slow directions, and the reciprocal is the fit score (S matrix It may be characterized as being used to limit ) to a range of 0 to 1.
[0212] As described in [Table 2] below and the above description, the matrix normalization decision algorithm may be characterized by being designed using functions such as logarithmic functions through examples of various tests, and may be characterized by being designed to reflect actual data distribution and experimental experience.
[0213] [Table 2]
[0214]
[0215] The actual time taken (T), which is each variable used in the matrix normalization decision algorithm matrix ), number of scenes(N s ), Number of role units (N r ), number of lighting attribute parameters (N a ), unit expected time (τ matrix ), penalty size weight (w matrix The characteristics of ) are as follows.
[0216] Actual time required (T matrix ) may mean the actual time spent in the processing section where the needs mapping module (130) generates the "role-specific lighting needs mapping matrix," and the unit may be seconds.
[0217] The management server (100) can record the system time in milliseconds immediately before calling the needs mapping module (130) and store it as the matrix creation start time, and when the needs mapping module (130) completes the creation of the role-specific lighting needs mapping matrix, it can record and store the system time immediately after that as the matrix creation end time.
[0218] At this time, the management server calculates the actual time taken (T) based on the difference between the matrix creation end time and the matrix creation start time. matrix ) can be derived, and the actual time required (T matrix ) is not a fixed value but can be updated with a measured value for each execution.
[0219] The matrix normalization judgment algorithm performs a suitability judgment of the needs mapping matrix based on time using the actual time taken (T matrix The actual time measured using ) can be used as an input value.
[0220] For example, if the matrix creation start time is 12:00:00.000 and the matrix creation end time is 12:00:03.200, the actual elapsed time (T matrix ) can be derived as 3.2s.
[0221] The actual time required (T) mentioned above matrix The method for deriving ) uses the difference in recorded time rather than perception or estimation, so abnormal situations such as delays or processing overload can be connected to and utilized in the judgment logic.
[0222] Number of scenes (N s ) can represent the number of scenes in the result where performance data is divided into scenes, and the unit is count, which can be used as a unitless value.
[0223] The management server (100) can receive performance data including script and stage scene configuration information from the performance production company terminal (500), and the data collection module (110) can apply a pre-set rule to determine the "scene start and end boundary."
[0224] For example, the data collection module (110) may adopt one or more of the scene notation of a script, the track or section boundary of a music timeline, and the scene ID change of stage scene configuration information as scene boundaries, and may generate a scene list based on the boundary criteria.
[0225] Afterwards, the management server (100) counts the number of items in the scene list and the number of scenes (N s It can be set to ), and if the performance data changes, the number of scenes (N) is set using the same procedure. s ) can be re-derived.
[0226] Since the matrix normalization decision algorithm can increase the number of units to be mapped as the number of scenes increases, the number of scenes (N s It can be characterized by being designed to reflect in configuring the expected time using ).
[0227] For example, if the scene list is generated from 1 to 12, the number of scenes (N s ) can be set to 12, and the number of scenes (N s If ) is reflected, suitability can be determined by considering the scale of the performance rather than the simple absolute time standard.
[0228] Number of role units (N) r ) may mean the number of roles resulting from the needs mapping module (130) classifying elements appearing in the performance into independent request units that are subject to lighting control, and the unit may be used as a count.
[0229] The management server (100) can obtain source information for extracting candidate elements (e.g., actors, ensemble groups, background areas, prop areas, instrument parts) from performance data including script character tables, entity IDs of actor movement data, stage area partition information, etc., and the needs mapping module (130) can apply criteria for determining role units.
[0230] For example, the needs mapping module (130) can use one or more of the following criteria to determine whether it is an "independent lighting requirement unit": narrative importance, frequency of appearance, range of movement, and emotional change per scene, and can generate a list of roles based on the criteria.
[0231] Additionally, each role list can be tagged with at least one type among “lead role, supporting role, ensemble, background, prop, instrument part,” and the management server (100) counts the number of items in the role list to determine the number of role units (N). r It can be derived as ).
[0232] If the role classification criteria change or the performance data changes, the number of role units (N) is changed using the same procedure. r ) can be re-derived.
[0233] Since the matrix normalization decision algorithm may increase expected time as the number of roles increases due to the increased workload of mapping roles and scenes, the number of role units (N) r This can be reflected using ).
[0234] For example, if the role list has a total of 9 items, the number of role units (N r ) can be derived as 9, and the number of role units (N r By reflecting ), the phenomenon of prolonged time in performances with many roles can be corrected by scale, thereby reducing false positives.
[0235] Number of lighting attribute parameters (N a ) may refer to the number of attributes actually selected as the target of application among the lighting attribute parameters defining the role unit, such as brightness, color, color temperature, illumination angle, focusing area, movement path, illumination time, and effect pattern, and the unit may be used as count.
[0236] The management server (100) provides a list of lighting attributes to be used in the performance, and the operator or manager can select the lighting to be used according to the nature of the performance and the equipment configuration.
[0237] The management server (100) counts the number of selected attribute items and the number of lighting attribute parameters (N a It can be set to ), template defaults can be used as initial values, and the number of lighting attribute parameters (N) can be changed by the operator. a ) can be updated.
[0238] The matrix normalization decision algorithm needs to reflect the number of lighting attribute parameters (N) in the expected time calculation because as the number of lighting attributes increases, the mapping amount of roles, scenes, and attributes also increases. a It can be characterized by the use of ).
[0239] For example, if you select brightness, color, angle, and effect pattern, the number of lighting attribute parameters (N a ) can be derived as 4.
[0240] The matrix normalization determination algorithm is based on the number of lighting attribute parameters (N a By reflecting ), the increase in time occurring in performances with large attribute dimensions can be reflected to be considered within the normal range.
[0241] Unit expected time (τ) matrix ) can mean the average time expected to process a unit that maps scenes, roles, and attributes, i.e., a reference value, and the unit can be used as seconds (s) / (unit).
[0242] Unit expected time (τ) matrix ) can be configured by inputting it through an administrator, who sets the unit expected time (τ) on the settings screen based on server specifications and target processing speed. matrix You can enter ).
[0243] Also, unit expected time (τ matrix ) can be set in a manner derived based on record data, and the management server (100) determines the actual time taken (T) for each past execution. matrix ) and number of scenes (N s ), Number of role units (N r ), number of lighting attribute parameters (N a ) can be recorded, and the manager can query the records for a specific period, calculate the average, and use that value as the unit expected time (τ matrix It can be derived as ).
[0244] Third, it can be set using a simple numerical adjustment method, with an initial unit expected time (τ matrix After setting ), if the warning is excessive, the unit expected time (τ matrix Increase ) slightly, and if you miss the ideal, the unit expected time (τ matrixIt can be adjusted step by step by slightly reducing ).
[0245] Unit expected time (τ) matrix ) can start with a template default or an administrator input value.
[0246] The matrix normalization decision algorithm requires a reference value because normal time can vary depending on server load or performance targets even for the same performance scale, so the unit expected time (τ) matrix It can be characterized by the use of ).
[0247] For example, unit expected time (τ matrix Set ) to 0.01 and the number of scenes (N s ), Number of role units (N r ), number of lighting attribute parameters (N a If the product of ) is 320, the expected time can be 3.2 seconds.
[0248] In addition, the matrix normalization decision algorithm has unit expected time (τ). matrix By applying ), the realism of judgment can be enhanced by reflecting standards appropriate to the environment.
[0249] Penalty size weight (w matrix ) can mean a sensitivity value that controls the penalty size for deviation relative to expected time, and can be used as a unitless value.
[0250] Penalty size weight (w matrix ) can be configured by inputting it through an administrator, who sets a policy such as "Strict, Moderate, Relaxed" and inputs corresponding values (e.g., 1.0 / 0.7 / 0.5) to set the penalty size weight (w matrix You can set ).
[0251] Also, penalty size weight (w matrix ) may also be set in a way that is derived based on historical data, and the administrator [can] set the "suitability score (S) of cases judged as normal" from past records. matrixBased on operational records such as "warnings were frequent because ) was too low," penalty size weighting (w matrix It can be adjusted by lowering ).
[0252] Penalty size weight (w matrix ) can also be set using a simple numerical adjustment method, where the manager checks the warning frequency (e.g., 30 cases per day) during the pilot operation and adjusts the penalty size weight (w) to match the target frequency (e.g., 5 cases per day). matrix ) can be increased or decreased in increments of 0.1.
[0253] For example, penalty size weight (w matrix ) can be set to an initial value of 1.0 and can be changed according to the operation policy.
[0254] The matrix normalization judgment algorithm recognizes that even with the same deviation, the permissible perspective may differ depending on the operational stage (rehearsal or main performance), so the penalty size weight (w matrix You can adjust the sensitivity using ).
[0255] For example, right before the main performance, penalty size weight (w matrix ) 1.0, penalty size weight (w) for rehearsal matrix ) can be operated at 0.6.
[0256] Also, penalty size weight (w matrix By applying ), you can adjust the warning sensitivity to meet operational requirements while maintaining the same formula structure.
[0257] The implementation process of the matrix normalization judgment algorithm is, for example, the number of scenes (N s ) is 10, number of role units (N r ) is 8, number of lighting attribute parameters (N a ) is 4, unit expected time (τ matrix ) is derived in 0.01 seconds / units, and penalty size weight (w matrix ) is set to 1.0, and the actual time required (T matrix If ) is derived as 5.0 seconds, the suitability score (Smatrix ) can be output as approximately 0.691.
[0258] If the threshold value set in the needs mapping module (130) is set to 0.70, the suitability score (S matrix If ) is above the threshold, it can be determined as a fit, and the fit score (S matrix If ) is below the threshold, it can be determined that review is required.
[0259] The matrix normalization determination algorithm counts the number of scenes in the scene list generated by the data collection module (110) and the number of scenes (N s ) is derived, and the number of role units (N) is counted by the number of role lists generated by the needs mapping module (130). r Deriving ), and counting the number of items of the selected lighting attribute to determine the number of lighting attribute parameters (N a It can be implemented in a way that derives ).
[0260] In addition, the start time and end time of matrix generation of the needs mapping module (130) are recorded in a log, and the difference is calculated to determine the actual time required (T matrix ) can be derived, and the unit expected time (τ) from the pre-set value matrix ), penalty size weight (w matrix After reading ), input it into the matrix normalization decision algorithm to obtain the fit score (S matrix Can output ).
[0261] Subsequently, the fit score (S matrix You can compare ) with a threshold value to save or display the status values of suitable, need review, or unsuitable on the screen.
[0262] The present invention relates to a conformity score (S matrix After outputting ), the condition can be determined using a threshold value, for example, the goodness-of-fit score (S matrix If ) is above the threshold, it can be determined as a fit, and the fit score (S matrix If ) is below the threshold, it may be determined to require review or be unsuitable.
[0263] The threshold can be set by inputting it by the manager or by deriving it based on historical data (e.g., the suitability score of normal cases (S matrix ) setting the lower boundary value of the distribution as the threshold), and can also be adjusted during operation using a simple numerical adjustment method (e.g., lowering the threshold if there are many warnings and raising the threshold if anomalies are missed).
[0264] Since the matrix normalization decision algorithm is a time-based single score, it can basically be composed of a single condition comparison, and the fit score (S matrix It can also be used as a step control to withhold delivery to a subsequent module so that a re-verification procedure for the needs mapping result is performed only when ) is below a threshold.
[0265] In addition, since the matrix normalization decision algorithm may be executed repeatedly during the performance rehearsal and modification process, the actual time required (T for each execution) matrix ) is newly measured and the conformance score (S) is obtained through the same implementation process. matrix It can be characterized by being configured to output ) anew.
[0266] Also, the current fit score (S matrix (t)) and the previous fit score (S matrix By comparing (t-1)), if there is a sudden change, it can be determined that the impact of the change is significant, for example, the current goodness-of-fit score (S matrix (t)) and the previous fit score (S matrix If the difference in (t-1)) exceeds 0.2, a review procedure may be initiated to determine whether one or more of the following had an effect: increased scene division, increased role decomposition, or increased attribute selection.
[0267] The matrix normalization decision algorithm can be configured so that the input from the operator or the manufacturer is reflected in the result, and the operator can control the unit expected time (τ). matrixIf you set ) to a smaller value, the expected time decreases, resulting in the same actual time required (T matrix The ratio also increases in ), so the fit score (S matrix Since ) can be lowered, stricter judgment may become possible.
[0268] In addition, the operator has penalty size weighting (w matrix If ) is set high, the penalty for the same deviation increases, so the goodness-of-fit score (S matrix Since ) can be lowered, the warning sensitivity can be increased.
[0269] In addition, since raising the threshold makes it difficult to determine suitability and lowering it makes it easier, the judgment criteria can be adjusted according to the operational stage (rehearsal or main performance).
[0270] The above technical configurations and examples are sufficiently provided so that a person skilled in the art can easily implement the matrix normalization judgment algorithm and variable definitions of the present invention. Although the present invention is not limited to specific examples and various modifications are possible within its scope, it can be confirmed that a person skilled in the art can obviously understand and realize them.
[0271] The lighting recommendation module (150) can automatically recommend a plurality of lighting design packages including the type, quantity, and placement location of lighting equipment by considering the role-specific lighting needs mapping matrix generated by the needs mapping module (130) and the performance budget included in the performance data received from the performance production company terminal (500).
[0272] More specifically, the lighting recommendation module (150) can generate a plurality of lighting design combinations using the role-specific lighting needs mapping matrix and performance budget information as input values, and the type, quantity, placement location, and usage frequency of lighting equipment as variables, and generate a lighting design evaluation result by calculating at least one of budget suitability, lighting needs satisfaction, and equipment utilization efficiency as an evaluation indicator for each generated lighting design combination, and can recommend a plurality of lighting design packages by utilizing artificial intelligence that performs learning or rule-based operations to automatically recommend a plurality of lighting design packages according to the lighting design evaluation result.
[0273] The operation placement module (170) can modify the existing lighting operation plan received in real time and generate and provide a lighting relocation plan in response to unexpected situations, including scene changes, additional performances, and special events occurring during the performance period, equipped with a lighting design package recommended by the lighting recommendation module (150).
[0274] More specifically, the operation placement module (170) can detect or receive scene change information, additional performance information, or special event occurrence information input during the performance in real time, compare and analyze the change information with a previously stored lighting operation plan, and recalculate at least one of the activation order, placement position, or control parameter of the lighting equipment in response to the changed scene or event, and generate and provide a modified lighting operation plan and a corresponding lighting relocation plan in real time.
[0275] Meanwhile, the operation deployment module (170) may use a relocation plan quantification judgment algorithm to determine the suitability of the relocation plan by considering the time taken to generate the lighting relocation plan as a key criterion, along with the scale of change, server load, and urgency.
[0276] The relocation plan quantification judgment algorithm is the time required (T gen ), reference generation time (T ref ), change scale indicator (ΔC re-plan ), Server CPU load (U cpu ), urgency (u re-plan ), time performance weight (w re-plan1 ) and change scale weight (w re-plan2 ) can be used as an input value, and the final relocation score (S re-plan Can output ).
[0277] The redeployment plan quantification judgment algorithm can be used as a tool to be performed in the judgment (evaluation) stage, receiving the time, load, change scale, and urgency recorded during the process as input immediately after the operational deployment module (170) generates the redeployment plan.
[0278] The relocation plan quantification judgment algorithm may be characterized by utilizing a logarithmic function to increase the stability of the judgment by reducing excessive spikes in scores even when input values become extremely large.
[0279] More specifically, the relocation plan quantification judgment algorithm may be characterized by being composed of the first to fourth items.
[0280] The first item of the relocation plan quantification judgment algorithm may be characterized by being configured to indicate whether the actual generation time is faster than the reference time.
[0281] The first item is the time required (T gen Normalize by adding 1 to ), and reference generation time (T ref Normalized time (T gen Add 1 to the result divided by ) and input it into the logarithmic function, and the time performance weight (w) to the result input into the logarithmic function re-plan1 It can be characterized by being configured to multiply )
[0282] Here, the time required (Tgen If ) is small, the fractional value increases, the result of the logarithmic function increases, and consequently, the final relocation score (S re-plan ) can grow larger.
[0283] The second item of the relocation plan quantification judgment algorithm may be characterized by being configured to perform a correction that reduces the bonus points as the scale of change increases.
[0284] The second item is the change scale indicator (ΔC re-plan After normalizing by adding 1 to ), the normalized change magnitude indicator (ΔC re-plan Convert ) to the reciprocal, add 1 to the reciprocal value and input it into the logarithmic function, and the change scale weight (w) on the result input into the logarithmic function re-plan2 It can be characterized by being configured to multiply )
[0285] The third item of the relocation plan quantification judgment algorithm is that the higher the server load, the higher the final relocation score (S re-plan It can be characterized by being configured so that ) becomes a deduction point.
[0286] The third item is server CPU load (U cpu 1 is added to ) and input into the logarithmic function, but it can be reflected as a subtraction from the first and second elements to be reflected as a deduction factor in the relocation plan quantification judgment algorithm.
[0287] The fourth item of the relocation plan quantification judgment algorithm is that the higher the urgency, the higher the final relocation score (S re-plan It can be characterized by being configured so that ) becomes a deduction point.
[0288] The fourth item is urgency (u re-plan 1 is added to ) and input into the logarithmic function, but it can be reflected as a subtraction from the first and second elements to be reflected as a deduction factor in the relocation plan quantification judgment algorithm.
[0289] As described above, the relocation plan quantification judgment algorithm generates a final relocation score (S) as the lighting relocation plan is generated faster. re-plan ) increases, and the larger the change, or the busier or more urgent the server, the higher the final redeployment score (S re-plan It can be characterized by being designed to go down or go up less.
[0290] The redeployment plan quantification judgment algorithm is important for real-time response of the redeployment plan of the operational deployment module (170), so the time required to generate (T gen To make it more advantageous for the shorter the ) is, a bonus point item can be formed using time relative to the standard.
[0291] The time relative to the standard is the time required (T gen After normalizing by adding 1 to ), the reference generation time (T ref Normalized time (T gen It could mean dividing by ), the time required (T gen Normalizing ) can mean a process to prevent operation errors by making the denominator zero.
[0292] In addition, since operational difficulty and risk may increase when the scale of change in a relocation plan is large, the change scale indicator (ΔC re-plan It can be characterized by being reflected as an inverse, in which the bonus points decrease as ) increases.
[0293] In redeployment planning, if server load is high or urgency is high, the risk of the same delay can increase, so server CPU load (U cpu ) and urgency (u re-plan ) is reflected as a deduction item, and the final reassignment score (S re-plan It can be characterized by being configured so that ) goes down.
[0294] In addition, the relocation plan quantification judgment algorithm determines the final relocation score (S re-planIt can be characterized by using a logarithmic function for each item to smooth out the change of ) and prevent the result from fluctuating excessively.
[0295] That is, the relocation plan quantification judgment algorithm may be characterized by utilizing a logarithmic function to normalize the score so that it does not spike excessively when the value increases and the influence of extreme values becomes milder.
[0296] As described in [Table 3] below and the above description, the relocation plan quantification judgment algorithm may be characterized by being designed using functions such as logarithmic functions through examples of various tests, and may be characterized by being designed to reflect actual data distribution and experimental experience.
[0297] [Table 3]
[0298]
[0299] Each variable used in the relocation plan quantification judgment algorithm, the time required (T gen ), reference generation time (T ref ), change scale indicator (ΔC re-plan ), Server CPU load (U cpu ), urgency (u re-plan ), time performance weight (w re-plan1 ) and change scale weight (w re-plan2 The characteristics of ) are as follows.
[0300] Time required (T gen ) is a value representing the time taken to generate a lighting relocation plan that includes a modified operation plan reflecting change information and to finalize the result, and its unit can be seconds (s).
[0301] The operation deployment module (170) can record the time when the redeployment plan is started after receiving change information such as scene changes, additional performances, or special events, and can record the time when the redeployment plan including equipment activation order, deployment location, and control parameters is generated and server storage is completed, and the redeployment time (T) is calculated from the difference between the time when the redeployment plan starts and the time when the redeployment plan is completed. gen ) can be derived.
[0302] Re-processing time (T gen ) can be used as a value that is not a fixed value but is newly measured and calculated for each change event, and can be used because it is necessary to directly reflect the time as a numerical value to determine suitability based on the time required to generate a relocation plan in the present invention.
[0303] For example, if the redeployment plan start time is 12:00:00.000 and the redeployment plan completion time is 12:00:02.300, the re-execution time (T gen ) can be derived as 2.3s.
[0304] Reference generation time (T ref ) may represent a reference value representing the time typically expected to generate a relocation plan in the relevant performance or system environment, and the unit may be seconds (s).
[0305] Reference generation time (T ref The method of deriving ) first is a method of input by an administrator, and the administrator can set the initial standard value by directly entering a value into the "standard creation time (seconds)" input field of the management server (100).
[0306] For example, during initial operation, the administrator uses the standard creation time (T ref You can enter ) as 3.0s.
[0307] Second criterion generation time (T refThe derivation method of ) is based on recorded data, and the management server uses the elapsed time (T) of the last N times (e.g., 20 times). gen After querying ), calculate the median or average of the list to determine the reference generation time (T ref The reference value can be updated by saving it as ).
[0308] For example, the time taken for the last 20 times (T gen If the median of ) is 2.8 seconds, the reference generation time (T ref ) can be derived as 2.8s.
[0309] Third criterion generation time (T ref The derivation method of ) is a simple numerical adjustment method; if the operator sets a policy to "be stricter on delays," the standard generation time (T ref The operator can adjust the reference value under their responsibility by slightly lowering it (e.g., 3.0→2.5) or slightly raising it (e.g., 3.0→3.5) if they want to "relax it."
[0310] Reference generation time (T ref ) can be used to compare based on the “normal speed of the system” in situations where it is difficult to make a judgment based solely on absolute thresholds due to varying scales and system performances for each performance, and it enables judgments that reflect the performance environment rather than forcibly applying the same standard to all performances.
[0311] Change Scale Indicator (ΔC re-plan ) can represent a numerical value indicating the magnitude of the change that the change input affects the relocation calculation, and can be used as a dimensionless value based on the number of cases.
[0312] The operation placement module (170) can compare information before and after changes in lighting placement to count the number of scenes added, deleted, or modified through scene ID comparison, count the number of queues added, deleted, or modified through lighting queue list comparison, and count the number of equipment that needs to be relocated based on the number of equipment that has changed placement location or is newly introduced.
[0313] Subsequently, the number of modified scenes, the number of modified queues, and the number of equipment requiring relocation are summed to determine the scale of change indicator (ΔC re-plan ) can be derived, but if there is no modification, it is set to 0, and if a change occurs, the above count can be performed to derive it.
[0314] Change Scale Indicator (ΔC re-plan ) can be used as a correction value to evaluate more strictly even the same generation time, as large-scale changes can complicate lighting relocation plans and increase operational risks.
[0315] For example, if the number of modified scenes is 1, the number of modified queues is 3, and the number of equipment requiring relocation is 2, the change scale indicator (ΔC re-plan ) can be derived as 6.
[0316] The relocation plan quantification judgment algorithm is the change scale indicator (ΔC re-plan It can help reduce misjudgments that may occur when evaluating based solely on time.
[0317] Server CPU Load (U cpu ) can represent CPU usage indicating how busy the server is during the plan generation period, and can be used as a ratio in the range of 0 to 1 (e.g., 0.70=70%).
[0318] The operation batch module (170) can read CPU usage from a server monitoring module or operating system performance indicator at regular intervals (e.g., 1 second), calculate the average of the read values over the interval from start_time to end_time, and the average value is used to determine the server CPU load (U cpu It can be derived as ).
[0319] Server CPU Load (U cpu ) can be used as a value measured and stored for each event, and since there is a possibility of calculation delays when the server is busy and such delays can increase operational risks, it can be used to reflect high load as a deduction factor.
[0320] The relocation plan quantification judgment algorithm is server CPU load (U cpu Through ), judgments can be made more stably by including the system state, compared to the method of only looking at time.
[0321] Urgency (u re-plan ) may mean a value indicating the urgency level of a change request entered by an operator or manufacturer terminal, and there may be no unit used as a level value.
[0322] The operation deployment module (170) can provide options such as “Normal=0, Urgent=1, Very Urgent=2” through the performance production company terminal (500) or management server (100), and the server stores the value selected by the performance production company or manager as is, thereby increasing the urgency (u re-plan It can be derived as ).
[0323] Urgency (u re-plan ) is set to a default value of 0 if not entered by the user, and can be updated by the user for each change request. Since the impact of the same delay is greater the higher the urgency, it can be used as a factor to lower the score more strictly.
[0324] The redeployment plan quantification judgment algorithm is based on urgency (u re-planThrough ), judgments can be differentiated even for the same generation time by reflecting the on-site situation.
[0325] Time performance weight (w re-plan1 ) and change scale weight (w re-plan2 ) can be defined as a coefficient that controls the importance of the time performance term and the change scale term, and can be set as a dimensionless value (no units).
[0326] The method of deriving weights is, first, a method input by the manager, wherein the manager inputs the time performance weight (w) to the management server (100). re-plan1 ) and change scale weight (w re-plan2 You can set it as the initial value or policy value by directly entering ).
[0327] For example, the default time performance weight (w re-plan1 ) 1.0, change scale weight(w re-plan2 You can enter ) as 1.0.
[0328] The method for deriving the second weight is based on historical data, where the management server determines the time taken for each past event (T gen ), change scale indicator (ΔC re-plan ), Server CPU load (U cpu ), urgency (u re-plan ) and the operator's final judgment (suitable or unsuitable) are stored together, and time performance weights (w) are used to refer to the records to ensure that suitable judgments do not occur too frequently or too infrequently. re-plan1 ) and change scale weight (w re-plan2 A recommended value that slightly adjusts ) can be calculated and reflected.
[0329] For example, if there are an excessive number of non-conformity judgments in the past month, time performance weights (w) are used to increase the impact of the time term. re-plan1 It can be recommended and reflected in a direction that slightly increases ).
[0330] The derivation method for the third weight is a simple numerical adjustment method; if the manager intends to view time more strictly based on experience during rehearsals or performances, the time performance weight (w re-plan1 You can manually adjust it by increasing ) by a certain amount (e.g., 0.2) (e.g., 1.0→1.2), and conversely, if you want to reflect the change scale correction more strongly, use the change scale weight (w re-plan2 It can be adjusted by raising ), which can be recorded by the operator changing the value little by little without complex learning.
[0331] Time performance weight (w re-plan1 ) and change scale weight (w re-plan2 Since operational policies may vary for each performance, it can be used to adjust which element to emphasize more between time and scale of change adjustments.
[0332] For example, time performance weight (w re-plan1 ) is 1.0, change scale weight(w re-plan2 ) is 1.0, reference generation time (T ref With ) set to 3.0s, the elapsed time (T) for Example A gen ) is 2.0s, change magnitude indicator (ΔC re-plan ) is 2, server CPU load (U cpu ) is 0.30, urgency (u re-plan If ) yields 0, the final relocation score (S re-plan ) can be output as approximately 0.719.
[0333] The final relocation score (S) output by the example A described above re-plan Since ) is a value greater than or equal to 0, it can be judged as suitable by the pre-set criteria.
[0334] Also, the time required (T) in Example B gen ) is 8.0s, change magnitude indicator (ΔC re-plan ) is 10, server CPU load (U cpu ) is 0.80, urgency (u re-planIf ) is derived as 2, the final relocation score (S re-plan ) can be output as approximately -1.312.
[0335] The final relocation score (S) output by the example B described above re-plan Since ) is a value less than 0, it may be judged as unsuitable according to the pre-set criteria.
[0336] The algorithmic implementation records the start time of the relocation plan upon receiving change information, derives the number of modified scenes, the number of modified queues, and the number of equipment requiring relocation through a comparison before and after the change, and then the change scale indicator (ΔC re-plan It calculates ), collects CPU usage at 1-second intervals, and calculates the server CPU load (U) as the average of the interval from start_time to end_time. cpu Derive ) and urgency (u) as the operator UI selection value. re-plan After deriving ), record the time required (T after recording the completion time of the relocation plan gen Derive ) and the stored reference generation time (T ref ), time performance weight (w re-plan1 ) and change scale weight (w re-plan2 Input into the relocation plan quantification judgment algorithm along with ) to the final relocation score (S re-plan It can be implemented in the order of printing ) and then printing suitable or unsuitable based on whether the condition is 0 or greater.
[0337] The conditions and criteria of the relocation plan quantification judgment algorithm are, as in the example above, the final relocation score (S re-plan A case where ) satisfies a condition greater than or equal to 0 can be set as the suitability criterion.
[0338] Final relocation score (S re-plan ) can be output by adding the first item reflecting time and the second item reflecting change information, and subtracting the third item reflecting load and the fourth item reflecting urgency.
[0339] Reference generation time (T ref ) can be set and combined via administrator input, history-based updates, and simple numerical adjustment methods, and time performance weights (w re-plan1 ) and change scale weight (w re-plan2 ) can also be set in one or more ways, such as administrator input, record-based, or simple numerical adjustment.
[0340] The relocation plan quantification judgment algorithm determines the time taken (T) whenever a scene change or special event occurs. gen ), change scale indicator (ΔC re-plan ), Server CPU load (U cpu ) and urgency (u re-plan ) newly derived to rearrange the final score (S re-plan It can repeatedly output ), and the reference generation time (T ref If ) is periodically updated with the median of the last 20 times, it can operate in a way that the standard is corrected to the latest state over time.
[0341] The variability in behavior based on user input is the urgency (u) entered by the user. re-plan As ) increases, the fourth item, the deduction item, increases, resulting in the final reassignment score (S re-plan Since ) can be lowered, the same required time (T gen Even if it is an urgent request, it can lead to a result where judgment is made more strictly.
[0342] The above technical configurations and examples are sufficiently provided so that a person skilled in the art can easily implement them according to the relocation plan quantification judgment algorithm and variable definitions of the present invention. Although the present invention is not limited to specific examples and various modifications are possible within the scope thereof, it can be confirmed that a person skilled in the art can obviously understand and realize them.
[0343] The management reporting module (190) can collect and analyze external input data, including usage log data and audience social media reactions, after each performance to evaluate lighting operations and automatically generate a report containing plans to improve the lighting configuration for the next performance.
[0344] More specifically, the management reporting module (190) analyzes external input data including lighting equipment usage log data, lighting control history, power usage information, and audience social media reaction data collected after the end of the performance to evaluate the effectiveness of lighting operation based on the difference between the actual lighting operation results and the lighting design package or lighting operation plan, thereby generating a post-evaluation result, and can output a report that automatically generates a plan for improving the lighting configuration for the next performance, including changes to the lighting equipment configuration, adjustment of lighting attributes, or improvement of the operation plan, based on the post-evaluation result.
[0346] FIG. 3 is a flowchart of a lighting operation agency service system based on a performance venue environment profile according to one embodiment of the present invention.
[0347] Referring to FIG. 3, a method for customized lighting design and operation service based on performance content data analysis and a method for providing customized lighting operation service for each performance based on performance content and performance venue environment information according to an embodiment of the present invention may include the steps of quantifying lighting pattern requirements (S110), generating a lighting needs mapping matrix (S130), automatically recommending a plurality of lighting design packages (S150), generating and providing a lighting rearrangement plan (S170), and automatically generating a report (S190).
[0348] The step of quantifying lighting pattern requirements (S110) receives performance data including a performance script, music timeline, actor movement, and stage scene composition information provided by a performance production company terminal (500), structures the performance data by scene, and can quantify lighting pattern requirements according to the emotion, atmosphere, and key action of each scene.
[0349] The step of generating a lighting needs mapping matrix (S130) can generate a role-specific lighting needs mapping matrix that defines the attributes of lighting required for each role within the performance based on the lighting pattern requirements quantified from the step of quantifying lighting pattern requirements (S110).
[0350] The step of automatically recommending multiple lighting design packages (S150) can automatically recommend multiple lighting design packages including the type, quantity, and placement location of lighting equipment by considering the role-specific lighting needs mapping matrix generated by the step of generating a lighting needs mapping matrix (S130) and the performance budget included in the performance data received from the performance production company terminal (500).
[0351] The step of generating and providing a lighting relocation plan (S170) can modify the existing lighting operation plan received in real time and generate and provide a lighting relocation plan in response to unexpected situations, including scene changes, additional performances, and special events occurring during the performance period equipped with the lighting design packages recommended by the step of automatically recommending multiple lighting design packages (S150).
[0352] The step of automatically generating a report (S190) can automatically generate a report containing plans to improve the lighting configuration for the next performance by collecting and analyzing external input data, including usage log data and audience social media reactions, after each performance.
[0354] The embodiments described above are for illustrative purposes only, and those skilled in the art will understand that the embodiments described above can be easily modified into other specific forms without altering the technical concept or essential features of the embodiments described above. Therefore, the embodiments described above should be understood as illustrative in all respects and not restrictive. For example, each component described as a single unit may be implemented in a distributed manner, and components described as distributed may likewise be implemented in a combined form.
[0356] The scope of protection sought through this specification is defined by the claims set forth below rather than by the detailed description, and should be interpreted to include all modifications or variations derived from the meaning and scope of the claims and the concept of equivalents. Explanation of the symbols
[0357] 100: Management Server
Claims
Claim 1 A lighting operation agency service system based on a performance venue environment profile comprises: a database that stores and manages unique environmental information of each performance venue under management in a standardized data format; and a management server that manages lighting design and operation plans for the entire performance cycle based on performance data and controls lighting consoles according to said operation plans; wherein the management server includes: a data collection module that receives performance data including performance scripts, music timelines, actor movements, and stage scene composition information provided by a performance production company terminal, structures the performance data by scene, and quantifies lighting pattern requirements based on emotions, atmospheres, and key actions for each scene; a needs mapping module that generates a role-specific lighting needs mapping matrix that defines lighting attributes required for each role within the performance based on the lighting pattern requirements quantified by the data collection module; a lighting recommendation module that automatically recommends multiple lighting design packages including the type, quantity, and placement location of lighting equipment, considering the role-specific lighting needs mapping matrix generated by the needs mapping module and the performance budget included in the performance data received from the performance production company terminal; and an event occurring during the performance period equipped with the lighting design packages recommended by the lighting recommendation module It includes an operation layout module that modifies existing lighting operation plans received in real time and generates and provides lighting relocation plans in response to unexpected situations, including scene changes, additional performances, and special events; and a management reporting module that evaluates lighting operations by collecting and analyzing external input data, including usage log data and audience social media reactions, after each performance, and automatically generates a report containing plans to improve lighting configuration for the next performance; wherein the database includes structural information of the performance venue (ceiling height, stage size), equipment information (types, status, and DMX channels of lighting equipment owned), and power information (total power capacity, outlet locations).The method is characterized by constructing an environment profile for each performance venue that includes installation condition information (possible lighting installation locations, light reflectivity), and each role within the performance is defined as an independent lighting requirement unit subject to lighting control based on at least one of the narrative importance, frequency of appearance, range of movement, and emotional changes per scene for each role unit, as a result of the needs mapping module classifying elements appearing in the performance into multiple role units including at least one of lead actor, supporting actor, ensemble, stage background, prop area, and instrument part based on the performance data structured by the data collection module. The needs mapping module is characterized by defining the lighting required for each role unit as a set of lighting attribute parameters including at least one of brightness, color, color temperature, illumination angle, focusing area, movement path, illumination time, and effect pattern, and is configured to generate a lighting needs mapping matrix for each role by mapping the set of lighting attribute parameters by scene unit. The lighting attributes are defined by the needs mapping module as brightness, color, color temperature, illumination angle, focusing area, and movement It includes at least one of a path, an illumination time, and an effect pattern, and the lighting recommendation module generates a plurality of lighting design combinations using the role-specific lighting needs mapping matrix and performance budget information as input values, with the type, quantity, placement location, and scene-specific usage frequency of lighting equipment as variables, and for each generated lighting design combination, calculates at least one of budget suitability, lighting needs satisfaction, and equipment utilization efficiency as an evaluation indicator to generate a lighting design evaluation result, and recommends a plurality of lighting design packages using artificial intelligence that performs learning or rule-based computation to automatically recommend a plurality of lighting design packages according to the lighting design evaluation result, and the operation placement module includes scene change information input during the performance,The method is characterized by detecting or receiving additional performance information or special event occurrence information in real time, comparing and analyzing the previously stored lighting operation plan with the change information, recalculating at least one of the activation sequence, placement location, or control parameter of lighting equipment in response to the changed scene or event, and generating and providing a modified lighting operation plan and a corresponding lighting relocation plan in real time; the management reporting module analyzes external input data including lighting equipment usage log data, lighting control history, power usage information, and audience social media reaction data collected after the end of the performance, evaluates the effectiveness of lighting operation based on the difference between the actual lighting operation results and the lighting design package or lighting operation plan to generate a post-evaluation result, and outputs a report that automatically generates a lighting configuration improvement plan for the next performance, including changes to lighting equipment configuration, adjustments to lighting attributes, or improvements to the operation plan, based on the post-evaluation result; and the data collection module, when the scene-unit quantification work is delayed, the quantification time required (t, quan Number of scenes processed (n) quan By using the value divided by ), performance scale bias is reduced even when the total time becomes long due to a large number of scenes, and the number of items requiring correction (m quan Number of scenes processed (n) quan Determining whether to additionally collect performance data by utilizing a data request judgment control algorithm characterized by being configured to distinguish between cases where it is slow due to a large amount of computation and cases where it is slow due to frequent corrections caused by missing or ambiguous input data, using a value divided by ). The data request judgment control algorithm includes a first element designed so that the calculated value increases as quantification proceeds at a speed slower than the standard, and a second element designed so that the calculated value increases as corrections occur frequently due to missing or ambiguous input performance data, wherein the first element is the quantification time (t quan Number of scenes processed (n) quan The result of dividing by ) based on the quantification time per scene (t limit Divided by ), and based on quantification time per scene (t limit Add 1 to the result divided by ), input it into the logarithmic function, and for the result of the logarithmic function, the time weight (w quan1 It is characterized by being configured to multiply by ), and the second element is the number of items requiring correction (m quan Number of scenes processed (n) quan Add 1 to the result of the value divided by ), input it into the logarithmic function, and apply the correction weight (w) to the result of the logarithmic function quan2 A performance venue environment profile-based lighting operation agency service system characterized by being configured to multiply ). Claim 2 delete
Citation Information
Patent Citations
Central server and dramatic performance system including same
EP3726491A1
Integration management system for performance directing
KR101617168B1
Emergence device using control console for stage apparatus
KR1020160011860A
Light emitting device for performing light emission suitable for a sound source being output externally and light emitting control device for controlling the light emission
KR1020230104823A
Management system for performance directing
KR101687189B1