Port Cube

Post by DG » Tue Oct 11, 2022 7:38 pm

Ha ha, Boris! Very timely.

Stunning visuals in that Rocket Man video, Balti. Great find.

This is how I'm feeling these days. Take my word, I'm a madman, don't you know?

Post by **Curly** » Tue Oct 11, 2022 7:47 pm

Post by **Sherman** » Tue Oct 11, 2022 7:54 pm

And now we return you to our regularly scheduled program.

hydra3333 · Post by **hydra3333** » Tue Oct 11, 2022 10:49 pm

Curly wrote: ↑
Tue Oct 11, 2022 7:47 pm

Not wishing to intrude and not understanding what's going on around me,
I have watched this a few dozen times over the last year or so and admired the song.

Post by **Rocky** » Wed Oct 12, 2022 11:31 am

Great one, hydra3333. Awesome tribute to Vincent, the tortured soul.

OK, so the z code returns values of Kr and Kb that I can inspect. Kg is 1 - (Kr + Kb). Then it all goes into AVX512 etc. And the stupid STL and object-oriented filter graph crapola makes it impenetrable. No comments in the code either. Not trying to ding z. I'm sure it's just great for genius-level humans, but I'm a primitive rodent and so use only procedural code without all the crapola. Look at thdmerge source to see the kind of code I like. However, there is a standard way to convert Kr/Kb/Kg to actual matrix equations. I'll do that and see what results viz-a-viz my equations.

@Guest 2

What is the claimed speedup for the 'fast' mode you described? I'm just not grokking how multithreading can make a significant difference. The bottleneck is simply the amount of data versus the available PCIe bandwidth. Kernel launch, etc., is insignificant compared to that. I keep saying this but nobody gives up the magic!

Guest 2 · Post by **Guest 2** » Wed Oct 12, 2022 3:28 pm

Rocky wrote: ↑
Wed Oct 12, 2022 11:31 am
What is the claimed speedup for the 'fast' mode you described?

Dunno! Anyway I am forwarding you all the possible solutions with an available source code.

Please, if you find it a lost of time, just tell me.

Post by **Rocky** » Thu Oct 13, 2022 5:50 am

Not a loss of time. Keep all ideas coming.

Guest 2 · Post by **Guest 2** » Wed Dec 07, 2022 11:44 am

Who should I ask to get this project to resume?

At least for Christmas

Guest 2 · Post by **Guest 2** » Sat Dec 10, 2022 4:10 am

Bullwinkle wrote: ↑
Fri Dec 09, 2022 9:12 am
we need a specification of the equations used for the YUV<-->RGB conversion. Perhaps the author could provide one of those.

Aren't those standard?

https://en.wikipedia.org/wiki/YUV#:~:te ... %20format.

Guest 2 · Post by **Guest 2** » Fri May 12, 2023 12:14 pm

Dear ones,

is there any chance that we can see some progression in DGCube development?

It stopped while thinking about some more color space and conversions.

Levi · Post by **Levi** » Sun May 14, 2023 3:43 pm

Guest 2 · Post by **Guest 2** » Wed May 17, 2023 11:16 am

Nice song.

Anyway proper colorspace path to have direct PQ to HLG would be really useful.

Post by **Curly** » Wed May 17, 2023 8:47 pm

Not allowed to say duh.

Britney · Post by **Britney** » Wed May 17, 2023 9:03 pm

Post by **Rocky** » Fri May 19, 2023 5:10 pm

Just not interesting. Pecuniary compensation could change that.

Guest 2 · Post by **Guest 2** » Thu May 25, 2023 4:39 pm

Rocky wrote: ↑
Fri May 19, 2023 5:10 pm
Just not interesting. Pecuniary compensation could change that.

Share the source on Github so that someone could help.

Post by **Rocky** » Thu May 25, 2023 7:15 pm

Don't need help. DGCube is closed source.

Guest 2 · Post by **Guest 2** » Thu Jun 15, 2023 5:16 am

Rocky wrote: ↑
Thu May 25, 2023 7:15 pm
Don't need help. DGCube is closed source.

Can I ask you, at least, HLG support? PQ is evil.
:bow:

Post by **Rocky** » Thu Jun 15, 2023 7:41 am

I don't understand your question. DGCube is agnostic to PQ/HLG. And we have our PQ to HLG filter. Please clarify.

Guest 2 · Post by **Guest 2** » Thu Jun 15, 2023 9:38 am

Rocky wrote: ↑
Thu Jun 15, 2023 7:41 am
I don't understand your question. DGCube is agnostic to PQ/HLG. And we have our PG to HLG filter. Please clarify.

My answer was indeed a bit fuzzy.

If I recall well, the conversion from PQ to SDR is a single DGCube line.

When we need to convert from PQ to HLG, the real bottleneck is that we have to use two conversions, before and after DGCube. AFAIK the reason is that DGCube can convert 4:2:0 only and you can't specify the resizing kernel or dithering.

propclearall()

z_ConvertFormat(pixel_type="RGBP16", colorspace_op="2020:st2084:2020:limited=>rgb:st2084:2020:full", resample_filter_uv="Spline64", dither_type="error_diffusion", use_props=0)

DGCube("1a_PQ1000_HLG_mode-nar_in-nar_out-nar_nocomp.cube", in="full", lut="full", out="full")

z_ConvertFormat(pixel_type="YUV420P16", colorspace_op="rgb:std-b67:2020:full=>2020:std-b67:2020:limited", resample_filter_uv="Spline64", dither_type="error_diffusion", use_props=0)

That annihilates the huge gpu speed gain. You were thinking about rewrite a zimg CUDA porting but I can understand is a real PITA. At least we need those two conversions in CUDA.

Post by **Rocky** » Fri Jun 16, 2023 9:23 am

Again, I am just not interested in porting any zimg functionality to CUDA.

Guest 2 · Post by **Guest 2** » Fri Jun 16, 2023 4:42 pm

Rocky wrote: ↑
Fri Jun 16, 2023 9:23 am
Again, I am just not interested in porting any zimg functionality to CUDA.

That is not what I am asking for. As I told. porting zimg is a PITA. More than enough to be able to convert PQ to HLG via GPU/CUDA only.

Post by **Rocky** » Fri Jun 16, 2023 5:24 pm

Have you tried DGPQtoHLG? I'm willing to address any issues you have with it.

Guest 2 · Post by **Guest 2** » Fri Jun 16, 2023 6:24 pm

Rocky wrote: ↑
Fri Jun 16, 2023 5:24 pm
Have you tried DGPQtoHLG? I'm willing to address any issues you have with it.

Yes and the quality you can achieve with a LUT is another world. Plus you can customize the LUT according to your preferences or the effect you want to achieve.

Post by **Rocky** » Fri Jun 16, 2023 8:13 pm

PQ to HLG is a well-defined specification that we follow. All this "another world" stuff is nonsense.