Feng Office Community Edition (formerly OpenGoo) is an open-source collaboration platform developed and supported by Feng Office and the OpenGoo community. It is a fully featured online office suite with a similar set of features as other online office suites, like Google Workspace, Microsoft 365, Zimbra, LibreOffice Online and Zoho Office Suite. The application can be downloaded and installed on a server. Feng Office could also be categorized as collaborative software and as personal information manager software. == Features == Feng Office Community Edition main features include project management, document management, contact management, e-mail and time management. Text documents and presentations can be created and edited online. Files can be uploaded, organized and shared, independent of file formats. Organization of the information in Feng Office Community Edition is done using workspaces and tags. The application presents the information stored using different interfaces such as lists, dashboards and calendar views. == Licensing == Feng Office Community Edition is distributed under the GNU Affero General Public License, version 3 only. == Technology used == Feng Office uses PHP, JavaScript, AJAX (ExtJS) and MySQL technology. Several open source projects served as a basis for development. ActiveCollab's last open sourced release was used as the initial code base. It includes CKEditor for online document editing. == System requirements == The server could run on any operating system. The system needs the following packages: Apache HTTP Server 2.0+ PHP 5.0+ MySQL 4.1+ (InnoDB support recommended) On the client side, the user is only required to use a modern Web browser. == History == OpenGoo started as a degree project at the faculty of Engineering of the University of the Republic, Uruguay. The project was presented and championed by Software Engineer Conrado Viña. Software Engineers Marcos Saiz and Ignacio de Soto developed the first prototype as their thesis. Professors Eduardo Fernández and Tomas Laurenzo served as tutors. Conrado, Ignacio and Marcos founded the OpenGoo community and remain active members and core developers. The thesis was approved with the highest score. In 2008, Viña joined the Uruguayan software development company Moove It. Currently there is a second project for OpenGoo at the same university being developed by students Fernando Rodríguez, Ignacio Vázquez and Juan Pedro del Campo. Their project aims to build an open source Web-based spreadsheet. In December 2009 the OpenGoo name was changed to Feng Office Community Edition.
Order-independent transparency
Order-independent transparency (OIT) is a class of techniques in rasterisational computer graphics for rendering transparency in a 3D scene, which do not require rendering geometry in sorted order for alpha compositing. == Description == Commonly, 3D geometry with transparency is rendered by blending (using alpha compositing) all surfaces into a single buffer (think of this as a canvas). Each surface occludes existing color and adds some of its own color depending on its alpha value, a ratio of light transmittance. The order in which surfaces are blended affects the total occlusion or visibility of each surface. For a correct result, surfaces must be blended from farthest to nearest or nearest to farthest, depending on the alpha compositing operation, over or under. Ordering may be achieved by rendering the geometry in sorted order, for example sorting triangles by depth, but can take a significant amount of time, not always produce a solution (in the case of intersecting or circularly overlapping geometry) and the implementation is complex. Instead, order-independent transparency sorts geometry per-pixel, after rasterisation. For exact results this requires storing all fragments before sorting and compositing. == History == The A-buffer is a computer graphics technique introduced in 1984 which stores per-pixel lists of fragment data (including micro-polygon information) in a software rasteriser, REYES, originally designed for anti-aliasing but also supporting transparency. More recently, depth peeling in 2001 described a hardware accelerated OIT technique. With limitations in graphics hardware the scene's geometry had to be rendered many times. A number of techniques have followed, to improve on the performance of depth peeling, still with the many-pass rendering limitation. For example, Dual Depth Peeling (2008). In 2009, two significant features were introduced in GPU hardware/drivers/Graphics APIs that allowed capturing and storing fragment data in a single rendering pass of the scene, something not previously possible. These are, the ability to write to arbitrary GPU memory from shaders and atomic operations. With these features a new class of OIT techniques became possible that do not require many rendering passes of the scene's geometry. The first was storing the fragment data in a 3D array, where fragments are stored along the z dimension for each pixel x/y. In practice, most of the 3D array is unused or overflows, as a scene's depth complexity is typically uneven. To avoid overflow the 3D array requires large amounts of memory, which in many cases is impractical. Two approaches to reducing this memory overhead exist. Packing the 3D array with a prefix sum scan, or linearizing, removed the unused memory issue but requires an additional depth complexity computation rendering pass of the geometry. The "Sparsity-aware" S-Buffer, Dynamic Fragment Buffer, "deque" D-Buffer, Linearized Layered Fragment Buffer all pack fragment data with a prefix sum scan and are demonstrated with OIT. Storing fragments in per-pixel linked lists provides tight packing of this data and in late 2011, driver improvements reduced the atomic operation contention overhead making the technique very competitive. == Exact OIT == Exact, as opposed to approximate, OIT accurately computes the final color, for which all fragments must be sorted. For high depth complexity scenes, sorting becomes the bottleneck. One issue with the sorting stage is local memory limited occupancy, in this case a SIMT attribute relating to the throughput and operation latency hiding of GPUs. Backwards memory allocation (BMA) groups pixels by their depth complexity and sorts them in batches to improve the occupancy and hence performance of low depth complexity pixels in the context of a potentially high depth complexity scene. Up to a 3× overall OIT performance increase is reported. Sorting is typically performed in a local array, however performance can be improved further by making use of the GPU's memory hierarchy and sorting in registers, similarly to an external merge sort, especially in conjunction with BMA. == Approximate OIT == Approximate OIT techniques relax the constraint of exact rendering to provide faster results. Higher performance can be gained from not having to store all fragments or only partially sorting the geometry. A number of techniques also compress, or reduce, the fragment data. These include: Stochastic Transparency: draw in a higher resolution in full opacity but discard some fragments. Downsampling will then yield transparency. Adaptive Transparency, a two-pass technique where the first constructs a visibility function which compresses on the fly (this compression avoids having to fully sort the fragments) and the second uses this data to composite unordered fragments. Intel's pixel synchronization avoids the need to store all fragments, removing the unbounded memory requirement of many other OIT techniques. Weighted Blended Order-Independent Transparency replaced the over operator with a commutative approximation. Feeding depth information into the weight produces visually-acceptable occlusion. == OIT in Hardware == The Sega Dreamcast games console included hardware support for automatic OIT.
Multiple buffering
In computer science, multiple buffering is the use of more than one buffer to hold a block of data, so that a "reader" will see a complete (though perhaps old) version of the data instead of a partially updated version of the data being created by a "writer". It is very commonly used for computer display images. It is also used to avoid the need to use dual-ported RAM (DPRAM) when the readers and writers are different devices. == Description == === Double buffering Petri net === The Petri net in the illustration shows double buffering. Transitions W1 and W2 represent writing to buffer 1 and 2 respectively while R1 and R2 represent reading from buffer 1 and 2 respectively. At the beginning, only the transition W1 is enabled. After W1 fires, R1 and W2 are both enabled and can proceed in parallel. When they finish, R2 and W1 proceed in parallel and so on. After the initial transient where W1 fires alone, this system is periodic and the transitions are enabled – always in pairs (R1 with W2 and R2 with W1 respectively). == Double buffering in computer graphics == In computer graphics, double buffering is a technique for drawing graphics that shows less stutter, tearing, and other artifacts. It is difficult for a program to draw a display so that pixels do not change more than once. For instance, when updating a page of text, it is much easier to clear the entire page and then draw the letters than to somehow erase only the pixels that are used in old letters but not in new ones. However, this intermediate image is seen by the user as flickering. In addition, computer monitors constantly redraw the visible video page (traditionally at around 60 times a second), so even a perfect update may be visible momentarily as a horizontal divider between the "new" image and the un-redrawn "old" image, known as tearing. === Software double buffering === A software implementation of double buffering has all drawing operations store their results in some region of system RAM; any such region is often called a "back buffer". When all drawing operations are considered complete, the whole region (or only the changed portion) is copied into the video RAM (the "front buffer"); this copying is usually synchronized with the monitor's raster beam in order to avoid tearing. Software implementations of double buffering necessarily require more memory and CPU time than single buffering because of the system memory allocated for the back buffer, the time for the copy operation, and the time waiting for synchronization. Compositing window managers often combine the "copying" operation with "compositing" used to position windows, transform them with scale or warping effects, and make portions transparent. Thus, the "front buffer" may contain only the composite image seen on the screen, while there is a different "back buffer" for every window containing the non-composited image of the entire window contents. === Page flipping === In the page-flip method, instead of copying the data, both buffers are capable of being displayed. At any one time, one buffer is actively being displayed by the monitor, while the other, background buffer is being drawn. When the background buffer is complete, the roles of the two are switched. The page-flip is typically accomplished by modifying a hardware register in the video display controller—the value of a pointer to the beginning of the display data in the video memory. The page-flip is much faster than copying the data and can guarantee that tearing will not be seen as long as the pages are switched over during the monitor's vertical blanking interval—the blank period when no video data is being drawn. The currently active and visible buffer is called the front buffer, while the background page is called the back buffer. == Triple buffering == In computer graphics, triple buffering is similar to double buffering but can provide improved performance. In double buffering, the program must wait until the finished drawing is copied or swapped before starting the next drawing. This waiting period could be several milliseconds during which neither buffer can be touched. In triple buffering, the program has two back buffers and can immediately start drawing in the one that is not involved in such copying. The third buffer, the front buffer, is read by the graphics card to display the image on the monitor. Once the image has been sent to the monitor, the front buffer is flipped with (or copied from) the back buffer holding the most recent complete image. Since one of the back buffers is always complete, the graphics card never has to wait for the software to complete. Consequently, the software and the graphics card are completely independent and can run at their own pace. Finally, the displayed image was started without waiting for synchronization and thus with minimum lag. Due to the software algorithm not polling the graphics hardware for monitor refresh events, the algorithm may continuously draw additional frames as fast as the hardware can render them. For frames that are completed much faster than interval between refreshes, it is possible to replace a back buffers' frames with newer iterations multiple times before copying. This means frames may be written to the back buffer that are never used at all before being overwritten by successive frames. Nvidia has implemented this method under the name "Fast Sync". An alternative method sometimes referred to as triple buffering is a swap chain three buffers long. After the program has drawn both back buffers, it waits until the first one is placed on the screen, before drawing another back buffer (i.e. it is a 3-long first in, first out queue). Most Windows games seem to refer to this method when enabling triple buffering. == Quad buffering == The term quad buffering is the use of double buffering for each of the left and right eye images in stereoscopic implementations, thus four buffers total (if triple buffering was used then there would be six buffers). The command to swap or copy the buffer typically applies to both pairs at once, so at no time does one eye see an older image than the other eye. Quad buffering requires special support in the graphics card drivers which is disabled for most consumer cards. AMD's Radeon HD 6000 Series and newer support it. 3D standards like OpenGL and Direct3D support quad buffering. == Double buffering for DMA == The term double buffering is used for copying data between two buffers for direct memory access (DMA) transfers, not for enhancing performance, but to meet specific addressing requirements of a device (particularly 32-bit devices on systems with wider addressing provided via Physical Address Extension). Windows device drivers are a place where the term "double buffering" is likely to be used. Linux and BSD source code calls these "bounce buffers". Some programmers try to avoid this kind of double buffering with zero-copy techniques. == Other uses == Double buffering is also used as a technique to facilitate interlacing or deinterlacing of video signals.
Exposure Notification
The (Google/Apple) Exposure Notification System (GAEN) is a framework and protocol specification developed by Apple Inc. and Google to facilitate digital contact tracing during the COVID-19 pandemic. When used by health authorities, it augments more traditional contact tracing techniques by automatically logging close approaches among notification system users using Android or iOS smartphones. Exposure Notification is a decentralized reporting protocol built on a combination of Bluetooth Low Energy technology and privacy-preserving cryptography. It is an opt-in feature within COVID-19 apps developed and published by authorized health authorities. Unveiled on April 10, 2020, it was made available on iOS on May 20, 2020, as part of the iOS 13.5 update and on December 14, 2020, as part of the iOS 12.5 update for older iPhones. On Android, it was added to devices via a Google Play Services update, supporting all versions since Android Marshmallow. The Apple/Google protocol is similar to the Decentralized Privacy-Preserving Proximity Tracing (DP-3T) protocol created by the European DP-3T consortium and the Temporary Contact Number (TCN) protocol by Covid Watch, but is implemented at the operating system level, which allows for more efficient operation as a background process. Since May 2020, a variant of the DP-3T protocol is supported by the Exposure Notification Interface. Other protocols are constrained in operation because they are not privileged over normal apps. This leads to issues, particularly on iOS devices where digital contact tracing apps running in the background experience significantly degraded performance. The joint approach is also designed to maintain interoperability between Android and iOS devices, which constitute nearly all of the market. The ACLU stated the approach "appears to mitigate the worst privacy and centralization risks, but there is still room for improvement". In late April, Google and Apple shifted the emphasis of the naming of the system, describing it as an "exposure notification service", rather than "contact tracing" system. == Technical specification == Digital contact tracing protocols typically have two major responsibilities: encounter logging and infection reporting. Exposure Notification only involves encounter logging which is a decentralized architecture. The majority of infection reporting is centralized in individual app implementations. To handle encounter logging, the system uses Bluetooth Low Energy to send tracking messages to nearby devices running the protocol to discover encounters with other people. The tracking messages contain unique identifiers that are encrypted with a secret daily key held by the sending device. These identifiers change every 15–20 minutes as well as Bluetooth MAC address in order to prevent tracking of clients by malicious third parties through observing static identifiers over time. The sender's daily encryption keys are generated using a random number generator. Devices record received messages, retaining them locally for 14 days. If a user tests positive for infection, the last 14 days of their daily encryption keys can be uploaded to a central server, where it is then broadcast to all devices on the network. The method through which daily encryption keys are transmitted to the central server and broadcast is defined by individual app developers. The Google-developed reference implementation calls for a health official to request a one-time verification code (VC) from a verification server, which the user enters into the encounter logging app. This causes the app to obtain a cryptographically signed certificate, which is used to authorize the submission of keys to the central reporting server. The received keys are then provided to the protocol, where each client individually searches for matches in their local encounter history. If a match meeting certain risk parameters is found, the app notifies the user of potential exposure to the infection. Google and Apple intend to use the received signal strength (RSSI) of the beacon messages as a source to infer proximity. RSSI and other signal metadata will also be encrypted to resist deanonymization attacks. === Version 1.0 === To generate encounter identifiers, first a persistent 32-byte private Tracing Key ( t k {\displaystyle tk} ) is generated by a client. From this a 16 byte Daily Tracing Key is derived using the algorithm d t k i = H K D F ( t k , N U L L , 'CT-DTK' | | D i , 16 ) {\displaystyle dtk_{i}=HKDF(tk,NULL,{\text{'CT-DTK'}}||D_{i},16)} , where H K D F ( Key, Salt, Data, OutputLength ) {\displaystyle HKDF({\text{Key, Salt, Data, OutputLength}})} is a HKDF function using SHA-256, and D i {\displaystyle D_{i}} is the day number for the 24-hour window the broadcast is in starting from Unix Epoch Time. These generated keys are later sent to the central reporting server should a user become infected. From the daily tracing key a 16-byte temporary Rolling Proximity Identifier is generated every 10 minutes with the algorithm R P I i , j = Truncate ( H M A C ( d t k i , 'CT-RPI' | | T I N j ) , 16 ) {\displaystyle RPI_{i,j}={\text{Truncate}}(HMAC(dtk_{i},{\text{'CT-RPI'}}||TIN_{j}),16)} , where H M A C ( Key, Data ) {\displaystyle HMAC({\text{Key, Data}})} is a HMAC function using SHA-256, and T I N j {\displaystyle TIN_{j}} is the time interval number, representing a unique index for every 10 minute period in a 24-hour day. The Truncate function returns the first 16 bytes of the HMAC value. When two clients come within proximity of each other they exchange and locally store the current R P I i , j {\displaystyle RPI_{i,j}} as the encounter identifier. Once a registered health authority has confirmed the infection of a user, the user's Daily Tracing Key for the past 14 days is uploaded to the central reporting server. Clients then download this report and individually recalculate every Rolling Proximity Identifier used in the report period, matching it against the user's local encounter log. If a matching entry is found, then contact has been established and the app presents a notification to the user warning them of potential infection. === Version 1.1 === Unlike version 1.0 of the protocol, version 1.1 does not use a persistent tracing key, rather every day a new random 16-byte Temporary Exposure Key ( t e k i {\displaystyle tek_{i}} ) is generated. This is analogous to the daily tracing key from version 1.0. Here i {\displaystyle i} denotes the time is discretized in 10 minute intervals starting from Unix Epoch Time. From this two 128-bit keys are calculated, the Rolling Proximity Identifier Key ( R P I K i {\displaystyle RPIK_{i}} ) and the Associated Encrypted Metadata Key ( A E M K i {\displaystyle AEMK_{i}} ). R P I K i {\displaystyle RPIK_{i}} is calculated with the algorithm R P I K i = H K D F ( t e k i , N U L L , 'EN-RPIK' , 16 ) {\displaystyle RPIK_{i}=HKDF(tek_{i},NULL,{\text{'EN-RPIK'}},16)} , and A E M K i {\displaystyle AEMK_{i}} using the algorithm A E M K i = H K D F ( t e k i , N U L L , 'EN-AEMK' , 16 ) {\displaystyle AEMK_{i}=HKDF(tek_{i},NULL,{\text{'EN-AEMK'}},16)} . From these values a temporary Rolling Proximity Identifier ( R P I i , j {\displaystyle RPI_{i,j}} ) is generated every time the BLE MAC address changes, roughly every 15–20 minutes. The following algorithm is used: R P I i , j = A E S 128 ( R P I K i , 'EN-RPI' | | 0 x 000000000000 | | E N I N j ) {\displaystyle RPI_{i,j}=AES128(RPIK_{i},{\text{'EN-RPI'}}||{\mathtt {0x000000000000}}||ENIN_{j})} , where A E S 128 ( Key, Data ) {\displaystyle AES128({\text{Key, Data}})} is an AES cryptography function with a 128-bit key, the data is one 16-byte block, j {\displaystyle j} denotes the Unix Epoch Time at the moment the roll occurs, and E N I N j {\displaystyle ENIN_{j}} is the corresponding 10-minute interval number. Next, additional Associated Encrypted Metadata is encrypted. What the metadata represents is not specified, likely to allow the later expansion of the protocol. The following algorithm is used: Associated Encrypted Metadata i , j = A E S 128 _ C T R ( A E M K i , R P I i , j , Metadata ) {\displaystyle {\text{Associated Encrypted Metadata}}_{i,j}=AES128\_CTR(AEMK_{i},RPI_{i,j},{\text{Metadata}})} , where A E S 128 _ C T R ( Key, IV, Data ) {\displaystyle AES128\_CTR({\text{Key, IV, Data}})} denotes AES encryption with a 128-bit key in CTR mode. The Rolling Proximity Identifier and the Associated Encrypted Metadata are then combined and broadcast using BLE. Clients exchange and log these payloads. Once a registered health authority has confirmed the infection of a user, the user's Temporary Exposure Keys t e k i {\displaystyle tek_{i}} and their respective interval numbers i {\displaystyle i} for the past 14 days are uploaded to the central reporting server. Clients then download this report and individually recalculate every Rolling Proximity Identifier starting from interval number i {\displaystyle i} ,
Vismon
Vismon was the Bell Labs system which displayed authors' faces on one of their internal e-mail systems. The name was a pun on the sysmon program used at Bell to show the load on computer systems. It can also be interpreted as "visual monitor". The system inspired Rich Burridge to develop the similar but more widespread faces system, which spread with Unix distributions in the 1980s. This in turn inspired Steve Kinzler to develop the Picons, or personal icons, which have the goal of offering symbols and other images, as well as faces, to represent individuals and institutions in email messages. Other systems such as the faces available on the LAN email functions of the NeXTSTEP platform also seem to have been influenced by the original Vismon capabilities. The faces program in Plan 9 is the direct descendant of this system. Vismon was the work of Rob Pike and Dave Presotto. It was based on some early experiments by Luca Cardelli. Many other scientists and engineers of the Computing Science Research Center of the Murray Hill facility were also involved. All had been spurred by the introduction in 1983 of the new Blit graphics terminal developed by Pike and Bart Locanthi and marketed by Teletype Corporation of Skokie, Illinois as the DMD 5620. Pike was eager, along with his colleagues, to exploit the new graphic capabilities. Pike and company went around their Center, convincing everybody, from directors and administrative assistants to engineers and scientists, to pose as they got out a 4×5 view camera with a Polaroid back and took black-and-white photos (Polaroid type 52) of their faces. Their efforts yielded nearly 100 faces, which they digitised with a scanner from graphics colleagues. They wrote several programs to transform the faces, store them and serve them on several machines at the lab. As time went by, they added faces from outside their Center and outside Bell Labs. This database also led to the pico image editor (originally named zunk) which was used for image transformations, many of them with colleagues as the preferred target. The first programs built around vismon were used to announce incoming mail in a dedicated window, using the 48 by 48 pixel faces. Later on the faces were also used to decorate line printer banners.
IMPACT (computer graphics)
IMPACT (sometimes spelled Impact) is a computer graphics architecture for Silicon Graphics computer workstations. IMPACT Graphics was developed in 1995 and was available as a high-end graphics option on workstations released during the mid-1990s. IMPACT graphics gives the workstation real-time 2D and 3D graphics rendering capability similar to that of even high-end PCs made well after IMPACT's introduction. IMPACT graphics systems consist of either one or two Geometry Engines and one or two Raster Engines in various configurations. IMPACT graphics consists of five graphics subsystems: the Command Engine, Geometry Subsystem, Raster Engine, framebuffer and Display Subsystem. IMPACT Graphics can produce resolutions up to 1600 x 1200 pixels with 32-bit color and can also process unencoded NTSC and PAL analog television signals. IMPACT graphics subsystems come in three configurations for SGI Indigo2 IMPACT workstations: Solid IMPACT, High IMPACT, and Maximum IMPACT. The equivalent configurations also exist for the SGI Octane workstation but are referred to as SI, SSI, and MXI (I-series). Later Octane workstations used a similar configuration but with updated ASIC chips and are referred to as SE, SSE, and MXE (E-series). IMPACT uses Rambus RDRAM for texture memory. The IMPACT graphics architecture was superseded by SGI's VPro graphics architecture in 1997.
Kai's Power Tools
Kai's Power Tools (KPT) are a set of API plugins created by the German computer scientist Kai Krause in 1992 that were designed for use with Adobe Photoshop and Corel Photo-Paint. Kai's Power Tools were sold to Corel in 2000 when MetaCreations was closed. There are various versions of Kai's Power Tools. KPT 3, 5, 6, and X sets are compilations of different filters. The program interface features a reward-based function in which a bonus function is revealed as the user moves towards more complex aspects of the tool. == Filters == The KPT Convolver is a mathematics based filter; the level of precision and varying effects can be achieved by using numerical values of colour, tint, hue, saturation, contrast, brightness, luminosity, and posterize. The KPT Projector takes the current image or selection and offers a number of interactive perspective warp effects. To a large extent, with its draggable distortion handles and its moving, scaling and rotating options, this simply duplicates Adobe Photoshop's Free Transform capabilities. What is completely different is the ability to rotate the bitmap image in 3D space and to tile the results if desired. It can also animate the distortions by dragging keyframes from the preview window into an animation palette. KPT 6 will then preview the animation and output it to various sizes in avi or mov format. This animation capability is even more useful with the KPT Turbulence filter. This is another distortion filter, but one that treats the image as if it was completely liquid. The preview panel shows the animation in real time. The KPT Goo filter is used to produce a single frame freeform liquid distortion. This filter is available both with KPT 6 and the standalone version. It works by effectively turning a bitmap image into a liquid that can be interactively smeared, smudged, twirled, and pinched with the range of tools on offer. The obvious use is to distort photographic portraits into caricatures. KPT Materializer can create advanced surface textures based on bump maps that define troughs and peaks. It can use any external image for the basis of the bump map or alternatively the user can pick out the hue, saturation, luminance or red, green, or blue channel of the current image. It can then offset, scale and rotate the texture map, control its lighting, and even blend in a reflection map. The filter can be used for anything from providing an oil-painting feel to an entire image, to giving the illusion of depth to a selection. Also producing the impression of depth is the KPT Gel filter which uses various paint tools to synthesize photo-realistic 3D materials such as metals, liquids, or plastics. Gel painting is very different from traditional 2D painting as the brush strokes pool together when they touch and refract the underlying image. It can also manipulate 3D paint—once it has been added—by twirling, pinching, and carving it. The opposite is true of the Equalizer filter, which is used for applying variations on sharpening effects. The filter has three modes. The first mode, Equalizer, looks and works rather like the graphic equalizer on a stereo system, enabling adjustment of the level of pixel contrast within nine bands of different visual frequencies. The second mode, Contrast Sharpen, allows for increasing the contrast between light and dark areas in an image. The third mode, Bounded Sharpen, can sharpen an image without causing oversharpening, which can lead to halo effects. This feature is particularly useful when pulling out the detail in an image softened by resizing. KPT SceneBuilder is used for producing photorealistic 3D scenes by importing and rendering 3DS files. The main image window offers three tabs for editing in 2D and 3D mode and for setting up the object's final texture. Many users regard this filter as being the most impressive because it acts as a standalone 3D rendering tool and provides control over everything from transparency, reflection, refraction, bump mapping through to multiple light sources, and so on but without the ability to create or edit objects. The final filter, KPT SkyEffects, also has its roots in Metacreations' experience with 3D programs such as Bryce and RayDream. This filter is designed to simulate the interaction between the light from the sun or moon with no less than six atmospheric layers of haze, fog and cloud. The filter is typical of the KPT 6 collection as a whole: at times the interface is inspired and offers the ability to create beautiful reddening sunsets simply by interactively dragging the sun toward the horizon, producing realistic sunsets and moonscapes. == Other effects == Kai's Power Tools 6 features a lens flare effect for precisely managing the type of glow, halo, streaks, and reflection. The addition of a library of preset effects helps to overcome this by allowing the user to choose a standard effect and then interactively position the flare in the image preview. KPT 6 provides a new engine in the form of the KPT Reaction, which takes a reaction seed and turns it into a seamlessly tiling pattern based on a reaction diffusion process. It offers random noise, regular dots or reticulated voronoi patterns or a bitmap image itself as the seed. Corel has no plans for any updates.