- Apr 13, 2023
-
-
Niklas Haas authored
So, this is a big mathdump with little in the way of history, but I arrived at these algorithms after extensive testing, feedback and research. The basic approach is to construct a 3DLUT in IPTQc4 space. Inside the 3DLUT, we use a simplified, peak-dependent power-law relationship between intensity and chromaticity in order to clip into the gamut hull, with a brute force (bisection method) search. Every attempt was made to provide approximately analogous equivalents to the old PL_GAMUT_* modes, though the nature of this new infrastructure means all results will be subtly different from before. In particular, most of the colorimetric clipping modes (except "desaturate") will prefer to slightly darken/brighten colors rather than desaturating them towards white. I could go on in more depth describing the new algorithms, but the code should hopefully somewhat speak for itself.
-
- Mar 13, 2023
-
-
Niklas Haas authored
And also add a variety of checks to ensure this is the case. This allows us to delete large, large swathes of shitty back-compat code for GLSL 110.
-
Niklas Haas authored
-
Niklas Haas authored
No reason to prefer this distro over others, they all have packages.
-
- Feb 19, 2023
-
-
quietvoid authored
-
- Dec 21, 2022
-
-
Niklas Haas authored
-
- Oct 14, 2022
-
-
Niklas Haas authored
Since jinja2 is a necessary dependency of glad2, which we depend on for OpenGL, it makes sense to re-use that to avoid pulling in *two* string templaters. Also, I think, vastly more likely to be pre-installed on the system in some fashion or another.
-
- Oct 10, 2022
-
-
Niklas Haas authored
libepoxy was removed from libplacebo with the switch to glad2.
-
- Sep 19, 2022
-
-
In preparation for adding more dither methods, including error diffusion dithering, I decided it's a good idea to split this off into its own header. It doesn't fit the "colorspace.h" namespace that well.
-
- Sep 08, 2022
-
-
Niklas Haas authored
Alongside the basic/trivial deinterlacing modes, this contains an implementation of the raw yadif deinterlacing kernel, based on vf_yadif_cuda.cu by @philipl. Currently only supports fragment shaders, with no compute shader speedup (although such a thing is conceptually possible, to share duplicate sampling work between adjacent pixels). Design the API in such a way that it permits field-merging (PAFF) should the need should arise in the future. Also adds a few related helpers. Closes: videolan/libplacebo#20
-
- Jul 23, 2022
-
-
Niklas Haas authored
Reference the existence of the 3rdparty submodules.
-
- Dec 29, 2021
-
-
Niklas Haas authored
I was very unsatisfied with the old tone-mapping approach for a number of reasons: 1. The requirement for all tone-mapping functions to be pure GLSL was very restrictive and made it so we had to start worrying about GPU performance. 2. For the more complicated functions, using a LUT is vastly better. Using a LUT also opens us up to using more complicated functions overall, like piecewise splines, including exact inverses of other tone mapping functions, or functions based on dynamic metadata. 3. Having this be an open-ended API in theory allows users to define custom tone mapping functions (e.g. perhaps one based on extra frame metadata). 4. Extensible enough to support e.g. inverse tone mapping as well. I will probably still include GLSL fast paths for tone-mapping functions that are faster to implement in pure GLSL, but for now I plan on switching entirely to a LUT-based approach. The major downside of this approach is that it doesn't afford us the ability to combine this style of tone-mapping with full peak detection, but I'm unsatisfied with the complexity of peak detection overall so I'm not sure this is a huge loss in practice. One way we can salvage the situation is by always using the detected peak merely to (linearly) adjust the output of the LUT, e.g. something like `sdr = lut(hdr) / lut(peak)`. Closes videolan/libplacebo#154
-
- Sep 07, 2021
-
-
Niklas Haas authored
This is not entirely spec-compliant with SMPTE RDD 5-2006. Notably, I swapped out their recommended PRNG in favor of a significantly better one that's also more friendly for GPU usage. In exchange for this, we don't currently perform any deblocking of vertical block edges. This is because proper deblocking would be prohibitively expensive in a single-pass environment due to the 8x8 averaging required to determine the correct intensity interval. It's possible that, in theory, we could get around this by just assuming that the intensity interval is the same for adjacent blocks. (In practice, this is basically true anyway). Or simply attenuating edge blocks. But visually, I simply don't think this is actually that necessary, at least for real-time playback. I'll probably re-evaluate this in the future. For the time being, this solves the problem well enough to my estimation. Closes videolan/libplacebo#148
-
Niklas Haas authored
Refactor the whole API to support other types of film grain through a common interface, to cut down on the amount of code duplication that would otherwise be required for new film grain synthesis shaders. Rather annoyingly, I can't really easily make this backwards compatible. Fortunately, this API has no external users that I could find in the wild - ever since dav1dplay switched to using the dav1d.h helpers.
-
- Sep 04, 2021
-
-
Niklas Haas authored
-
Niklas Haas authored
Forgot to add this.
-
- Jul 02, 2021
-
-
James Ross-Gowan authored
Add a pl_gpu implementation that uses Direct3D 11. This uses SPIRV-Cross to translate shaders from GLSL to HLSL. In its current state, plplay works and the test suite passes with feature level 10_0 and up. (9_x is unlikely to ever pass due to runtime-enforced shader complexity limits.) Missing features include emulated texture formats, cached_program, `pl_gpu_limits.thread_safe`, and HDR/high bit depth support in pl_swapchain, though these shouldn't be too hard to implement. This also updates the GLFW demos to be able to use Direct3D 11 through GLFW_NO_API. Closes #18
-
- Apr 21, 2021
-
-
Over the past few years, the use case of `pl_context` has increasingly shrinked, finally dwindling to "nothing other than logging" with the introduction of thread safety (and thus the loss of the "thread safety guard") As such, this being called `pl_context` is really unnecessarily confusing. It's just a glorified logging subsystem. Rename it, and make it optional in the process. Also introduce a typedef to make the new name shorter, as part of a new convention that I will be switching to moving forwards. This technically breaks the auto-cleanup behaviour of `pl_shader` and `pl_filter` but I really don't think those were all that useful or justified, and I don't think anybody relied on it.
-
- Mar 26, 2021
-
-
Niklas Haas authored
It would be cool if I could figure out more screenshots to add, maybe some sort of comparison between bilinear and jinc scaling or w/e.
-
Niklas Haas authored
The API for `pl_frame_mix` is currently a bit abstract and high-level. Most clients will probably not care to reimplement the massive amounts of logic that go into constructing a proper frame queue. Enter `pl_queue`, the solution for all your frame queuing needs! This will interface with the decoder via your choice of a push or pull API, and translate all decoded frames into an abstract internal timeline, `pl_frame_mix` slices of which can be probed for arbitrary timestamps. As an extra bonus, this also contains code for things like FPS estimation and VPS (vsyncs per second) estimation, somewhat mirroring the logic in e.g. mpv's interpolation/display-sync code. It's worth pointing out that this is a rather severe API break for `pl_frame_mix`, but I'm pretty sure this API has absolutely zero users, given the massive amount of effort required to use it before this commit. So I didn't bother with backwards compatibility, aside from an API bump as usualy.
-
- Feb 19, 2021
-
-
Niklas Haas authored
Renamed from 3DLUT to ICC across the board, and moved to its own conditionally installed header Also, merged with the internal lcms code, since it was a bit redundant now. Mostly to make room for more LUT formats I will be adding, and since colorspace.h was a bit cluttered.
-
- Jan 27, 2021
-
-
Niklas Haas authored
Almost identical to the libav helpers, with some code taken from the boilerplate I wrote for dav1dplay. Should be fairly comprehensive.
-
Niklas Haas authored
It's no longer true that libplacebo derives from mpv/mplayer.
-
- Dec 05, 2020
-
-
Niklas Haas authored
RIP
-
Niklas Haas authored
-
Niklas Haas authored
A lot of this was kinda dry and out-of-date. Modernize and expand by emphasizing the kinda cool things libplacebo can actually do.
-
- Jun 02, 2020
-
-
Niklas Haas authored
Make it point at the actual HTML coverage report.
-
- May 29, 2020
-
-
Niklas Haas authored
Hard-code some common alternative locations to the vulkan XML, and improve the error message otherwise. Fixes https://github.com/haasn/libplacebo/issues/75 Fixes videolan/libplacebo#95
-
- May 25, 2020
-
-
Niklas Haas authored
Now that `python3-mako` represents the first nontrivial dependency of a main feature (e.g. `vulkan`), document this list properly. Formatting could be bikeshed, but whatever. I just wanted to have a list out there.
-
- Apr 06, 2020
-
-
Niklas Haas authored
This is missing support for texel buffers (which are considered optional anyway by the API), and also for some swapchain-related features (which I'm not sure in what way we even want to represent in our code). This is mainly here so we can get support for OpenGL-related GPU backend features in the context of e.g. shader generation. We also update the GLFW demo program to support using OpenGL. This is all still very primitive and rather untested. Closes #17.
-
- Apr 02, 2020
-
-
Niklas Haas authored
No idea why this changed
-
- Jan 04, 2020
-
-
Niklas Haas authored
-
- Oct 19, 2019
-
-
Niklas Haas authored
-
- Feb 14, 2019
-
-
Niklas Haas authored
- change HTML syntax to markdown syntax - move the (now rather lengthy) authors section below the (more important) API overview section - merge (and reword) the contributors and authors sections, which were a bit redundant - also remove the (now redundant) support section
-
-
- Feb 06, 2019
-
-
Niklas Haas authored
-
- Dec 05, 2018
-
-
Niklas Haas authored
So the world can point and laugh at our awful test suite
-
- Dec 04, 2018
-
-
Niklas Haas authored
To point to our fancy new gitlab CI badge.
-
- Nov 07, 2018
-
-
Niklas Haas authored
The renderer no longer has any abort() code paths, and the API version indicator is now stable on git master. Hooray!
-
- Nov 06, 2018
-
-
Niklas Haas authored
Replaced by a better one upstream. Closes #48.
-