AI Image Generators

Explore the best AI Image Generators — independent reviews, comparisons, pricing and step-by-step how-to guides, curated by Aizhi.

  • TAPPS2

    TAPPS2

    TAPPS2 (Technische Alternative Planungs- und Programmier-System) is a tool used for developing the program logic for the universal, heating and solar thermal controllers by Austrian manufacturer Technische Alternative. Its primary usecase is defining the exact reaction of the controller to a certain event. Other than its predecessor, TAPPS, which could only be used to program controllers of type UVR1611, TAPPS2 is mainly used to program the UVR16x2 and RSM610 controllers, as well as several extension modules. == Development == Development in TAPPS2 is done on a vector-based drawing surface using components that can be placed via drag and drop. The components, which can be separated into inputs, functions and outputs are then being connected according to their individual features. Available components vary according to the current solar thermal control unit.

    Read more →
  • Mojito (framework)

    Mojito (framework)

    Mojito is an environment agnostic, Model-View-Controller (MVC) web application framework. It was designed by Yahoo. == Features == Mojito supports agile development of web applications. Mojito has built-in support for unit testing, Internationalization, syntax and coding convention checks. Both server and client components are written in JavaScript. Mojito allows developers designing web applications to leverage the utilities of both configuration and MVC framework. Mojito is capable of running on both JavaScript-enabled web browsers and servers using Node.js because they both utilize JavaScript. Mojito applications mainly consist of two components: JSON Configuration files: these define relationships between code components, assets, routing paths, and framework defaults and are available at the application and mojit level. Directories: these reflect MVC architecture and are used to separate resources such as assets, libraries, middleware, etc. == Architecture == In Mojito, both server and "client" side scripting is done in JavaScript, allowing it to run on both client and server thereby breaking the "front-end back-end barrier." It has both client and server runtimes. === Server runtime === This block houses operations needed by server side components. Services include: Routing rules, HTTP Server, config loader and disk-based loader. === Client runtime === This block houses operations called upon while running client sides components. Services include local storage/cache access and JSON based /URL based loader === Core === Core function can be accessed on client or server. Services include Registry, Dispatcher, Front controller, Resource store. === Container === mojit object comes into the picture. This container also include the services used by mojits. API and Mojito services are the blocks which caters to services needed for execution of mojits. === API (Action Context) === Mojito services are a customizable service block. It offers mojits a range of services which might be needed by mojit to carry out certain actions. These services can be availed at both client and server side. Reusable services can be created and aggregated to the core here. == Mojits == Mojits are the modules of a Mojito application. An application consists of one or more mojits. A mojit encompasses a Model, Views and a Controller defined by JSON configuration files. It includes a View factory where views are created according to the model and a View cache that holds frequently requested views to aid performance. === Application Architecture === A Mojito application is a set of mojits facilitated by configurable JSON files which define the code for model, view and controller. This MVC structure works with API block and Mojito services, and can be deployed at both client and server side. While the application is deployed at client side, it can call server-side modules using binders. Binders are mojit codes that let mojits request services from each other. Mojit Proxy acts as an intermediary between binders and mojit's API (application context) block and other mojits. Controllers are command-issuing units of mojits. Models mirror the core logic and hold data. Applications can have multiple models. They can be centrally accessed from controllers. View files are created in accordance with controllers and models, and are marked-up before they are sent to users as output. === Application Directory Structure === Directory structure of a Mojito application with one mojit: [mojito_app]/ |-- application.json |-- assets/ | `-- favicon.icon |-- yui_modules/ | `-- .{affinity}.js |-- index.js |-- mojits/ | `-- [mojit_name | |-- assets/ | |-- yui_modules/ | | `-- .{affinity}.js | |-- binders/ | | `-- {view_name}.js | |-- controller.{affinity}.js | |-- defaults.json | |-- definition.json | |-- lang/ | | `-- {mojit_name}_{lang}.js | |-- models/ | | `-- {model_name}.{affinity}.js | |-- tests/ | | |-- yui_modules/ | | | `-- {module_name}.{affinity}-tests.js | | |-- controller.{affinity}-tests.js | | `-- models/ | | `-- {model_name}.{affinity}-tests.js | `-- views/ | |-- {view_name}.{view_engine}.html | `-- {view_name}.{device}.{view_engine}.html |-- package.json |-- routes.json (deprecated) |-- server.js == Model, View and Controller == The Model hosts data, which is accessed by the Controller and presented to the View. Controller also handles any client requests for data, in which case controller fetches data from the model and passes the data to the client. All three components are clustered in the mojit. Mojits are physically illustrated by directory structures and an application can have multiple mojits. Every mojit can have one controller, one or more views and zero or more models. === Model === The model it represents the application data and is independent of view or controller. Model contains code to manipulate the data. They are found in the models directory of each mojit. Functions include: Storing information for access by controller. Validation and error handling. Metadata required by the view === Controller === The controller acts like a connecting agent between model and view. It supplies input to Model and after fetching data from model, passes it to View. Functions include Redirection Monitors authentication Web safety Encoding === View === The view acts as a presentation filter by highlighting some model attributes and suppressing others. A view can be understood as a visual permutation of the model. The view renders data received from controller and displays it to the end user.

    Read more →
  • Online OS

    Online OS

    The Online Operating System was a fully multi-lingual and free to use web desktop written in JavaScript using Ajax. It was a Windows-based desktop environment with open-source applications and system utilities developed upon the reBOX web application framework by iCUBE Network Solutions, an Austrian company located in Vienna. == About the project == OOS.cc, which is short for Online Operating System, was a web application platform that mimicked the look and feel of classic desktop operating systems such as Microsoft Windows, Mac OS X or KDE. It consisted of various open source applications built upon the so-called reBOX web application framework. As applications could be executed in an integrated and parallel way, the OOS could have been considered a web desktop or webtop. It provided basic services such as a GUI, a virtual file system, access control management and possibilities to develop and deploy applications online. As the Online Operating System was executed within a web browser, it was no real operating system but rather a portal to various web applications, offering a high usability and flexibility. The project was partly funded by grants from the Internetprivatstiftung Austria (IPA). As at 01.08.2008 almost 20.000 users have joined the oos.cc community, using the offered featured and applications. == History == The development of the web desktop was started by iCUBE Network Solutions in 2005, followed by the first beta releases in 2006. Hence, together with YouOS and eyeOS, it can be considered to be one of the first publicly available systems of its kind. The first full version including core-level multi-language support, the file system and a basic set of applications was released to the public in March 2007 on the occasion of a national exhibition (ITnT Austria Archived 2007-06-30 at the Wayback Machine) and has left beta state half a year later in October 2007. The first release considered stable (1.0.0) was published in July 2007. The project itself and the contained applications have received several national innovation awards (see,) and have gained attention mainly due to the comprehensive approach taken (see,). OOS.cc started as a national project. The full platform including all offered applications are currently available in three languages (German, English as well as Spanish) and is receiving increasing coverage around the world (for examples see, or). The current version is 1.3.01 from 01.08.2008. == Technical overview == The project is fully written in JavaScript, exclusively using DHTML techniques to run in any web browser without any additional software installation needed. The system implements a modern kind of web application model, excessively using Ajax for communicating between client components and the Java server backend in an exclusively asynchronous manner. Aim is to offer users the unique interaction behavior following the desktop metaphor, which is the main idea of any web desktop. Also typical for this sort of web application is the broadly use of Javascript-on-demand techniques, cutting the complete project source into pieces and loading them instantly when needed. Based on this technical basis, reBOX was the framework library all applications in oos.cc were built of. It is a fully flexible and extensible API, including a GUI widget set, communication mechanisms and server services offering general and framework specific services. The Online Operating System itself consisted of a basic framework, which was able to launch any JavaScript application using the reBOX library. The user interface was based on the behavior of the Windows desktop with a start menu, a task bar and a desktop background. All applications were running in this environment. At server side, there were Java based web services that ran to serve the client processes and to provide data from the relational database in the backend. oos.cc also provided an integrated development environment called Developer Suite, which allowed the community to build own applications for the desktop environment based on reBOX (see development section below). == License == All applications available in oos.cc were open source under the European Union Public Licence (EUPL). The reBOX development toolkit is free to use developing any applications for the webtop. == Features == As mentioned above, all applications published on oos.cc are open source based on the EUPL, and can be "installed" or "deinstalled" to what-ever preferences the user has. Besides global services like the multi-language support or the global theme support, as well as some minor tools and games, oos.cc offered four major services that could be used completely free of charge. Integrated and fully flexible file storage (1 GB per user) HTTP as well as FTP file transfer from and to local file system User-based file-shares within the oos-community WebDAV access Document Management (including Version Control and File Locking mechanisms) Image publishing, organization and post-processing A free sub domain (user.oos.cc) for web- or image publishing, directly integrated in the desktop Groupware applications, including free mail, fetchmail and contact management An integrated development environment where oos-applications can be created directly from within the system (see development section below) Next releases were planned to focus on an extensive security and privacy suite, dealing with challenges like anonymous communication (browsing as well as temporary mail-addresses) as well as offering encrypted password and file storage and connectivity services. Since its initial stable release, OOS.cc could have been accessed using https to ensure secure communication. == Limitations and drawbacks == Limited number of applications: no commercial applications can be hosted. Only reviewed applications are being published No processing of popular office formats (.doc, .odt, etc.) Limited language support: Only English, German and Spanish Dependence on foreign infrastructure: No possibility to extend storage, no additional/guaranteed bandwidth, etc. == Development == One of the key focuses of the team was right from the beginning to offer a very flexible and comprehensive API, that can be used to develop not only custom applications within oos.cc, but also stand-alone web-applications or to integrate single components in existing web-sites. By decoupling the development from web-related "problems" using the reBOX API web-applications can be development in a similar fashion to any Java program: Elements can be positioned and can interact like in high-level object oriented programming languages, without taking care of divs, browser specific behavior or communication handling. The framework also offers multi-language and theme support for existing as well as newly created applications, allowing changing almost every aspect of the look and feel of the used components according to the preferences of its users. For taking advantage of this approach, one of the applications offered in the OOS was an integrated Development Suite, allowing directly writing and executing code and hence creating new programs within the boundaries of the web computer. All applications on oos.cc were released as open source, thus all existing programs were offered to be imported, reviewed or changed and then locally deployed. Following this idea, every user was free to submit changed or newly created applications to be included in the globally offered application set. The last release offered features like auto-completion and an outline-window.

    Read more →
  • Elements (toolchain)

    Elements (toolchain)

    RemObjects Elements is a toolchain for software development, comprising six programming languages: C#, Swift, Go, Java, Oxygene (a form of modern Object Pascal), and Visual Basic .NET. All languages interoperate, meaning a single project can use any combination of languages, and they can all be compiled to .NET, the JVM, native, or WebAssembly. Elements supports Microsoft Windows, all Apple Inc. platforms (including iOS, visionOS and watchOS), Android, and Linux. Elements also supports language conversion, allowing source code in one language to be rewritten in another. Elements is supported in Visual Studio, but RemObjects also makes their own IDEs, Fire (on MacOS) and Water (on Windows.) == Background == RemObjects began in 2002, creating software for Delphi, but in 2005 in response to the growth of .NET and that Delphi was targeting only native Windows, they released Oxygene (known as Chrome at the time) as a new version of Object Pascal, with more modern syntax as well as being .NET-native. Since then, five other languages have been added to the suite, as well as compiling for the web via WebAssembly and to native architectures (eg Intel 32/64 or ARM64). Elements is primarily intended for developers who want to pull together libraries and codebases written in multiple languages, including legacy codebases in older languages while modernizing either with newer syntax and features or by adding in the use of newer or more popular languages. Because of the Oxygene flavour of Object Pascal, supporting Delphi apps is a primary focus, including allowing Pascal to be compiled for other architectures or providing language features that match other prominent languages. == Approach == New versions of the Elements come out approximately every week. RemObjects names its programming languages after chemical elements, sometimes with poetic or musical spelling, rather than referring to them directly. They are: C#: Hydrogene Object Pascal: Oxygene Java: Iodine Visual Basic: Mercury Go: Gold Swift: Silver == History == The Elements compiler was first introduced with version 1.0 in 2005 under the name "Chrome", with support for only the Oxygene language on the .NET platform, primarily as a response to the then-new and not well-received Delphi .NET compiler from Embarcadero. Chrome saw updates to version 1.5 'Floorshow' and Chrome 2.0 'Joyride' over the next few years, moving in parallel with major advancements on the .NET platform for .NET 2.0 (Generics) and .NET 3.x (LINQ), respectively. With the release of version 3.0 (code-named Oxygène after the Jean-Michel Jarre album of the same name) Chrome was rebranded to Oxygene in 2008, and also shipped co-branded by Embarcadero as Delphi Prism (later just Prism) as part of RAD Studio, replacing Embarcadero's own and now-defunct Delphi.NET compiler. 2010 saw the release of Oxygene 4 ("Echoes"), the last version to focus on just a single language and platform. With Oxygene 5 in 2011 and Oxygene 6 in 2013, RemObjects introduced new platform support for Java/Android (code-name "Cooper") and then Cocoa, the Apple development platform (code-name "Toffee"). Elements 7.0 was released at the beginning of 2014, adding the second programming language, C# to the compiler, and delegating Oxygene from the product name to merely branding the Object Pascal-based language. Over the subsequent years, Elements gained support for additional languages, with Apple Swift in 2015, Java in 2017, and subsequently Google's Go and Mercury, a revitalized Visual Basic.NET. Elements also gained support for its fourth target platform, "Island", for CPU-native compilation for Windows, Linux, and WebAssembly. In addition to the chemical elements-based names for the different languages, the "Elements" concept was carried on with the introduction of dedicated development environments alchemically named Fire (for the Mac, in 2015) and Water (for Windows, in 2018). == Fire and Water (IDEs) == Fire and Water are integrated development environments developed by RemObjects Software. They are designed specifically for use with the Elements Compiler. Fire is the version developed for macOS, while Water is intended for Microsoft Windows. Both IDEs are designed to work closely with the Elements compiler and are primarily intended for developers using the RemObjects language ecosystem. They support software development across multiple platforms, including .NET, Android, iOS, macOS, Windows, Linux, and WebAssembly. The IDEs include standard development tools such as syntax highlighting, code completion, debugging, and project navigation. Build operations are managed using a custom system known as EBuild, which is part of the broader Elements toolchain. The IDEs are distributed as part of the RemObjects Elements package and are updated in coordination with the compiler itself. == In media == Oxygene has been mentioned several times by Verity Stob in their Chronicles of Delphi series, currently living at The Register.

    Read more →
  • Process map

    Process map

    Process map is a global-system process model that is used to outline the processes that make up the business system and how they interact with each other. Process map shows the processes as objects, which means it is a static and non-algorithmic view of the processes. It should be differentiated from a detailed process model, which shows a dynamic and algorithmic view of the processes, usually known as a process flow diagram. There are different notation standards that can be used for modelling process maps, but the most notable ones are TOGAF Event Diagram, Eriksson-Penker notation, and ARIS Value Added Chain. == Global process models == Global characteristics of the business system are captured by global or system models. Global process models are presented using different methodologies and sometimes under different names. Most notably, they are named process map in Visual Paradigm and MMABP, value-added chain in ARIS, and process diagram in Eriksson-Penker notation – which can easily lead to the confusion with process flow (detailed process model). Global models are mainly object-oriented and present a static view of the business system; they do not describe dynamic aspects of processes. A process map shows the presence of processes and their mutual relationships. The requirement for the global perspective of the system as a supplementary to the internal process logic description results from the necessity of taking into consideration not only the internal process logic but also its significant surroundings. The algorithmic process model cannot take the place of this perspective since it represents the system model of the process. The detailed process model and the global process model represent different perspectives on the same business system, so these models must be mutually consistent. A macro process map represents the major processes required to deliver a product or service to the customer. These macro process maps can be further detailed in sub-diagrams. It is often the case that process maps cross different functional areas of the organization. Process maps are used by many companies to have a holistic view of all processes and the connections between them. Maps help in navigating the sub-processes and make understanding of the organization's operations easier. The process map shows relationships and dependencies between processes and its focus should be on core business processes of the organization. A process map can be seen as the most abstract level of the process architecture, and it acts as the introduction to the more detailed levels. A process map that is correctly designed is able to provide a general understanding of a company's operations. Designing the process map is an important and strategic step for the organization, and it is followed by further business process modelling implementation. == Context == Methodology for Modelling and Analysis of Business Process (MMABP) is a business process modelling methodology developed at the Department of Information Technology, Faculty of Informatics and Statistics of the Prague University of Economics and Business. The methodology is defined as a “general methodology for modelling business systems using informatics methods and approaches”. Methodology is used to analyse business processes and to develop a comprehensive model of the system. The goal of developing a model is to be used for process optimization. The model should be created following the characteristics and specifics of the organization in question and following external influences that can affect the organization. The model should be optimal from an economic perspective, but it should also be optimal from a factual perspective, meaning that it should be as simple as possible while maintaining complete functionality. Business system modelling is based on a two-dimensional approach: Real World structure (substance) – set of objects and their relationships Real World behaviour – set of mutually connected business processes Additionally, there are also two views of the systems: Global view of the system Detailed view of the system's parts This results in the need to model the system from four different perspectives in order to achieve the complete and comprehensive view of the business system. MMABP also proposes which notation languages can be used for modelling each perspective, and it also suggests some improvements to the notation languages in order to fit the purpose. Global view of the objects – Conceptual model (Class diagram) Detailed view of the objects – Object life cycle (State Chart) Global view of the processes – Process map (Eriksson-Penker Diagram/TOGAF Event Diagram/ARIS VAC) Detailed view of the processes – Model of the process flow (BPMN Diagram) Data Flow Diagram (DFD) is additional diagram used for describing the required functionalities of the information system. == Notation standards == === Eriksson-Penker Diagram === Eriksson-Penker diagram is a tool used in business model analysis and design. It is named after Hans-Erik Eriksson and Magnus Penker, who developed the concept in their book "Business modelling with UML: Business Patterns at Work”. Eriksson-Penker diagrams are used to map out the key components of a business model and how they interact with one another. The diagrams typically consist of a series of boxes and lines that represent the different elements of the business model, such as the value proposition, customer segments, channels, revenue streams, and key resources. The lines between the boxes represent the relationships and dependencies between the different elements of the business model. These diagrams are useful for visualizing and understanding the various components of a business model, and can help organizations identify potential areas for improvement or areas of risk. They can also be used as a communication tool to help stakeholders understand the business model and its underlying assumptions. These diagrams are useful for visualizing and understanding the various components of a business model, and can help organizations identify potential areas for improvement or areas of risk. They can also be used as a communication tool to help stakeholders understand the business model and its underlying assumptions. It is possible to use Eriksson-Penker diagrams to create a global process view of a business. In this case, a diagram would be used to map out the key processes and activities that are involved in the business, as well as the relationships and dependencies between these processes. For example, an Eriksson-Penker diagram could be used to depict the various steps involved in the product development process, from concept development to market launch. It could also be used to show how different functions within the organization, such as marketing, sales, and production, interact and depend on one another to support the overall business. Eriksson-Penker diagram is one of the most popular de facto standards that can be used for an object-oriented global view of business processes. It is developed as an extension of the UML, and it is often used together with the BPMN to compensate for the lack of possibility to model the global view with this widely accepted standard. === TOGAF Event Diagram === TOGAF (The Open Group Architecture Framework) is a framework for enterprise architecture that provides a common language and set of standards for designing, planning, implementing, and governing an enterprise's IT architecture. TOGAF event diagrams are diagrams used in the TOGAF framework to represent the flow of events within a system or process. The TOGAF Event Diagram is a visual representation of the events within an organization or system. It can be used to show the sequence of events that occur in a particular process, as well as the relationships between the events and the stakeholders involved. TOGAF Event Diagrams can be useful in creating a global process view because they provide a visual representation of the events, which can be helpful in understanding how the process fits into the larger context of the organization. TOGAF Event Diagram is the most perspective standard for the system view of processes today. It is used to represent the system of processes as well as their connections to the functional organizational structure. === ARIS Value Added Chain === ARIS (Architecture of Integrated Information Systems) is a methodology and a set of tools for designing and managing business processes. It is based on the idea that business processes are the core of an organization and that they can be modelled and optimized to improve efficiency and effectiveness. The ARIS methodology provides a framework for understanding and analysing business processes, as well as for designing and implementing improvements to those processes. It includes a set of graphical modelling languages and tools for creating process models, as well as a database for storing and managing pr

    Read more →
  • Sahara Net

    Sahara Net

    Sahara Net is an information and communications technology provider (ICT) serving the Saudi market, the company has rapidly grown since 1989 to offer various complementary services such as connectivity, internet, hosting, cloud, optimization, cyber security, and managed services. == History == Sahara Net is a Saudi Joint Stock Company (JSC) and its history goes back to 1989 when Sahara Net established the 1st Saudi Bulletin Board Service (BBS) in the Kingdom. During this period, it operated as a hub for email exchange in the FidoNet network. And in 1994 Sahara Net started offering Internet connectivity and other related services like internet email, web design, web hosting, and Domain name registry services. These services made the first ISP in Saudi Arabia before the official licensing in 1998, when the Saudi Internet market was regulated and Sahara Net received Internet Service Provider (ISP) license and was appointed as the official Local Internet Registry (LIR) in the Kingdom of Saudi Arabia. == Today == The company grew over these years to become one of the main ICTs in the Saudi Arabian market, extending network coverage to all major cities in Saudi Arabia, and offering various connectivity options to business as well as home users. In 2009, the company was partially acquired by Telindus (the ICT investment arm of Belgacom), the famous telecom operator in Belgium and Europe. Then, in 2014, the company was fully acquired by its original founders. Recently, Sahara Net was converted from an LLC to a JSC with over 1200 shareholders by a capital raise (original founders still control 70% of the shares).

    Read more →
  • ActivityPub

    ActivityPub

    ActivityPub is a protocol and open standard for decentralized social networking. It provides a client-to-server (C2S) API for creating and modifying content, as well as a federated server-to-server (S2S) protocol for delivering notifications and content to other servers. ActivityPub is the defining standard of the Fediverse, a decentralised social network of various social interaction models, and content types, which consists of independently managed instances of software such as Mastodon, Pixelfed and PeerTube, among others. ActivityPub is considered to be an update to the ActivityPump protocol used in pump.io, and the official W3C repository for ActivityPub is identified as a fork of ActivityPump. The creation of a new standard for decentralized social networking was prompted by the complexity of OStatus, the most commonly used protocol at the time. OStatus was built using a multitude of technologies (such as Atom, Salmon, WebSub and WebFinger), a product of the infrastructure used in GNU social (the originator and largest user of the OStatus protocol), which made it difficult to implement the protocol into new software. OStatus was also only designed to work with microblogging services, with little flexibility to the types of data that it could hold. The standard was first published by the World Wide Web Consortium (W3C) as a W3C Recommendation in January 2018 by the Social Web Working Group (SocialWG), a working group chartered to build the protocols and vocabularies needed to create a standard for social functionality. Shortly after, further development was moved to the Social Web Community Group (SocialCG), the successor to the SocialWG. == Design == ActivityPub uses the ActivityStreams 2.0 format for building its content, which itself uses JSON-LD. The three main data types used in ActivityPub are Objects, Activities and Actors. Objects are the most common data type, and can be images, videos, or more abstract items such as locations or events. Activities are actions that create and modify objects, for example a Create activity creates an object. Actors are representative of an individual, a group, an application or a service, and are the owners of objects. Every actor type contains an inbox and outbox stream, which sends and receives activities for a user. In order to publish data (for example liking an article), a user creates an activity that declares that they liked an Article object and publishes it to their outbox, where it is then delivered by the ActivityPub server via a POST request to the inboxes listed in the activity's to, bto, cc and bcc fields. The receiving servers then account for the newly received activity and update the article by adding the like action to it. === Example data === An example actor object that represents a user account: An example activity that likes an article object: An example article object: == Project status == The SocialCG previously organized a yearly free conference called ActivityPub Conf about the future of ActivityPub. Triages are held regularly to review issues pertaining to the ActivityPub and ActivityStreams 2.0 specifications as part of the SocialCG. In 2023, Germany's Sovereign Tech Fund donated €152,000 to socialweb.coop with the goal of building a new suite for testing various ActivityPub implementations and their compliance with the specification. === Adoption === The initial wave of adoption for ActivityPub (circa 2016–2018) came from software that was already using OStatus as their federation protocol, such as Mastodon, GNU social and Pleroma. Following the acquisition of Twitter by Elon Musk in 2022, many groups of users that were critical of the acquisition migrated to Mastodon, bringing new attention to the ActivityPub protocol with it. Various major social media platforms and corporations have since pledged to implement ActivityPub support, including Tumblr, Flipboard and Meta Platforms' Threads. Threads introduced crossposting to ActivityPub in 2024 for users outside of the European Economic Area, however full 2-way compatibility remains incomplete as of 2025. == Criticism == === Accidental denial-of-service attacks === Poorly optimized ActivityPub implementations can cause unintentional distributed denial-of-service (DDOS) attacks on other websites and servers, due to the decentralized nature of the network. An example would be Mastodon's implementation of OpenGraph link previews, wherein every instance that receives a post that contains a link with OpenGraph metadata will download the associated data, such as a thumbnail, in a very short timeframe, which can slow down or crash servers as a result of the sudden burst of requests. === Account migration === ActivityPub has been criticized for not natively supporting moving accounts from one server to another, forcing implementations to build their own solutions. While there has been work on building a standardized system for migrating accounts using the Move activity via the Fediverse Enhancement Proposal organization, the current proposal only allows for basic follower migration, with all other data remaining linked to the original account. === Missing content and data === ActivityPub implementations have been criticized for missing replies and parts of reply threads from remote posts, and presenting outdated statistics (e.g. likes and reposts) about remote posts. However, this isn't a problem with the ActivityPub protocol itself, but with implementations not refreshing their content for updated data when needed. == Software using ActivityPub == === Future implementations === Flarum, an internet forum software Forgejo, a Git forge and development platform === Uncertain future implementations === GitLab, a Git forge and development platform which had previously had an open issue discussing the topic, but was later closed due to the development team moving focus to other areas. Tumblr, a microblogging platform. Despite previous statements from Automattic CEO Matt Mullenweg, ActivityPub integration has been delayed indefinitely. The integration would have been implemented with its WordPress migration, as the first-party plugin for interoperability would have been used for federation. Flickr, an image and video hosting site.

    Read more →
  • Color layout descriptor

    Color layout descriptor

    In digital image and video processing, a color layout descriptor (CLD) is designed to capture the spatial distribution of color in an image. The feature extraction process consists of two parts: grid based representative color selection and discrete cosine transform with quantization. Color is the most basic quality of the visual contents, therefore it is possible to use colors to describe and represent an image. The MPEG-7 standard has tested the most efficient procedure to describe the color and has selected those that have provided more satisfactory results. This standard proposes different methods to obtain these descriptors, and one tool defined to describe the color is the CLD, that permits describing the color relation between sequences or group of images. The CLD captures the spatial layout of the representative colors on a grid superimposed on a region or image. Representation is based on coefficients of the discrete cosine transform (DCT). This is a very compact descriptor being highly efficient in fast browsing and search applications. It can be applied to still images as well as to video segments. == Definition == The CLD is a very compact and resolution-invariant representation of color for high-speed image retrieval and it has been designed to efficiently represent the spatial distribution of colors. This feature can be used for a wide variety of similarity-based retrieval, content filtering and visualization. It is especially useful for spatial structure-based retrieval applications. This descriptor is obtained by applying the DCT transformation on a 2-D array of local representative colors in Y or Cb or Cr color space. The functionalities of the CLD are basically the matching: – Image-to-image matching – Video clip-to-video clip matching Remark that the CLD is one of the most precise and fast color descriptor. == Extraction == The extraction process of this color descriptor consists of four stages: Image partitioning Representative color selection DCT transformation Zigzag scanning The standard MPEG-7 recommends using the YCbCr color space for the CLD. === Image partitioning === In the image partitioning stage, the input picture (on RGB color space) is divided into 64 blocks to guarantee the invariance to resolution or scale. The inputs and outputs of this step are summarized in the following table: === Representative color selection === After the image partitioning stage, a single representative color is selected from each block. Any method to select the representative color can be applied, but the standard recommends the use of the average of the pixel colors in a block as the corresponding representative color, since it is simpler and the description accuracy is sufficient in general. The selection results in a tiny image icon of size 8x8. The next figure shows this process. Note that in the image of the figure, the resolution of the original image has been maintained only in order to facilitate its representation. The inputs and outputs of this stage are summarized in the next table: Once the tiny image icon is obtained, the color space conversion between RGB and YCbCr is applied. === DCT transformation === In the fourth stage, the luminance (Y) and the blue and red chrominance (Cb and Cr) are transformed by 8x8 DCT, so three sets of 64 DCT coefficients are obtained. To calculate the DCT in a 2D array, the formulas below are used. B p q = α p α q ∑ m = 0 M − 1 ∑ n = 0 N − 1 A m n cos ⁡ π ( 2 m + 1 ) p 2 M cos ⁡ π ( 2 n + 1 ) q 2 N , 0 ≤ p ≤ M − 1 , 0 ≤ q ≤ N − 1 {\displaystyle B_{pq}=\alpha _{p}\alpha _{q}\sum _{m=0}^{M-1}\sum _{n=0}^{N-1}A_{mn}\cos {\frac {\pi (2m+1)p}{2M}}\cos {\frac {\pi (2n+1)q}{2N}},\qquad 0\leq p\leq M-1,\;0\leq q\leq N-1} α p = { 1 M , p = 0 2 M , 1 ≤ p ≤ M − 1 α q = { 1 N , q = 0 2 N , 1 ≤ q ≤ N − 1 {\displaystyle \alpha _{p}={\begin{cases}{\frac {1}{\sqrt {M}}},&p=0\\{\sqrt {\frac {2}{M}}},&1\leq p\leq M-1\end{cases}}\qquad \alpha _{q}={\begin{cases}{\frac {1}{\sqrt {N}}},&q=0\\{\sqrt {\frac {2}{N}}},&1\leq q\leq N-1\end{cases}}} The inputs and outputs of this stage are summarized in the next table: === Zigzag scanning === A zigzag scanning is performed with these three sets of 64 DCT coefficients, following the schema presented in the figure. The purpose of the zigzag scan is to group the low frequency coefficients of the 8x8 matrix into a vector. The inputs and outputs of this stage are summarized in the next table: Finally, these three set of matrices correspond to the CLD of the input image. == Matching == The matching process helps to evaluate if two elements are equal comparing both elements and calculating the distance between them. In the case of color descriptors the matching process helps to evaluate if two images are similar. Its procedure is the following: – Given an image as an input, the application attempts to find an image with a similar descriptor in a data base of images. If we consider two CLDs: {DY, DCb, DCr} { DY‟, DCb‟, DCr‟ }, The distance between the two descriptors can be computed as: D = ∑ i w y i ( D Y i − D Y i ′ ) 2 + ∑ i w b i ( D C b i − D C b i ′ ) 2 + ∑ i w r i ( D C r i − D C r i ′ ) 2 {\displaystyle D={\sqrt {\sum _{i}w_{yi}(DY_{i}-DY_{i}')^{2}}}+{\sqrt {\sum _{i}w_{bi}(DCb_{i}-DCb_{i}')^{2}}}+{\sqrt {\sum _{i}w_{ri}(DCr_{i}-DCr_{i}')^{2}}}} The subscript i represents the zigzag-scanning order of the coefficients. Furthermore, notice that is possible to weight the coefficients (w) in order to adjust the performance of the matching process. These weights let us give to some components of the descriptor more importance than others. Observing the formula, it can be extracted that: – 2 images are the same if the distance is 0 – 2 images are similar if the distance is near to 0 Therefore, this matching process will let to identify images with similar color descriptors. Since the complexity of the similarity matching process shown above is low, high-speed image matching can be achieved.

    Read more →
  • Logogen model

    Logogen model

    The logogen model of 1969 is a model of speech recognition that uses units called "logogens" to explain how humans comprehend spoken or written words. Logogens are a vast number of specialized recognition units, each able to recognize one specific word. This model provides for the effects of context on word recognition. == Overview == The word logogen can be traced back to the Greek-language word logos, which means "word", and genus, which means "birth". British scientist John Morton's logogen model was designed to explain word recognition using a new type of unit known as a logogen. A critical element of this theory is the involvement of lexicons, or specialized aspects of memory that include semantic and phonemic information about each item that is contained in memory. A given lexicon consists of many smaller, abstract items known as logogens. Logogens contain a variety of properties about given word such as their appearance, sound, and meaning. Logogens do not store words within themselves, but rather they store information that is specifically necessary for retrieval of whatever word is being searched for. A given logogen will become activated by psychological stimuli or contextual information (words) that is consistent with the properties of that specific logogen and when the logogen's activation level rises to or above its threshold level, the pronunciation of the given word is sent to the output system. Certain stimuli can affect the activation levels of more than one word at a time, usually involving words that are similar to one another. When this occurs, whichever of the words' activation levels reaches the threshold level, it is that word that is then sent to the output system with the subject remaining unaware of any partially excited logogens. This assumption was made by Marslen-Wilson and Welch (1978), who added to the model some assumptions of their own in order to account for their experimental results. They also assumed that the analysis of phonetic input can only become available to other parts of the system by process of how the input affects the logogen system. Finally, Marslen-Wilson and Welch assume that the first syllable of a given word will increase the activation level of a given logogen more than those of the latter syllables, which supported the data found at the time. == Analysis == The logogen model can be used to help linguists explain particular occurrences in the human language. The most-helpful application of the model is to show how one accesses words and their meanings in the lexicon. The word-frequency effect is best explained by the logogen model in that words (or logogens) that have a higher frequency (or are more common) have a lower threshold. This means that they require less perceptual power in the brain to be recognized and decoded from the lexicon and are recognized faster than those words that are less common. Also, with high-frequency words, the recovery from lowering the item's threshold is less fulfilled compared to low-frequency words so less sensory information is needed for that particular item's recognition. There are ways to lower thresholds, such as repetition and semantic priming. Also, each time a word is encountered through these methods, the threshold for that word is temporarily lowered partially because of its recovering ability. This model also conveys that specific concrete words are recalled better because they use images and logogens, whereas abstract words are not as easily recalled well because they only use logogens, hence showing the difference in thresholds between these two types of words. At the time of its conception, Morton's logogen model was one of the most influential models in springing up other parallel word access models and served as the essential basis for these subsequent models. Morton's model also strongly influenced other contemporary theories on lexical access. However, despite the advantages that the logogen theory presents, it also displays some negative facets. First and foremost, the logogen model does not explain all occurrences in language, such as the introduction of new words or non-words into a person's lexicon. Also, because of the distinctive model application, it may vary in its effectiveness in different languages. == Criticisms == While this model does a reasonable job of understanding the underlying semantics of many aspects in psycholinguistics, there are some flaws that have been pointed out in the logogen model. It has been argued that the prior stimulus patterns that have been seen in the logogen theory are not centrally localized in the logogen itself but are actually distributed throughout the different pathways over which the stimulus is being processed. What this directs at is that the notion and proliferation of logogens was due to modality. In essence, the logogen is unnecessary in the idea of attaining the title of being a recognition unit because of the variety of pathways that it is open to, not just logogens. Another criticism has been that this model essentially ignores larger and more critical structures in language and phonetics such as the different syntactic rules or grammatical construction that innately exists in language. Since this model overtly limits itself to the scope of lexical access then this model is seen as biased and misunderstood. To many psychologists, the logogen model does not meet the functional or representational adequacy that a theory should include to sufficiently comprehend language. Also, another criticism is that the logogen theory was supposed to predict that stimulus degradation should affect priming and word frequency in humans. However, many psychologists have conducted studies and researched the model to show that only priming and not word frequency is interacted with stimulus degradation. Priming is supposed to deteriorate a stimulus because it postulates that the semantic characteristics of previously known words are fed back into the detector of a person which in turn raises the threshold of related items. In word frequency, stimulus degradation is supposed to occur because it postulates that familiar words have lower thresholds than their low-frequency counterparts. However, in studies, priming is the only structure that does show observable and notable stimulus decadence. Even though the logogen theory has many unfilled holes, Morton was a revolutionary of his field whose speculation and research has opened up a remarkable era of psycholinguistics. == Other models to consider == cohort model – This model was proposed by Marslen-Wilson and was designed specifically to account for auditory word recognition. It works by breaking the word down and states that when a word is heard all words that begin with the first sound of the target word are activated. This set of words is considered the cohort. Once the first cohort has been activated, the other information, or sounds in the word narrow down the choices. The person recognizes the word when you are left with a single choice; this is considered the "recognition point". checking model – This model was developed by Norris in 1986. In this particular model, he took the approach that any word that partially matches the input is analyzed and checked to see if it fits with the context of the situation. interactive-activation model – This model is considered a connectionist model. Proposed by McClelland and Rumelhart in the 1981 to 1982 period, it is based around nodes, which are visual features, and positions of letters within a given word. They also act as word detectors which have inhibitory and excitatory connections between them. This model starts with first letter and suggests that all the words with that first letter are activated at first and then going through the word one can determine what the word is they are looking at. The main principle is that mental phenomena can be described by interconnected networks of simple units. verification model – The model was developed by Curtis Becker in 1970. The main idea is that a small number of candidates that are activated in parallel are subject to a serial-verification process. This model starts the word-recognition process with a basic representation of the stimulus. Then, sensory trace, consisting of line features is used to activate word detectors. When an acceptable number of detectors are activated these are used to generate a search set. These items are drawn from the lexicon on the basis of similarity to the sensory trace, which help with the identity of the stimulus. Then, in a serial process the candidates are compared to the representation of the sensory-trace input. == Related concepts == word frequency – This is the belief that the speed and accuracy with which a word is recognized is related to how frequently the word occurs in our language. Each logogen has a threshold (for identification) and words with higher frequencies have lower thresholds. Words with higher freq

    Read more →
  • Oracle Cloud Platform

    Oracle Cloud Platform

    Oracle Cloud Platform refers to a Platform as a Service (PaaS) offerings by Oracle Corporation as part of Oracle Cloud Infrastructure. These offerings are used to build, deploy, integrate and extend applications in the cloud. The offerings support a variety of programming languages, databases, tools and frameworks including Oracle-specific, open source and third-party software and systems. == Deployment models == Oracle Cloud Platform offers public, private and hybrid cloud deployment models. == Architecture == Oracle Cloud Platform provides both Infrastructure as a Service (IaaS) and Platform as a Service (PaaS). The infrastructure is offered through a global network of Oracle managed data centers. Oracle deploys their cloud in Regions. Inside each Region are at least three fault-independent Availability Domains. Each of these Availability Domains contains an independent data center with power, thermal and network isolation. Oracle Cloud is generally available in North America, EMEA, APAC and Japan with announced South America and US Govt. regions coming soon.

    Read more →
  • Charge-coupled device

    Charge-coupled device

    A charge-coupled device (CCD) is an integrated circuit containing an array of linked, or coupled, capacitors. Under the control of an external circuit, each capacitor can transfer its electric charge to a neighboring capacitor. CCD sensors are a major technology used in digital imaging. In a CCD image sensor, pixels are represented by p-doped metal–oxide–semiconductor (MOS) capacitors. These MOS capacitors, the basic building blocks of a CCD, are biased above the threshold for inversion when image acquisition begins, allowing the conversion of incoming photons into electron charges at the semiconductor-oxide interface; the CCD is then used to read out these charges. Although CCDs are not the only technology to allow for light detection, CCD image sensors are widely used in professional, medical, and scientific applications where high-quality image data are required. In applications with less exacting quality demands, such as consumer and professional digital cameras, active pixel sensors, also known as CMOS sensors (complementary MOS sensors), are generally used. However, the large quality advantage CCDs enjoyed early on has narrowed over time and since the late 2010s CMOS sensors are the dominant technology, having largely if not completely replaced CCD image sensors. == History == The basis for the CCD is the metal–oxide–semiconductor (MOS) structure, with MOS capacitors being the basic building blocks of a CCD, and a depleted MOS structure used as the photodetector in early CCD devices. In the late 1960s, Willard Boyle and George E. Smith at Bell Labs were researching MOS technology while working on semiconductor bubble memory. They realized that an electric charge was the analog of the magnetic bubble and that it could be stored on a tiny MOS capacitor. As it was fairly straightforward to fabricate a series of MOS capacitors in a row, they connected a suitable voltage to them so that the charge could be stepped along from one to the next. This led to the invention of the charge-coupled device by Boyle and Smith in 1969. They conceived of the design of what they termed, in their notebook, "Charge 'Bubble' Devices". The initial paper describing the concept in April 1970 listed possible uses as memory, a delay line, and an imaging device. The device could also be used as a shift register. The essence of the design was the ability to transfer charge along the surface of a semiconductor from one storage capacitor to the next. The first experimental device demonstrating the principle was a row of closely spaced metal squares on an oxidized silicon surface electrically accessed by wire bonds. It was demonstrated by Gil Amelio, Michael Francis Tompsett and George Smith in April 1970. This was the first experimental application of the CCD in image sensor technology, and used a depleted MOS structure as the photodetector. The first patent (U.S. patent 4,085,456) on the application of CCDs to imaging was assigned to Tompsett, who filed the application in 1971. The first working CCD made with integrated circuit technology was a simple 8-bit shift register, reported by Tompsett, Amelio and Smith in August 1970. This device had input and output circuits and was used to demonstrate its use as a shift register and as a crude eight pixel linear imaging device. Development of the device progressed at a rapid rate. By 1971, Bell researchers led by Michael Tompsett were able to capture images with simple linear devices. Several companies, including Fairchild Semiconductor, RCA and Texas Instruments, picked up on the invention and began development programs. Fairchild's effort, led by ex-Bell researcher Gil Amelio, was the first with commercial devices, and by 1974 had a linear 500-element device and a 2D 100 × 100 pixel device. Peter L. P. Dillon, a scientist at Kodak Research Labs, invented the first color CCD image sensor by overlaying a color filter array on this Fairchild 100 x 100 pixel Interline CCD starting in 1974. Steven Sasson, an electrical engineer working for the Kodak Apparatus Division, invented a digital still camera using this same Fairchild 100 × 100 CCD in 1975. The interline transfer (ILT) CCD device was proposed by L. Walsh and R. Dyck at Fairchild in 1973 to reduce smear and eliminate a mechanical shutter. To further reduce smear from bright light sources, the frame-interline-transfer (FIT) CCD architecture was developed by K. Horii, T. Kuroda and T. Kunii at Matsushita (now Panasonic) in 1981. The first KH-11 KENNEN reconnaissance satellite equipped with charge-coupled device array (800 × 800 pixels) technology for imaging was launched in December 1976. Under the leadership of Kazuo Iwama, Sony started a large development effort on CCDs involving a significant investment. Eventually, Sony managed to mass-produce CCDs for their camcorders. Before this happened, Iwama died in August 1982. Subsequently, a CCD chip was placed on his tombstone to acknowledge his contribution. The first mass-produced consumer CCD video camera, the CCD-G5, was released by Sony in 1983, based on a prototype developed by Yoshiaki Hagiwara in 1981. Early CCD sensors suffered from shutter lag. This was largely resolved with the invention of the pinned photodiode (PPD). It was invented by Nobukazu Teranishi, Hiromitsu Shiraki and Yasuo Ishihara at NEC in 1980. They recognized that lag can be eliminated if the signal carriers could be transferred from the photodiode to the CCD. This led to their invention of the pinned photodiode, a photodetector structure with low lag, low noise, high quantum efficiency and low dark current. It was first publicly reported by Teranishi and Ishihara with A. Kohono, E. Oda and K. Arai in 1982, with the addition of an anti-blooming structure. The new photodetector structure invented at NEC was given the name "pinned photodiode" (PPD) by B.C. Burkey at Kodak in 1984. In 1987, the PPD began to be incorporated into most CCD devices, becoming a fixture in consumer electronic video cameras and then digital still cameras. Since then, the PPD has been used in nearly all CCD sensors and then CMOS sensors. In January 2006, Boyle and Smith were awarded the National Academy of Engineering Charles Stark Draper Prize, and in 2009 they were awarded the Nobel Prize for Physics for their invention of the CCD concept. Michael Tompsett was awarded the 2010 National Medal of Technology and Innovation, for pioneering work and electronic technologies including the design and development of the first CCD imagers. He was also awarded the 2012 IEEE Edison Medal for "pioneering contributions to imaging devices including CCD Imagers, cameras and thermal imagers". == Basics of operation == In a CCD for capturing images, there is a photoactive region (an epitaxial layer of silicon), and a transmission region made out of a shift register (the CCD, properly speaking). An image is projected through a lens onto the capacitor array (the photoactive region), causing each capacitor to accumulate an electric charge proportional to the light intensity at that location. A one-dimensional array, used in line-scan cameras, captures a single slice of the image, whereas a two-dimensional array, used in video and still cameras, captures a two-dimensional picture corresponding to the scene projected onto the focal plane of the sensor. Once the array has been exposed to the image, a control circuit causes each capacitor to transfer its contents to its neighbor (operating as a shift register). The last capacitor in the array dumps its charge into a charge amplifier, which converts the charge into a voltage. By repeating this process, the controlling circuit converts the entire contents of the array in the semiconductor to a sequence of voltages. In a digital device, these voltages are then sampled, digitized, and usually stored in memory; in an analog device (such as an analog video camera), they are processed into a continuous analog signal (e.g. by feeding the output of the charge amplifier into a low-pass filter), which is then processed and fed out to other circuits for transmission, recording, or other processing. == Detailed physics of operation == === Charge generation === Before the MOS capacitors are exposed to light, they are biased into the depletion region; in n-channel CCDs, the silicon under the bias gate is slightly p-doped or intrinsic. The gate is then biased at a positive potential, above the threshold for strong inversion, which will eventually result in the creation of an n channel below the gate as in a MOSFET. However, it takes time to reach this thermal equilibrium: up to hours in high-end scientific cameras cooled at low temperature. Initially after biasing, the holes are pushed far into the substrate, and no mobile electrons are at or near the surface; the CCD thus operates in a non-equilibrium state called deep depletion. Then, when electron–hole pairs are generated in the depletion region, they are separated by the electric field, the elec

    Read more →
  • Gcore

    Gcore

    Gcore is an edge AI, cloud, network, and security company headquartered in Luxembourg. Founded in 2014, the company provides low-latency services to industries including finance, healthcare, manufacturing, gaming, media and telecommunications internationally. As of March 2024, its global network includes over 180 Points of Presence (PoPs) across six continents. == History == Gcore was founded in 2014 in Luxembourg. The company built its own content delivery network, originally designed for the needs of the gaming industry. In 2016, Gcore's infrastructure expanded to multiple regions that were underserved by hyperscale cloud providers. In 2020, the company formed partnerships with Intel and Equinix. In 2022, Gcore launched the European AI Cloud, providing access to infrastructure for machine learning tasks. In March 2024, Gcore announced the acquisition of a web application and API protection (WAAP) solution from StackPath. In April 2024, Gcore received a commendation in the Industry Innovation category at the NVIDIA Partner Network Awards EMEA for developing the first speech-to-text technology for Luxembourgish, using the LuxemBERT AI model. In May 2024, Philipp Rösler, former vice-chancellor of Germany and federal minister of health joined the Gcore board. In July 2024, Gcore raised $60 million in a Series A funding round, marking the company's first external investment since its founding. In August 2024, Gcore was recognized as a Major Player in the IDC MarketScape report for European public cloud Infrastructure (IaaS) 2024 by IDC, the global market intelligence firm. In May 2025, Feiyu Xu became a member of the Gcore advisory board. == Network infrastructure == According to the company's website, Gcore has network locations in six continents: Europe, North America, Asia, South America, Africa, and Australia with over 14,000 peering partners and a network capacity exceeding 200 Tbps. According to a 2025 review by Geekflare, Gcore's CDN achieved an average global response time of around 30 milliseconds. Gcore offers AI cloud clusters, including a generative AI cluster with Nvidia GPUs in Luxembourg and additional sites in the Netherlands and Wales, as part of its European AI infrastructure. == Products and services == Gcore offers a range of services, including content delivery network (CDN), cloud computing,virtual machines, bare-metal servers, object storage AI infrastructure and inference, Kubernetes, video streaming, DDoS mitigation, web application and API protection (WAAP), Domain Name System (DNS). Gcore provides AI services and GPU cloud infrastructure to support model development, training, fine-tuning, and inference. In January 2025, the company introduced Everywhere Inference, a serverless inference solution that enables AI model deployment. == Controversies == Correctiv and Tageszeitung reported that Gcore supported the distribution of the TV network RT until April 2023, which has been under sanctions by the EU since March 2022. However, Gcore denies these allegations. == Collaborations == In 2024, Gcore and Qareeb Data Centres, a data center provider in the Middle East, launched a collaboration to integrate Gcore's AI, cloud and edge services across data centers in multiple Middle Eastern countries. In June 2025, Gcore joined the SmartSpires initiative, a €3.1 million smart city project co-funded by the Connecting Europe Facility. The three-year programme is coordinated by a public–private consortium including 5SKYE, the Luxembourg Institute of Science and Technology (LIST), Orange Luxembourg, and Gcore. The project aims to transform the Belval campus into a smart city by deploying 5G-enabled smart towers that integrate edge computing, artificial intelligence and IoT services. Within the consortium, Gcore acts as project coordinator and is responsible for the deployment of the edge infrastructure.

    Read more →
  • Connected-component labeling

    Connected-component labeling

    Connected-component labeling (CCL), connected-component analysis (CCA), blob extraction, region labeling, blob discovery, or region extraction is an algorithmic application of graph theory, where subsets of connected components are uniquely labeled based on a given heuristic. Connected-component labeling is not to be confused with segmentation. Connected-component labeling is used in computer vision to detect connected regions in binary digital images, although color images and data with higher dimensionality can also be processed. When integrated into an image recognition system or human-computer interaction interface, connected component labeling can operate on a variety of information. Blob extraction is generally performed on the resulting binary image from a thresholding step, but it can be applicable to gray-scale and color images as well. Blobs may be counted, filtered, and tracked. Blob extraction is related to but distinct from blob detection. == Overview == A graph, containing vertices and connecting edges, is constructed from relevant input data. The vertices contain information required by the comparison heuristic, while the edges indicate connected 'neighbors'. An algorithm traverses the graph, labeling the vertices based on the connectivity and relative values of their neighbors. Connectivity is determined by the medium; image graphs, for example, can be 4-connected neighborhood or 8-connected neighborhood. Following the labeling stage, the graph may be partitioned into subsets, after which the original information can be recovered and processed . == Definition == The usage of the term connected-component labeling (CCL) and its definition is quite consistent in the academic literature, whereas connected-component analysis (CCA) varies both in terminology and in its definition of the problem. Rosenfeld et al. define connected components labeling as the “[c]reation of a labeled image in which the positions associated with the same connected component of the binary input image have a unique label.” Shapiro et al. define CCL as an operator whose “input is a binary image and [...] output is a symbolic image in which the label assigned to each pixel is an integer uniquely identifying the connected component to which that pixel belongs.” There is no consensus on the definition of CCA in the academic literature. It is often used interchangeably with CCL. A more extensive definition is given by Shapiro et al.: “Connected component analysis consists of connected component labeling of the black pixels followed by property measurement of the component regions and decision making.” The definition for connected-component analysis presented here is more general, taking the thoughts expressed in into account. == Algorithms == The algorithms discussed can be generalised to arbitrary dimensions, albeit with increased time and space complexity. === One component at a time === This is a fast and very simple method to implement and understand. It is based on graph traversal methods in graph theory. In short, once the first pixel of a connected component is found, all the connected pixels of that connected component are labelled before going onto the next pixel in the image. This algorithm is part of Vincent and Soille's watershed segmentation algorithm, other implementations also exist. In order to do that a linked list is formed that will keep the indexes of the pixels that are connected to each other, steps (2) and (3) below. The method of defining the linked list specifies the use of a depth or a breadth first search. For this particular application, there is no difference which strategy to use. The simplest kind of a last in first out queue implemented as a singly linked list will result in a depth first search strategy. It is assumed that the input image is a binary image, with pixels being either background or foreground and that the connected components in the foreground pixels are desired. The algorithm steps can be written as: Start from the first pixel in the image. Set current label to 1. Go to (2). If this pixel is a foreground pixel and it is not already labelled, give it the current label and add it as the first element in a queue, then go to (3). If it is a background pixel or it was already labelled, then repeat (2) for the next pixel in the image. Pop out an element from the queue, and look at its neighbours (based on any type of connectivity). If a neighbour is a foreground pixel and is not already labelled, give it the current label and add it to the queue. Repeat (3) until there are no more elements in the queue. Go to (2) for the next pixel in the image and increment current label by 1. Note that the pixels are labelled before being put into the queue. The queue will only keep a pixel to check its neighbours and add them to the queue if necessary. This algorithm only needs to check the neighbours of each foreground pixel once and doesn't check the neighbours of background pixels. The pseudocode is: algorithm OneComponentAtATime(data) input : imageData[xDim][yDim] initialization : label = 0, labelArray[xDim][yDim] = 0, statusArray[xDim][yDim] = false, queue1, queue2; for i = 0 to xDim do for j = 0 to yDim do if imageData[i][j] has not been processed do if imageData[i][j] is a foreground pixel do check its four neighbors(north, south, east, west) : if neighbor is not processed do if neighbor is a foreground pixel do add it to queue1 else update its status to processed end if labelArray[i][j] = label (give label) statusArray[i][j] = true (update status) while queue1 is not empty do For each pixel in the queue do : check its four neighbors if neighbor is not processed do if neighbor is a foreground pixel do add it to queue2 else update its status to processed end if give it the current label update its status to processed remove the current element from queue1 copy queue2 into queue1 end While increase the label end if else update its status to processed end if end if end if end for end for === Two-pass === Relatively simple to implement and understand, the two-pass algorithm, (also known as the Hoshen–Kopelman algorithm) iterates through 2-dimensional binary data. The algorithm makes two passes over the image: the first pass to assign temporary labels and record equivalences, and the second pass to replace each temporary label by the smallest label of its equivalence class. The input data can be modified in situ (which carries the risk of data corruption), or labeling information can be maintained in an additional data structure. Connectivity checks are carried out by checking neighbor pixels' labels (neighbor elements whose labels are not assigned yet are ignored), or say, the north-east, the north, the north-west and the west of the current pixel (assuming 8-connectivity). 4-connectivity uses only north and west neighbors of the current pixel. The following conditions are checked to determine the value of the label to be assigned to the current pixel (4-connectivity is assumed) Conditions to check: Does the pixel to the left (west) have the same value as the current pixel? Yes – We are in the same region. Assign the same label to the current pixel No – Check next condition Do both pixels to the north and west of the current pixel have the same value as the current pixel but not the same label? Yes – We know that the north and west pixels belong to the same region and must be merged. Assign the current pixel the minimum of the north and west labels, and record their equivalence relationship No – Check next condition Does the pixel to the left (west) have a different value and the one to the north the same value as the current pixel? Yes – Assign the label of the north pixel to the current pixel No – Check next condition Do the pixel's north and west neighbors have different pixel values than current pixel? Yes – Create a new label id and assign it to the current pixel The algorithm continues this way, and creates new region labels whenever necessary. The key to a fast algorithm, however, is how this merging is done. This algorithm uses the union-find data structure which provides excellent performance for keeping track of equivalence relationships. Union-find essentially stores labels which correspond to the same blob in a disjoint-set data structure, making it easy to remember the equivalence of two labels by the use of an interface method E.g.: findSet(l). findSet(l) returns the minimum label value that is equivalent to the function argument 'l'. Once the initial labeling and equivalence recording is completed, the second pass merely replaces each pixel label with its equivalent disjoint-set representative element. A faster-scanning algorithm for connected-region extraction is presented below. On the first pass: Iterate through each element of the data by column, then by row (Raster Scanning) If the element is not the background Get the neighboring elements of the current element If there are no neighbors, uniquely

    Read more →
  • Software diversity

    Software diversity

    Software diversity is a research field about the comprehension and engineering of diversity in the context of software. == Areas == The different areas of software diversity are discussed in surveys on diversity for fault-tolerance or for security. The main areas are: design diversity, n-version programming, data diversity for fault tolerance randomization software variability == Techniques == === Code transformations === It is possible to amplify software diversity through automated transformation processes that create synthetic diversity. A "multicompiler" is compiler embedding a diversification engine. A multi-variant execution environment (MVEE) is responsible for selecting the variant to execute and compare the output. Fred Cohen was among the very early promoters of such an approach. He proposed a series of rewriting and code reordering transformations that aim at producing massive quantities of different versions of operating systems functions. These ideas have been developed over the years and have led to the construction of integrated obfuscation schemes to protect key functions in large software systems. Another approach to increase software diversity of protection consists in adding randomness in certain core processes, such as memory loading. Randomness implies that all versions of the same program run differently from each other, which in turn creates a diversity of program behaviors. This idea was initially proposed and experimented by Stephanie Forrest and her colleagues. Recent work on automatic software diversity explores different forms of program transformations that slightly vary the behavior of programs. The goal is to evolve one program into a population of diverse programs that all provide similar services to users, but with a different code. This diversity of code enhances the protection of users against one single attack that could crash all programs at the same time. Transformation operators include: code layout randomization: reorder functions in code globals layout randomization: reorder and pad globals stack variable randomization: reorder variables in each stack frame heap layout randomization === Natural software diversity === It is known that some functionalities are available in multiple interchangeable implementations. This natural diversity can be exploited, for example it has been shown valuable to increase security in cloud systems.

    Read more →
  • Transportation Economic Development Impact System

    Transportation Economic Development Impact System

    Transportation Economic Development Impact System (TREDIS) is an economic analysis system sold by consulting firm Economic Development Research Group that is used in planning major transportation investments in the US and Canada. The role of economic impact analysis and TREDIS in the transportation planning process is explained in guidebooks of the US Department of Transportation and the American Association of State Highway and Transportation Officials. TREDIS has been most commonly used for assessing the expected economic impacts of statewide highway programs, regional multi-modal plans and public transport investment. Its history and theoretical foundation are explained in peer reviewed journal articles. == How It Works == TREDIS has a series of modules that calculate different forms of impacts and benefits. One module is an accounting framework that calculates user benefits, including impacts on cargo transportation and commuting costs, based on transportation forecasting results. A second module calculates wider economic development benefits, including impacts on business productivity, economic development and multiplier effects from the input-output analysis. It applies an economic model to estimate impacts on jobs, income, gross regional product and business output, by sector of the economy. A third module applies cost-benefit analysis from alternative perspectives.

    Read more →