future of hdr colorspaces

[Simon Legrand]

On Fri, Jun 1, 2012 at 7:44 AM, Boudewijn Rempt <boud at valdyas.org> wrote:

> On Friday 01 June 2012 Jun, Simon Legrand wrote:
>
> > Lol. Yes, we do have plenty or ram. However we're dealing with such high
> > resolution textures most of the time that even our massive amount of ram
> > needs to be saved and used wisely. (64Gb in my current
> > machine<
> http://h10010.www1.hp.com/wwpc/us/en/sm/WF06a/12454-12454-296719-307907-4270224-3718645.html?dnr=1
> >
> > )
>
> I'm jealous!
>

> > ILM and NVIDIA more or less pioneered 16bit half for memory reasons and
> > it's become standard for us in almost all case except extreme
> displacement
> > maps which sometimes require 32bit grayscale.
> >
>
> The good thing is that Marti has all but decided to support half in the
> next release of lcms2 after I and Kai-Uwe asked for it again. So that shows
> a good path forward :-)
>
>
> > That said. This discussion should be all about performance. I've no idea
> > what effect OpenColorIO would have on both the performance and initial
> > stability, and neither do I really know how much work it would involve to
> > implement.
> >
> > What Krita offers now is very promising so if you thin it is possible to
> > stick with what's currently available and refine it then I would
> prioritise
> > that.
>
> I really need to dig in, but Krita can actually support multiple color
> engines concurrently. Krita is also a bit weird compared to other
> application in that we offload almost all color manipulation, including
> things like levels filters to the color engine -- and those engines are
> plugins. We have/had a couple already:
>
> lcms1
> lcms2
> ctlcs
> and, sort of, the painterly colorspace engine
>
> I guess we could just add another one... But the ocio docs are really
> limited.
>
> >
> > I'm in the process of making templates of our most commonly used image
> > formats and bit depth, which I will send to Boudewijn tomorrow.
> >
> > But just to give a rough idea, we're almost never painting in 8bit and
> > under 4096x4096.
> >
> > Usually we're looking at images of 8192x8192 at 16bit.
>
> Float, right?
>

Yes, sorry.


>
> > Trying it at home with the latest and greatest everything (kubuntu 12.04
> > and krita 2.4 straight out of apt) the performance is actually very good.
> > Definitely usable without much trouble. I have tried all the filters
> brush
> > ect yet, but it seems great to me.
> >
> > The tarball I'm using at work is not cutting it as easily at those
> > resolution but that's simply because it's a 32bit build. Boudewijn said
> he
> > was working on a 64bit build for us so I'm impatiently waiting for it to
> > start benchmarking against the photoshop box that sits next to me. :)
>
> Good point... I'll also compile the 64 bits version with more
> optimizations and less debug. The 32 bit build was very experimental.
>

That would be brilliant!


>
>
> >
> > And I'm rambling again.
> >
> >
> > >
> > > --
> > > Cyrille Berger
> > > _______________________________________________
> > > kimageshop mailing list
> > > kimageshop at kde.org
> > > https://mail.kde.org/mailman/listinfo/kimageshop
> > >
> >
> >
> >
> >
>
>
> --
> Boudewijn Rempt
> http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl
> _______________________________________________
> kimageshop mailing list
> kimageshop at kde.org
> https://mail.kde.org/mailman/listinfo/kimageshop
>



-- 
Simon Legrand
http://slegrand.blogspot.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kimageshop/attachments/20120601/0a8332d8/attachment.html>