A stencil buffer is an extra data buffer, in addition to the color buffer and Z-buffer, found on modern graphics hardware. The buffer is per pixel and works on integer values, usually with a depth of one byte per pixel. The Z-buffer and stencil buffer often share the same area in the RAM of the graphics hardware. In the simplest case, the stencil buffer is used to limit the area of rendering (stenciling). More advanced usage of the stencil buffer makes use of the strong connection between the Z-buffer and the stencil buffer in the rendering pipeline. For example, stencil values can be automatically increased/decreased for every pixel that fails or passes the depth test. The simple combination of depth test and stencil modifiers make a vast number of effects possible (such as stencil shadow volumes, Two-Sided Stencil, compositing, decaling, dissolves, fades, swipes, silhouettes, outline drawing, or highlighting of intersections between complex primitives) though they often require several rendering passes and, therefore, can put a heavy load on the graphics hardware. The most typical application is still to add shadows to 3D applications. It is also used for planar reflections. Other rendering techniques, such as portal rendering, use the stencil buffer in other ways; for example, it can be used to find the area of the screen obscured by a portal and re-render those pixels correctly. The stencil buffer and its modifiers can be accessed in computer graphics by using APIs like OpenGL, Direct3D, Vulkan or Metal. == Architecture == The stencil buffer typically shares the same memory space as the Z-buffer, and typically the ratio is 24 bits for Z-buffer + 8 bits for stencil buffer or, in the past, 15 bits for Z-buffer + 1 bit for stencil buffer. Another variant is 4 + 24, where 28 of the 32 bits are used and 4 ignored. Stencil and Z-buffers are part of the frame buffer, coupled to the color buffer. The first chip available to a wider market was 3Dlabs' Permedia II, which supported a one-bit stencil buffer. The bits allocated to the stencil buffer can be used to represent numerical values in the range [0, 2n-1], and also as a Boolean matrix (n is the number of allocated bits), each of which may be used to control the particular part of the scene. Any combination of these two ways of using the available memory is also possible. == Stencil test == Stencil test or stenciling is among the operations on the pixels/fragments (Per-pixel operations), located after the alpha test, and before the depth test. The stencil test ensures undesired pixels do not reach the depth test. This saves processing time for the scene. Similarly, the alpha test can prevent corresponding pixels to reach the stencil test. The test itself is carried out over the stencil buffer to some value in it, or altered or used it, and carried out through the so-called stencil function and stencil operations. The stencil function is a function by which the stencil value of a certain pixel is compared to a given reference value. If this comparison is logically true, the stencil test passes. Otherwise not. In doing so, the possible reaction caused by the result of comparing three different state-depth and stencil buffer: Stencil test is not passed Stencil test is passed but not the depth test Both tests are passed (or stencil test is passed, and the depth is not enabled) For each of these cases, different operations can be set over the examined pixel. In the OpenGL stencil functions, the reference value and mask, respectively, define the function glStencilFunc. In Direct3D each of these components is adjusted individually using methods SetRenderState devices currently in control. This method expects two parameters, the first of which is a condition that is set and the other its value. In the order that was used above, these conditions are called D3DRS_STENCILFUNC, D3DRS_STENCILREF, and D3DRS_STENCILMASK. Stencil operations in OpenGL adjust glStencilOp function that expects three values. In Direct3D, again, each state sets a specific method SetRenderState. The three states that can be assigned to surgery are called D3DRS_STENCILFAIL, D3DRENDERSTATE_STENCILZFAIL, and D3DRENDERSTATE_STENCILPASS. == Z-fighting == Due to the lack of precision in the Z-buffer, coplanar polygons that are short-range, or overlapping, can be portrayed as a single plane with a multitude of irregular cross-sections. These sections can vary depending on the camera position and other parameters and are rapidly changing. This is called Z-fighting. There exist multiple solutions to this issue: - Bring the far plane closer to restrict the scene's depth, thus increasing the accuracy of the Z-buffer, or reducing the distance at which objects are visible in the scene. - Increase the number of bits allocated to the Z-buffer, which is possible at the expense of memory for the stencil buffer. - Move polygons farther apart from one another, which restricts the possibilities for the artist to create an elaborate scene. All of these approaches to the problem can only reduce the likelihood that the polygons will experience Z-fighting, and do not guarantee a definitive solution in the general case. A solution that includes the stencil buffer is based on the knowledge of which polygon should be in front of the others. The silhouette of the front polygon is drawn into the stencil buffer. After that, the rest of the scene can be rendered only where the silhouette is negative, and so will not clash with the front polygon. == Shadow volume == Shadow volume is a technique used in 3D computer graphics to add shadows to a rendered scene. They were first proposed by Frank Crow in 1977 as the geometry describing the 3D shape of the region occluded from a light source. A shadow volume divides the virtual world in two: areas that are in shadow and areas that are not. The stencil buffer implementation of shadow volumes is generally considered among the most practical general-purpose real-time shadowing techniques for use on modern 3D graphics hardware. It has been popularised by the video game Doom 3, and a particular variation of the technique used in this game has become known as Carmack's Reverse. == Reflections == Reflection of a scene is drawn as the scene itself transformed and reflected relative to the "mirror" plane, which requires multiple render passes and using of stencil buffer to restrict areas where the current render pass works: Draw the scene excluding mirror areas – for each mirror lock the Z-buffer and color buffer Render visible part of the mirror Depth test is set up so that each pixel is passed to enter the maximum value and always passes for each mirror: Depth test is set so that it passes only if the distance of a pixel is less than the current (default behavior) The matrix transformation is changed to reflect the scene relative to the mirror plane Unlock the Z-buffer and color buffer Draw the scene, but only the part of it that lies between the mirror plane and the camera. In other words, a mirror plane is also a clipping plane Again locks color buffer, depth test is set so that it always passes, reset stencil for the next mirror. == Planar Shadows == While drawing a plane of shadows, there are two dominant problems: The first concerns the problem of deep struggle in case the flat geometry is not awarded on the part covered with the shadow of shadows and outside. See the section that relates to this. Another problem relates to the extent of the shadows outside the area where the plane there. Another problem, which may or may not appear, depending on the technique, the design of more polygons in one part of the shadow, resulting in darker and lighter parts of the same shade. All three problems can be solved geometrically, but because of the possibility that hardware acceleration is directly used, it is a far more elegant implementation using the stencil buffer: 1. Enable lights and the lights 2. Draw a scene without any polygon that should be projected shadows 3. Draw all polygons which should be projected shadows, but without lights. In doing so, the stencil buffer, the pixel of each polygon to be assigned to a specific value for the ground to which they belong. The distance between these values should be at least two, because for each plane to be used two values for two states: in the shadows and bright. 4. Disable any global illumination (to ensure that the next steps will affect only individual selected light) For each plane: For each light: 1. Edit a stencil buffer and only the pixels that carry a specific value for the selected level. Increase the value of all the pixels that are projected objects between the date of a given level and bright. 2. Allow only selected light for him to draw level at which part of her specific value was not changed. == Spatial shadows == Stencil buffer implementation of spatial drawing shadows is any shadow of a geometric body that its volume includes part of the scene that is
Textual case-based reasoning
Textual case-based reasoning (TCBR) is a subtopic of case-based reasoning, in short CBR, a popular area in artificial intelligence. CBR suggests the ways to use past experiences to solve future similar problems, requiring that past experiences be structured in a form similar to attribute-value pairs. This leads to the investigation of textual descriptions for knowledge exploration whose output will be, in turn, used to solve similar problems. == Subareas == Textual case-base reasoning research has focused on: measuring similarity between textual cases mapping texts into structured case representations adapting textual cases for reuse automatically generating representations.
Semantic analysis (knowledge representation)
Semantic analysis is a method for eliciting and representing knowledge about organisations. Initially the problem must be defined by domain experts and passed to the project analyst(s). The next step is the generation of candidate affordances. This step will generate a list of semantic units that may be included in the schema. The candidate grouping follows where some of the semantic units that will appear in the schema are placed in simple groups. Finally the groups will be integrated together into an ontology chart. Semantic analysis always starts from the problem definition which if not clear, require the analyst to employ relevant literature, interviews with the stakeholders and other techniques towards collecting supplementary information. All assumptions made must be genuine and not limiting the system.
Is-a
In knowledge representation, ontology components and ontology engineering, including for object-oriented programming and design, is-a (also written as is_a or is a) is a subsumptive relationship between abstractions (e.g., types, classes), wherein one class A is a subclass of another class B (and so B is a superclass of A). In other words, type A is a subtype of type B when A's specification implies B's specification. That is, any object (or class) that satisfies A's specification also satisfies B's specification, because B's specification is weaker. For example, a cat 'is a[n]' animal, but not vice versa. All cats are animals, but not all animals are cats. Behaviour that is relevant to all animals is defined on an animal class, whereas behaviour that is relevant only for cats is defined in a cat class. By defining the cat class as 'extending' the animal class, all cats 'inherit' the behaviour defined for animals, without the need to explicitly code that behaviour for cats. == Related concepts == The is-a relationship is to be contrasted with the has-a (has_a or has a) relationship between types (classes); confusing the relations has-a and is-a is a common error when designing a model (e.g., a computer program) of the real-world relationship between an object and its subordinate. The is-a relationship may also be contrasted with the instance-of relationship between objects (instances) and types (classes): see Type–token distinction. To summarize the relations, there are: hyperonym–hyponym (supertype/superclass–subtype/subclass) relations between types (classes) defining a taxonomic hierarchy, where for a subsumption relation: a hyponym (subtype, subclass) has a type-of (is-a) relationship with its hyperonym (supertype, superclass); holonym–meronym (whole/entity/container–part/constituent/member) relations between types (classes) defining a possessive hierarchy, where for an aggregation (i.e. without ownership) relation: a holonym (whole) has a has-a relationship with its meronym (part), for a composition (i.e. with ownership) relation: a meronym (constituent) has a part-of relationship with its holonym (entity), for a containment relation: a meronym (member) has a member-of relationship with its holonym (container); concept–object (type–token) relations between types (classes) and objects (instances), where a token (object) has an instance-of relationship with its type (class).
ITU-WHO Focus Group on Artificial Intelligence for Health
The ITU-WHO Focus Group on Artificial Intelligence for Health (AI for Health) was an inter-agency collaboration from 2018 between the World Health Organization and the ITU, which in 2019 created a benchmarking framework to assess the accuracy of AI in health. The organization convened an international network of experts and stakeholders from fields like research, practice, regulation, ethics, public health, etc, that developed guideline documentation and code. The documents have addressed ethics, assessment/evaluation, handling, and regulation of AI for health solutions, covering specific use cases including AI in ophthalmology, histopathology, dentistry, malaria detection, radiology, symptom checker applications, etc. FG-AI4H has established an ad hoc group concerned with digital technologies for health emergencies, including COVID-19. All documentation is public. The idea for the Focus Group came out of the Health Track of the 2018 AI for Good Global Summit. Administratively, FG-AI4H was created by ITU-T Study Group 16. Under ITU-T's framework, participation in Focus Groups is open to anyone from an ITU Member State. The secretariat is provided by the Telecommunication Standardization Bureau (under Director Chaesub Lee). It was first created at the July 2018 meeting with a lifetime of two years, at the July 2020 meeting, this was extended for another two years, where the focus group also submitted its deliverables to its parent body. It was also presented at the NeurIPS 2020 health workshop. In July 2023 "the work was grandfathered in the Global Initiative on AI for Health (GI-AI4H)". == AI for Health Framework == The outline of the benchmarking framework was published in a 2019 commentary in The Lancet. The output of the Focus Group AI for Health were structured in the AI for Health Framework. Depending on their primary domain being health or ICT, the individual components of the AI for Health Framework were ratified by the corresponding United Nations Specialized Agency, as WHO Guidelines and ITU Recommendations respectively. Standards drawn up by FG-AI4H were titled as: AI4H ethics considerations AI4H regulatory [best practices | considerations] AI4H requirements specification AI software life cycle specification Data specification AI training best practices specification AI4H evaluation considerations AI4H scale-up and adoption AI4H applications and platforms Use cases of the ITU-WHO Focus Group on AI for Health
Lexical choice
Lexical choice is the subtask of Natural language generation that involves choosing the content words (nouns, non-auxiliary verbs, adjectives, and adverbs) in a generated text. Function words (determiners, for example) are usually chosen during realisation. == Examples == The simplest type of lexical choice involves mapping a domain concept (perhaps represented in an ontology) to a word. For example, the concept Finger might be mapped to the word finger. A more complex situation is when a domain concept is expressed using different words in different situations. For example, the domain concept Value-Change can be expressed in many ways: The temperature rose: the verb rose is used for a Value-Change in temperature which increases the value. The temperature fell: the verb fell is used for a Value-Change in temperature which decreases the value. The rain got heavier: the phrase got heavier is used for a Value-Change in precipitation amount when the precipitation is rain. Sometimes words can communicate additional contextual information, for example: The temperature plummeted: the verb plummeted is used for a Value-Change in temperature which decreases the value, when the change is rapid and large. Contextual information is especially significant for vague terms such as tall. For example, a 2m tall man is tall, but a 2m tall horse is small. == Linguistic perspective == Lexical choice modules must be informed by linguistic knowledge of how the system's input data maps onto words. This is a question of semantics, but it is also influenced by syntactic factors (such as collocation effects) and pragmatic factors (such as context). Hence NLG systems need linguistic models of how meaning is mapped to words in the target domain (genre) of the NLG system. Genre tends to be very important; for example the verb veer has a very specific meaning in weather forecasts (wind direction is changing in a clockwise direction) which it does not have in general English, and a weather-forecast generator must be aware of this genre-specific meaning. In some cases there are major differences in how different people use the same word; for example, some people use by evening to mean 6PM and others use it to mean midnight. Psycholinguists have shown that when people speak to each other, they agree on a common interpretation via lexical alignment; this is not something which NLG systems can yet do. Ultimately, lexical choice must deal with the fundamental issue of how language relates to the non-linguistic world. For example, a system which chose colour terms such as red to describe objects in a digital image would need to know which RGB pixel values could generally be described as red; how this was influenced by visual (lighting, other objects in the scene) and linguistic (other objects being discussed) context; what pragmatic connotations were associated with red (for example, when an apple is called red, it is assumed to be ripe as well as have the colour red); and so forth. == Algorithms and models == A number of algorithms and models have been developed for lexical choice in the research community, for example Edmonds developed a model for choosing between near-synonyms (words with similar core meanings but different connotations). However such algorithms and models have not been widely used in applied NLG systems; such systems have instead often used quite simple computational models, and invested development effort in linguistic analysis instead of algorithm development.
Modular Audio Recognition Framework
Modular Audio Recognition Framework (MARF) is an open-source research platform and a collection of voice, sound, speech, text and natural language processing (NLP) algorithms written in Java and arranged into a modular and extensible framework that attempts to facilitate addition of new algorithms. MARF may act as a library in applications or be used as a source for learning and extension. A few example applications are provided to show how to use the framework. There is also a detailed manual and the API reference in the javadoc format as the project tends to be well documented. MARF, its applications, and the corresponding source code and documentation are released under the BSD-style license.