An N-jet is the set of (partial) derivatives of a function f ( x ) {\displaystyle f(x)} up to order N. Specifically, in the area of computer vision, the N-jet is usually computed from a scale space representation L {\displaystyle L} of the input image f ( x , y ) {\displaystyle f(x,y)} , and the partial derivatives of L {\displaystyle L} are used as a basis for expressing various types of visual modules. For example, algorithms for tasks such as feature detection, feature classification, stereo matching, tracking and object recognition can be expressed in terms of N-jets computed at one or several scales in scale space.
Toy problem
In scientific disciplines, a toy problem or a puzzlelike problem is a problem that is not of immediate scientific interest, yet is used as an expository device to illustrate a trait that may be shared by other, more complicated, instances of the problem, or as a way to explain a particular, more general, problem solving technique. A toy problem is useful to test and demonstrate methodologies. Researchers can use toy problems to compare the performance of different algorithms. They are also good for game designing. For instance, while engineering a large system, the large problem is often broken down into many smaller toy problems which have been well understood in detail. Often these problems distill a few important aspects of complicated problems so that they can be studied in isolation. Toy problems are thus often very useful in providing intuition about specific phenomena in more complicated problems. As an example, in the field of artificial intelligence, classical puzzles, games and problems are often used as toy problems. These include sliding-block puzzles, N-Queens problem, missionaries and cannibals problem, tic-tac-toe, chess, Tower of Hanoi and others.
Microscope image processing
Microscope image processing is a broad term that covers the use of digital image processing techniques to process, analyze and present images obtained from a microscope. Such processing is now commonplace in a number of diverse fields such as medicine, biological research, cancer research, drug testing, metallurgy, etc. A number of manufacturers of microscopes now specifically design in features that allow the microscopes to interface to an image processing system. == Image acquisition == Until the early 1990s, most image acquisition in video microscopy applications was typically done with an analog video camera, often simply closed circuit TV cameras. While this required the use of a frame grabber to digitize the images, video cameras provided images at full video frame rate (25-30 frames per second) allowing live video recording and processing. While the advent of solid state detectors yielded several advantages, the real-time video camera was actually superior in many respects. Today, acquisition is usually done using a CCD camera mounted in the optical path of the microscope. The camera may be full colour or monochrome. Very often, very high resolution cameras are employed to gain as much direct information as possible. Cryogenic cooling is also common, to minimise noise. Often digital cameras used for this application provide pixel intensity data to a resolution of 12-16 bits, much higher than is used in consumer imaging products. Ironically, in recent years, much effort has been put into acquiring data at video rates, or higher (25-30 frames per second or higher). What was once easy with off-the-shelf video cameras now requires special, high speed electronics to handle the vast digital data bandwidth. Higher speed acquisition allows dynamic processes to be observed in real time, or stored for later playback and analysis. Combined with the high image resolution, this approach can generate vast quantities of raw data, which can be a challenge to deal with, even with a modern computer system. While current CCD detectors allow very high image resolution, often this involves a trade-off because, for a given chip size, as the pixel count increases, the pixel size decreases. As the pixels get smaller, their well depth decreases, reducing the number of electrons that can be stored. In turn, this results in a poorer signal-to-noise ratio. For best results, one must select an appropriate sensor for a given application. Because microscope images have an intrinsic limiting resolution, it often makes little sense to use a noisy, high resolution detector for image acquisition. A more modest detector, with larger pixels, can often produce much higher quality images because of reduced noise. This is especially important in low-light applications such as fluorescence microscopy. Moreover, one must also consider the temporal resolution requirements of the application. A lower resolution detector will often have a significantly higher acquisition rate, permitting the observation of faster events. Conversely, if the observed object is motionless, one may wish to acquire images at the highest possible spatial resolution without regard to the time required to acquire a single image. == 2D image techniques == Image processing for microscopy application begins with fundamental techniques intended to most accurately reproduce the information contained in the microscopic sample. This might include adjusting the brightness and contrast of the image, averaging images to reduce image noise and correcting for illumination non-uniformities. Such processing involves only basic arithmetic operations between images (i.e. addition, subtraction, multiplication and division). The vast majority of processing done on microscope image is of this nature. Another class of common 2D operations called image convolution are often used to reduce or enhance image details. Such "blurring" and "sharpening" algorithms in most programs work by altering a pixel's value based on a weighted sum of that and the surrounding pixels (a more detailed description of kernel based convolution deserves an entry for itself) or by altering the frequency domain function of the image using Fourier Transform. Most image processing techniques are performed in the Frequency domain. Other basic two dimensional techniques include operations such as image rotation, warping, color balancing etc. At times, advanced techniques are employed with the goal of "undoing" the distortion of the optical path of the microscope, thus eliminating distortions and blurring caused by the instrumentation. This process is called deconvolution, and a variety of algorithms have been developed, some of great mathematical complexity. The end result is an image far sharper and clearer than could be obtained in the optical domain alone. This is typically a 3-dimensional operation, that analyzes a volumetric image (i.e. images taken at a variety of focal planes through the sample) and uses this data to reconstruct a more accurate 3-dimensional image. == 3D image techniques == Another common requirement is to take a series of images at a fixed position, but at different focal depths. Since most microscopic samples are essentially transparent, and the depth of field of the focused sample is exceptionally narrow, it is possible to capture images "through" a three-dimensional object using 2D equipment like confocal microscopes. Software is then able to reconstruct a 3D model of the original sample which may be manipulated appropriately. The processing turns a 2D instrument into a 3D instrument, which would not otherwise exist. In recent times this technique has led to a number of scientific discoveries in cell biology. == Analysis == Analysis of images will vary considerably according to application. Typical analysis includes determining where the edges of an object are, counting similar objects, calculating the area, perimeter length and other useful measurements of each object. A common approach is to create an image mask which only includes pixels that match certain criteria, then perform simpler scanning operations on the resulting mask. It is also possible to label objects and track their motion over a series of frames in a video sequence.
BigDog
BigDog is a dynamically stable quadruped military robot platform that was created in 2005 by Boston Dynamics with the Harvard University Concord Field Station. It was funded by the U.S. Defense Advanced Research Projects Agency (DARPA), but the project was shelved after the BigDog's gas engine was deemed too loud for combat. == History == BigDog was funded by the Defense Advanced Research Projects Agency (DARPA) in the hopes that it would be able to serve as a mechanic pack mule to accompany soldiers in terrain too rough for conventional vehicles. Instead of wheels or treads, BigDog uses four legs for movement, allowing it to move across surfaces that would be difficult for wheels. The legs contain a variety of sensors, including joint position and ground contact. BigDog also features a laser gyroscope and a stereo vision system. BigDog is 3 feet (0.91 m) long, stands 2.5 feet (0.76 m) tall, and weighs 240 pounds (110 kg), making it about the size of a small mule. It is capable of traversing difficult terrain, running at four miles per hour (6.4 km/h), carrying 340 pounds (150 kg), and climbing a 35 degree incline. Locomotion is controlled by an onboard computer that receives input from the robot's various sensors. Navigation and balance are also managed by the control system. BigDog's walking pattern is controlled through four legs, each equipped with four low-friction hydraulic cylinder actuators that power the joints. BigDog's locomotion behaviors can vary greatly. It can stand up, sit down, walk with a crawling gait that lifts one leg at a time, walk with a trotting gait lifting diagonal legs, or trot with a running gait. The travel speed of BigDog varies from a 0.62 mph (1 km/h) crawl to a 3.3 mph (5.3 km/h) trot. The BigDog project was headed by Dr. Martin Buehler, who received the Joseph Engelberger Award from the Robotics Industries Association in 2012 for the work. Dr. Buehler while previously a professor at McGill University, headed the robotics lab there, developing four-legged walking and running robots. Built onto the actuators are sensors for joint position and force, and movement is ultimately controlled through an onboard computer which manages the sensors. Approximately 50 sensors are located on BigDog. These measure the attitude and acceleration of the body, motion, and force of joint actuators as well as engine speed, temperature and hydraulic pressure inside the robot's internal engine. Low-level control, such as position and force of the joints, and high-level control such as velocity and altitude during locomotion, are both controlled through the onboard computer. BigDog was featured in episodes of Web Junk 20 and Hungry Beast, and in articles in New Scientist, Popular Science, Popular Mechanics, and The Wall Street Journal. In September 2011 Boston Dynamics released video footage of a new generation of BigDog known as AlphaDog. The footage shows AlphaDog's ability to walk on rough terrain and recover its balance when kicked from the side. The refined equivalent has been designed by Boston Dynamics to exceed the BigDog in terms of capabilities and use to dismounted soldiers. In February 2012, with further DARPA support, the militarized Legged Squad Support System (LS3) variant of BigDog demonstrated its capabilities during a hike over a rough terrain. Starting in the summer of 2012, DARPA planned to complete the overall development of the system and refine its key capabilities in 18 months, ensuring its worth to dismounted warfighters before it is rolled out to squads operating in-theatre. BigDog must be able to demonstrate its ability to complete a 20-mile (32 km) trail in 24 hours, without refuelling, while carrying a 325-pound (150 kg) load. A refinement of its vision sensors will also be conducted. At the end of February 2013, Boston Dynamics released video footage of a modified BigDog with an arm. The arm could pick up objects and throw them. The robot is relying on its legs and torso to help power the motions of the arm. It is believed that it can lift weights around 55 pounds (25 kg). This work was funded by the United States Army Research Laboratory and paved the way for integrating manipulators with quadrupeds as found on Spot, the spiritual successor of BigDog. === Discontinuation === At the end of December 2013, the BigDog project was discontinued. Despite hopes that it would one day work like a pack mule for US soldiers in the field, the gasoline-powered engine was deemed too noisy for use in combat, and it could be heard from hundreds of meters away. A similar project for an all-electric robot named Spot in 2016 was much quieter, but could only carry 45 pounds (20 kg). Both projects are no longer in progress, but the Spot was only released in 2020. == Hardware == BigDog is powered by a small two-stroke, one-cylinder, 15-brake-horsepower (11 kW) engine operating at 9,000 RPM. The engine drives a hydraulic pump, which in turn drives the hydraulic leg actuators. Each leg has four actuators (two for the hip joint, and two each for the knee and ankle joints), for a total of 16. Each actuator unit consists of a hydraulic cylinder, servo valve, position sensor, and force sensor. Onboard computing power is a ruggedized PC/104 board stack with two computers, one running a Pentium M processor running QNX (used for sensor data processing) and another running a Core Duo processor (used for visual data processing). == Gallery ==
PCPaint
PCPaint was one of the first IBM PC-based mouse-driven GUI paint programs, released in 1984. It followed after Microsoft Doodle, released in 1983 with the Microsoft Mouse version 1 drivers for DOS, and around the same time as Digital Research’s Draw program. It was developed and created by John Bridges and Doug Wolfgram. It was later developed into Pictor Paint. The hardware manufacturer Mouse Systems bundled PCPaint with millions of computer mice that they sold, making PCPaint one of the best-selling DOS-based paint programs of the mid 1980s. == History == In 1983, Doug Wolfgram bought a Microsoft Mouse and decided to write a drawing program for it. They named it “Mouse Draw”. The interface was primitive but the program functioned well. Wolfgram traveled to SoftCon in New Orleans where he demonstrated the program to Mouse Systems. Mouse Systems was developing an optical mouse and they wanted to bundle a painting program so they agreed to publish Mouse Draw. The original program was written entirely in assembly language with primitive graphics routines developed by Wolfgram. John Bridges worked for an educational software company, Classroom Consortia Media, Inc., developing and writing Apple and IBM graphics libraries for CCM's software. Bridges and Wolfgram were friends who had been connected through a bulletin board system developed and run by Wolfgram. The two collaborated cross country via the BBS, Wolfram in California and Bridges in New York. Mouse Systems wanted the paint program to capture the look and feel of MacPaint. John Bridges and Doug Wolfgram started reworking Mouse Draw into what became PCPaint. The program was completely re-written using Bridge's graphics library and the top-level elements were written in C rather than assembly language. Bridges developed the core graphics code for the first version of PCPaint while Wolfgram worked on the user interface and top-level code. Mouse Systems signed an exclusive agreement with Wolfgram's company, Microtex Industries, Inc., to bundle PCPaint with every mouse they sold. They began publishing PCPaint with their mice in 1984. Microsoft responded in 1985 by bundling a competing product, PC Paintbrush, with version 4 of its DOS drivers for the Microsoft Mouse, replacing its in-house Microsoft Doodle program which it published with version 1 of the DOS drivers in mid-1983. Microsoft’s mouse began to outsell Mouse Systems mouse. In November 1985 Microsoft bundled a cut-down version of PC Paintbrush with Windows 1.0 (called Microsoft Paint), later bundling an updated version of PC Paintbrush with Windows 3.0 (as Paintbrush), impacting PCPaint’s marketshare. In early 1987, Mouse Systems decided that PCPaint wasn't helping to sell mice any longer so they discontinued the bundle deal and returned rights to the code to MicroTex Industries, but retained rights to the name, PCPaint. Wolfgram then combined the paint program with a new animation system he was developing (called GRASP) and Paul Mace Software bought publishing rights to the animation system and PCPaint, which was to be renamed Pictor. Bridges again got involved and took over programming responsibilities for GRASP as well as PCPaint while Wolfgram focused on more of the business details. In creating the first version of PCPaint, Doug had a dual-floppy machine with a Computer Innovations compiler on one disk and source code on the other. John had the "luxury" of a 10MB hard disk in his XT. Data was exchanged daily via 1200, then 2400 baud modems. === Authorship and Ownership === John Bridges and Wolfgram continued to work on PCPaint and GRASP on behalf of Paul Mace Software until 1990. Also in that year, Doug Wolfgram sold his remaining rights to PCPaint (and its animation system, GRASP) to John Bridges. In 1994, GRASP development stopped and so did development of Pictor Paint. John Bridges terminated his GRASP publishing contract with Paul Mace Software, and went off to create GLPro (the next generation of GRASP) with GMEDIA. Along with GLPro, came GLPaint, the successor to PCPaint and Pictor Paint. == Versions == In June 1984, Mouse Systems shipped PCPaint 1.0, the first GUI based Paint program for the IBM PC family of computers. John Bridges and Doug Wolfgram, were the co-authors of PCPaint 1.0. PCPaint 1.0 saved its graphics in a modified BSaved image format with the extension of ".PIC". The release of PCPaint Version 1.5 followed in late 1984, with the additions of graphics image compression for the .PIC format and support for "larger-than-screen" images. PCjr support was also added in this version after overcoming severe memory shortage problems getting PCPaint to run on the 128k PCjr. October 1985 saw the release of PCPaint 2.0. EGA support and publishing features were added to this version. The .PIC format was further refined, offering support for the rapidly expanding graphics capabilities of the PC and efficient image compression. PCPaint 3.1 was released in 1989. Unlike previous versions, it was not bundled with mice but was sold as a stand-alone software product. PCPaint 3.1 offered improved text and image handling, provided 36 types of flood and fill, worked with VGA adapters in hi-res 16-color and 256-color modes, allowed the user to save and retrieve files in a variety of intercompatible formats (.PIC, .GIF, .PCX, .IMG), and printed selected portions of images on color or black-and-white dot matrix, ink jet, and laser printers such as PostScript and HP Laser Jet. PCPaint 3.1 is still in use today by some users of DOS emulation programs like DOSBox and available for free download. Pictor Paint was an improved version, written by John Bridges, and bundled with GRASP GRaphical System for Presentation also written by John Bridges. It was also called "The Painter's Easel". GLPaint, released in 1995, was the last in this series of paint programs written by John Bridges. By 1998 version 7.0 provided support for TrueColor images and the Pictor PIC format was expanded to handle these. == Pictor PIC Image Format == PCPaint 1.0 saved its graphics in a modified BSAVE image format (which was popular at the time) with the file type (extension) of ".PIC". By PCPaint 1.5 this format was extended further to accommodate image compression. With the release of version 2.0 the PICtor PIC image format was developed almost to its present state, with no similarity to the BSAVE format used by earlier versions. Pictor Paint saved its files in a compressed format with the file extension PIC, which was the same format used by PCPaint.
Kdb+
kdb+ is a column-based relational time series database (TSDB) with in-memory (IMDB) abilities, developed and marketed by KX Systems. The database is commonly used in high-frequency trading (HFT) to store, analyze, process, and retrieve large data sets at high speed. kdb+ has the ability to handle billions of records and analyzes data within a database. The database is available in 32-bit and 64-bit versions for several operating systems. Financial institutions use kdb+ to analyze time series data such as stock or commodity exchange data. The database has also been used for other time-sensitive data applications including commodity markets such as energy trading, telecommunications, sensor data, log data, machine and computer network usage monitoring along with real time analytics in Formula One racing. == Overview == kdb+ is a high-performance column-store database that was designed to process and store large amounts of data. Commonly accessed data is pushed into random-access memory (RAM), which is faster to access than data in disk storage. Created with financial institutions in mind, the database was developed as a central repository to store time series data that supports real-time analysis of billions of records. kdb+ has the ability to analyze data over time and responds to queries similar to Structured Query Language (SQL). Columnar databases return answers to some queries in a more efficient way than row-based database management systems. kdb+ dictionaries, tables and nanosecond time stamps are native data types and are used to store time series data. At the core of kdb+ is the built-in programming language, q, a concise, expressive query array language, and dialect of the language APL. Q can manipulate streaming, real-time, and historical data. kdb+ uses q to aggregate and analyze data, perform statistical functions, and join data sets and supports SQL queries The vector language q was built for speed and expressiveness and eliminates most need for looping structures. kdb+ includes interfaces in C, C++, Java, C#, and Python. == History == In 1998, KX released kdb, a database built on the language K written by Arthur Whitney. In 2003, kdb+ was released as a 64-bit version of kdb. In 2004, the kdb+ tick market database framework was released along with kdb+ taq, a loader for the New York Stock Exchange (NYSE) taq data. kdb+ was created by Arthur Whitney, building on his prior work with array languages. In April 2007, KX announced that it was releasing a version of kdb+ for Mac OS X. Then, kdb+ was also available on the operating systems Linux, Windows, and Solaris. In September 2012, version 3.0 was released. It was optimized for Intel's upgraded processors with support for WebSockets, and universally unique identifiers (UUIDs, termed globally unique identifiers (GUID)s in Microsoft software). Intel's Advanced Vector Extensions (AVX) and Streaming SIMD Extensions 4 (SSE4) 4.2 on the Sandy Bridge processors of the time allowed for enhanced support of the kdb+ system. In June 2013, version 3.1 was released, with benchmarks up to 8 times faster than older versions. In March 2020, version 4.0 was released. New features included Multithreaded primitives, Intel Optane DC persistent memory support and Data at Rest Encryption.
ISSCO Graphics
Integrated Software Systems Corporation (ISSCO), doing business as ISSCO Graphics, was an American software developer and publisher based in San Diego, California, and active from 1970 to 1986. They were best known for their enterprise graphics software packages, including Tellagraf, CueChart and Disspla. == History == ISSCO Graphics had considered acquiring Breakthrough Software, whose software focus involved PC DOS, as a means of getting into the PC arena, but backed off when Computer Associates made an offer to acquire ISSCO. By early 1987 it was reported that "Issco users breathe sigh of relief" that all was well. The ISSCO User's Group was founded in 1976. ISSCO, which was founded in 1970 by Peter Preuss, was acquired by Computer Associates in 1986. == Notable products == === Tellagraf === ISSCO's Tellagraf is an early software package designed to allow end-users to "turn out full color, professional quality charts" with initial results displayed on a screen, modified as needed, and then "a final 'hard-copy' can be made .. or made into 35mm color transparencies for projection onto a screen." Users of Tellagraf often had access to CueChart and Disspla software. Often computer sites having one had all three. Terminals with varying degrees of graphics, such as the DEC's VT100 and Tektronix's Tektronix 4xxx family of text and graphics terminals. were supported, and the software ran on popular computing platforms. Four years are important to Tellagraf's early history: 1978: ease of use 1980: graphic-artist quality 1982: introduction of CueChart, and recognition by IEEE. 1983: "quality graphics enters the mainstream of data processing with ..." Tellegraf was eventually acquired by Computer Associates and renamed CA-Tellegraf. SAS users found it helpful. Universities, research institutes and financial services firms were among early users. === Disspla === Disspla is a package of data plotting subroutines that can be used from high level languages. It was also acquired by Computer Associates. === Tellaplan === In 1983 ISSCO introduced Tellaplan, "a project planning, report and schedule charting system for Tell-A- Graf users in IBM MVS or CMS or Digital Equipment Corp. VAX computers" atop which they built "two visual project management software packages" three years later.