Am 18.01.2013 23:44, schrieb Moritz Moeller: > On 19/1/13 4:39 AM, Ulrich Pegelow wrote: >> The first issue (off pixels) is obviously a bug. As you already wrote we >> are converting values from RGB to HSL and back. If the input is out of >> range, this leads to problems. In current git master I fixed the issue >> by clamping the input values accordingly (which btw was already done in >> our OpenCL path). I might need to inspect further to find out where the >> out-of-range pixels are generated. It's quite clear we *need* to clamp >> all input pixels in blending if we want to transfer to some other color >> space. > > But that means we loose all headroom when certain blending operations > are used? Are you saying L in HSL not be >1? >
Right. All blending operations do clamping. There is the one noteworthy exception, blend mode "unbounded". The reason is that the vast majority of blend calculations inherently need input values to be in a defined range, else they will lead to strong artifacts. Look for example at blend modes overlay, softlight, hardlight and all the modes that need RGB<->HSL or Lab<->LCh. Ulrich ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122912 _______________________________________________ darktable-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/darktable-devel
