Kernel Assisted Superuser (short: KernelSU) is an alternative method for obtaining root privileges on Android devices. KernelSU implementations are developed as free and open-source software under the terms of the GPLv3 license. == Technical differences == KernelSU differs from other methods in that root access is implemented directly in the kernel. Compared to other root methods that run in userspace, such as Magisk, this has the advantage that commands with su can be executed like normal commands, but still have root privileges. This is not prevented by SELinux or detected by the PlayIntegrity API check, so applications that use it will continue to function. Unlike Magisk, /system/bin/su is a virtual file implemented by hooking system calls with kprobes, and overlayfs is used for systemless modifications to the system partition instead of magic mount. == History == The planning of KernelSU was started in 2018 by developer Jason Donenfeld, also known as XDA user zx2c4. The lack of a root manager app and the difficulty of creating boot images meant that KernelSU was not suitable for productive use, and for a long time this method remained theoretical and could only be used by developers. In 2021, Google launched Generic Kernel Images (GKI for short), which facilitates the creation of a set of device-independent rooted boot images. In response, the developer known on XDA as weishu, who had also worked on projects such as VirtualXposed, adapted KernelSU for GKI-compatible kernels. The adaptation, which was released in January 2023, ensures that any device booting with Linux kernel version 5.10 or higher should be compatible. In addition, the developer also offers a special manager app that, in addition to managing root privileges, also offers overlay-based modding similar to Magisk modules. As of November 2025, 310 developers have contributed to the development of the KernelSU implementation. == Distribution == KernelSU can be installed on all devices that use GKI, as well as on individually supported devices without GKI. Some custom ROMs already have it integrated by default, including ROMs such as CrDroid, Bliss OS, and Evolution X.
Digital Michelangelo Project
The Digital Michelangelo Project was a pioneering initiative undertaken during the 1998–1999 academic year to digitize the sculptures and architecture of Michelangelo using advanced laser scanning technology. The project was led by a team of 30 faculty, staff, and students from Stanford University and the University of Washington, with the aim of creating high-resolution 3D models of Michelangelo's works for scholarly, educational, and preservation purposes. == Objectives == The primary goals of the Digital Michelangelo Project were: To apply recent advancements in laser rangefinder technology for digitizing large cultural artifacts. To create detailed digital archives of Michelangelo's sculptures and architectural spaces for future study and analysis. To explore potential educational and curatorial applications for 3D scanned data. === Artworks digitized === The project involved scanning several iconic works by Michelangelo, including: David The Unfinished Slaves (Atlas, Awakening, Bearded, and Youthful) St. Matthew The allegorical statues from the Medici tombs (Night, Day, Dawn, and Dusk) The architectural interiors of the Tribuna del David at the Galleria dell'Accademia and the New Sacristy in the Medici Chapels. == Technology and methodology == === 3D scanning === The project's primary scanner was a laser triangulation rangefinder mounted on a motorized gantry, custom-built by Cyberware Inc. The scanner used a laser sheet to project onto an object, capturing its shape through triangulation. Multiple scans were taken from various angles and combined into a single, detailed 3D mesh. The resolution achieved was fine enough to capture even Michelangelo's chisel marks, with triangles approximately 0.25 mm on each side. In addition to shape data, color data was captured using a spotlight and a secondary camera, enabling the creation of textured 3D models. === Data processing === The project developed a software suite for processing the scanned data. This included: Aligning and merging multiple scans into a seamless 3D model. Filling holes in the geometry caused by inaccessible areas. Correcting color data for lighting inconsistencies and shadowing. Non-photorealistic rendering techniques were also applied, highlighting surface features such as Michelangelo’s chisel marks for enhanced visualization. == Logistical challenges == The scale and complexity of the project presented several challenges: Data size: The dataset for David alone comprised 2 billion polygons and 7,000 color images, occupying 60 GB of storage. Artifact safety: Ensuring the safety of the statues during scanning required extensive crew training, foam-encased equipment, and collision-prevention mechanisms. == Applications and impact == The digitized models have numerous potential applications: Art history: Allowing precise measurements and geometric analysis, such as determining chisel types or evaluating structural balance. Education: Providing new ways to study art, including interactive viewing from unconventional angles and with custom lighting. Museum curation: Enhancing visitor experiences through interactive kiosks and virtual models. The project demonstrated the potential for 3D technology to preserve and disseminate cultural heritage. == Data distribution == The project's models are available through Stanford University for scholarly purposes, under strict licensing due to Italian intellectual property laws. === ScanView === To provide public access to the 3D models while respecting usage restrictions, the project developed ScanView, a client/server rendering system. ScanView allows users to view and interact with high-resolution 3D models without downloading the data. The client component consists of a freely available viewer program and simplified 3D models. Users can navigate these models locally, adjusting position, orientation, lighting, and surface appearance. When a user finalizes a view, the client queries a remote server for a high-resolution rendering of the model, which is sent back to overwrite the simplified version on the user’s screen. A typical query-response cycle takes 1–2 seconds, depending on network conditions. To protect the models from unauthorized reconstruction, the system employs several security measures, including: Encrypting queries Perturbing viewpoint and lighting parameters Adding noise and warping rendered images Compressing images before transmission ScanView operates on Windows-based PCs and provides access to selected models, including David and St. Matthew, as well as other artifacts such as fragments of the Forma Urbis Romae and items from the Stanford 3D Scanning Repository. == Sponsors == The Digital Michelangelo Project was supported by Stanford University, Interval Research Corporation, and the Paul G. Allen Foundation for the Arts.
Stride (software)
Stride was a cloud-based team business communication and collaboration tool, launched by Atlassian on 7 September 2017 to replace the cloud-based version of HipChat. Stride software was available to download onto computers running Windows, Mac or Linux, as well as Android, iOS smartphones, and tablets. Stride was bought by Atlassian's competitor Slack Technologies and was discontinued on February 15, 2019. The features of Stride include chat rooms, one-on-one messaging, file sharing, 5 GB of file storage, group voice and video calling, built-in collaboration tools, and up to 25,000 of searchable message history. Premium features include unlimited file storage, users, group chat rooms, file sharing and storage, apps, and history retention. The premium version, priced at $3/user/month, also includes advanced meeting functionality like group screen sharing, remote desktop control, and dial-in/dial-out capabilities. Stride offered integrations with Atlassian's other products as well as other third-party applications listed in the Atlassian Marketplace, such as GitHub, Giphy, Stand-Bot and Google Calendar. Stride offered additional features beyond messaging to improve efficiency and productivity. It aimed to reduce collaboration noise by introducing a "focus" mode, and eliminates the divisions between text chat, voice meetings, and videoconferencing, by simplifying transitioning between these modes in the same channel. On July 26, 2018, Atlassian announced that HipChat and Stride would be discontinued February 15, 2019, and that it had reached a deal to sell their intellectual property to Slack. Slack paid an undisclosed amount over three years to assume the user bases of the services, while Atlassian took a minority investment in Slack. The companies also announced a commitment to work on integration of Slack with Atlassian services.
Deep image compositing
Deep image compositing is a way of compositing and rendering digital images that emerged in the mid-2010s. In addition to the usual color and opacity channels a notion of spatial depth is created. This allows multiple samples in the depth of the image to make up the final resulting color. This technique produces high quality results and removes artifacts around edges that could not be dealt with otherwise. == Deep data == Deep data is encoded by advanced 3D renderers into an image that samples information about the path each rendered pixel takes along the z axis extending outward from the virtual camera through space, including the color and opacity of every non-opaque surface or volume it passes through along the way, as well as neighboring samples. It might be considered somewhat analogous to the way ray tracing generates simulated photon paths through such mediums; however, ray tracing and other traditional rendering techniques generally produce images that contain only three or four channels of color and opacity values per pixel, flattened into a two dimensional frame. Depth maps, on the other hand, contain z axis information encoded in a grayscale image. Each level of gray represents a different slice of the z space. The "thickness" of each slice is determined at time of render, allowing for more or less depth fidelity depending on how deep the scene is. Depth maps have been a boon to compositors for blending 3D renders with live action and practical elements. To be useful, the map must have high enough bit depth to encode separation between close-to-camera objects and objects near infinity. Most 3D software packages are now capable of generating 16-bit and 32-bit depth maps, providing up to 2 billion depth levels. Depth maps do not however include transparency information about non-opaque surfaces or volumes and as such, objects beyond and viewed through these semi- or fully-transparent objects will have no depth information of their own and may not get composited or blurred correctly. Even the popular addition of cryptomattes to many post-production and VFX studios' pipelines, while providing separate color-coded ID shapes for individual elements in a rendered scene to further bridge the gap between CGI and compositing, don't allow for the nearly automated and fully non-linear workflows that deep data does. This is because deep images encapsulate enough 3D information that normally time-intensive tasks such as rotoscoping with numerous holdout mattes for complex interactions between moving characters and semi-transparent environmental volumes like smoke or water, are essentially trivial. Instead of going through that process, multiple mattes could easily be generated from a single set of deep images with no need to re-render every matte element and background for each case. In addition to that efficiency and flexibility, deep data images inherently provide much higher visual quality in common areas that have been difficult with traditional renders, such as the motion-blurred edges of characters with semi-transparent elements like hair. One downside to the use of deep images is their substantial file size, since they encode a relatively enormous amount of data per frame compared to even multichannel formats such as OpenEXR. === Function-based (integrated) === The data is stored as a function of depth. This results in a function curve that can be used to look up the data at any arbitrary depth. Manipulating the data is harder. === Sample-based (deintegrated) === Each sample is considered as an independent piece and can so be manipulated easily. To make sure the data is representing the right detail, an additional expand value needs to be introduced. == Generating deep data == 3D renderers produce the necessary data as a part of the rendering pipeline. Samples are gathered in depth and then combined. The deep data can be written out before this happens and so is nothing new to the process. Generating deep data from camera data needs a proper depth map. This is used in a couple of cases but still not accurate enough for detailed representation. For basic holdout task this can be sufficient though. == Compositing deep data images == Deep images can be composited like regular images. The depth component makes it easier to determine the layering order. Traditionally this had to be input by the user. Deep images have that information for themselves and need no user input. Edge artifacts are reduced as transparent pixels have more data to work with. == History == Deep Images have been around in 3D rendering packages for quite a while now. The use of them for holdouts was first done at several VFX houses in shaders. Holdout mattes can be generated at render time. Using them in a more interactive manner was started recently by several companies, SideFX integrated it in their Houdini software and facilities like Industrial Light & Magic, DreamWorks Animation, Weta, AnimalLogic and DRD studios have implemented interactive solutions. In 2014 the Academy of Motion Picture Arts and Sciences honored the technology with its annual SciTech awards. Dr. Peter Hillman for the long-term development and continued advancement of innovative, robust and complete toolsets for deep compositing and to Colin Doncaster, Johannes Saam, Areito Echevarria, Janne Kontkanen and Chris Cooper for the development, prototyping and promotion of technologies and workflows for deep compositing. == Resources == Pixar Paper Deep Image Paper Video tutorial of Deep Imaging as used on 2012 film Rise of the Planet of the Apes, Nuke compositing software Deep Compositing Course Deep Image File Format at Google Code Academy Award for the Technology Theory of Deep Pixels OpenEXR Deep Pixels
SwissCovid
SwissCovid is a COVID-19 contact tracing app used for digital contact tracing in Switzerland. Use of the app is voluntary and based on a decentralized approach using Bluetooth Low Energy and Decentralized Privacy-Preserving Proximity Tracing (dp3t). == Development == The app was developed in collaboration with the FOPH by Federal Office for Information Technology, Systems and Communications FOITT, École polytechnique fédérale de Lausanne (EPFL) and the Swiss Federal Institute of Technology in Zurich (ETH) as well as other experts. == Non-interoperability with applications in European countries == There is an agreement between EU countries to make applications compatible. However, there is no legal basis for the SwissCovid application to be part of this portal even though technically speaking it is ready, according to Sang-Ill Kim, head of the digital transformation department of the Federal Office of Public Health. == Criticism == === Not full open source and dependence on Google and Apple === In June 2020, researchers Serge Vaudenay and Martin Vuagnoux published a critical analysis of the application, noting that it relies heavily on Google and Apple's exposure notification system, which is integrated into their respective Android and iOS operating systems. Since Google and Apple have not released the full source code of this system, this would call into question the truly open source nature of the application. The researchers note that the dp3t collective, which includes the developers of the application, has asked Google and Apple to release their code. Moreover, they criticize the official description of the application and its functionalities, as well as the adequacy of the legal basis for its effective operation. === Cyber attacks === Professor Serge Vaudenay and Martin Vuagnoux identify also various security vulnerabilities in the application. The system would thus allow a third party to trace the movements of a phone using the application by means of Bluetooth sensors scattered along its path, for example in a building. Another possible attack would be to copy identifiers from the phones of people who may be ill (for example, in a hospital), and to reproduce those identifiers in order to receive notification of exposure to COVID-19 and illegitimately benefit from quarantine (thus entitling them to paid leave, a postponed examination, or other benefits). The system would also allow a third party to use a phone using the application by means of Bluetooth sensors scattered along the way. Paul-Olivier Dehaye of Personaldata.io and professor Joel Reardon of the University of Calgary published in June 2020 several examples of AEM (Associated Encrypted Metadata) replay and manipulation attacks via software development kits (SDKs) found in benign third-party mobile applications downloaded by the general public and having the phone's Bluetooth access permissions and in September 2020 a paper indicating that "Bluetooth-based proximity tracing apps are fundamentally insecure with respect to an attacker leveraging a malevolent app or SDK". === Costs === According to a publication by the federal administration, "the costs of developing the software for the mobile phone application, the GR back-end and the code management system as well as the costs for access management for the cantonal doctors' services are estimated at a one-off amount of 1.65 million francs. However, the Zurich-based company Ubique, responsible for the development of the application, was finally awarded the mandate to develop the application for an amount of 1.8 million francs. Through the Botnar Foundation based in Basel, École polytechnique fédérale de Lausanne received 3.5 million Swiss francs for the development of the application
Camera interface
The Camera Interface block or CAMIF is the hardware block that interfaces with different image sensor interfaces and provides a standard output that can be used for subsequent image processing. A typical Camera Interface would support at least a parallel interface although these days many camera interfaces are beginning to support the Mobile Industry Processor Interface (MIPI) Camera Serial Interface (CSI) interface. == Electrical connections == The camera interface's parallel interface consists of the following lines: 8 to 12 bits parallel data line These are parallel data lines that carry pixel data. The data transmitted on these lines change with every Pixel Clock (PCLK). Horizontal Sync (HSYNC) This is a special signal that goes from the camera sensor or ISP to the camera interface. An HSYNC indicates that one line of the frame is transmitted. Vertical Sync (VSYNC) This signal is transmitted after the entire frame is transferred. This signal is often a way to indicate that one entire frame is transmitted. Pixel Clock (PCLK) This is the pixel clock and it would change on every pixel. NOTE: The above lines are all treated as input lines to the Camera Interface hardware.
Screen generator
A screen generator, also known as a screen painter, screen mapper, or forms generator is a software package (or component thereof) which enables data entry screens to be generated declaratively, by "painting" them on the screen WYSIWYG-style, or through filling-in forms, rather than requiring writing of code to display them manually. 4GLs commonly incorporate a screen generator feature. They are also commonly found bundled with database systems, especially entry-level databases. A screen generator is one aspect of an application generator, which can also include other functions such as report generation and a data dictionary. The earliest screen generators were character-based; by the 1990s, GUI support became common, and then support for generating HTML forms as well. Some screen generators work by generating code to display the screen in a high-level language (for example, COBOL); others store the screen definition in a data file or in database tables, and then have a runtime component responsible for actually displaying the form and receiving and validating user input. == Examples == Examples of screen generators include: IBM Screen Definition Facility II: generates screens for CICS BMS, IMS MFS, ISPF, GDDM and CSP/AD. Performix for Informix. Microsoft Visual Basic the forms component of Microsoft Access Oracle Developer, in particular its Oracle Forms component the QDesign component of PowerHouse SystemBuilder/SB+ the Screen Painter component of SAP's ABAP Workbench the FoxView component of FoxPro. FoxView was originally developed by Luis Castro as a dBASE screen generator named ViewGen; Fox purchased it and bundled it with FoxPro 1.0. Later, Fox replaced Castro's code with their own screen painter code. dBASE included a built-in screen generator in dBASE IV onwards; in dBASE III and earlier, third party screen generators were available, including the already mentioned ViewGen DPS 1100 for UNIVAC 1100 series mainframes.