Indic OCR refers to the process of converting text images written in Indic scripts into e-text using Optical character recognition (OCR) techniques. Broadly, it can also refer to the OCR systems of Brahmic scripts for languages of South Asia and Southeast Asia, not just the scripts of the Indian subcontinent, which are all written in an abugida-based writing system. OCR for Latin characters is still not 100% accurate but a relatively high degree of accuracy in conversion has been able to be achieved. Such accuracy has not yet been able to be achieved for Indic scripts using OCR. This is due in part to the writing systems of Indic languages as well as a lack of standard representation, encoding, and support among operating systems and keyboards. The Centre for Development of Advanced Computing (C-DAC) and Technology Development for Indian Languages, the premier R&D organisation of the Ministry of Electronics and Information Technology (also known as MeitY) of India have carried out many projects relating to OCR. Their projects include OCR for Malayalam, Odia, Punjabi, Telugu and Devanagari script. == Properties of Indian writing systems == There are 22 officially recognised languages in India. Of these, Hindi, Bengali and Punjabi are the most widely spoken Indo-Aryan languages and are also the fourth, seventh and tenth most widely spoken languages in the world respectively. Two or more languages can be written with same script. For example, Devanagari is used to write Hindi, Marathi, Rajasthani, Sanskrit, Bhojpuri and others, while Eastern Nagari is used to write Bengali, Assamese, Manipuri and others. Apart from basic characters as consonants and vowels, most Indic languages combine 2 or more basic characters to form compound characters. The shape of a compound character is more complex than the constituent basic characters. Some Indo-Aryan languages (including Hindi and Punjabi) have a horizontal line over the characters, while other languages (including Gujarati) and Dravidian languages (Malayalam, Kannada, Tamil, and Telugu) do not. These are some of the main challenges for creating a single OCR for all Indic languages. Indic OCR also generally includes support for recently invented scripts in India like Ol Chiki, Warang Citi, Mundari Bani, etc. which are mainly created for writing Munda languages of Austroasiatic family. The concept of upper/lower case is absent in Indic scripts. Apart from Urdu, Sindhi, Kashmiri and Thaana, all other Indic languages are written from left to right. == Examples == SanskritOCR - OCR software for Sanskrit, Hindi and other Indo-Aryan languages based on the Devanagari script. Sanskrit OCR is developed by a Sanskrit scholar from Germany - Dr. Oliver Hellwig of Department for Languages and Cultures of Southern Asia, Freie Universität Berlin. The official website is in German. The interface of earlier versions of the software was also in German, but later versions have an English interface too. E-aksharayan - Optical character recognition engine for Indian languages Chitrankan - This technology was developed by ISI, Kolkata, and transferred to C-DAC. It processes printed Hindi text from a scanner or from an image. Indic OCR models for Tesseract (software) == OCR in use == OCR has been used for Wikisource and other projects.
Plumbr
Plumbr was an Estonian software product company founded in late 2011 that developed performance monitoring software. The Plumbr product was built on top of a proprietary algorithm that automatically detected the root causes of performance issues by interpreting application performance data. In October 2020, Plumbr was acquired by Splunk. == Products == Plumbr monitored customers' JVM applications for memory leaks, garbage collection pauses and locked threads. Plumbr problem detection algorithms were based on analysis of performance data of thousands of applications. Plumbr consisted of an agent and a portal. Plumbr Agent was attached to application runtime and sent memory usage and garbage collection information to Plumbr Portal. On Plumbr Portal one could see information such as heap and permgen memory usage, garbage collection pauses' and lock contention duration. Clients that were not able to send data to third parties could order a self-hosted portal and have a full solution in-house. In case of performance incidents Plumbr provided its users with information on problem severity and problem's root cause location in source code or runtime configuration, and listed the steps needed to take to remediate the problem. Clients included NASA, NATO, Dell, HBO, Experian, EMC Corporation.
CAMeL-View TestRig
CAMeL-View is a software application, which is used for the model based design of mechatronic systems (multi-body simulation, block diagrams, pneumatic systems, hydraulic systems, general simulation, linear analysis and Hardware-in-the-Loop). CAMeL-View enables object-oriented model creation of mechatronic systems through the use of graphic blocks. The basic elements of multi-body system dynamics, control technology, hydraulics and hardware connectivity support the modeling process. The user’s proprietary C-Code can also be integrated into the models, which allows CAMeL-View TestRig to be implemented in all phases of the model based design process ( modeling, physical testing and prototyping), and lends itself especially well to mechatronic system design. The model’s structure is described and displayed with the help of directional connectors. Physical connections (such as mechanical or hydraulic linkages) as well as input and output connections (signal flow) are also available. The input of equations is done via mathematical expressions, e.g. the input of constitutive differential equations in vector and matrix form. Based on the model’s structure, the descriptive equations are converted into non-linear state space representations and converted into executable C-Code. CAMeL-View supports the simulation process with a configurable “experiment environment” (for simulator and instrumentation components) which allows the user to apply simulation models to supported targets (MPC5200, TriCore, X86, etc.) without the need for additional software tools for Hardware-in-the-Loop applications. In addition, the generation of so-called S-Functions for use in Simulink and the generation of ANSI C-Code for use in stand-alone simulators is also supported. A particularly noteworthy feature in CAMeL-View TestRig is the way in which the descriptive equations for multi-body system models are created. All multi-body simulation formalisms used for code generation create their equations in the form of typical explicit differential equations (ODE). This is especially important in Hardware-in-the-Loop applications where the calculation of simulation results within a specific, defined time frame must be assured. Only then is it possible to implement complex multi-body simulation models for Hardware-in-the-Loop applications under stringent real-time conditions. These constraints cannot be met when using DAE-based methods. Additional Toolboxes are available for linear analysis (Eigenvalues, pole-zero analysis, frequency response, etc.) of VRML-based animation. Development of CAMeL-View began in 1991 in the Paderborn Mechatronic Laboratory of Professor Dr. Ing. J. Lückel. The software was based on predecessors that had been developed there since 1986. The name stands for Computer Aided Mechatronic Laboratory – Virtual Engineering Workbench and describes the basic intent of one of the specific demands placed on development engineers in the computer lab.
Dimensions CM
Dimensions CM is a software change and configuration management product developed by OpenText Corporation. It includes revision control, change, build and release management capabilities. Since 2014 (v14.1) Dimensions CM includes PulseUno module providing Code review and Continuous integration capabilities. Starting with the version 14.5.2 (2020) it can also serve as a binary repository manager. == History == Previous product names: PCMS Dimensions (SQL Software) PVCS Dimensions (Merant, Intersolv)
Floyd–Steinberg dithering
Floyd–Steinberg dithering is an image dithering algorithm first published in 1976 by Robert W. Floyd and Louis Steinberg. It is commonly used by image manipulation software, for example, when converting an image from a Truecolor 24-bit PNG format into a GIF format, which is restricted to a maximum of 256 colors. == Implementation == The algorithm achieves dithering using error diffusion, meaning it pushes (adds) the residual quantization error of a pixel onto its neighboring pixels, to be quantized after. It spreads the debt out according to the distribution (shown as a map of the neighboring pixels): [ ∗ 7 16 … … 3 16 5 16 1 16 … ] {\displaystyle {\begin{bmatrix}&&&{\frac {\displaystyle 7}{\displaystyle 16}}&\ldots \\\ldots &{\frac {\displaystyle 3}{\displaystyle 16}}&{\frac {\displaystyle 5}{\displaystyle 16}}&{\frac {\displaystyle 1}{\displaystyle 16}}&\ldots \\\end{bmatrix}}} The pixel indicated with a star () indicates the pixel currently being scanned, and the blank pixels are the previously scanned pixels. The specific values (7/16, 3/16, 5/16, 1/16) were originally found by trial-and-error, "guided by the desire to have a region of desired density 0.5 come out as a checkerboard pattern". The algorithm scans the image from left to right, top to bottom, quantizing pixel values one by one. Each time, the quantization error is transferred to the neighboring pixels, while not affecting the pixels that already have been quantized. Hence, if a number of pixels have been rounded downwards, it becomes more likely that the next pixel is rounded upwards, such that on average, the quantization error is close to zero. The diffusion coefficients have the property that if the original pixel values are exactly halfway in between the nearest available colors, the dithered result is a checkerboard pattern. For example, 50% grey data could be dithered as a black-and-white checkerboard pattern. For optimal dithering, the counting of quantization errors should be in sufficient accuracy to prevent rounding errors from affecting the result. For correct results, all values should be linearized first, rather than operating directly on sRGB values as is common for images stored on computers. In some implementations, the horizontal direction of scan alternates between lines; this is called "serpentine scanning" or boustrophedon transform dithering. The algorithm described above is in the following pseudocode. This works for any approximately linear encoding of pixel values, such as 8-bit integers, 16-bit integers or real numbers in the range [0, 1]. for each y from top to bottom do for each x from left to right do oldpixel := pixels[x][y] newpixel := find_closest_palette_color(oldpixel) pixels[x][y] := newpixel quant_error := oldpixel - newpixel pixels[x + 1][y ] := pixels[x + 1][y ] + quant_error × 7 / 16 pixels[x - 1][y + 1] := pixels[x - 1][y + 1] + quant_error × 3 / 16 pixels[x ][y + 1] := pixels[x ][y + 1] + quant_error × 5 / 16 pixels[x + 1][y + 1] := pixels[x + 1][y + 1] + quant_error × 1 / 16 When converting grayscale pixel values from a high to a low bit depth (e.g. 8-bit grayscale to 1-bit black-and-white), find_closest_palette_color() may perform just a simple rounding, for example: find_closest_palette_color(oldpixel) = round(oldpixel / 255) The pseudocode can result in pixel values exceeding the valid values (such as greater than 255 in 8-bit grayscale images). Such values should ideally be handled by the find_closest_palette_color() function, rather than clipping the intermediate values, since a subsequent error may bring the value back into range. However, if fixed-width integers are used, wrapping of intermediate values would cause inversion of black and white, and so should be avoided. The find_closest_palette_color() implementation is nontrivial for a palette that is not evenly distributed, however small inaccuracies in selecting the correct palette color have minimal visual impact due to error being propagated to future pixels. A nearest neighbor search in 3D is frequently used.
Yap (company)
Yap Speech Cloud was a multimodal speech recognition system developed by American technology company Yap Inc. It offered a fully cloud-based speech-to-text transcription platform that was used by customers such as Microsoft. The Company was a contestant at the inaugural TechCrunch conference and was subsequently acquired by Amazon in September 2011 to help develop products such as Alexa Voice Service, Echo, and Fire TV.
IBM ALP
IBM Assembly Language Processor (ALP) is an assembler written by IBM for 32-bit OS/2 Warp (OS/2 3.0), which was released in 1994. ALP accepts source programs compatible with Microsoft Macro Assembler (MASM) version 5.1, which was originally used to build many of the device drivers included with OS/2. For OS/2 versions 3 and 4, ALP was distributed, along with other tools and documentation, as part of the Device Driver Kit (DDK). The DDK was withdrawn in 2004 as part of IBM's discontinuance of OS/2.