You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, libprojectM always renders to the current viewport at [0,0] with the set resolution. There is no way of performing up- or downscaling to a different canvas size. There are also no ways of applaying additional filters like blur, sharpen, hue shifts etc. without adding another (complex) rendering step in the embedding application.
Your Suggested Enhancement
Add a new repository which willl contain a separate library which can act as a middleware between libprojectM and the application. This library would provide a set of filters and effects to be applied to the projectM rendering output, returning a texture (or drawing onto a native surface, e.g. FBO 0) with the configured filters applied.
Having this as a separate library has many advantages over adding this functionality directly into libprojectM:
The library can be licensed under a more permissive license like MIT to allow static linking or fully embedding into closed-source applications.
The libprojectM API will stay as simple as possible.
The release cycle of this filtering library would be decoupled from libprojectM, making it easier to quickly add new features.
The middleware would be compatible with a range of libprojectM versions, e.g. any version from 4.2 onwards (as this version will introduce FBO rendering support). This would enable backwards compatibility as well, as long as libprojectM supports the required API calls.
Putting the code into a separate library will keep the projectM core codebase cleaner and thus reduces the potential for bugs. Application developers can then opt-in to use the additional dependency if needd.
The new library should provide a similar C API as libprojectM to make it useable in a wider range of programming languages. The implementation itself could be done in different languages like C, C++ or Rust. It should compile on the same platforms as libprojectM.
Some potential effects that could be implemented include:
Upscaling filter: render at a lower resolution, then scale the result to the output screen size. Useful for less powerful devices such as the Raspberry Pi.
Downscaling filter: render as a higher resolution, then scale down to the output size using bilinear or bicubic filtering. Adds anti-aliasing to the output, but will darken or black out some presets due to lines always being drawn at a 1px fixed width.
Blur: Parameterized gaussian/radial blur applied to the whole image.
Chromatic abberation: A lens distortion effect that separates certain colors close to the screen edges.
Hue shift/mapping: Either shift colors in hue or map the whole output to a specific color.
Color reduction: Reduce the number of color steps, creating a cartoonish or art-like appearance.
Bloom: Add a glow effect to bright colors.
There are many more possible filters that could be added. Configuring them could be done by building a filter chain, as filter order is important.
Is Your Enhancement Related to a Problem?
Currently, libprojectM always renders to the current viewport at [0,0] with the set resolution. There is no way of performing up- or downscaling to a different canvas size. There are also no ways of applaying additional filters like blur, sharpen, hue shifts etc. without adding another (complex) rendering step in the embedding application.
Your Suggested Enhancement
Add a new repository which willl contain a separate library which can act as a middleware between libprojectM and the application. This library would provide a set of filters and effects to be applied to the projectM rendering output, returning a texture (or drawing onto a native surface, e.g. FBO
0
) with the configured filters applied.Having this as a separate library has many advantages over adding this functionality directly into libprojectM:
The new library should provide a similar C API as libprojectM to make it useable in a wider range of programming languages. The implementation itself could be done in different languages like C, C++ or Rust. It should compile on the same platforms as libprojectM.
Some potential effects that could be implemented include:
There are many more possible filters that could be added. Configuring them could be done by building a filter chain, as filter order is important.
Alternative Solutions
No response
Additional Context
Originally suggested in PR #844
The text was updated successfully, but these errors were encountered: