[Kde-graphics-devel] KImageF ?

Has anyone thought about a KDE class to handle data like the nvidia "half"
data type (16-bit per channel, floating point).

I'm thinking about how we can handle high definition images in a sensible way.
Ideally it would be accelerated on hardware that can support it, and would
still work OK for people with 8bit ARGB hardware.

Brad
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-graphics-devel/attachments/20051129/e282533a/attachment.pgp

On Tuesday 29 November 2005 10:45, Brad Hards wrote:
> Has anyone thought about a KDE class to handle data like the nvidia
> "half" data type (16-bit per channel, floating point).

Don't look at Cg, it's going away.

> I'm thinking about how we can handle high definition images in a
> sensible way. Ideally it would be accelerated on hardware that can
> support it, and would still work OK for people with 8bit ARGB
> hardware.

Ideally I'd like to have a 16bit channel support in Qt. The future of
KImageEffect looks as follows right now:
a) scrap it,
b) create OpenGL SL to C compiler and finish SL support in Mesa,
c) create image manipulation library where /all/ algorithms are
implemented with SL.
d) build a simple graph library on top of it. So you can mix and match
the algorithms from C as filters.

If the hardware supports fragment shaders, we're getting hardware
accelerated image manipulation library of the bat, if it doesn't we're
getting software fallbacks for free. It'd be one codebase that unifies
it all.

Zack

--
Winners compare their achievments to their goals,
losers compare theirs to that of others.

[Ignacio "Castaño"]

On Tuesday 29 November 2005 07:11 am, Zack Rusin wrote:
> On Tuesday 29 November 2005 10:45, Brad Hards wrote:
> > Has anyone thought about a KDE class to handle data like the nvidia
> > "half" data type (16-bit per channel, floating point).
>
> Don't look at Cg, it's going away.

What makes you think that way? We have no plans on stop supporting Cg, in
fact, Cg 1.5 is going to be our best release so far.

My only concern with Cg is the lack of a free implementation, but there's
nothing stopping developers writting their own implementation. We tried to
encourage that by releasing the compiler frontend and "Cg" is not protected
by any trademark so that people could write their own implementations and
still call them "Cg".

http://developer.nvidia.com/object/cg_compiler_code.html

> > I'm thinking about how we can handle high definition images in a
> > sensible way. Ideally it would be accelerated on hardware that can
> > support it, and would still work OK for people with 8bit ARGB
> > hardware.
>
> Ideally I'd like to have a 16bit channel support in Qt. The future of
> KImageEffect looks as follows right now:
> a) scrap it,
> b) create OpenGL SL to C compiler and finish SL support in Mesa,
> c) create image manipulation library where /all/ algorithms are
> implemented with SL.
> d) build a simple graph library on top of it. So you can mix and match
> the algorithms from C as filters.
>
> If the hardware supports fragment shaders, we're getting hardware
> accelerated image manipulation library of the bat, if it doesn't we're
> getting software fallbacks for free. It'd be one codebase that unifies
> it all.

You can currently use the arbfp target of the Cg compiler and use the Mesa
software implementation. Cg 1.4 also has a software backend, but it's very
slow and currently does not support texture sampling, so it's not very useful
for that purpouse.

--
Ignacio Casta?o
castanyo at yahoo.es

On Wednesday 30 November 2005 09:08, Ignacio Casta?o wrote:
> What makes you think that way? We have no plans on stop supporting
> Cg, in fact, Cg 1.5 is going to be our best release so far.
>
> My only concern with Cg is the lack of a free implementation, but
> there's nothing stopping developers writting their own
> implementation. We tried to encourage that by releasing the compiler
> frontend and "Cg" is not protected by any trademark so that people
> could write their own implementations and still call them "Cg".

Interesting. So you'll continue supporting 3 SL?
Unfortunately we have to support OpenGL SL anyway and it simply doesn't
look like we'll have enough resources to maintain more than one SL in
Mesa which is really the limiting factor here.

> You can currently use the arbfp target of the Cg compiler and use the
> Mesa software implementation. Cg 1.4 also has a software backend, but
> it's very slow and currently does not support texture sampling, so
> it's not very useful for that purpouse.

Yeah, in that sense that solution would be nice but I'm a little
hesitant when it comes to adding a hard requirement of some kind of
OpenGL implementation to KDE. I don't know, maybe it's not a problem
anymore but I'm sensing quite a few people would be very unhappy about
that.
I guess the bottom line is that unfortunately either I or someone else
would have to get very motivated to create an open implementation that
supports more than just i86 and x86-64 (for example currently I'm on a
powerbook, and as much as I'd love to get my hands on a i86 laptop,
especially with NVIDIA card, to try out Cg 1.5 it doesn't look like
it's going to happen (mainly because I don't want to be spending money
on a 17'' laptop and I'm not the biggest fan of 6200, which leaves
6400, 6600, 7300 and 7800 - from what i've seen, all but the first used
in 17'' laptops, well the third just impossible to get at all).


Zack

--
Maintenance-free: When it breaks, it can't be fixed...