mirror of
https://github.com/GraphiteEditor/Graphite.git
synced 2026-10-04 05:58:12 +08:00
Update the website roadmap and other details
This commit is contained in:
Keavon Chambers
@@ -33,36 +33,6 @@ When it comes to writing the proposal, which you will submit to the GSoC applica
|
||||
|
||||
## Project idea list
|
||||
|
||||
In addition to the detailed projects below, here are some loose ideas that may be developed into full project options before the next GSoC application period:
|
||||
- Color management for HDR/WCG
|
||||
- Sophisticated text layout and advanced typography features
|
||||
- Traditional brush engine
|
||||
- [Procedural brush engine](https://github.com/Keavon/Brush-Nodes)
|
||||
- Image processing algorithms for photography
|
||||
- Snapping system overhaul
|
||||
- [Node equivalence rewriting](https://github.com/GraphiteEditor/Graphite/issues/2021)
|
||||
<!-- PDF import/export -->
|
||||
<!-- ONNX model embedding to run in WebGPU and native (Tauri) and server -->
|
||||
|
||||
<!--
|
||||
TODO: Add to the completed projects list after successful completion.
|
||||
|
||||
### Port LibRaw to Rust
|
||||
|
||||
*For Graphite to support editing photos from professional digital cameras, it needs a raw decoding/processing library.*
|
||||
|
||||
- **Needed Skills:** Rust, C++, binary format parsing
|
||||
- **Project Size:** Large *(GSoC: 350 hours)*
|
||||
- **Difficulty:** Hard
|
||||
- **Expected Outcomes:** Develop a Rust library that ports LibRaw functionality to native Rust. A clean, well-structured code base and API. At a minimum, demonstrate the successful end-to-end decoding, debayering, and color space handling of Sony ARW format photos in Graphite. Publish the library to crates.io.
|
||||
|
||||
For Graphite to work as a photo editing app, it needs to import raw photos. These contain compressed sensor imagery and metadata in a variety of formats. Sony ARW is the first target, and additional camera brands are stretch goals, while porting all useful functionality would be the best outcome.
|
||||
|
||||
Graphite needs a library written in pure Rust with a suitable (non-GPL) license, which does not currently exist in the ecosystem, so we need to create one ourselves. LibRaw is a common C++ library that supports most camera brands and formats and has a compatible license. Since raw formats are rarely documented by camera manufacturers, porting LibRaw to Rust is the most practical approach.
|
||||
|
||||
This project involves diving into the LibRaw source code (~44,000 lines), understanding its architecture, and translating its pieces to idiomatic Rust. Because of Rust's differences from C++, this is not likely to be as simple as a 1:1 source code translation. The student should have strong familiarity with the two languages, experience exploring moderately large code bases, working with binary format parsing, and ideally some knowledge of color science.
|
||||
-->
|
||||
|
||||
### Marquee selection masking
|
||||
|
||||
*Graphite's raster editing features requires the implementation of Select mode, where users can draw a mask which becomes a marquee (marching ants) selection.*
|
||||
@@ -191,46 +161,101 @@ If none of the projects above suit your interests or experience, we are very ope
|
||||
|
||||
As is the case with all projects, please discuss this with us on Discord to flesh out your idea. Unsolicited proposals that have not been discussed with us will almost certainly be rejected.
|
||||
|
||||
### More ideas for 2025
|
||||
|
||||
In addition to the detailed projects above, here are some loose ideas that may be expanded into full project descriptions before the 2025 GSoC application period opens:
|
||||
|
||||
- Sophisticated text layout and advanced typography features
|
||||
- PDF import/export? (Scope and viability depend on the state of available libraries)
|
||||
- Traditional brush engine
|
||||
- [Procedural brush engine](https://github.com/Keavon/Brush-Nodes)
|
||||
- Color management for HDR/WCG (requires good understanding of color science)
|
||||
- Image processing algorithms for photography
|
||||
- Snapping system overhaul
|
||||
- Photo processing graphics algorithms
|
||||
- [Node equivalence rewriting](https://github.com/GraphiteEditor/Graphite/issues/2021)
|
||||
|
||||
## Successful past projects
|
||||
|
||||
### 2024: Node graph auto layout
|
||||
### 2024: Interactive node graph auto-layout
|
||||
|
||||
*Graphite's graph UI needs a system to automatically arrange layers and nodes given incremental changes to the graph contents.*
|
||||
|
||||
Affiliation: GSoC 2024
|
||||
Duration: 3 months
|
||||
Student: Adam Gerhant
|
||||
|
||||
<https://summerofcode.withgoogle.com/programs/2024/projects/gvbBoCpT>
|
||||
|
||||
*Graphite's graph UI needs a system to automatically arrange layers and nodes given incremental changes to the graph contents.*
|
||||
- [Program project listing](https://summerofcode.withgoogle.com/programs/2024/projects/gvbBoCpT)
|
||||
- [Report and weekly updates](https://github.com/GraphiteEditor/Graphite/discussions/1769)
|
||||
|
||||
**Outcomes:** A system that manages the placement of nodes based on a set of layout constraint rules and incremental updates to the graph topology. It should run efficiently, even with large graphs. It should be robust enough to handle a variety of graph topologies and user interactions, producing organized, useful, and stable layouts.
|
||||
|
||||
The Graphite concept is built around a node graph representation of layer stacks, while tools automatically generate and manipulate nodes. When a layer or node is inserted, deleted, moved, or referenced, the graph needs to be reorganized to maintain a clear and useful layout. Users can also interactively expand and collapse groups of nodes which occupies or frees up graph real estate.
|
||||
**Background:** The Graphite concept is built around a node graph representation of layer stacks, while tools automatically generate and manipulate nodes. When a layer or node is inserted, deleted, moved, or referenced, the graph needs to be reorganized to maintain a clear and useful layout. Users can also interactively expand and collapse groups of nodes which occupies or frees up graph real estate.
|
||||
|
||||
Unlike other node editors that are centered around manual graph editing, where users are fully in charge of node placements within one large node network, Graphite's node UI is more oriented towards automatic layout management and viewing just parts of the graph at one time. This means the shown graph topology is constantly changing and the layout system needs to cooperatively organize the graph in concert with user actions.
|
||||
|
||||
While general graph layout algorithms are complex and struggle to produce good results in other node editors, Graphite's graph topology is more constrained and predictable, which makes it possible to design a layout system that can produce good results. Nodes tend to be organized into rows, and layers into columns. This turns the problem into more of a constraint-based, axis-aligned packing problem.
|
||||
|
||||
### 2024: Rendering Performance infrastructure improvements
|
||||
|
||||
*Graphite performance is bottlenecked by limitations in the new node graph rendering architecture that needs improvements.*
|
||||
|
||||
Affiliation: GSoC 2024
|
||||
Duration: 4 months
|
||||
Student: Dennis Kobert
|
||||
|
||||
- [Program project listing](https://summerofcode.withgoogle.com/programs/2024/projects/v5z2Psnc)
|
||||
- [Report and weekly updates](https://github.com/GraphiteEditor/Graphite/discussions/1773)
|
||||
|
||||
**Outcomes:** A holistic, metrics-driven focus on fixing the many unoptimized areas of Graphite's node graph compilation, execution, and rendering systems. Integration of Vello as an integrated rendering backend. A significant improvement in the performance of the editor, especially in the node graph, and a more stable and predictable performance profile. Benchmarking and profiling tools to measure and visualize performance improvements and regressions.
|
||||
|
||||
**Background:** Graphite's node graph system is the backbone of the editor, but it has many performance problems that need to be addressed because the system is relatively immature and performance-impacting shortcuts were taken during its initial development. This project is all about making the node graph system more robust and optimized, which will have a direct impact on the user experience and the editor's overall performance. By the end of the project, the editor should finally feel usable in the majority of user workflows. Vello should be enabled as an alternate render engine that will fully replace the existing SVG-based one in the future, once browser support arrives across major platforms.
|
||||
|
||||
### 2024: Raw photograph decoding in Rust
|
||||
|
||||
*For Graphite to support editing photos from professional digital cameras, it needs a raw decoding/processing library.*
|
||||
|
||||
Affiliation: GSoC 2024
|
||||
Duration: 5 months
|
||||
Student: Elbert Ronnie
|
||||
|
||||
- [Program project listing](https://summerofcode.withgoogle.com/programs/2024/projects/2uiwOfz8)
|
||||
- [Report and weekly updates](https://github.com/GraphiteEditor/Graphite/discussions/1771)
|
||||
- [Rawkit library](https://crates.io/crates/rawkit)
|
||||
|
||||
**Outcomes:** A Rust library that implements raw photo decoding functionality to native Rust. A clean, well-structured code base and API. At a minimum, demonstrate the successful end-to-end decoding, debayering, and color space handling of Sony ARW format photos in Graphite. Publish the library to crates.io.
|
||||
|
||||
**Background:** For Graphite to work as a photo editing app, it needs to import raw photos. These contain compressed sensor imagery and metadata in a variety of formats. Sony ARW is the first target and additional camera brands are stretch goals. Graphite needs a library written in pure Rust with a suitable (non-GPL) license, which does not currently exist in the ecosystem, so we need to create one ourselves.
|
||||
|
||||
### 2023: Bezier-rs library
|
||||
|
||||
*Graphite's vector editing features require the implementation of Bezier curve and path manipulation computational geometry algorithms.*
|
||||
|
||||
Affiliation: University of Waterloo, Ontario, Canada
|
||||
Duration: 9 months
|
||||
Students: Hannah Li, Rob Nadal, Thomas Cheng, Linda Zheng, Jackie Chen
|
||||
|
||||
The student group designed an API for representing and manipulating Bezier curves and paths as a standalone Rust library which was [published to crates.io](https://crates.io/crates/bezier-rs). It now serves as the underlying vector data format used in Graphite, and acts as a testbed for new computational geometry algorithms. The team also built an [interactive web demo catalog](/libraries/bezier-rs/) to showcase many of the algorithms, which are also handily embedded in the library's [documentation](https://docs.rs/bezier-rs/latest/bezier_rs/).
|
||||
- [Bezier-rs library](https://crates.io/crates/bezier-rs)
|
||||
- [Interactive web demo](/libraries/bezier-rs/)
|
||||
|
||||
**Outcomes:** The student group designed an API for representing and manipulating Bezier curves and paths as a standalone Rust library which was published to crates.io. It now serves as the underlying vector data format used in Graphite, and acts as a testbed for new computational geometry algorithms. The team also built an interactive web demo catalog to showcase many of the algorithms, which are also handily embedded in the library's [documentation](https://docs.rs/bezier-rs/latest/bezier_rs/).
|
||||
|
||||
### 2022: Backend layout system
|
||||
|
||||
*Graphite's UI needs a system to define and manage layouts for widgets from the backend.*
|
||||
|
||||
Affiliation: California Polytechnic State University, San Luis Obispo, USA
|
||||
Duration: 3 months
|
||||
Student: Max Fisher
|
||||
|
||||
The student designed and implemented a new system across the editor's frontend and backend which made it possible to define and manage layouts for widgets from the backend and receive input data from those widgets. Previously, all layouts were statically defined in the frontend and extensive plumbing was required to pass data back and forth.
|
||||
**Outcomes:** The student designed and implemented a new system across the editor's frontend and backend which made it possible to define and manage layouts for widgets from the backend and receive input data from those widgets. Previously, all layouts were statically defined in the frontend and extensive plumbing was required to pass data back and forth.
|
||||
|
||||
### 2022: Path boolean operations
|
||||
|
||||
*Graphite's vector editing features require the implementation of boolean operations on paths, such as union, intersection, and difference.*
|
||||
|
||||
Affiliation: California Polytechnic State University, San Luis Obispo, USA
|
||||
Duration: 3 months
|
||||
Student: Caleb Dennis
|
||||
|
||||
The student devised and prototyped algorithms for performing boolean operations on paths, such as union, intersection, and difference. These were used as a stopgap during 2022 and 2023 to provide users with a rudimentary boolean operation feature set.
|
||||
**Outcomes:** The student devised and prototyped algorithms for performing boolean operations on paths, such as union, intersection, and difference. These were used as a stopgap during 2022 and 2023 to provide users with a rudimentary boolean operation feature set.
|
||||
|
||||
Reference in New Issue
Block a user