Domain adaptation is a field associated with machine learning and transfer learning. It addresses the challenge of training a model on one data distribution (the source domain) and applying it to a related but different data distribution (the target domain). A common example is spam filtering, where a model trained on emails from one user (source domain) is adapted to handle emails for another user with significantly different patterns (target domain). Domain adaptation techniques can also leverage unrelated data sources to improve learning. When multiple source distributions are involved, the problem extends to multi-source domain adaptation. Domain adaptation is a specific type of transfer learning. According to the taxonomy laid out by Pan and Yang (2010), it falls into the category of transductive transfer learning. In this setting, the source and target tasks are the same (e.g., both are object recognition), but the domains differ (different marginal distributions). This distinguishes it from inductive transfer learning (where labeled data is available for the target task) and unsupervised transfer learning (where labels are unavailable in both domains). == Classification of domain adaptation problems == Domain adaptation setups are classified in two different ways: according to the distribution shift between the domains, and according to the available data from the target domain. === Distribution shifts === Common distribution shifts are classified as follows: Covariate Shift occurs when the input distributions of the source and destination change, but the relationship between inputs and labels remains unchanged. The above-mentioned spam filtering example typically falls in this category. Namely, the distributions (patterns) of emails may differ between the domains, but emails labeled as spam in the one domain should similarly be labeled in another. Prior Shift (Label Shift) occurs when the label distribution differs between the source and target datasets, while the conditional distribution of features given labels remains the same. An example is a classifier of hair color in images from Italy (source domain) and Norway (target domain). The proportions of hair colors (labels) differ, but images within classes like blond and black-haired populations remain consistent across domains. A classifier for the Norway population can exploit this prior knowledge of class proportions to improve its estimates. Concept Shift (Conditional Shift) refers to changes in the relationship between features and labels, even if the input distribution remains the same. For instance, in medical diagnosis, the same symptoms (inputs) may indicate entirely different diseases (labels) in different populations (domains). === Data available during training === Domain adaptation problems typically assume that some data from the target domain is available during training. Problems can be classified according to the type of this available data: Unsupervised: Unlabeled data from the target domain is available, but no labeled data. In the above-mentioned example of spam filtering, this corresponds to the case where emails from the target domain (user) are available, but they are not labeled as spam. Domain adaptation methods can benefit from such unlabeled data, by comparing its distribution (patterns) with the labeled source domain data. Semi-supervised: Most data that is available from the target domain is unlabelled, but some labeled data is also available. In the above-mentioned case of spam filter design, this corresponds to the case that the target user has labeled some emails as being spam or not. Supervised: All data that is available from the target domain is labeled. In this case, domain adaptation reduces to refinement of the source domain predictor. In the above-mentioned example classification of hair-color from images, this could correspond to the refinement of a network already trained on a large dataset of labeled images from Italy, using newly available labeled images from Norway. == Formalization == Let X {\displaystyle X} be the input space (or description space) and let Y {\displaystyle Y} be the output space (or label space). The objective of a machine learning algorithm is to learn a mathematical model (a hypothesis) h : X → Y {\displaystyle h:X\to Y} able to attach a label from Y {\displaystyle Y} to an example from X {\displaystyle X} . This model is learned from a learning sample S = { ( x i , y i ) ∈ ( X × Y ) } i = 1 m {\displaystyle S=\{(x_{i},y_{i})\in (X\times Y)\}_{i=1}^{m}} . Usually in supervised learning (without domain adaptation), we suppose that the examples ( x i , y i ) ∈ S {\displaystyle (x_{i},y_{i})\in S} are drawn i.i.d. from a distribution D S {\displaystyle D_{S}} of support X × Y {\displaystyle X\times Y} (unknown and fixed). The objective is then to learn h {\displaystyle h} (from S {\displaystyle S} ) such that it commits the least error possible for labelling new examples coming from the distribution D S {\displaystyle D_{S}} . The main difference between supervised learning and domain adaptation is that in the latter situation we study two different (but related) distributions D S {\displaystyle D_{S}} and D T {\displaystyle D_{T}} on X × Y {\displaystyle X\times Y} . The domain adaptation task then consists of the transfer of knowledge from the source domain D S {\displaystyle D_{S}} to the target one D T {\displaystyle D_{T}} . The goal is then to learn h {\displaystyle h} (from labeled or unlabelled samples coming from the two domains) such that it commits as little error as possible on the target domain D T {\displaystyle D_{T}} . The major issue is the following: if a model is learned from a source domain, what is its capacity to correctly label data coming from the target domain? == Four algorithmic principles == === Reweighting algorithms === The objective is to reweight the source labeled sample such that it "looks like" the target sample (in terms of the error measure considered). === Iterative algorithms === A method for adapting consists in iteratively "auto-labeling" the target examples. The principle is simple: a model h {\displaystyle h} is learned from the labeled examples; h {\displaystyle h} automatically labels some target examples; a new model is learned from the new labeled examples. Note that there exist other iterative approaches, but they usually need target labeled examples. === Search of a common representation space === The goal is to find or construct a common representation space for the two domains. The objective is to obtain a space in which the domains are close to each other while keeping good performances on the source labeling task. This can be achieved through the use of Adversarial machine learning techniques where feature representations from samples in different domains are encouraged to be indistinguishable. === Hierarchical Bayesian Model === The goal is to construct a Bayesian hierarchical model p ( n ) {\displaystyle p(n)} , which is essentially a factorization model for counts n {\displaystyle n} , to derive domain-dependent latent representations allowing both domain-specific and globally shared latent factors. == Software packages == Several compilations of domain adaptation and transfer learning algorithms have been implemented over the past decades: SKADA (Python) ADAPT (Python) TLlib (Python) Domain-Adaptation-Toolbox (MATLAB)
MoltenVK
MoltenVK is a software library which allows Vulkan applications to run on top of Metal on Apple's macOS, iOS, and tvOS operating systems. It is the first software component to be released for the Vulkan Portability Initiative, a project to have a subset of Vulkan run on platforms lacking native Vulkan drivers. There are some limitations compared with a native Vulkan implementation. == History == MoltenVK was first released as a proprietary and commercially licensed product by The Brenwill Workshop on July 27, 2016. On July 31, 2017, Khronos announced the formation of the Vulkan Portability Technical Subgroup. === Open source === On February 26, 2018, Khronos announced that Vulkan became available on macOS and iOS products through the MoltenVK library. Valve announced that Dota 2 will run on macOS using the Vulkan API with the aid of MoltenVK, and that they had made an arrangement with developer The Brenwill Workshop Ltd to release MoltenVK as open-source software under the Apache License version 2.0. On May 30, 2018, Qt was updated with Vulkan for Qt on macOS using MoltenVK. On May 31, 2018, optional Vulkan support for Dota 2 on macOS was released. Benchmarks for the game were available the following day, showing better performance using Vulkan and MoltenVK compared to OpenGL. On July 20, 2018, Wine was updated with Vulkan support on macOS using MoltenVK. On 29 July 2018, the first app using MoltenVK was accepted onto the App Store, after initially being rejected. On 6 August 2018, Google open-sourced Filament, a crossplatform real-time physically based rendering engine with MoltenVK for macOS/iOS. On November 28, 2018, Valve released Artifact, their first Vulkan-only game on macOS using MoltenVK. === Version 1.0 === On 29 January 2019, MoltenVK 1.0.32 was released with early prototype of Vulkan Portability Extensions. RPCS3 and Dolphin emulators were updated with Vulkan support on macOS using MoltenVK. On 13 April 2019, MoltenVK 1.0.34 was released with support for tessellation. On July 30, 2019, MoltenVK 1.0.36 was released targeting Metal 3.0. On July 31, 2020, MoltenVK 1.0.44 was released, adding support for the tvOS platform. On January 23, 2020, MoltenVK was updated to support for some of the new features of Vulkan 1.2, as of Vulkan SDK 1.2.121. === Version 1.1 === On October 1, 2020, MoltenVK 1.1.0 was released, adding full support for Vulkan 1.1, as of Vulkan SDK 1.2.154. On 9 December 2020, MoltenVK 1.1.1 was released, providing support for Vulkan on Apple silicon GPUs and support for the Mac Catalyst platform for porting iOS/iPadOS apps to macOS. === Version 1.2 === On October 18, 2022, MoltenVK 1.2.0 was released, adding full support for Vulkan 1.2 as of Vulkan SDK 1.3.231. In January 2023, MoltenVK 1.2.2 added support for Vulkan as of SDK 1.3.239, while this version of Vulkan SDK fixed some issues with the interconnectivity with Metal API, while version 1.2.3 supported some additional extensions. === Version 1.3 === On May 1, 2025, MoltenVK 1.3 was released with support for Vulkan 1.3. === Version 1.4 === On August 20, 2025, MoltenVK 1.4 was released with support for Vulkan 1.4.
Structural synthesis of programs
Structural synthesis of programs (SSP) is a special form of (automatic) program synthesis that is based on propositional calculus. More precisely, it uses intuitionistic logic for describing the structure of a program in such a detail that the program can be automatically composed from pieces like subroutines or even computer commands. It is assumed that these pieces have been implemented correctly, hence no correctness verification of these pieces is needed. SSP is well suited for automatic composition of services for service-oriented architectures and for synthesis of large simulation programs. == History == Automatic program synthesis began in the artificial intelligence field, with software intended for automatic problem solving. The first program synthesizer was developed by Cordell Green in 1969. At about the same time, mathematicians including R. Constable, Z. Manna, and R. Waldinger explained the possible use of formal logic for automatic program synthesis. Practically applicable program synthesizers appeared considerably later. The idea of structural synthesis of programs was introduced at a conference on algorithms in modern mathematics and computer science organized by Andrey Ershov and Donald Knuth in 1979. The idea originated from G. Pólya’s well-known book on problem solving. The method for devising a plan for solving a problem in SSP was presented as a formal system. The inference rules of the system were restructured and justified in logic by G. Mints and E. Tyugu in 1982. A programming tool PRIZ that uses SSP was developed in the 1980s. A recent Integrated development environment that supports SSP is CoCoViLa — a model-based software development platform for implementing domain specific languages and developing large Java programs. == The logic of SSP == Structural synthesis of programs is a method for composing programs from already implemented components (e.g. from computer commands or software object methods) that can be considered as functions. A specification for synthesis is given in intuitionistic propositional logic by writing axioms about the applicability of functions. An axiom about the applicability of a function f is a logical implication X1 ∧ X2 ∧ ... ∧ Xm → Y1 ∧ Y2 ... Yn, where X1, X2, ... Xm are preconditions and Y1, Y2, ... Yn are postconditions of the application of the function f. In intuitionistic logic, the function f is called a realization of this formula. A precondition can be a proposition stating that input data exists, e.g. Xi may have the meaning “variable xi has received a value”, but it may denote also some other condition, e.g. that resources needed for using the function f are available, etc. A precondition may also be an implication of the same form as the axiom given above; then it is called a subtask. A subtask denotes a function that must be available as an input when the function f is applied. This function itself must be synthesized in the process of SSP. In this case, realization of the axiom is a higher order function, i.e., a function that uses another function as an input. For instance, the formula (state → nextState) ∧ initialState → result can specify a higher order function with two inputs and an output result. The first input is a function that has to be synthesized for computing nextState from state, and the second input is initialState. Higher order functions give generality to the SSP – any control structure needed in a synthesized program can be preprogrammed and used then automatically with a respective specification. In particular, the last axiom presented here is a specification of a complex program – a simulation engine for simulating dynamic systems on models where nextState can be computed from state of the system.
EyeOS
eyeOS was a web desktop for cloud computing, whose main purpose is to enable collaboration and communication among users. It is mainly written in PHP, XML, and JavaScript. It is a private-cloud application platform with a web-based desktop interface. eyeOS delivers a whole desktop from the cloud with file management, personal management information tools, and collaborative tools, with the integration of the client's applications. == History == The first publicly available eyeOS version was released on August 1, 2005, as eyeOS 0.6.0 in Olesa de Montserrat, Barcelona (Spain). A worldwide community of developers soon took part in the project and helped improve it by translating, testing, and developing it. After two years of development, the eyeOS Team published eyeOS 1.0 on June 4, 2007. Compared with previous versions, eyeOS 1.0 introduced a complete reorganization of the code and some new web technologies, like eyeSoft, a portage-based web software installation system. Moreover, eyeOS also included the eyeOS Toolkit, a set of libraries allowing easy and fast development of new web applications. With the release of eyeOS 1.1 on July 2, 2007, eyeOS changed its license and migrated from GNU GPL Version 2 to Version 3. Version 1.2 was released just a month after the 1.1 version and integrated full compatibility with Microsoft Word files. eyeOS 1.5 Gala was released on January 15, 2008. This version was the first to support both Microsoft Office and OpenOffice.org file formats for documents, presentations, and spreadsheets. With this version, eyeOS also gained the ability to import and export documents in both formats using server-side scripting. eyeOS 1.6 was released on April 25, 2008, and included many improvements such as synchronization with local computers, drag and drop, a mobile version, and more. eyeOS 1.8 Lars was released on January 7, 2009, and featured a completely rewritten file manager and a new sound API to develop media-rich applications. Later, on April 1, 2009, 1.8.5 was released with a new default theme and some rewritten apps, such as the Word Processor and the Address Book. On July 13, 2009, 1.8.6 was released with an interface for the iPhone and a new version of eyeMail with support for POP3 and IMAP. eyeOS 1.9 was released on December 29, 2009. It was followed up with the 1.9.0.1 release with minor fixes on February 18, 2010. These releases were the last of the "classic desktop" interfaces. A major re-work was completed in March 2010, now called eyeOS 2.x. However, a small group of eyeOS developers still maintain the code within the eyeOS forum, where support is provided, but the eyeOS group itself has stopped active 1.x development. It is now available as the On-eye project on GitHub. Active development was halted on 1.x as of February 3, 2010. eyeOS 2.0 release took place on March 3, 2010. This was a total restructure of the operating system. The 2.x stable is the new series of eyeOS, which is in active development and will replace 1.x as stable in a few months. It includes live collaboration and more social capabilities than eyeOS 1.x. eyeOS then released 2.2.0.0 on July 28, 2010. On December 14, 2010, a working group inside the eyeOS open-source development community began the structure development and further upgrade of eyeOS 1.9.x. The group's main goal is to continue the work eyeOS has stopped on 1.9.x. eyeOS released 2.5 on May 17, 2011. This was the last release under an open source license. It is available on SourceForge for download under another project called eyeOS 2.5 Open Source Version. On April 1, 2014, Telefónica announced their acquisition of eyeOS. eyeOS would maintain its headquarters in the Catalonia, Spain, where their staff would continue to work but now as part of Telefónica. After its integration into Telefónica, eyeOS would continue to function as an independent subsidiary under CEO Michel Kisfaludi. == Structure and API == For developers, EyeOS provides the eyeOS Toolkit, a set of libraries and functions to develop applications for eyeOS. Using the integrated Portage-based eyeSoft system, one can create their own repository for eyeOS and distribute applications through it. Each core part of the desktop is its own application, using JavaScript to send server commands as the user interacts. As actions are performed using AJAX (such as launching an application), it sends event information to the server. The server then sends back tasks for the client to do in XML format, such as drawing a widget. On the server, eyeOS uses XML files to store information. This makes it simple for a user to set up on the server, as it requires zero configuration other than the account information for the first user, making it simple to deploy. To avoid bottlenecks that flat files present, each user's information and settings are stored in different files, preventing resource starvation from occurring, though this in turn may create issues in high volume user environments due to host operating system open file descriptor limits. == Professional edition == A Professional Edition of eyeOS was launched on September 15, 2011, as an operating system for businesses. It uses a new version number and was released under version 1.0 instead of continuing with the next version number in the open source project. The Professional Edition retains the web desktop interface used by the open source version while targeting enterprise users. A host of new features designed for enterprises, like file sharing and synchronization (called eyeSync), Active Directory/LDAP connectivity, system-wide administration controls, and a local file execution tool called eyeRun were introduced. A new suite of Web Apps (a mail client, calendar, instant messaging, and collaboration tools) was also introduced, specific to the enterprise edition for the web desktop. With eyeOS Professional Edition 1.1, a to-do task manager tool, Citrix XenApp integration, and a Facebook like 'wall' for collaboration were introduced. == Awards == 2007 – Received the Softpedia's Pick award. 2007 – Finalist at SourceForge's 2007 Community Choice Awards at the "Best Project" category. The winner for that category was 7-Zip. 2007 – Won the Yahoo! Spain Web Revelation award in the Technology category. 2008 – Finalist for the Webware 100 awards by CNET, under the "Browsing" category. 2008 – Finalist at the SourceForge's 2008 Community Choice Awards at the "Most Likely to Change the World" category. The winner for that category was Linux. 2009 – Selected Project of the Month (August 2009) by SourceForge. 2009 – BMW Innovation Award. 2010 – Winner of Accelera (Ernst & Young). 2010 – Asturias & Girona Spanish Prince award “IMPULSA”. 2011 – Winner of MIT's TR35 award as Innovator of the Year in Spain. == Community == eyeOS community is formed with the eyeOS forums, which reached 10,000 members on April 4, 2008; the eyeOS wiki; and the eyeOS Application Communities, available at the eyeOS-Apps website, hosted and provided by openDesktop.org as well as Softpedia.
Cloud-based integration
Cloud-based integration is a form of systems integration business delivered as a cloud computing service that addresses data, process, service-oriented architecture (SOA) and application integration. == Description == Integration platform as a service (iPaaS) is a suite of cloud services enabling customers to develop, execute and govern integration flows between disparate applications. Under the cloud-based iPaaS integration model, customers drive the development and deployment of integrations without installing or managing any hardware or middleware. The iPaaS model allows businesses to achieve integration without big investment into skills or licensed middleware software. iPaaS used to be regarded primarily as an integration tool for cloud-based software applications, used mainly by small to mid-sized business. Over time, a hybrid type of iPaaS—hybrid-IT iPaaS—that connects cloud to on-premises, is becoming increasingly popular. Additionally, large enterprises are exploring new ways of integrating iPaaS into their existing IT infrastructures. Cloud integration was created to break down the data silos, improve connectivity and optimize the business process. Cloud integration has increased in popularity as the usage of Software as a Service solutions has grown. Prior to the emergence of cloud computing in the early 2000s, integration could be categorized as either internal or business to business (B2B). Internal integration requirements were serviced through an on-premises middleware platform and typically utilized a service bus to manage exchange of data between systems. B2B integration was serviced through EDI gateways or value-added network (VAN). The advent of SaaS applications created a new kind of demand which was met through cloud-based integration. Since their emergence, many such services have also developed the capability to integrate legacy or on-premises applications, as well as function as EDI gateways. The following essential features were proposed by one marketing company: Deployed on a multi-tenant, elastic cloud infrastructure Subscription model pricing (operating expense, not capital expenditure) No software development (required connectors should already be available) Users do not perform deployment or manage the platform itself Presence of integration management and monitoring features The emergence of this sector led to new cloud-based business process management tools that do not need to build integration layers - since those are now a separate service. Drivers of growth include the need to integrate mobile app capabilities with proliferating API publishing resources and the growth in demand for the Internet of things functionalities as more 'things' connect to the Internet.
Structured-light 3D scanner
A structured-light 3D scanner is a device used to capture the three-dimensional shape of an object by projecting light patterns, such as grids or stripes, onto its surface. The deformation of these patterns is recorded by cameras and processed using specialized algorithms to generate a detailed 3D model. Structured-light 3D scanning is widely employed in fields such as industrial design, quality control, cultural heritage preservation, augmented reality gaming, and medical imaging. Compared to laser-based 3D scanning, structured-light scanners use non-coherent light sources, such as LEDs or projectors, which enable faster data acquisition and eliminate potential safety concerns associated with lasers. However, the accuracy of structured-light scanning can be influenced by external factors, including ambient lighting conditions and the reflective properties of the scanned object. == Principle == Projecting a narrow band of light onto a three-dimensional surface creates a line of illumination that appears distorted when viewed from perspectives other than that of the projector. This distortion can be analyzed to reconstruct the geometry of the surface, a technique known as light sectioning. Projecting patterns composed of multiple stripes or arbitrary fringes simultaneously enables the acquisition of numerous data points at once, improving scanning speed. While various structured light projection techniques exist, parallel stripe patterns are among the most commonly used. By analyzing the displacement of these stripes, the three-dimensional coordinates of surface details can be accurately determined. === Generation of light patterns === Two major methods of stripe pattern generation have been established: Laser interference and projection. The laser interference method works with two wide planar laser beam fronts. Their interference results in regular, equidistant line patterns. Different pattern sizes can be obtained by changing the angle between these beams. The method allows for the exact and easy generation of very fine patterns with unlimited depth of field. Disadvantages are high cost of implementation, difficulties providing the ideal beam geometry, and laser typical effects like speckle noise and the possible self interference with beam parts reflected from objects. Typically, there is no means of modulating individual stripes, such as with Gray codes. The projection method uses incoherent light and basically works like a video projector. Patterns are usually generated by passing light through a digital spatial light modulator, typically based on one of the three currently most widespread digital projection technologies, transmissive liquid crystal, reflective liquid crystal on silicon (LCOS) or digital light processing (DLP; moving micro mirror) modulators, which have various comparative advantages and disadvantages for this application. Other methods of projection could be and have been used, however. Patterns generated by digital display projectors have small discontinuities due to the pixel boundaries in the displays. Sufficiently small boundaries however can practically be neglected as they are evened out by the slightest defocus. A typical measuring assembly consists of one projector and at least one camera. For many applications, two cameras on opposite sides of the projector have been established as useful. Invisible (or imperceptible) structured light uses structured light without interfering with other computer vision tasks for which the projected pattern will be confusing. Example methods include the use of infrared light or of extremely high framerates alternating between two exact opposite patterns. === Calibration === Geometric distortions by optics and perspective must be compensated by a calibration of the measuring equipment, using special calibration patterns and surfaces. A mathematical model is used for describing the imaging properties of projector and cameras. Essentially based on the simple geometric properties of a pinhole camera, the model also has to take into account the geometric distortions and optical aberration of projector and camera lenses. The parameters of the camera as well as its orientation in space can be determined by a series of calibration measurements, using photogrammetric bundle adjustment. === Analysis of stripe patterns === There are several depth cues contained in the observed stripe patterns. The displacement of any single stripe can directly be converted into 3D coordinates. For this purpose, the individual stripe has to be identified, which can for example be accomplished by tracing or counting stripes (pattern recognition method). Another common method projects alternating stripe patterns, resulting in binary Gray code sequences identifying the number of each individual stripe hitting the object. An important depth cue also results from the varying stripe widths along the object surface. Stripe width is a function of the steepness of a surface part, i.e. the first derivative of the elevation. Stripe frequency and phase deliver similar cues and can be analyzed by a Fourier transform. Finally, the wavelet transform has recently been discussed for the same purpose. In many practical implementations, series of measurements combining pattern recognition, Gray codes and Fourier transform are obtained for a complete and unambiguous reconstruction of shapes. Another method also belonging to the area of fringe projection has been demonstrated, utilizing the depth of field of the camera. It is also possible to use projected patterns primarily as a means of structure insertion into scenes, for an essentially photogrammetric acquisition. === Precision and range === The optical resolution of fringe projection methods depends on the width of the stripes used and their optical quality. It is also limited by the wavelength of light. An extreme reduction of stripe width proves inefficient due to limitations in depth of field, camera resolution and display resolution. Therefore, the phase shift method has been widely established: A number of at least 3, typically about 10 exposures are taken with slightly shifted stripes. The first theoretical deductions of this method relied on stripes with a sine wave shaped intensity modulation, but the methods work with "rectangular" modulated stripes, as delivered from LCD or DLP displays as well. By phase shifting, surface detail of e.g. 1/10 the stripe pitch can be resolved. Current optical stripe pattern profilometry hence allows for detail resolutions down to the wavelength of light, below 1 micrometer in practice or, with larger stripe patterns, to approx. 1/10 of the stripe width. Concerning level accuracy, interpolating over several pixels of the acquired camera image can yield a reliable height resolution and also accuracy, down to 1/50 pixel. Arbitrarily large objects can be measured with accordingly large stripe patterns and setups. Practical applications are documented involving objects several meters in size. Typical accuracy figures are: Planarity of a 2-foot (0.61 m) wide surface, to 10 micrometres (0.00039 in). Shape of a motor combustion chamber to 2 micrometres (7.9×10−5 in) (elevation), yielding a volume accuracy 10 times better than with volumetric dosing. Shape of an object 2 inches (51 mm) large, to about 1 micrometre (3.9×10−5 in) Radius of a blade edge of e.g. 10 micrometres (0.00039 in), to ±0.4 μm === Navigation === As the method can measure shapes from only one perspective at a time, complete 3D shapes have to be combined from different measurements in different angles. This can be accomplished by attaching marker points to the object and combining perspectives afterwards by matching these markers. The process can be automated, by mounting the object on a motorized turntable on robotic inspection cell, or CNC positioning device. Markers can as well be applied on a positioning device instead of the object itself. The 3D data gathered can be used to retrieve CAD (computer aided design) data and models from existing components (reverse engineering), hand formed samples or sculptures, natural objects or artifacts. === Challenges === As with all optical methods, reflective or transparent surfaces raise difficulties. Reflections cause light to be reflected either away from the camera or right into its optics. In both cases, the dynamic range of the camera can be exceeded. Transparent or semi-transparent surfaces also cause major difficulties. In these cases, coating the surfaces with a thin opaque lacquer just for measuring purposes is a common practice. A recent method handles highly reflective and specular objects by inserting a 1-dimensional diffuser between the light source (e.g., projector) and the object to be scanned. Alternative optical techniques have been proposed for handling perfectly transparent and specular objects. Double reflections and inter-reflections can cause the stripe pattern to be overlaid with unwanted ligh
BioBIKE
BioBike(nee. BioLingua ) is a cloud-based, through-the-web programmable (Paas) symbolic biocomputing and bioinformatics platform that aims to make computational biology, and especially intelligent biocomputing (that is, the application of Artificial Intelligence to computational biology) accessible to research scientists who are not expert programmers. == Unique capabilities == BioBIKE is an integrated symbolic biocomputing and bioinformatics platform, built from the start as an entirely (what is now called) cloud-based architecture where all computing is done in remote servers, and all user access is accomplished through web browsers. BioBIKE has a built-in frame system in which all objects, data, and knowledge are represented. This enables code written either in the native Lisp, in the visual programming language, or systems of rules expressed in the SNARK theorem prover to access the whole of biological knowledge in an integrated manner. For its time (released in 2002) it was unique in permitting users to create fully functional biocomputing programs that run on the back-end servers entirely through the web browser UI. (In modern terms it was one of the first PaaS (Platform as a Service) systems, predating even Salesforce in this capability.) Initially this programming was carried out in raw Lisp, but Jeff Elhai's team at VCU, with NSF funding, created an entirely graphical programming environment on top of BioBIKE based upon the Boxer-style programming environments. Being a multi-headed, multi-threaded, multi-user, multi-tenancy cloud-based system, BioBIKE users were able to directly work together through their web browsers, remotely sharing the same listener and memory space. This permitted a unique sort of collaboration, discussed in Shrager (2007). A specialized offshoot of BioBIKE called "BioDeducta" includes SRI's SNARK theorem prover, offering unique "deductive biocomputing" capabilities. == Implementation == BioBIKE is open-source software implemented using the Lisp programming language. Continuing development takes place by the BioBIKE team centered at Virginia Commonwealth University . == History == BioBIKE was originally called "BioLingua", and was developed by Jeff Shrager at The Carnegie Inst. of Washington Dept. of Plant Biology, and JP Massar with funding from NASA's Astrobiology Division. Shrager and Massar wanted to create a web-based, multi-user Lisp Machine, specialized for bioinformatics. Other early contributors to the project included Mike Travers, and Jeff Elhai of VCU. Elhai obtained continuing funding from the National Science Foundation for the project, which was renamed BioBIKE. Elhai and colleagues added BioBIKE's unique visual programming language. Shrager, meanwhile, collaborated with Richard Waldinger at SRI to build SRI's (SNARK) theorem prover into BioBIKE, creating a deductive biocomputing system, called BioDeducta. == Instances == There used to be a number of BioBIKE verticals in different biological domains, including viral pathogens, cyanobacteria and other bacteria, Arabidopsis thaliana, and several others described in the references.