The boundary vector field (BVF) is an external force for parametric active contours (i.e. Snakes). In the fields of computer vision and image processing, parametric active contours are widely used for segmentation and object extraction. The active contours move progressively towards its target based on the external forces. There are a number of shortcomings in using the traditional external forces, including the capture range problem, the concave object extraction problem, and high computational requirements. The BVF is generated by an interpolation scheme which reduces the computational requirement significantly, and at the same time, improves the capture range and concave object extraction capability. The BVF is also tested in moving object tracking and is proven to provide fast detection method for real time video applications.
Principle of rationality
The principle of rationality (or rationality principle) was coined by Karl R. Popper in his Harvard Lecture of 1963, and published in his book Myth of Framework. It is related to what he called the 'logic of the situation' in an Economica article of 1944/1945, published later in his book The Poverty of Historicism. According to Popper's rationality principle, agents act in the most adequate way according to the objective situation. It is an idealized conception of human behavior which he used to drive his model of situational analysis. Cognitive scientist Allen Newell elaborated on the principle in his account of knowledge level modeling. == Popper == Popper called for social science to be grounded in what he called situational analysis or situational logic. This requires building models of social situations which include individual actors and their relationship to social institutions, e.g. markets, legal codes, bureaucracies, etc. These models attribute certain aims and information to the actors. This forms the 'logic of the situation', the result of reconstructing meticulously all circumstances of an historical event. The 'principle of rationality' is the assumption that people are instrumental in trying to reach their goals, and this is what drives the model. Popper believed that this model could be continuously refined to approach the objective truth. Popper called his principle of rationality nearly empty (a technical term meaning without empirical content) and strictly speaking false, but nonetheless tremendously useful. These remarks earned him a lot of criticism because seemingly he had swerved from his famous Logic of Scientific Discovery. Among the many philosophers having discussed Popper's principle of rationality from the 1960s up to now are Noretta Koertge, R. Nadeau, Viktor J. Vanberg, Hans Albert, E. Matzner, Ian C. Jarvie, Mark A. Notturno, John Wettersten, Ian C. Böhm. == Newell == In the context of knowledge-based systems, Newell (in 1982) proposed the following principle of rationality: "If an agent has knowledge that one of its actions will lead to one of its goals, then the agent will select that action." This principle is employed by agents at the knowledge level to move closer to a desired goal. An important philosophical difference between Newell and Popper is that Newell argued that the knowledge level is real in the sense that it exists in nature and is not made up. This allowed Newell to treat the rationality principle as a way of understanding nature and avoid the problems Popper ran into by treating knowledge as non physical and therefore non empirical.
Line integral convolution
In scientific visualization, line integral convolution (LIC) is a method to visualize a vector field (such as fluid motion) at high spatial resolutions. The LIC technique was first proposed by Brian Cabral and Leith Casey Leedom in 1993. In LIC, discrete numerical line integration is performed along the field lines (curves) of the vector field on a uniform grid. The integral operation is a convolution of a filter kernel and an input texture, often white noise. In signal processing, this process is known as a discrete convolution. == Overview == Traditional visualizations of vector fields use small arrows or lines to represent vector direction and magnitude. This method has a low spatial resolution, which limits the density of presentable data and risks obscuring characteristic features in the data. More sophisticated methods, such as streamlines and particle tracing techniques, can be more revealing but are highly dependent on proper seed points. Texture-based methods, like LIC, avoid these problems since they depict the entire vector field at point-like (pixel) resolution. Compared to other integration-based techniques that compute field lines of the input vector field, LIC has the advantage that all structural features of the vector field are displayed, without the need to adapt the start and end points of field lines to the specific vector field. In other words, it shows the topology of the vector field. In user testing, LIC was found to be particularly good for identifying critical points. == Algorithm == === Informal description === LIC causes output values to be strongly correlated along the field lines, but uncorrelated in orthogonal directions. As a result, the field lines contrast each other and stand out visually from the background. Intuitively, the process can be understood with the following example: the flow of a vector field can be visualized by overlaying a fixed, random pattern of dark and light paint. As the flow passes by the paint, the fluid picks up some of the paint's color, averaging it with the color it has already acquired. The result is a randomly striped, smeared texture where points along the same streamline tend to have a similar color. Other physical examples include: whorl patterns of paint, oil, or foam on a river visualisation of magnetic field lines using randomly distributed iron filings fine sand being blown by strong wind === Formal mathematical description === Although the input vector field and the result image are discretized, it pays to look at it from a continuous viewpoint. Let v {\displaystyle \mathbf {v} } be the vector field given in some domain Ω {\displaystyle \Omega } . Although the input vector field is typically discretized, we regard the field v {\displaystyle \mathbf {v} } as defined in every point of Ω {\displaystyle \Omega } , i.e. we assume an interpolation. Streamlines, or more generally field lines, are tangent to the vector field in each point. They end either at the boundary of Ω {\displaystyle \Omega } or at critical points where v = 0 {\displaystyle \mathbf {v} =\mathbf {0} } . For the sake of simplicity, critical points and boundaries are ignored in the following. A field line σ {\displaystyle {\boldsymbol {\sigma }}} , parametrized by arc length s {\displaystyle s} , is defined as d σ ( s ) d s = v ( σ ( s ) ) | v ( σ ( s ) ) | . {\displaystyle {\frac {d{\boldsymbol {\sigma }}(s)}{ds}}={\frac {\mathbf {v} ({\boldsymbol {\sigma }}(s))}{|\mathbf {v} ({\boldsymbol {\sigma }}(s))|}}.} Let σ r ( s ) {\displaystyle {\boldsymbol {\sigma }}_{\mathbf {r} }(s)} be the field line that passes through the point r {\displaystyle \mathbf {r} } for s = 0 {\displaystyle s=0} . Then the image gray value at r {\displaystyle \mathbf {r} } is set to D ( r ) = ∫ − L / 2 L / 2 k ( s ) N ( σ r ( s ) ) d s {\displaystyle D(\mathbf {r} )=\int _{-L/2}^{L/2}k(s)N({\boldsymbol {\sigma }}_{\mathbf {r} }(s))ds} where k ( s ) {\displaystyle k(s)} is the convolution kernel, N ( r ) {\displaystyle N(\mathbf {r} )} is the noise image, and L {\displaystyle L} is the length of field line segment that is followed. D ( r ) {\displaystyle D(\mathbf {r} )} has to be computed for each pixel in the LIC image. If carried out naively, this is quite expensive. First, the field lines have to be computed using a numerical method for solving ordinary differential equations, like a Runge–Kutta method, and then for each pixel the convolution along a field line segment has to be calculated. The final image will normally be colored in some way. Typically, some scalar field in Ω {\displaystyle \Omega } (like the vector length) is used to determine the hue, while the grayscale LIC output determines the brightness. Different choices of convolution kernels and random noise produce different textures; for example, pink noise produces a cloudy pattern where areas of higher flow stand out as smearing, suitable for weather visualization. Further refinements in the convolution can improve the quality of the image. === Programming description === Algorithmically, LIC takes a vector field and noise texture as input, and outputs a texture. The process starts by generating in the domain of the vector field a random gray level image at the desired output resolution. Then, for every pixel in this image, the forward and backward streamline of a fixed arc length is calculated. The value assigned to the current pixel is computed by a convolution of a suitable convolution kernel with the gray levels of all the noise pixels lying on a segment of this streamline. This creates a gray level LIC image. == Versions == === Basic === Basic LIC images are grayscale images, without color and animation. While such LIC images convey the direction of the field vectors, they do not indicate orientation; for stationary fields, this can be remedied by animation. Basic LIC images do not show the length of the vectors (or the strength of the field). === Color === The length of the vectors (or the strength of the field) is usually coded in color; alternatively, animation can be used. === Animation === LIC images can be animated by using a kernel that changes over time. Samples at a constant time from the streamline would still be used, but instead of averaging all pixels in a streamline with a static kernel, a ripple-like kernel constructed from a periodic function multiplied by a Hann function acting as a window (in order to prevent artifacts) is used. The periodic function is then shifted along the period to create an animation. === Fast LIC (FLIC) === The computation can be significantly accelerated by re-using parts of already computed field lines, specializing to a box function as convolution kernel k ( s ) {\displaystyle k(s)} and avoiding redundant computations during convolution. The resulting fast LIC method can be generalized to convolution kernels that are arbitrary polynomials. === Oriented Line Integral Convolution (OLIC) === Because LIC does not encode flow orientation, it cannot distinguish between streamlines of equal direction but opposite orientation. Oriented Line Integral Convolution (OLIC) solves this issue by using a ramp-like asymmetric kernel and a low-density noise texture. The kernel asymmetrically modulates the intensity along the streamline, producing a trace that encodes orientation; the low-density of the noise texture prevents smeared traces from overlapping, aiding readability. Fast Rendering of Oriented Line Integral Convolution (FROLIC) is a variation that approximates OLIC by rendering each trace in discrete steps instead of as a continuous smear. === Unsteady Flow LIC (UFLIC) === For time-dependent vector fields (unsteady flow), a variant called Unsteady Flow LIC has been designed that maintains the coherence of the flow animation. An interactive GPU-based implementation of UFLIC has been presented. === Parallel === Since the computation of an LIC image is expensive but inherently parallel, the process has been parallelized and, with availability of GPU-based implementations, interactive on PCs. === Multidimensional === Note that the domain Ω {\displaystyle \Omega } does not have to be a 2D domain: the method is applicable to higher dimensional domains using multidimensional noise fields. However, the visualization of the higher-dimensional LIC texture is problematic; one way is to use interactive exploration with 2D slices that are manually positioned and rotated. The domain Ω {\displaystyle \Omega } does not have to be flat either; the LIC texture can be computed also for arbitrarily shaped 2D surfaces in 3D space. == Applications == This technique has been applied to a wide range of problems since it first was published in 1993, both scientific and creative, including: Representing vector fields: visualization of steady (time-independent) flows (streamlines) visual exploration of 2D autonomous dynamical systems wind mapping water flow mapping Artistic effects for image generation and stylization: pencil drawing (auto
Thunderspy
Thunderspy is a type of security vulnerability, based on the Intel Thunderbolt 3 port, first reported publicly on 10 May 2020, that can result in an evil maid (i.e., attacker of an unattended device) attack gaining full access to a computer's information in about five minutes, and may affect millions of Apple, Linux and Windows computers, as well as any computers manufactured before 2019, and some after that. According to Björn Ruytenberg, the discoverer of the vulnerability, "All the evil maid needs to do is unscrew the backplate, attach a device momentarily, reprogram the firmware, reattach the backplate, and the evil maid gets full access to the laptop. All of this can be done in under five minutes." The malicious firmware is used to clone device identities which makes classical DMA attack possible. == History == The Thunderspy security vulnerabilities were first publicly reported by Björn Ruytenberg of Eindhoven University of Technology in the Netherlands on 10 May 2020. Thunderspy is similar to Thunderclap, another security vulnerability, reported in 2019, that also involves access to computer files through the Thunderbolt port. == Impact == The security vulnerability affects millions of Apple, Linux and Windows computers, as well as all computers manufactured before 2019, and some after that. However, this impact is restricted mainly to how precise a bad actor would have to be to execute the attack. Physical access to a machine with a vulnerable Thunderbolt controller is necessary, as well as a writable ROM chip for the Thunderbolt controller's firmware. Additionally, part of Thunderspy, specifically the portion involving re-writing the firmware of the controller, requires the device to be in sleep, or at least in some sort of powered-on state, to be effective. Machines that force power-off when the case is open may assist in resisting this attack to the extent that the feature (switch) itself resists tampering. Due to the nature of attacks that require extended physical access to hardware, it's unlikely the attack will affect users outside of a business or government environment. == Mitigation == The researchers claim there is no easy software solution, and may only be mitigated by disabling the Thunderbolt port altogether. However, the impacts of this attack (reading kernel level memory without the machine needing to be powered off) are largely mitigated by anti-intrusion features provided by many business machines. Intel claims enabling such features would substantially restrict the effectiveness of the attack. Microsoft's official security recommendations recommend disabling sleep mode while using BitLocker. Using hibernation in place of sleep mode turns the device off, mitigating potential risks of attack on encrypted data.
Common Image Generator Interface
The Common Image Generator Interface (CIGI) (pronounced sig-ee), is an on-the-wire data protocol that allows communication between an Image Generator and its host simulation. The interface is designed to promote a standard way for a host device to communicate with an image generator (IG) within the industry. CIGI enables plug-and-play by standard-compliant image generator vendors and reduces integration costs when upgrading visual systems. == Background == Most high-end simulators do not have everything running on a single machine the way popular home software flight simulators are currently implemented. The airplane model is run on one machine, normally referred to as the host, and the out the window visuals or scene graph program is run on another, usually referred to as an Image Generator (IG). Frequently there are multiple IGs required to display the surrounding environment created by a host. CIGI is the interface between the 'host' and the IGs. The main goal of CIGI is to capitalize on previous investments through the use of a common interface. CIGI is designed to assist suppliers and integrators of IG systems with ease of integration, code reuse, and overall cost reduction. In the past most image generators provided their own proprietary interface; every host had to implement that interface making changing image generators a costly ordeal. CIGI was created to standardize the interface between the host and the image generator so that little modification would be needed to switch image generators. The CIGI initiative was largely spearheaded by The Boeing Company during the early 21st century. The latest version of CIGI (CIGI 4.0) was developed by the Simulation Interoperability Standards Organization (SISO) in the form of SISO-STD-013-2014, Standard for Common Image Generator Interface (CIGI), Version 4.0, dated 22 August 2014. SISO-STD-013-2014 is freely available from SISO. == Definitions == Image generator – In this context an image generator consists of one or more rendering channels that produce an image that can be used to visualize an “Out-The-Window” scene, or images produced by various sensor simulations such as Infra-red, Day TV, electro-optical, and night vision. Host simulation – In this context a “Host” is the computational system that provides information about the device being simulated so that the image generator can portray the correct scenery to the user. This information is passed via CIGI to the image generator. == Maturation == CIGI 4 is the latest version of the standard as was approved by the Simulation Interoperability Standards Organization on August 22, 2014. CIGI became an international SISO standard known as SISO-STD-013-2014; which contains the CIGI version 4.0 Interface Control Document (ICD). CIGI 4.0 is the official standard, published by SISO. Previous versions of CIGI were spearheaded by Boeing include CIGI v3.3, in November 2008, v3.2 April 2006, v3.1 June 2004, v3 November 2003, v2 in March 2002, and the original (v1) in March 2001 == Protocol dependencies == Typically, CIGI uses UDP as its transport protocol, but CIGI does not require a specific transport mechanism, only packet definition conformance. CIGI traffic does not have a well known port; however, the use of ports 8004-8005 has been widely adopted by commercial image generator vendors implementations. == Development tools == === Host Emulator === The Host Emulator can be used as a surrogate to manipulate the interface when a simulation Host is not available. It is a Windows-based image generator Host application used to develop, integrate and test image generators that use the CIGI protocol. It provides a graphical user interface (GUI) for the creation, modification and deletion of entities; manipulation of views; control of environmental attributes and phenomena; and other host functions. The Host Emulator has several features that are useful for integration and testing. A free-flight mode allows for fixed-wing and rotorcraft flight, movement along entity axes and free rotation using a joystick or a joystick-like widget. Scripting and record/playback features support regression testing, demonstrations and other tasks needing exact reproduction of certain sequences of events. A packet-level snoop feature allows the user to examine the contents of CIGI messages, image generator response times and latencies. A Heartbeat Monitor Window shows a graphical timing history of the Image Generator's data frame rate. Other features include explicit packet creation, animation control, missile flyouts and a situation display window (Host Emulator 3.x only). === Multi-Purpose Viewer === The Multi-Purpose Viewer (MPV) provides the basic functionality expected of an Image Generator, such as loading and displaying a terrain database, displaying entities and so forth. The Multi-Purpose Viewer can be used as a surrogate to manipulate the interface when a real Image Generator is not available. The MPV is capable of operating with both the Windows and Linux operating systems. === CIGI Class Library === The CCL is an object-oriented software interface that automatically handles message composition and decomposition (i.e. packing, unpacking and byte swapping to the ICD specification) on both the Host and Image Generator sides of the interface. The CCL interprets Host or Image Generator messages based on compile time parameters. It also performs error handling and translation between different versions of CIGI. Each packet type has its own class. The individual packet members are accessed through packet class accessors. Outgoing messages are constructed by placing each packet into the outgoing buffer using a streaming operator. Incoming messages are parsed using callback or event-based mechanisms that supply the using program with fully populated packet objects. === Current tool suite === A set of CIGI development tools are managed and maintained by the SISO CIGI Product Support Group. The latest packages are available on SourceForge. Comments/Suggestions to the package can be directed to the SISO discussion board at: https://discussions.sisostds.org/index.htm?A0=SAC-PSG-CIGI Archived 2017-09-13 at the Wayback Machine === Wireshark === Wireshark is a free and open source packet analyzer. It is used for network troubleshooting, analysis, software and communications protocol development, and education. Wireshark provides a dissector for CIGI packets. As of October 2016, “The CIGI dissector is fully functional for CIGI version 2 and 3. Version 1 is not yet implemented.” === Older versions of CIGI === A CIGI Interface Control Document (ICD) and development suite is available in open source format. The tools, ICD, and accompanying user documentation can be found and downloaded from the CIGI sourceforge web site. The SourceForge version of the MPV is limited in its support of CIGI data packets and is intended to grow as needs arise. The MPV uses CIGI 3 as its interface, but the MPV is backward-compatible with earlier CIGI versions through the use of the CCL. The MPV uses the Open Scene Graph library to render a scene. The scene graph is manipulated according to the CIGI commands received from the Host via the CCL. The MPV itself is an application layer that consists of a small kernel leveraging heavily on a plug-in architecture for ease of maintainability and flexibility. An implementer can implement the interface from scratch, however a full suite of integration tools is available. These tools consist of three elements. The Host Emulator (HE), the Multi-Purpose Viewer (MPV), and the CIGI Class Library (CCL).
Database dump
A database dump contains a record of the table structure and/or the data from a database and is usually in the form of a list of SQL statements ("SQL dump"). A database dump is most often used for backing up a database so that its contents can be restored in the event of data loss. Corrupted databases can often be recovered by analysis of the dump. Database dumps are often published by free content projects, to facilitate reuse, forking, offline use, and long-term digital preservation. Dumps can be transported into environments with Internet blackouts or otherwise restricted Internet access, as well as facilitate local searching of the database using sophisticated tools such as grep.
Glow (app)
Glow is a fertility awareness and period-tracking app. It is part of a suite of mobile apps focused on women's reproductive health and childcare, which includes Eve by Glow (a dedicated period tracker), Glow Nurture (a pregnancy tracker), and Glow Baby (a baby development tracker). The Glow company also operates an online shop that sells several fertility-related products, including ovulation test strips, pregnancy tests, and wearable breast pumps. In 2024, Glow was reported to have approximately 25 million users across its various apps and community message boards. == History == Glow debuted in August 2013 as an iOS app. It was founded by Michael Huang and Max Levchin and launched with $6 million in Series A funding from venture capital firms Founders Fund and Andreesen Horowitz. In 2014, Glow raised an additional $17 million in Series B funding, with Formation 8 joining existing investors. In 2015, Glow launched Ruby, an app dedicated to sexual health. That year, Wired reported that the company had added features to their apps allowing men to monitor their fertility. Glow subsequently released an additional set of apps focused on pregnancy tracking and infant development. In 2016, Glow reported that it had a total of approximately 3 million users; by 2018, this had grown to 15 million. Vox described it as one of the “big two” period and fertility tracking apps and the one that had started the “boom” in the femtech space. == Application and features == Glow was initially described as a fertility application that applied data-driven methods to menstrual and ovulation tracking. Core features include cycle logging, ovulation prediction, and symptom tracking. The app also provides educational content related to reproductive health and childcare, as well as a set of online message boards that allow individuals to share experiences and seek peer support. == Privacy and legal issues == Glow has received significant media attention for its privacy and security practices. In 2016, Consumer Reports identified potential exploits in the Glow app that they claimed could have exposed private user data to hackers. Glow subsequently reported that it had fixed the vulnerabilities and told The Washington Post they had no evidence that user data had been compromised. In September 2020, the California Attorney General announced a settlement with Glow related to Consumer Reports’ findings, which included a $250,000 civil penalty. Following the US Supreme Court's 2022 Dobbs v. Jackson ruling, which legalized state-level bans on abortion, Glow (and other fertility trackers, such as Clue and Flo) came under additional scrutiny over concerns that user data on abortions could be reported to law enforcement. After this surge of media interest, a research team affiliated with the University of New South Wales conducted an investigation into the privacy practices of several popular fertility apps, including Glow. Their review of Glow was mixed, noting that they provided several privacy settings and de-identified sensitive data, but that user information could still be disclosed in the future if the app was sold. Glow rejected that claim, telling the Australian Associated Press that it "did not share" personal data. The company also cited several internal security measures it had implemented and its apps' offline data protection setting, which allows users to permanently delete their health-related data. == Reception == In 2014, Fast Company reported that 20,000 women had used Glow to conceive. Later that year, The Guardian included Glow Nurture on its list of the best iPhone apps of 2014. Media coverage often praised Glow's array of menstrual tracking options, although some reviews also noted that fertility apps are not birth control tools and cautioned against relying on them for that purpose. In 2019, Cosmopolitan singled Glow's community of users as one of its standout features.