Tagsistant is a semantic file system for the Linux kernel, written in C and based on FUSE. Unlike traditional file systems that use hierarchies of directories to locate objects, Tagsistant introduces the concept of tags. == Design and differences with hierarchical file systems == In computing, a file system is a type of data store which could be used to store, retrieve and update files. Each file can be uniquely located by its path. The user must know the path in advance to access a file and the path does not necessarily include any information about the content of the file. Tagsistant uses a complementary approach based on tags. The user can create a set of tags and apply those tags to files, directories and other objects (devices, pipes, ...). The user can then search all the objects that match a subset of tags, called a query. This kind of approach is well suited for managing user contents like pictures, audio recordings, movies and text documents but is incompatible with system files (like libraries, commands and configurations) where the univocity of the path is a security requirement to prevent the access to a wrong content. == The tags/ directory == A Tagsistant file system features four main directories: archive/ relations/ stats/ tags/ Tags are created as sub directories of the tags/ directory and can be used in queries complying to this syntax: tags/subquery/[+/subquery/[+/subquery/]]/@/ where a subquery is an unlimited list of tags, concatenated as directories: tag1/tag2/tag3/.../tagN/ The portion of a path delimited by tags/ and @/ is the actual query. The +/ operator joins the results of different sub-queries in one single list. The @/ operator ends the query. To be returned as a result of the following query: tags/t1/t2/+/t1/t4/@/ an object must be tagged as both t1/ and t2/ or as both t1/ and t4/. Any object tagged as t2/ or t4/, but not as t1/ will not be retrieved. The query syntax deliberately violates the POSIX file system semantics by allowing a path token to be a descendant of itself, like in tags/t1/t2/+/t1/t4/@ where t1/ appears twice. As a consequence a recursive scan of a Tagsistant file system will exit with an error or endlessly loop, as done by Unix find: This drawback is balanced by the possibility to list the tags inside a query in any order. The query tags/t1/t2/@/ is completely equivalent to tags/t2/t1/@/ and tags/t1/+/t2/t3/@/ is equivalent to tags/t2/t3/+/t1/@/. The @/ element has the precise purpose of restoring the POSIX semantics: the path tags/t1/@/directory/ refers to a traditional directory and a recursive scan of this path will properly perform. == The reasoner and the relations/ directory == Tagsistant features a simple reasoner which expands the results of a query by including objects tagged with related tags. A relation between two tags can be established inside the relations/ directory following a three level pattern: relations/tag1/rel/tag2/ The rel element can be includes or is_equivalent. To include the rock tag in the music tag, the Unix command mkdir can be used: mkdir -p relations/music/includes/rock The reasoner can recursively resolve relations, allowing the creation of complex structures: mkdir -p relations/music/includes/rock mkdir -p relations/rock/includes/hard_rock mkdir -p relations/rock/includes/grunge mkdir -p relations/rock/includes/heavy_metal mkdir -p relations/heavy_metal/includes/speed_metal The web of relations created inside the relations/ directory constitutes a basic form of ontology. == Autotagging plugins == Tagsistant features an autotagging plugin stack which gets called when a file or a symlink is written. Each plugin is called if its declared MIME type matches The list of working plugins released with Tagsistant 0.6 is limited to: text/html: tags the file with each word in
and <keywords> elements and with document, webpage and html too image/jpeg: tags the file with each Exif tag == The repository == Each Tagsistant file system has a corresponding repository containing an archive/ directory where the objects are actually saved and a tags.sql file holding tagging information as an SQLite database. If the MySQL database engine was specified with the --db argument, the tags.sql file will be empty. Another file named repository.ini is a GLib ini store with the repository configuration. Tagsistant 0.6 is compatible with the MySQL and Sqlite dialects of SQL for tag reasoning and tagging resolution. While porting its logic to other SQL dialects is possible, differences in basic constructs (especially the INTERSECT SQL keyword) must be considered. == The archive/ and stats/ directories == The archive/ directory has been introduced to provide a quick way to access objects without using tags. Objects are listed with their inode number prefixed. The stats/ directory features some read-only files containing usage statistics. A file configuration holds both compile time information and current repository configuration. == Main criticisms == It has been highlighted that relying on an external database to store tags and tagging information could cause the complete loss of metadata if the database gets corrupted. It has been highlighted that using a flat namespace tends to overcrowd the tags/ directory. This could be mitigated introducing triple tags.</p>
<h2><a href="https://aizhi.co/html/345a199653.html" title="Automated storage and retrieval system">Automated storage and retrieval system</a></h2>
<p>An automated storage and retrieval system (ASRS or AS/RS) consists of a variety of computer-controlled systems for automatically placing and retrieving loads from defined storage locations. Automated storage and retrieval systems (AS/RS) are typically used in applications where: There is a very high volume of loads being moved into and out of storage Storage density is important because of space constraints No value is added in this process (no processing, only storage and transport) Accuracy is critical because of potential expensive damages to the load An AS/RS can be used with standard loads as well as nonstandard loads, meaning that each standard load can fit in a uniformly-sized volume; for example, the film canisters in the image of the Defense Visual Information Center are each stored as part of the contents of the uniformly sized metal boxes, which are shown in the image. Standard loads simplify the handling of a request of an item. In addition, audits of the accuracy of the inventory of contents can be restricted to the contents of an individual metal box, rather than undergoing a top-to-bottom search of the entire facility, for a single item. They can also be used in self storage places. == Overview == AS/RS systems are designed for automated storage and retrieval of parts and items in manufacturing, distribution, retail, wholesale and institutions. They first originated in the 1960s, initially focusing on heavy pallet loads but with the evolution of the technology the handled loads have become smaller. The systems operate under computerized control, maintaining an inventory of stored items. Retrieval of items is accomplished by specifying the item type and quantity to be retrieved. The computer determines where in the storage area the item can be retrieved from and schedules the retrieval. It directs the proper automated storage and retrieval machine (SRM) to the location where the item is stored and directs the machine to deposit the item at a location where it is to be picked up. A system of conveyors and or automated guided vehicles is sometimes part of the AS/RS system. These take loads into and out of the storage area and move them to the manufacturing floor or loading docks. To store items, the pallet or tray is placed at an input station for the system, the information for inventory is entered into a computer terminal and the AS/RS system moves the load to the storage area, determines a suitable location for the item, and stores the load. As items are stored into or retrieved from the racks, the computer updates its inventory accordingly. The benefits of an AS/RS system include reduced labor for transporting items into and out of inventory, reduced inventory levels, more accurate tracking of inventory, and space savings. Items are often stored more densely than in systems where items are stored and retrieved manually. Within the storage, items can be placed on trays or hang from bars, which are attached to chains/drives in order to move up and down. The equipment required for an AS/RS include a storage & retrieval machine (SRM) that is used for rapid storage and retrieval of material. SRMs are used to move loads vertically or horizontally, and can also move laterally to place objects in the correct storage location. The trend towards Just In Time production often requires sub-pallet level availability of production inputs, and AS/RS is a much faster way of organizing the storage of smaller items next to production lines. The Material Handling Institute of America (MHIA), the non-profit trade association for the material handling world, and its members have categorised AS/RS into two primary segments: Fixed Aisle and Carousels/Vertical Lift Modules (VLMs). Both sets of technologies provide automated storage and retrieval for parts and items, but use different technologies. Each technology has its unique set of benefits and disadvantages. Fixed Aisle systems are characteristically larger systems whereas carousels and Vertical Lift Modules are used individually or grouped, but in small to medium-sized applications. A fixed-aisle AS/R machine (stacker crane) is one of two main designs: single-masted or double masted. Most are supported on a track and ceiling guided at the top by guide rails or channels to ensure accurate vertical alignment, although some are suspended from the ceiling. The 'shuttles' that make up the system travel between fixed storage shelves to deposit or retrieve a requested load (ranging from a single book in a library system to a several ton pallet of goods in a warehouse system). The entire unit moves horizontally within an aisle, while the shuttles are able to elevate up to the necessary height to reach the load, and can extend and retract to store or retrieve loads that are several positions deep in the shelving. A semi-automated system can be achieved by utilizing only specialized shuttles within an existing rack system. Another AS/RS technology is known as shuttle technology. In this technology the horizontal movement is made by independent shuttles each operating on one level of the rack while a lift at a fixed position within the rack is responsible for the vertical movement. By using two separate machines for these two axes the shuttle technology is able to provide higher throughput rates than stacker cranes. Storage and Retrieval Machines pick up or drop off loads to the rest of the supporting transportation system at specific stations, where inbound and outbound loads are precisely positioned for proper handling. In addition, there are several types of Automated Storage & Retrieval Systems (AS/RS) devices called Unit-load AS/RS, Mini-load AS/RS, Mid-Load AS/RS, Vertical Lift Modules (VLMs), Horizontal Carousels and Vertical Carousels. These systems are used either as stand-alone units or in integrated workstations called pods or systems. These units are usually integrated with various types of pick to light systems and use either a microprocessor controller for basic usage or inventory management software. These systems are ideal for increasing space utilization up to 90%, productivity levels by 90%, accuracy to 99.9%+ levels and throughput up to 750 lines per hour/per operator or more depending on the configuration of the system. == Horizontal carousels == Robotic Inserter/Extractor devices can be used for horizontal carousels. The robotic device is positioned in the front or rear of up to three horizontal carousels tiered high. The robot grabs the tote required in the order and often replenishes at the same time to speed up throughput. The tote(s) are then delivered to a conveyor, which routes it to a work station for picking or replenishing. Up to eight transactions per minute per unit can be done. Totes or containers up to 36" x 36" x 36" can be used in a system. On a simplistic level, horizontal carousels are also often used as "rotating shelving". With simple "fetch" command, items are brought to the operator and otherwise wasted space is eliminated. AS/RS Applications: Most applications of AS/RS technology have been associated with warehousing and distribution operations. An AS/RS can also be used to store raw materials and work in process in manufacturing. Three application areas can be distinguished for AS/RS: (1) Unit load storage and handling, (2) Order picking, and (3) Work in process storage. Unit load storage and retrieval applications are represented by unit load AS/RS and deep-lane storage systems. These kinds of applications are commonly found in warehousing for finishing goods in a distribution center, rarely in manufacturing. Deep-lane systems are used in the food industry. As described above, order picking involves retrieving materials in less than full unit load quantities. Minilpass, man-on board, and items retrieval systems are used for this second application area. Work in process storage is a more recent application of automated storage technology. While it is desirable to minimize the amount of work in process, WIP is unavoidable and must be effectively managed. Automated storage systems, either automated storage/retrieval systems or carousel systems, represent an efficient way to store materials between processing steps, particularly in batch and job shop production. In high production, work in process is often carried between operations by conveyor system, which this serve both storage and transport functions. === Inventory Category-specific AS/RS === Each inventory category—raw materials, work-in-process, and finished goods—requires its own specialized Automated Storage and Retrieval System (AS/RS). Particularly for work-in-process (WIP) inventories, due to variations in manufacturing processes, the AS/RS systems are significantly different in design and function, tailored specifically to match unique handling, storage, and retrieval requirements === Installed applications === Installed applications of this technology can be wide-ranging. In some librarie</p>
<h2><a href="https://aizhi.co/news/76c999914.html" title="MADI">MADI</a></h2>
<p>Multichannel Audio Digital Interface (MADI) standardized as AES10 by the Audio Engineering Society (AES) defines the data format and electrical characteristics of an interface that carries multiple channels of digital audio. The AES first documented the MADI standard in AES10-1991 and updated it in AES10-2003 and AES10-2008. The MADI standard includes a bit-level description and has features in common with the two-channel AES3 interface. MADI supports serial digital transmission over coaxial cable or fibre-optic lines of 28, 56, 32, or 64 channels; and sampling rates to 96 kHz and beyond with an audio bit depth of up to 24 bits per channel. Like AES3 and ADAT Lightpipe, it is a unidirectional interface from one sender to one receiver. == Development and applications == MADI was developed by AMS Neve, Solid State Logic, Sony and Mitsubishi and is widely used in the audio industry, especially in the professional audio sector. It provides advantages over other audio digital interface protocols and standards such as AES3, ADAT Lightpipe, TDIF (Tascam Digital Interface), and S/PDIF (Sony/Philips Digital Interface). These advantages include: Support for a greater number of channels per line Use of coaxial and optical fiber media that support transmission of audio signals over 100 meters, up to 3000 meters over multi-mode and 40,000 meters over single-mode optical fiber The original specification (AES10-1991) defined the MADI link as a 56-channel transport for linking large-format mixing consoles to digital multitrack recording devices. Large broadcast studios also adopted it for routing multi-channel audio throughout their facilities. The 2003 revision (AES10-2003) adds a 64-channel capability by removing varispeed operation and supports 96 kHz sampling frequency with reduced channel capacity. The latest AES10-2008 standard includes minor clarifications and updates to correspond to the current AES3 standard. Audio over Ethernet of various types is the primary alternative to MADI for transport of many channels of professional digital audio. == Transmission format == MADI links use a transmission format similar to Fiber Distributed Data Interface (FDDI) networking. Since MADI is most often transmitted on copper links via 75-ohm coaxial cables, it more closely compares to the FDDI specification for copper-based links, called CDDI. AES10-2003 recommends using BNC connectors with coaxial cables and SC connectors with optic fibers. MADI over fibre can support a range of up to 2 km. The basic data rate is 100 Mbit/s of data using 4B5B encoding to produce a 125 MHz physical baud rate. Unlike AES3, this clock is not synchronized to the audio sample rate, and the audio data payload is padded using JK sync symbols. Sync symbols may be inserted at any subframe boundary, and must occur at least once per frame. Though the standard disassociates the transmission clock from the audio sample rate, and thus requires a separate word clock connection to maintain synchronization, some vendors do give the option of locking to parts of the transmission timing information for purposes of deriving a word clock. The audio data is almost identical to the AES3 payload, though with more channels. Rather than letters, MADI assigns channel numbers from 0–63. Frame synchronization is provided by sync symbols outside the data itself, rather than an embedded preamble sequence, and the first four time slots of each sub-channel are encoded as normal data, used for sub-channel identification: Bit 0: Set to 1 to mark channel 0, the first channel in each frame Bit 1: Set to 1 to indicate that this channel is active (contains interesting data) Bit 2: notA/B channel marker, used to mark left (0) and right (1) channels. Generally, even channels are A and odd channels are B. Bit 3: Set to 1 to mark the beginning of a 192-sample data block == Sampling frequency == The original AES10-1991 specification allowed 56 channels at sample rates from 32 to 48 kHz with an additional vari-speed range of ± 12.5%. This leads to a total range of 28 to 54 kHz. At the highest frequency, this produces a total of 56 × 32 × 54 = 96768 kbit/s, leaving 3.232% of the channel for synchronization marks and transmit clock error. The 2003 revision specifies different relations between sampling frequency and number of channels. 32 kHz to 48 kHz ± 12.5%, 56 channels; 32 kHz to 48 kHz nominal, 64 channels; 64 kHz to 96 kHz ± 12.5%, 28 channels. With a 48 kHz sampling frequency, 64 channels take 64 × 32 × 48000 = 98.304 Mbit/s. Adding the minimum 8 × 58 kbit/s of framing produces 98688 bit/s, leaving 1.312% free for timing variation and other overhead. Both versions of the standard accommodate higher sampling frequencies (for example, 96 kHz or 192 kHz) by using two or more channels per audio sample on the link.</p>
<h2><a href="https://aizhi.co/html/407d999583.html" title="Control communications">Control communications</a></h2>
<p>In telecommunications, control communications is the branch of technology devoted to the design, development, and application of communications facilities used specifically for control purposes, such as for controlling (a) industrial processes, (b) movement of resources, (c) electric power generation, distribution, and utilization, (d) communications networks, and (e) transportation systems.</p>
<h2><a href="https://aizhi.co/html/29d999961.html" title="Digital Cinema Initiatives">Digital Cinema Initiatives</a></h2>
<p>Digital Cinema Initiatives, LLC (DCI) is a consortium of major motion picture studios, formed to establish specifications for a common systems architecture for digital cinema systems. The organization was formed in March 2002 by Metro-Goldwyn-Mayer, Paramount Pictures, Sony Pictures, 20th Century Studios, Universal Studios, Walt Disney Studios and Warner Bros. Entertainment The primary purpose of DCI is to establish and document specifications for an open architecture for digital cinema that ensures a uniform and high level of technical performance, reliability and quality. By establishing a common set of content requirements, distributors, studios, exhibitors, d-cinema manufacturers and vendors can be assured of interoperability and compatibility. Because of the relationship of DCI to many of Hollywood's key studios, conformance to DCI's specifications is considered a requirement by software developers or equipment manufacturers targeting the digital cinema market. == Specification == On July 20, 2005, DCI released Version 1.0 of its "Digital Cinema System Specification", commonly referred to as the "DCI Specification". The document describes overall system requirements and specifications for digital cinema. Between March 28, 2006, and March 21, 2007, DCI issued 148 errata to Version 1.0. DCI released Version 1.1 of the DCI Specification on April 12, 2007, incorporating the previous 148 errata into the DCI Specification. On April 15, 2007, at the annual NAB Digital Cinema Summit, DCI announced the new version, as well as some future plans. They released the "Stereoscopic Digital Cinema Addendum" to begin to establish 3-D technical specifications in response to the popularity of 3-D stereoscopic films. It was also announced "which studios would take over the leadership roles in DCI after the current leadership term expires at the end of September." Subsequently, between August 27, 2007, and February 1, 2008, DCI issued 100 errata to Version 1.1. So, DCI released Version 1.2 of the DCI Specification on March 7, 2008, again incorporating the previous 100 errata into the specification document. An additional 96 errata were issued by August 30, 2012, so a revised Version 1.2 incorporating those additional errata was approved on October 10, 2012. DCI approved DCI Specification Version 1.3 on June 27, 2018, integrating the 45 errata issued to the previous version into a new document. On July 20, 2020, fifteen years to the day after Version 1.0, DCI issued a new DCI Specification Version 1.4 that assimilated 29 errata issued since Version 1.3. On October 13, 2021, DCI approved a new DCI Specification Version 1.4.1 that integrated the 23 errata that had been issued to DCI Specification Version 1.4. For the convenience of users, DCI also created an online HTML version of DCI Specification, Version 1.4.1. Due to the HTML conversion process, the footnotes in the DCSS now appear as endnotes. The PDF version contains pagination and page numbers whereas the HTML version does not. DCI Specification Version 1.4.2, dated June 15, 2022, includes revisions and refinements respecting Object-Based Audio Essence (OBAE), also known as Immersive Audio Bitstream (IAB). Version 1.4.2 also implements post-show log record collection utilizing SMPTE 430-17 SMS-OMB Communications Protocol Specification. Additionally, Version 1.4.2 incorporated two prior addenda: the Digital Cinema Object-Based Audio Addendum, dated October 1, 2018 and the Stereoscopic Digital Cinema Addendum, Version 1.0, dated July 11, 2007. Users using Version 1.4.2 no longer need to refer to the separate addenda. Previous DCSS versions are archived on the DCI web site. Based on many SMPTE and ISO standards, such as JPEG 2000-compressed image and "broadcast wave" PCM/WAV sound, the DCI Specification explains the route to create an entire Digital Cinema Package (DCP) from a raw collection of files known as the Digital Cinema Distribution Master (DCDM), as well as the specifics of its content protection, encryption, and forensic marking. The DCI Specification also establishes standards for the decoder requirements and the presentation environment itself, such as ambient light levels, pixel aspect and shape, image luminance, white point chromaticity, and those tolerances to be kept. Even though it specifies what kind of information is required, the DCI Specification does not include specific information about how data within a distribution package is to be formatted. Formatting of this information is defined by the Society of Motion Picture and Television Engineers (SMPTE) digital cinema standards and related documents. == Image and audio capability overview == === 2D image === 2048×1080 (2K) at 24 frame/s or 48 frame/s, or 4096×2160 (4K) at 24 frame/s In 2K, for Scope (2.39:1) presentation 2048×858 pixels of the imager is used In 2K, for Flat (1.85:1) presentation 1998×1080 pixels of the imager is used In 4K, for Scope (2.39:1) presentation 4096×1716 pixels of the imager is used In 4K, for Flat (1.85:1) presentation 3996×2160 pixels of the imager is used 12 bits per color component (36 bits per pixel) via dual HD-SDI (encrypted) 10 bits only permitted for 2K at 48 frame/s CIE XYZ color space, gamma-corrected TIFF 6.0 container format (one file per frame) JPEG 2000 compression From 0 to 5 or from 1 to 6 wavelet decomposition levels for 2K or 4K resolutions, respectively Compression rate of 4.71 bits/pixel (2K @ 24 frame/s), 2.35 bits/pixel (2K @ 48 frame/s), 1.17 bits/pixel (4K @ 24 frame/s) 250 Mbit/s maximum image bit rate === Stereoscopic 3D image === 2048×1080 (2K) at 48 frame/s - 24 frame/s per eye (4096×2160 4K not supported) In 2K, for Scope (2.39:1) presentation 2048×858 pixels of the imager is used In 2K, for Flat (1.85:1) presentation 1998×1080 pixels of the imager is used Optionally, in the HD-SDI link only: 12 bit color, YCxCz 4:2:2 (i.e. chroma subsampling in XYZ space), each eye in separate stream === Audio === 24 bits per sample, 48 kHz or 96 kHz Up to 16 channels WAV container, uncompressed PCM DCI has additionally published a document outlining recommended practice for High Frame Rate digital cinema. This document discloses the following proposed frame rates: 60, 96, and 120 frames per second for 2D at 2K resolution; 48 and 60 for stereoscopic 3D at 2K resolution; 48 and 60 for 2D at 4K resolution. The maximum compressed bit rate for support of all proposed frame rates should be 500 Mbit/s. == Related information == The idea for DCI was originally mooted in late 1999 by Tom McGrath, then COO of Paramount Pictures, who applied to the U.S. Department of Justice for anti-trust waivers to allow the joint cooperation of all seven major motion picture studios. Universal Pictures made one of the first feature-length DCPs created to DCI specifications, using their film Serenity. Although it was not distributed theatrically, it had one public screening on November 7, 2005, at the USC Entertainment Technology Center's Digital Cinema Laboratory in the Pacific Theatre, Hollywood. Inside Man (2006) was Universal's first DCP commercial release, and, in addition to 35mm film distribution, was delivered via hard drive to 20 theatres in the United States along with two trailers. The Academy Film Archive houses the Digital Cinema Initiatives, LLC Collection, which includes film and digital elements from DCI's Standard Evaluation Material (StEM), a 12-minute production shot on 35mm and 65mm film, created for vendors and standards organizations to test and evaluate image compression and digital projection technologies.</p>
<h2><a href="https://aizhi.co/html/258d199740.html" title="Plotting algorithms for the Mandelbrot set">Plotting algorithms for the Mandelbrot set</a></h2>
<p>There are many programs and algorithms used to plot the Mandelbrot set and other fractals, some of which are described in fractal-generating software. These programs use a variety of algorithms to determine the color of individual pixels efficiently. == Escape time algorithm == The simplest algorithm for generating a representation of the Mandelbrot set is known as the "escape time" algorithm. A repeating calculation is performed for each x, y point in the plot area and based on the behavior of that calculation, a color is chosen for that pixel. === Unoptimized naïve escape time algorithm === In both the unoptimized and optimized escape time algorithms, the x and y locations of each point are used as starting values in a repeating, or iterating calculation (described in detail below). The result of each iteration is used as the starting values for the next. The values are checked during each iteration to see whether they have reached a critical "escape" condition, or "bailout". If that condition is reached, the calculation is stopped, the pixel is drawn, and the next x, y point is examined. For some starting values, escape occurs quickly, after only a small number of iterations. For starting values very close to but not in the set, it may take hundreds or thousands of iterations to escape. For values within the Mandelbrot set, escape will never occur. The programmer or user must choose how many iterations–or how much "depth"–they wish to examine. The higher the maximal number of iterations, the more detail and subtlety emerge in the final image, but the longer time it will take to calculate the fractal image. Escape conditions can be simple or complex. Because no complex number with a real or imaginary part greater than 2 can be part of the set, a common bailout is to escape when either coefficient exceeds 2. A more computationally complex method that detects escapes sooner, is to compute distance from the origin using the Pythagorean theorem, i.e., to determine the absolute value, or modulus, of the complex number. If this value exceeds 2, or equivalently, when the sum of the squares of the real and imaginary parts exceed 4, the point has reached escape. More computationally intensive rendering variations include the Buddhabrot method, which finds escaping points and plots their iterated coordinates. The color of each point represents how quickly the values reached the escape point. Often black is used to show values that fail to escape before the iteration limit, and gradually brighter colors are used for points that escape. This gives a visual representation of how many cycles were required before reaching the escape condition. To render such an image, the region of the complex plane we are considering is subdivided into a certain number of pixels. To color any such pixel, let c {\displaystyle c} be the midpoint of that pixel. We now iterate the critical point 0 under P c {\displaystyle P_{c}} , checking at each step whether the orbit point has modulus larger than 2. When this is the case, we know that c {\displaystyle c} does not belong to the Mandelbrot set, and we color our pixel according to the number of iterations used to find out. Otherwise, we keep iterating up to a fixed number of steps, after which we decide that our parameter is "probably" in the Mandelbrot set, or at least very close to it, and color the pixel black. In pseudocode, this algorithm would look as follows. The algorithm does not use complex numbers and manually simulates complex-number operations using two real numbers, for those who do not have a complex data type. The program may be simplified if the programming language includes complex-data-type operations. for each pixel (Px, Py) on the screen do x0 := scaled x coordinate of pixel (scaled to lie in the Mandelbrot X scale (-2.00, 0.47)) y0 := scaled y coordinate of pixel (scaled to lie in the Mandelbrot Y scale (-1.12, 1.12)) x := 0.0 y := 0.0 iteration := 0 max_iteration := 1000 while (xx + yy ≤ 22 AND iteration < max_iteration) do xtemp := xx - yy + x0 y := 2xy + y0 x := xtemp iteration := iteration + 1 color := palette[iteration] plot(Px, Py, color) Here, relating the pseudocode to c {\displaystyle c} , z {\displaystyle z} and P c {\displaystyle P_{c}} : z = x + i y {\displaystyle z=x+iy\ } z 2 = x 2 + 2 i x y {\displaystyle z^{2}=x^{2}+2ixy} - y 2 {\displaystyle y^{2}\ } c = x 0 + i y 0 {\displaystyle c=x_{0}+iy_{0}\ } and so, as can be seen in the pseudocode in the computation of x and y: x = R e ( z 2 + c ) = x 2 − y 2 + x 0 {\displaystyle x=\mathop {\mathrm {Re} } (z^{2}+c)=x^{2}-y^{2}+x_{0}} and y = I m ( z 2 + c ) = 2 x y + y 0 . {\displaystyle y=\mathop {\mathrm {Im} } (z^{2}+c)=2xy+y_{0}.\ } To get colorful images of the set, the assignment of a color to each value of the number of executed iterations can be made using one of a variety of functions (linear, exponential, etc.). One practical way, without slowing down calculations, is to use the number of executed iterations as an entry to a palette initialized at startup. If the color table has, for instance, 500 entries, then the color selection is n mod 500, where n is the number of iterations. === Optimized escape time algorithms === The code in the previous section uses an unoptimized inner while loop for clarity. In the unoptimized version, one must perform five multiplications per iteration. To reduce the number of multiplications the following code for the inner while loop may be used instead: x2:= 0 y2:= 0 w:= 0 while (x2 + y2 ≤ 4 and iteration < max_iteration) do x:= x2 - y2 + x0 y:= w - x2 - y2 + y0 x2:= x x y2:= y y w:= (x + y) (x + y) iteration:= iteration + 1 The above code works via some algebraic simplification of the complex multiplication: ( i y + x ) 2 = − y 2 + 2 i y x + x 2 = x 2 − y 2 + 2 i y x {\displaystyle {\begin{aligned}(iy+x)^{2}&=-y^{2}+2iyx+x^{2}\\&=x^{2}-y^{2}+2iyx\end{aligned}}} Using the above identity, the number of multiplications can be reduced to three instead of five. The above inner while loop can be further optimized by expanding w to w = x 2 + 2 x y + y 2 {\displaystyle w=x^{2}+2xy+y^{2}} Substituting w into y = w − x 2 − y 2 + y 0 {\displaystyle y=w-x^{2}-y^{2}+y_{0}} yields y = 2 x y + y 0 {\displaystyle y=2xy+y_{0}} and hence calculating w is no longer needed. The further optimized pseudocode for the above is: x:= 0 y:= 0 x2:= 0 y2:= 0 while (x2 + y2 ≤ 4 and iteration < max_iteration) do x2:= x x y2:= y y y:= 2 x y + y0 x:= x2 - y2 + x0 iteration:= iteration + 1 Note that in the above pseudocode, 2 x y {\displaystyle 2xy} seems to increase the number of multiplications by 1, but since 2 is the multiplier the code can be optimized via ( x + x ) y {\displaystyle (x+x)y} . == Coloring algorithms == In addition to plotting the set, a variety of algorithms have been developed to efficiently color the set in an aesthetically pleasing way show structures of the data (scientific visualisation) === Histogram coloring === A more complex coloring method involves using a histogram which pairs each pixel with said pixel's maximum iteration count before escape/bailout. This method will equally distribute colors to the same overall area, and, importantly, is independent of the maximum number of iterations chosen. This algorithm has four passes. The first pass involves calculating the iteration counts associated with each pixel (but without any pixels being plotted). These are stored in an array IterationCounts[x][y], where x and y are the x and y coordinates of said pixel on the screen respectively. The first step of the second pass is to create an array NumIterationsPerPixel[n], where the array size n is the maximum iteration count. Next, one must iterate over the array of pixel-iteration count pairs IterationCounts[x][y], and retrieve each pixel's saved iteration count, i, via e.g. i = IterationCounts[x][y]. After each pixel's iteration count i is retrieved, it is necessary to index the NumIterationsPerPixel array at i and increment the indexed value (which is initially zero) -- e.g. NumIterationsPerPixel[i] = NumIterationsPerPixel[i] + 1. for (x = 0; x < width; x++) do for (y = 0; y < height; y++) do i:= IterationCounts[x][y] NumIterationsPerPixel[i]++ The third pass iterates through the NumIterationsPerPixel array and adds up all the stored values, saving them in total. The array index represents the number of pixels that reached that iteration count before bailout. total: = 0 for (i = 0; i < max_iterations; i++) do total += NumIterationsPerPixel[i] After this, the fourth pass begins and all the values in the IterationCounts array are indexed, and, for each iteration count i, associated with each pixel, the count is added to a global sum of all the iteration counts from 1 to i in the NumIterationsPerPixel array . This value is then normalized by dividing the sum by the total value computed earlier. hue[][]:= 0.0 for (x = 0; x < width; x++) do for (y = 0; y < height; y++) do iteration:= Iteration</p>
<h2><a href="https://aizhi.co/html/368b999622.html" title="WebGL">WebGL</a></h2>
<p>WebGL (short for Web Graphics Library) is a JavaScript API for rendering interactive 2D and 3D graphics within any compatible web browser without the use of plug-ins. WebGL is fully integrated with other web standards, allowing GPU-accelerated usage of physics, image processing, and effects in the HTML canvas. WebGL elements can be mixed with other HTML elements and composited with other parts of the page or page background. WebGL programs consist of control code written in JavaScript, and shader code written in OpenGL ES Shading Language (GLSL ES, sometimes referred to as ESSL), a language similar to C or C++. WebGL code is executed on a computer's GPU. WebGL is designed and maintained by the non-profit Khronos Group. On February 9, 2022, Khronos Group announced WebGL 2.0 support from all major browsers. From 2024, a new graphics API, WebGPU, is being developed to supersede WebGL. WebGPU provides extended capabilities, a more modern interface, and direct GPU access, which is useful for demanding graphics as well as AI applications. == Design == WebGL 1.0 is based on OpenGL ES 2.0 and provides an API for 3D graphics. It uses the HTML5 canvas element and is accessed using Document Object Model (DOM) interfaces. WebGL 2.0 is based on OpenGL ES 3.0. It guarantees the availability of many optional extensions of WebGL 1.0, and exposes new APIs. Automatic memory management is provided implicitly by JavaScript. Like OpenGL ES 2.0, WebGL lacks the fixed-function APIs introduced in OpenGL 1.0 and deprecated in OpenGL 3.0. This functionality, if required, has to be implemented by the developer using shader code and JavaScript. Shaders in WebGL are written in GLSL and passed to the WebGL API as text strings. The WebGL implementation compiles these strings to GPU code. This code is executed for each vertex sent through the API and for each pixel rasterized to the screen. == History == WebGL evolved out of the Canvas 3D experiments started by Vladimir Vukićević at Mozilla. Vukićević first demonstrated a Canvas 3D prototype in 2006. By the end of 2007, both Mozilla and Opera had made their own separate implementations. In early 2009, the non-profit technology consortium Khronos Group started the WebGL Working Group, with initial participation from Apple, Google, Mozilla, Opera, and others. Version 1.0 of the WebGL specification was released March 2011. An early application of WebGL was Zygote Body. In November 2012 Autodesk announced that they ported most of their applications to the cloud running on local WebGL clients. These applications included Autodesk Fusion and AutoCAD. Development of the WebGL 2 specification started in 2013 and finished in January 2017. The specification is based on OpenGL ES 3.0. First implementations are in Firefox 51, Chrome 56 and Opera 43. == Implementations == === Almost Native Graphics Layer Engine === Almost Native Graphics Layer Engine (ANGLE) is an open source graphic engine which implements WebGL 1.0 (2.0 which closely conforms to ES 3.0) and OpenGL ES 2.0 and 3.0 standards. It is a default backend for both Google Chrome and Mozilla Firefox on Windows platforms and works by translating WebGL and OpenGL calls to available platform-specific APIs. ANGLE currently provides access to OpenGL ES 2.0 and 3.0 to desktop OpenGL, OpenGL ES, Direct3D 9, and Direct3D 11 APIs. ″[Google] Chrome uses ANGLE for all graphics rendering on Windows, including the accelerated Canvas2D implementation and the Native Client sandbox environment.″ == Software == WebGL is widely supported by modern browsers. However, its availability depends on other factors, too, like whether the GPU supports it. The official WebGL website offers a simple test page. More detailed information (like what renderer the browser uses, and what extensions are available) can be found at third-party websites. === Desktop browsers === Source: Google Chrome – WebGL 1.0 has been enabled on all platforms that have a capable graphics card with updated drivers since version 9, released in February 2011. By default on Windows, Chrome uses the ANGLE (Almost Native Graphics Layer Engine) renderer to translate OpenGL ES to Direct X 9.0c or 11.0, which have better driver support. However, on Linux and Mac OS X, the default renderer is OpenGL. It is also possible to force OpenGL as the renderer on Windows. Since September 2013, Chrome also has a newer Direct3D 11 renderer, which requires a newer graphics card. Chrome 56+ supports WebGL 2.0. Firefox – WebGL 1.0 has been enabled on all platforms that have a capable graphics card with updated drivers since version 4.0. Since 2013 Firefox also uses DirectX on the Windows platform via ANGLE. Firefox 51+ supports WebGL 2.0. Safari – Safari 6.0 and newer versions installed on OS X Mountain Lion, Mac OS X Lion and Safari 5.1 on Mac OS X Snow Leopard implemented support for WebGL 1.0, which was disabled by default before Safari 8.0. Safari version 12 (available in MacOS Mojave) has available support for WebGL 2.0 as an "Experimental" feature. Safari 15 enables WebGL 2.0 for all users. Opera – WebGL 1.0 has been implemented in Opera 11 and 12, but was disabled by default in 2014. Opera 43+ supports WebGL 2.0. Internet Explorer – WebGL 1.0 is partially supported in Internet Explorer 11. Internet Explorer initially failed most of the official WebGL conformance tests, but Microsoft later released several updates. The latest 0.94 WebGL engine currently passes ≈97% of Khronos tests. WebGL support can also be manually added to earlier versions of Internet Explorer using third-party plugins such as IEWebGL. Microsoft Edge – For Microsoft Edge Legacy, the initial stable release supports WebGL version 0.95 (context name: "experimental-webgl") with an open source GLSL to HLSL transpiler. Version 10240+ supports WebGL 1.0 as prefixed. Latest Chromium-based Edge supports WebGL 2.0. === Mobile browsers === Google Chrome – WebGL 1.0 is supported on Android as of Chrome 25. WebGL 2.0 is supported on Android as of Chrome 58. Chrome is used for the Android system webview as of Android 5. Firefox for mobile – WebGL 1.0 is available for Android devices since Firefox 4. Safari on iOS – WebGL 1.0 is available for mobile Safari in iOS 8. WebGL 2.0 is available for mobile Safari in iOS 15. Microsoft Edge – Prefixed WebGL 1.0 was available on Windows 10 Mobile.. Latest Chromium-based Edge supports WebGL 2.0. Opera Mobile – Opera Mobile 12 supports WebGL 1.0 (on Android only). Sailfish OS – WebGL 1.0 is supported in the default Sailfish browser. Tizen – WebGL 1.0 is supported == Tools and ecosystem == === Utilities === The low-level nature of the WebGL API, which provides little on its own to quickly create desirable 3D graphics, motivated the creation of higher-level libraries that abstract common operations (e.g. loading scene graphs and 3D objects in certain formats; applying linear transformations to shaders or view frustums). Some such libraries were ported to JavaScript from other languages. Examples of libraries that provide high-level features include A-Frame (VR), BabylonJS, PlayCanvas, three.js, OSG.JS, Google’s model-viewer and CopperLicht. Web3D also made a project called X3DOM to make X3D and VRML content run on WebGL. === Games === There has been an emergence of 2D and 3D game engines for WebGL, such as Unreal Engine 4 and Unity. The Stage3D/Flash-based Away3D high-level library also has a port to WebGL via TypeScript. A more light-weight utility library that provides just the vector and matrix math utilities for shaders is sylvester.js. It is sometimes used in conjunction with a WebGL specific extension called glUtils.js. There are also some 2D libraries built atop WebGL, like Cocos2d-x or Pixi.js, which were implemented this way for performance reasons in a move that parallels what happened with the Starling Framework over Stage3D in the Flash world. The WebGL-based 2D libraries fall back to HTML5 canvas when WebGL is not available. Removing the rendering bottleneck by giving almost direct access to the GPU has exposed performance limitations in the JavaScript implementations. Some were addressed by asm.js and WebAssembly (similarly, the introduction of Stage3D exposed performance problems within ActionScript, which were addressed by projects like CrossBridge). === Content creation === As with any other graphics API, creating content for WebGL scenes requires using a 3D content creation tool and exporting the scene to a format that is readable by the viewer or helper library. Desktop 3D authoring software such as Blender, Autodesk Maya or SimLab Composer can be used for this purpose. In particular, Blend4Web allows a WebGL scene to be authored entirely in Blender and exported to a browser with a single click, even as a standalone web page. There are also some WebGL-specific software such as CopperCube and the online WebGL-based editor Clara.io. Online platforms such as Sketchfab and Clara.io allow users to directly upload their 3D models </p>
</div>
<nav class="article-pagination" aria-label="More guides">
<div class="prev-article">
<span>← Previous</span>
<a href="https://aizhi.co/html/223d199775.html" title="Wilkinson's Grammar of Graphics">Wilkinson's Grammar of Graphics</a>
</div>
<div class="next-article">
<span>Next →</span>
<a href="https://aizhi.co/news/134d199864.html" title="Clapper (service)">Clapper (service)</a>
</div>
</nav>
</article>
<section class="related-articles" aria-label="Related articles">
<h2>Related Articles</h2>
<ul>
<li>
<a href="https://aizhi.co/news/153c399843.html" title="Keka HR">Keka HR</a>
<time datetime="2026-06-03 02:57">2026-06-03 02:57</time>
</li>
<li>
<a href="https://aizhi.co/html/282f999708.html" title="IAmAnas">IAmAnas</a>
<time datetime="2026-06-03 02:45">2026-06-03 02:45</time>
</li>
<li>
<a href="https://aizhi.co/html/87e999903.html" title="Hyperscale computing">Hyperscale computing</a>
<time datetime="2026-06-03 02:27">2026-06-03 02:27</time>
</li>
<li>
<a href="https://aizhi.co/news/9b999981.html" title="DBOS">DBOS</a>
<time datetime="2026-06-03 02:21">2026-06-03 02:21</time>
</li>
<li>
<a href="https://aizhi.co/html/498d099501.html" title="Graphical Kernel System">Graphical Kernel System</a>
<time datetime="2026-06-03 01:25">2026-06-03 01:25</time>
</li>
<li>
<a href="https://aizhi.co/html/84f999906.html" title="FactorDaily">FactorDaily</a>
<time datetime="2026-06-03 00:29">2026-06-03 00:29</time>
</li>
</ul>
</section>
</main>
<aside class="sidebar">
<section class="sidebar-section">
<h2>Categories</h2>
<ul>
<li><a href="https://aizhi.co/aivideotools/">AI Video Tools</a></li><li><a href="https://aizhi.co/aicodingtools/">AI Coding Tools</a></li><li><a href="https://aizhi.co/aichatbotsandassistants/">AI Chatbots and Assistants</a></li><li><a href="https://aizhi.co/ainewsandguides/">AI News and Guides</a></li><li><a href="https://aizhi.co/aiimagegenerators/">AI Image Generators</a></li><li><a href="https://aizhi.co/aiwritingtools/">AI Writing Tools</a></li><li><a href="https://aizhi.co/aiforbusiness/">AI for Business</a></li> </ul>
</section>
<section class="sidebar-section">
<h2>Latest Articles</h2>
<ul>
<li><a href="https://aizhi.co/html/463b399533.html" title="Image moment">Image moment</a></li><li><a href="https://aizhi.co/news/239d999751.html" title="Audience capture">Audience capture</a></li><li><a href="https://aizhi.co/html/496c999494.html" title="Greedy embedding">Greedy embedding</a></li><li><a href="https://aizhi.co/html/18b999972.html" title="Digital goods">Digital goods</a></li><li><a href="https://aizhi.co/html/81b499914.html" title="Computer audition">Computer audition</a></li><li><a href="https://aizhi.co/html/79d999911.html" title="M-DISC">M-DISC</a></li><li><a href="https://aizhi.co/news/290f999700.html" title="Full30">Full30</a></li><li><a href="https://aizhi.co/html/38d999952.html" title="Cyber-Duck">Cyber-Duck</a></li><li><a href="https://aizhi.co/news/360d099639.html" title="Continuous Exposure Management">Continuous Exposure Management</a></li><li><a href="https://aizhi.co/news/387e999603.html" title="Style sheet (web development)">Style sheet (web development)</a></li> </ul>
</section>
</aside>
</div>
</div>
</div>
<footer class="site-footer">
<div class="container">
<div class="footer-cols">
<div class="footer-col footer-about">
<a class="brand" href="https://aizhi.co/" aria-label="Aizhi">
<span class="brand-mark" aria-hidden="true">✦</span>
<span class="brand-text">Aizhi</span>
</a>
<p class="footer-tagline">Hand-picked AI tools, generators and practical how-to guides — independent reviews, updated for 2026.</p>
</div>
<nav class="footer-col" aria-label="Categories">
<h2 class="footer-h">Categories</h2>
<ul>
<li><a href="https://aizhi.co/ainewsandguides/">AI News and Guides</a></li><li><a href="https://aizhi.co/aicodingtools/">AI Coding Tools</a></li><li><a href="https://aizhi.co/aichatbotsandassistants/">AI Chatbots and Assistants</a></li><li><a href="https://aizhi.co/aivideotools/">AI Video Tools</a></li><li><a href="https://aizhi.co/aiimagegenerators/">AI Image Generators</a></li><li><a href="https://aizhi.co/aiforbusiness/">AI for Business</a></li><li><a href="https://aizhi.co/aiwritingtools/">AI Writing Tools</a></li> </ul>
</nav>
<nav class="footer-col" aria-label="Site">
<h2 class="footer-h">Site</h2>
<ul>
<li><a href="https://aizhi.co/">Home</a></li>
<li><a href="/sitemap.xml">XML Sitemap</a></li>
</ul>
</nav>
</div>
<div class="partner-links" aria-label="Network">
</div>
<p class="footer-copy">
© Aizhi. All rights reserved.
</p>
</div>
</footer>
</body>
</html>