Linux color management has the same goal as the color management systems (CMS) for other operating systems, which is to achieve the best possible color reproduction throughout an imaging workflow from its source (camera, video, scanner, etc.), through imaging software (Digikam, darktable, RawTherapee, GIMP, Krita, Scribus, etc.), and finally onto an output medium (monitor, video projector, printer, etc.). In particular, color management attempts to enable color consistency across media and throughout a color-managed workflow. Linux color management relies on the use of accurate ICC (International Color Consortium) and DCP (DNG Color Profile) profiles describing the behavior of input and output devices, and color-managed applications that are aware of these profiles. These applications perform gamut conversions between device profiles and color spaces. Gamut conversions, based on accurate device profiles, are the essence of color management. Historically, color management was not an initial design consideration of the X Window System on which much of Linux graphics support rests, and thus color-managed workflows have been somewhat more challenging to implement on Linux than on other OS's such as Microsoft Windows or macOS. This situation is now being progressively remedied, and color management under Linux, while functional, has not yet acquired mature status. Although it is now possible to obtain a consistent color-managed workflow under Linux, certain problems still remain: The absence of a central user control panel for color settings. Some hardware devices for color calibration lack Linux drivers, firmware or accessory data. Since ICC color profiles are written to an open specification, they are compatible across operating systems. Hence, a profile produced on one OS should work on any other OS given the availability of the necessary software to read it and perform the gamut conversions. This can be used as a workaround for the lack of support for certain spectrophotometers or colorimeters under Linux: one can simply produce a profile on a different OS and then use it in a Linux workflow. Additionally, certain hardware, such as most printers and certain monitors, can be calibrated under another OS and then used in a fully color-managed workflow on Linux. The popular Ubuntu Linux distribution added initial color management in the 11.10 release (the "Oneiric Ocelot" release). == Requirements for a color-managed workflow == Accurate device profiles obtained with source or output characterization software. Correctly loaded video card lookup tables (LUTs) (or monitor profiles that do not require LUT adjustments). Color-managed applications that are configured to use a correct monitor profile and input/output profiles, with support for control over the rendering intent and black point compensation. Calibration and profiling requires: for input devices (scanner, camera, etc.) a color target which the profiling software will compare to the manufacturer-provided color values of the target. or for output devices (monitor, printer, etc.) a reading with a specific device (spectrophotometer, colorimeter or spectrocolorimeter) of the color patch values and comparing the measured values against the values originally sent for output. === Monitor calibration and profiling === One of the critical elements in any color-managed workflow is the monitor, because, at one step or another, handling and making color adaptation through imaging software is required for most images, thus the ability of the monitor to present accurate colors is crucial. Monitor color management consists of calibration and profiling. The first step, calibration, is done by adjusting the monitor controls and the output of the graphics card (via calibration curves) to match user-definable characteristics, such as brightness, white point and gamma. The calibration settings are stored in a .cal file. The second step, profiling (characterization), involves measuring the calibrated display's response and recording it in a color profile. The profile is stored in an .icc file ("ICC file"). For convenience, the calibration settings are usually stored together with the profile in the ICC file. Note that .icm files are identical to .icc files - the difference is only in the name. Seeing correct colors requires using a monitor profile-aware application, together with the same calibration used when profiling the monitor. Calibration alone does not yield accurate colors. If a monitor was calibrated before it was profiled, the profile will only yield correct colors when used on the monitor with the same calibration (the same monitor control adjustments and the same calibration curves loaded into the video card's lookup table). macOS has built-in support for loading calibration curves and installing a system-wide color profile. Windows 7 onward allows loading calibration curves, though this functionality must be enabled manually. Linux and older versions of Windows require using a standalone LUT loader. === Device profiles === ICC profiles are cross-platform and can thus be created on other operating systems and used under Linux. Monitor profiles, however, require some additional attention. Since a monitor profile depends both on the monitor itself and on the video card, a monitor profile should only be used with the same monitor and video card with which it was created. The monitor settings should not be adjusted after creating the profile. In addition, since most calibration software use LUT adjustments during calibration, the corresponding LUTs must be loaded every time the display server (X11, Wayland) is started (e.g. with every graphical login). In the unlikely case of a colorimeter being unsupported by Linux, a profile created under Windows or macOS can be used under Linux. === Display-channel lookup tables === There are two approaches to loading display channel LUTs: Create a profile that does not modify video card LUTs and thus does not require LUTs be loaded later on. Ideally, this approach would rely on DDC-capable monitors—the internal monitor settings of which are set via calibration software. Unfortunately, monitors capable of making these adjustments through DDC are not common and are generally expensive. There is only one calibration software on Linux that can interact with a DDC monitor. For mainstream monitors, a couple of options exist: BasICColor software, which works with most colorimeters on the market, allows one to adjust display output via the monitor interface, and then to choose a "Profile, do not calibrate" option. By doing this, one can create a profile that does not require video card LUT adjustments. For EyeOne devices, EyeOne Match allows the user to calibrate to "Native" gamma and white point targets, which results in the LUT adjustment curves displayed after the calibration as a simple, linear 1:1 mapping (a straight line from corner to corner). Both BasICColor and EyeOne Match do not presently run under Linux but they are capable of creating a profile that does not require LUT adjustments. Use an LUT loader to actually load the LUT adjustments contained within the profile prepared during calibration. According to the documentation, these loaders do not modify the video card LUT by itself, but achieve the same type of adjustment by modifying the X server gamma ramp. Loaders are available for Linux distributions that use X.org or XFree86—the two most popular X servers on Linux. Other X servers are not guaranteed to work with the currently available loaders. There are two LUT loaders available for Linux: Xcalib is one such loader, and although it is a command-line utility, it is quite easy to use. dispwin is a part of Argyll CMS. If, for any reason, the LUT cannot be loaded, it is still recommended to go through the initial stages of calibration where a user is asked by calibration software to make some manual adjustments to the monitor, as this will often improve display linearity and also provide information on its color temperature. This is especially recommended for CRT monitors. === Color-managed applications === In ICC-aware applications, it is important to make sure the correct profiles are assigned to devices, mainly to the monitor and the printer. Some Linux applications can auto-detect the monitor profile, while others requires that it is specified manually. Although there is no designated place to store device profiles on Linux, /usr/share/color/icc/ has become the de facto standard. Most applications running under WINE have not been fully tested for color accuracy. While 8-bpp programs can have some color resolution difficulties due to depth conversion errors, colors in higher-depth applications should be accurate, as long as those programs perform their gamut conversions based on the same monitor profile as that used for loading the LUT, granted that the corresponding LUT adjustments are loaded. == List of color-managed applications == darktabl
Harmony (software)
Harmony is a Java-based software for creating high-definition music videos with 2D and 3D animations. The application was developed by Digital Chaotics, a company based in San Jose, California and established in 2010 by Ken and Leanna Scott. == History == During a March 1, 2011 interview published by The LIST magazine, Ken explained how he initially got into music and digital entertainment. According to Scott: “I came at it from both the art and the technology side. … I built one of the first digital audio synthesizers as an undergrad project back in 1979. It was a short jump from there to creating visuals with computers, too.” Taking inspiration from Fantasia – which Scott calls, “The greatest music video of all time” – he began writing software code for Harmony in late 2009, finishing the project in mid-2010. However, Scott has also said that the idea for Harmony began much earlier: I read a book in 1978 called Digital Harmony, by John H Whitney, Sr. (Interestingly, he was the father of the president of Digital Productions.) He said that there was a kind of visual art based on motion, and proposed theories about the underlying mathematical structure of visual harmony. So there's the book, combined with my desire to create art with computers-add a taste or two of things commonly used by college students during the 70's - and lots of Pink Floyd. Add it all up, and the seeds for Harmony were planted. My friends in school and at Floating Point Systems listened to me ranting about "making music videos with computers" incessantly. I'm sure it was both maddening and fascinating to see. == Features == Harmony runs on Windows 7 and Windows Vista. Currently, Digital Chaotics does not offer a macOS or Linux platform for the software. However, Harmony can be run on these platforms by running it on Windows in a virtual machine. == Harmony 2 == On November 1, 2011, Digital Chaotics released the 2.0 version of the Harmony software. Unlike the original version, the second release featured three product levels: Harmony 2 Express, Harmony 2 Pro, and Harmony 2 Extreme. The "Express" version was positioned as an entry-level, free release to allow users a chance to "test-drive" the software. The "Pro" version currently retails at $197, while the "Extreme" is priced at $397. These two versions, aimed more towards VJ and Fulldome theater usage, featured additional software capability and features such as higher resolution, more video formatting options, and more camera angles.
Feed forward (control)
A feed forward (sometimes written feedforward) is an element or pathway within a control system that passes a controlling signal from a source in its external environment to a load elsewhere in its external environment. This is often a command signal from an external operator. In control engineering, a feedforward control system is a control system that uses sensors to detect disturbances affecting the system and then applies an additional input to minimize the effect of the disturbance. This requires a mathematical model of the system so that the effect of disturbances can be properly predicted. A control system which has only feed-forward behavior responds to its control signal in a pre-defined way without responding to the way the system reacts; it is in contrast with a system that also has feedback, which adjusts the input to take account of how it affects the system, and how the system itself may vary unpredictably. In a feed-forward system, the control variable adjustment is not error-based. Instead it is based on knowledge about the process in the form of a mathematical model of the process and knowledge about, or measurements of, the process disturbances. Some prerequisites are needed for control scheme to be reliable by pure feed-forward without feedback: the external command or controlling signal must be available, and the effect of the output of the system on the load should be known (that usually means that the load must be predictably unchanging with time). Sometimes pure feed-forward control without feedback is called 'ballistic', because once a control signal has been sent, it cannot be further adjusted; any corrective adjustment must be by way of a new control signal. In contrast, 'cruise control' adjusts the output in response to the load that it encounters, by a feedback mechanism. These systems could relate to control theory, physiology, or computing. == Overview == With feed-forward or feedforward control, the disturbances are measured and accounted for before they have time to affect the system. In the house example, a feed-forward system may measure the fact that the door is opened and automatically turn on the heater before the house can get too cold. The difficulty with feed-forward control is that the effects of the disturbances on the system must be accurately predicted, and there must not be any unmeasured disturbances. For instance, if a window was opened that was not being measured, the feed-forward-controlled thermostat might let the house cool down. The term has specific meaning within the field of CPU-based automatic control. The discipline of feedforward control as it relates to modern, CPU based automatic controls is widely discussed, but is seldom practiced due to the difficulty and expense of developing or providing for the mathematical model required to facilitate this type of control. Open-loop control and feedback control, often based on canned PID control algorithms, are much more widely used. There are three types of control systems: open-loop, feed-forward, and feedback. An example of a pure open-loop control system is manual non-power-assisted steering of a motor car; the steering system does not have access to an auxiliary power source and does not respond to varying resistance to turning of the direction wheels; the driver must make that response without help from the steering system. In comparison, power steering has access to a controlled auxiliary power source, which depends on the engine speed. When the steering wheel is turned, a valve is opened which allows fluid under pressure to turn the wheels. A sensor monitors that pressure so that the valve only opens enough to cause the correct pressure to reach the wheel turning mechanism. This is feed-forward control where the output of the system, the change in direction of travel of the vehicle, plays no part in the system. See Model predictive control. If the driver is included in the system, then they do provide a feedback path by observing the direction of travel and compensating for errors by turning the steering wheel. In that case you have a feedback system, and the block labeled System in Figure(c) is a feed-forward system. In other words, systems of different types can be nested, and the overall system regarded as a black-box. Feedforward control is distinctly different from open-loop control and teleoperator systems. Feedforward control requires a mathematical model of the plant (process and/or machine being controlled) and the plant's relationship to any inputs or feedback the system might receive. Neither open-loop control nor teleoperator systems require the sophistication of a mathematical model of the physical system or plant being controlled. Control based on operator input without integral processing and interpretation through a mathematical model of the system is a teleoperator system and is not considered feedforward control. == History == Historically, the use of the term feedforward is found in works by Harold S. Black in US patent 1686792 (invented 17 March 1923) and D. M. MacKay as early as 1956. While MacKay's work is in the field of biological control theory, he speaks only of feedforward systems. MacKay does not mention feedforward control or allude to the discipline of feedforward controls. MacKay and other early writers who use the term feedforward are generally writing about theories of how human or animal brains work. Black also has US patent 2102671 invented 2 August 1927 on the technique of feedback applied to electronic systems. The discipline of feedforward controls was largely developed by professors and graduate students at Georgia Tech, MIT, Stanford and Carnegie Mellon. Feedforward is not typically hyphenated in scholarly publications. Meckl and Seering of MIT and Book and Dickerson of Georgia Tech began the development of the concepts of Feedforward Control in the mid-1970s. The discipline of Feedforward Controls was well defined in many scholarly papers, articles and books by the late 1980s. == Benefits == The benefits of feedforward control are significant and can often justify the extra cost, time and effort required to implement the technology. Control accuracy can often be improved by as much as an order of magnitude if the mathematical model is of sufficient quality and implementation of the feedforward control law is well thought out. Energy consumption by the feedforward control system and its driver is typically substantially lower than with other controls. Stability is enhanced such that the controlled device can be built of lower cost, lighter weight, springier materials while still being highly accurate and able to operate at high speeds. Other benefits of feedforward control include reduced wear and tear on equipment, lower maintenance costs, higher reliability and a substantial reduction in hysteresis. Feedforward control is often combined with feedback control to optimize performance. == Model == The mathematical model of the plant (machine, process or organism) used by the feedforward control system may be created and input by a control engineer or it may be learned by the control system. Control systems capable of learning and/or adapting their mathematical model have become more practical as microprocessor speeds have increased. The discipline of modern feedforward control was itself made possible by the invention of microprocessors. Feedforward control requires integration of the mathematical model into the control algorithm such that it is used to determine the control actions based on what is known about the state of the system being controlled. In the case of control for a lightweight, flexible robotic arm, this could be as simple as compensating between when the robot arm is carrying a payload and when it is not. The target joint angles are adjusted to place the payload in the desired position based on knowing the deflections in the arm from the mathematical model's interpretation of the disturbance caused by the payload. Systems that plan actions and then pass the plan to a different system for execution do not satisfy the above definition of feedforward control. Unless the system includes a means to detect a disturbance or receive an input and process that input through the mathematical model to determine the required modification to the control action, it is not true feedforward control. === Open system === In control theory, an open system is a feed forward system that does not have any feedback loop to control its output. In contrast, a closed system uses on a feedback loop to control the operation of the system. In an open system, the output of the system is not fed back into the input to the system for control or operation. == Applications == === Physiological feed-forward system === In physiology, feed-forward control is exemplified by the normal anticipatory regulation of heartbeat in advance of actual physical exertion by the central autonomic network. Feed-forward
Breakup Notifier
Breakup Notifier was a web application written by product developer and programmer Dan Loewenherz that enabled its registered users to track the relationship status of their Facebook friends. An email notification was sent to the user when one of their Facebook friends changed their relationship status. The app was one of the most viral Facebook app's at the time of its release. It was mentioned in a skit on The Jay Leno Show and news of its popularity was published in Time magazine, The New York Post, CNET, and The Globe and Mail. == Popularity and Facebook controversy == Breakup Notifier gathered 100,000 users in less than 24 hours of its launch and reached a user base of more than 3,000,000 in February 2011. Facebook then blocked the app. Loewenherz later created an app named Crush Notifier, which differs from the original app in that users can check if they have a mutual crush. Breakup Notifier was later unblocked by Facebook and monetized.
Robinson compass mask
In image processing, a Robinson compass mask is a type of compass mask used for edge detection. It has eight major compass orientations, each will extract the edges in respect to its direction. A combined use of compass masks of different directions could detect the edges from different angles. == Technical explanation == The Robinson compass mask is defined by taking a single mask and rotating it to form eight orientations: North: [ − 1 0 1 − 2 0 2 − 1 0 1 ] {\displaystyle {\text{North:}}{\begin{bmatrix}-1&0&1\\-2&0&2\\-1&0&1\end{bmatrix}}} North West: [ 0 1 2 − 1 0 1 − 2 − 1 0 ] {\displaystyle {\text{North West:}}{\begin{bmatrix}0&1&2\\-1&0&1\\-2&-1&0\end{bmatrix}}} West: [ 1 2 1 0 0 0 − 1 − 2 − 1 ] {\displaystyle {\text{West:}}{\begin{bmatrix}1&2&1\\0&0&0\\-1&-2&-1\end{bmatrix}}} South West: [ 2 1 0 1 0 − 1 0 − 1 − 2 ] {\displaystyle {\text{South West:}}{\begin{bmatrix}2&1&0\\1&0&-1\\0&-1&-2\end{bmatrix}}} South: [ 1 0 − 1 2 0 − 2 1 0 − 1 ] {\displaystyle {\text{South:}}{\begin{bmatrix}1&0&-1\\2&0&-2\\1&0&-1\end{bmatrix}}} South East: [ 0 − 1 − 2 1 0 − 1 2 1 0 ] {\displaystyle {\text{South East:}}{\begin{bmatrix}0&-1&-2\\1&0&-1\\2&1&0\end{bmatrix}}} East: [ − 1 − 2 − 1 0 0 0 1 2 1 ] {\displaystyle {\text{East:}}{\begin{bmatrix}-1&-2&-1\\0&0&0\\1&2&1\end{bmatrix}}} North East: [ − 2 − 1 0 − 1 0 1 0 1 2 ] {\displaystyle {\text{North East:}}{\begin{bmatrix}-2&-1&0\\-1&0&1\\0&1&2\end{bmatrix}}} The direction axis is the line of zeros in the matrix. Robinson compass mask is similar to kirsch compass masks, but is simpler to implement. Since the matrix coefficients only contains 0, 1, 2, and are symmetrical, only the results of four masks need to be calculated, the other four results are the negation of the first four results. An edge, or contour is an tiny area with neighboring distinct pixel values. The convolution of each mask with the image would create a high value output where there is a rapid change of pixel value, thus an edge point is found. All the detected edge points would line up as edges. == Example == An example of Robinson compass masks applied to the original image. Obviously, the edges in the direction of the mask is enhanced.
PhyCV
PhyCV is the first computer vision library which utilizes algorithms directly derived from the equations of physics governing physical phenomena. The algorithms appearing in the first release emulate the propagation of light through a physical medium with natural and engineered diffractive properties followed by coherent detection. Unlike traditional algorithms that are a sequence of hand-crafted empirical rules, physics-inspired algorithms leverage physical laws of nature as blueprints. In addition, these algorithms can, in principle, be implemented in real physical devices for fast and efficient computation in the form of analog computing. Currently PhyCV has three algorithms, Phase-Stretch Transform (PST) and Phase-Stretch Adaptive Gradient-Field Extractor (PAGE), and Vision Enhancement via Virtual diffraction and coherent Detection (VEViD). All algorithms have CPU and GPU versions. PhyCV is now available on GitHub and can be installed from pip. == History == Algorithms in PhyCV are inspired by the physics of the photonic time stretch (a hardware technique for ultrafast and single-shot data acquisition). PST is an edge detection algorithm that was open-sourced in 2016 and has 800+ stars and 200+ forks on GitHub. PAGE is a directional edge detection algorithm that was open-sourced in February, 2022. PhyCV was originally developed and open-sourced by Jalali-Lab @ UCLA in May 2022. In the initial release of PhyCV, the original open-sourced code of PST and PAGE is significantly refactored and improved to be modular, more efficient, GPU-accelerated and object-oriented. VEViD is a low-light and color enhancement algorithm that was added to PhyCV in November 2022. == Background == === Phase-Stretch Transform (PST) === Phase-Stretch Transform (PST) is a computationally efficient edge and texture detection algorithm with exceptional performance in visually impaired images. The algorithm transforms the image by emulating propagation of light through a device with engineered diffractive property followed by coherent detection. It has been applied in improving the resolution of MRI image, extracting blood vessels in retina images, dolphin identification, and waste water treatment, single molecule biological imaging, and classification of UAV using micro Doppler imaging. === Phase-Stretch Adaptive Gradient-Field Extractor (PAGE) === Phase-Stretch Adaptive Gradient-Field Extractor (PAGE) is a physics-inspired algorithm for detecting edges and their orientations in digital images at various scales. The algorithm is based on the diffraction equations of optics. Metaphorically speaking, PAGE emulates the physics of birefringent (orientation-dependent) diffractive propagation through a physical device with a specific diffractive structure. The propagation converts a real-valued image into a complex function. Related information is contained in the real and imaginary components of the output. The output represents the phase of the complex function. === Vision Enhancement via Virtual diffraction and coherent Detection (VEViD) === Vision Enhancement via Virtual diffraction and coherent Detection (VEViD) an efficient and interpretable low-light and color enhancement algorithm that reimagines a digital image as a spatially varying metaphoric light field and then subjects the field to the physical processes akin to diffraction and coherent detection. The term “Virtual” captures the deviation from the physical world. The light field is pixelated and the propagation imparts a phase with an arbitrary dependence on frequency which can be different from the quadratic behavior of physical diffraction. VEViD can be further accelerated through mathematical approximations that reduce the computation time without appreciable sacrifice in image quality. A closed-form approximation for VEViD which we call VEViD-lite can achieve up to 200 FPS for 4K video enhancement. == PhyCV on the Edge == Featuring low-dimensionality and high-efficiency, PhyCV is ideal for edge computing applications. In this section, we demonstrate running PhyCV on NVIDIA Jetson Nano in real-time. === NVIDIA Jetson Nano Developer Kit === NVIDIA Jetson Nano Developer Kit is a small- sized and power-efficient platform for edge computing applications. It is equipped with an NVIDIA Maxwell architecture GPU with 128 CUDA cores, a quad-core ARM Cortex-A57 CPU, 4GB 64-bit LPDDR4 RAM, and supports video encoding and decoding up to 4K resolution. Jetson Nano also offers a variety of interfaces for connectivity and expansion, making it ideal for a wide range of AI and IoT applications. In our setup, we connect a USB camera to the Jetson Nano to acquire videos and demonstrate using PhyCV to process the videos in real-time. === Real-time PhyCV on Jetson Nano === We use the Jetson Nano (4GB) with NVIDIA JetPack SDK version 4.6.1, which comes with pre- installed Python 3.6, CUDA 10.2, and OpenCV 4.1.1. We further install PyTorch 1.10 to enable the GPU accelerated PhyCV. We demonstrate the results and metrics of running PhyCV on Jetson Nano in real-time for edge detection and low-light enhancement tasks. For 480p videos, both operations achieve beyond 38 FPS, which is sufficient for most cameras that capture videos at 30 FPS. For 720p videos, PhyCV low-light enhancement can operate at 24 FPS and PhyCV edge detection can operate at 17 FPS. == Highlights == === Modular Code Architecture === The code in PhyCV has a modular design which faithfully follows the physical process from which the algorithm was originated. Both PST and PAGE modules in the PhyCV library emulate the propagation of the input signal (original digital image) through a device with engineered diffractive property followed by coherent (phase) detection. The dispersive propagation applies a phase kernel to the frequency domain of the original image. This process has three steps in general, loading the image, initializing the kernel and applying the kernel. In the implementation of PhyCV, each algorithm is represented as a class in Python and each class has methods that simulate the steps described above. The modular code architecture follows the physics behind the algorithm. Please refer to the source code on GitHub for more details. === GPU Acceleration === PhyCV supports GPU acceleration. The GPU versions of PST and PAGE are built on PyTorch accelerated by the CUDA toolkit. The acceleration is beneficial for applying the algorithms in real-time image video processing and other deep learning tasks. The running time per frame of PhyCV algorithms on CPU (Intel i9-9900K) and GPU (NVIDIA TITAN RTX) for videos at different resolutions are shown below. Note that the PhyCV low-light enhancement operates in the HSV color space, so the running time also includes RGB to HSV conversion. However, for all running times using GPUs, we ignore the time of moving data from CPUs to GPUs and count the algorithm operation time only. == Installation and Examples == Please refer to the GitHub README file for a detailed technical documentation. == Current Limitations == === I/O (Input/Output) Bottleneck for Real-time Video Processing === When dealing with real-time video streams from cameras, the frames are captured and buffered in CPU and have to be moved to GPU to run the GPU-accelerated PhyCV algorithms. This process is time-consuming and it is a common bottleneck for real-time video-processing algorithms. === Lack of Parameter Adaptivity for Different Images === Currently, the parameters of PhyCV algorithms have to be manually tuned for different images. Although a set of pre-selected parameters work relatively well for a wide range of images, the lack of parameter adaptivity for different images remains a limitation for now.
Reference Software International
Reference Software International, Inc. (RSI), was an American software developer active from 1985 to 1993 and based in Albuquerque, New Mexico, and San Francisco, California. The company released several productivity and reference software packages, including the Grammatik grammar checker, for MS-DOS. The company was acquired by WordPerfect Corporation in 1993. == History == === Background (1980–1985) === Reference Software International, Inc., was founded by Donald "Don" Emery and Bruce Wampler in 1985 in San Francisco, California. Both Wampler and Emery were college professors when they founded RSI: Wampler at the University of New Mexico as a professor of computer science and Emery a professor of marketing at San Francisco State University. After graduating from the University of Utah in around 1978, Wampler founded his first software company, Aspen Software, in Tijeras, New Mexico, in 1979. Wampler founded Aspen to develop an early spell checker software package, called Proofreader, for the TRS-80, licensing Random House's Webster's Unabridged Dictionary for the package's lexicon. In 1980, he began development on a grammar checker inspired by Writer's Workbench, a pioneering grammar checker for Unix systems. Wampler used Writer's Workbench heavily during the writer of his doctoral dissertation but disliked having to jump between the Apple II on which he composed the dissertation and the mainframe on which Writer's Workbench ran, and so wanted to develop a version of the latter for microcomputers. Wampler's work came to fruition as Grammatik in 1981, eventually ported to several other microcomputer platforms in the early 1980s. In 1983, by which point the company had 12 employees and sold a combined 80,000 units of Grammatik and Proofreader, Wampler sold Aspen to Dictronics, a software company best known for developing the Electronic Thesaurus, an early thesaurus program for microcomputers. Dictronics was in turn purchased by Wang Laboratories; according to Wampler, "Wang bought [Aspen] and sat on it. They did nothing with it". Wampler moved on to teach for the University of New Mexico, but, frustrated by Wang's inaction, got the urge to resurrect his work. In 1985, he was able to license back Grammatik and Proofreader from a small California-based software firm that had grandfathered rights to a forked version of both. In the same year, he met Emery, who, impressed by Wampler's, founded Reference Software International to market his software. RSI's research and development headquarters were based in Albuquerque, while the company's sales and marketing department was based in Walnut Creek, California. === Success (1985–1992) === In August 1985, RSI released their first product: the Random House Reference Set, a new version of Proofreader for the IBM Personal Computer and compatibles, revised to be a terminate-and-stay-resident program that ran atop other word processors such as WordStar or WordPerfect. At the time, Reference Set was the only such program on the market that functioned like this. RSI netted $114,000 from sales of Reference Set by the end of 1985. In June 1986, they released version 2.0 of Grammatik as Grammatik II for the PC. The latter was a breakout hit for RSI, receiving praise in the press (including technology journals such as PC Magazine) and RSI selling 1,000 units a month. In spring 1987, they released Reference Set II, which allowed users to import their own words into the built-in dictionary and added a thesaurus of 300,000 words. In November 1987, they released version 3.0 of Reference Set, which comprised two new field-specific dictionaries for the medical and legal professions. As well as the general Random House dictionary and thesaurus, it included Stedman's Medical Dictionary and Black's Law Dictionary. Emery consulted Paul Brest and Bob Jackson—professors of law at Stanford Law School and San Francisco State respectively—for the curation of the law dictionary; and Burton Grebin—at the time the executive director of Mount Saint Mary's Hospital—for the curation of the medical dictionary. In fall 1988, the company released Grammatik III, a total rewrite that made use of artificial intelligence to more accurately judge the grammar of sentences by breaking them down into a syntactic hierarchy. Grammatik III received universal acclaim, with Gloria Morris of InfoWorld calling it the apparent leader in the grammar checking field and Sandra Anderson of Mac Home Journal calling it "hands down ... the best of the industry" six years after its release. By 1989, the product had competitors in Correct Grammar by Lifetree Software and RightWriter by Rightsoft, Inc. By 1990, RSI achieved annual sales of $9.7 million. In the same year they released Grammatik IV, which was the first to offer direct integration with WordPerfect on both MS-DOS and Windows. In March 1992—by which point RSI had sold 1.5 million copies of Grammatik across all versions—the company released version 5 of the program, another rewrite that updated the lexicon further and added new functions such as word redundancy detection. Around the same time, the company introduced Easy Proof, a pared-down version of Grammatik intended for novice writers, students, and family computers. In 1991, the company was engaged in a trademark dispute with Systems Compatibility Corporation (SCC) of Chicago, Illinois, over the rights to the Software Toolkit title. Both companies had published software bundles bearing the name in the turn of the 1990s; SCC had published theirs first in 1988 and registered the trademark with the USPTO. SCC was granted a restraining order against RSI in January 1991. The following month, RSI agreed to rename their product, preventing a protracted legal battle. === Decline and acquisition (1992–1993) === By early 1992, RSI achieved annual sales of more than $13 million, employed 120 people, and had opened international offices in London, Belgium, and Antwerp to sell foreign versions of Reference Set and Grammatik. The company reached peak employment in the middle of 1992, with 140 employees. However, RSI's launch of six disparate titles in the year proved problematic for the company when they failed to sell as well as they had projected, and the company laid off employees by the dozens. By December 1992, only 71 employees were left, 32 from their San Francisco office. On the last day of 1992, RSI received an acquisition offer from WordPerfect Corporation, makers of the namesake word processor based in Orem, Utah. The deal was inked in January 1993, RSI's stakeholders receiving $19 million. The company's remaining employees were absorbed into WordPerfect in Orem. WordPerfect continued selling Grammatik as a standalone product for several years.