[RFC] LUT-free `RGB`->`XYZ` conversion
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 35/100
- Issue type
- Refactor
- Clarity
- Needs clarification
- Activity status
- Active
- Tech stack
- julia
- Domain
- computer-graphics, performance
Research direction
Start by reading issues #351 and #587, then locate the current LUT-based RGB{N0f8}→XYZ{Float32} conversion entry point. Benchmark the existing CPU path and investigate a LUT-free alternative for GPU suitability; done means documenting the CPU slowdown and whether the trade-off is acceptable.
Written by the indexing model from the issue text.
Description
I was working on speeding up the RGB<->XYZ conversion 7 years ago. (cf. issue #351)
The problem is v^2.4 and v^(1/2.4) used in the so-called gamma curve of sRGB.
In the end, for the RGB{N0f8}→XYZ{Float32} conversion, I chose to use LUTs.
Using LUTs is probably the fastest approach for CPU computation.
For GPU computation as well, a Float32 × 256 LUT is small enough that I don't think it would become a bottleneck.
However, when using a LUT, some form of instruction is required to make it shareable on the GPU. (cf. issue #587)
Since this package deals with colors rather than images, AFAIK there is no way for the method or compiler to determine whether the data is in a GPU array or a CPU array.
(From a long-term perspective, we might end up implementing ColorsGPUCompilerExt etc., but it is too large a project for me to shoulder alone.)
If we were to stop using a LUT in order to improve GPU suitability, how much slowdown on the CPU would be acceptable?
Edit:
Further consideration is still needed before deciding whether to make the RGB{N0f8} implementation LUT-free or to provide something like @device_override for each GPU package.
On the other hand, the current implementation for RGB{Float32} is not particularly fast and is also somewhat inaccurate.
Therefore, I am considering updating it to a LUT-free algorithm that produces 0 ULP error for all 256 inputs that can be represented by N0f8, when used as RGB{Float32} inputs.
This would make it possible to support conversions on GPU by explicitly converting RGB{N0f8} to RGB{Float32}.
- Dominant language
- Julia
- Stars
- 226
- Forks
- 53
- Avg merge
- 3d 3h
- Merged PRs (30d)
- 5
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from JuliaGraphics/Colors.jl
-
bug
Difficulty 4/5 3-5 days Newbie friendliness 30/100
JuliaGraphics/Colors.jl#599 · 1 comment ·
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
JuliaGraphics/Colors.jl#590 · 2 comments ·
-
enhancement help wanted
Difficulty 4/5 3-5 days Newbie friendliness 48/100
JuliaGraphics/Colors.jl#587 · 5 comments ·
-
make `_distinguishable_colors` public ?Possibly taken @kimikage claimed this 12 days ago. Openenhancement
Difficulty 5/5 Over a week Newbie friendliness 30/100
JuliaGraphics/Colors.jl#573 · 1 comment ·
-
enhancement
Difficulty 4/5 3-5 days Newbie friendliness 35/100
JuliaGraphics/Colors.jl#535 · 2 comments ·
All issues in JuliaGraphics/Colors.jl
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
gridap/GridapPETSc.jl#129 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
io
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
osrep/Runes2P.jl#115 ·