Fix a minor error in one of the color temperature constants.
Wikipedia cites http://icpr.snu.ac.kr/resource/wop.pdf/J01/2002/041/R06/J012002041R060865.pdf,
but seems to differ in in the last decimal of one of the coefficients.
The error is, of course, inconsequential, but it's good to be correct
in any case, and I trust the paper more.
This fixes an issue where reusing the same EffectChain from two different GL
contexts would cause errors even if they are shared, because FBOs cannot be
shared between contexts (in the ARB extension, anyway).
There might be some negative performance implications to this, but I was unable
to measure any on Intel/Mesa. If this should prove to be a problem in the future,
we could maybe keep one around per context, or have the caller invalidate the
FBO for us.
Fix a bug where DeconvolutionSharpenEffect would forget one line of the kernel.
This manifested itself in that non-identity filters would start changing alpha
of solid images (since the kernel didn't sum up to one), which obviously isn't
good. Added a unit test to make sure it doesn't happen again.
The intended use is for overlays, where you'd want to do e.g.
0.2*x atop y instead of just x atop y, fading the overlay in or out.
Also, give it full RGBA inputs, as that might potentially be useful
for someone. It certainly was useful for adapting it to continue to
be used in the EffectChain unit test, at least. (It doesn't have
its own unit test, since it's so trivial.)
Fix a bug where PaddingEffect could create assertion errors.
The ratinale is explained in the comment, but in short, PaddingEffect
could convert blank to premultiplied alpha without realizing that
it then needed linear light (since premultiplied alpha in our case
is defined as being in linear light). Also added a unit test.
Clip below-zero (out-of-gamut) colors in LiftGammaGainEffect.
pow(x, y) for x < 0 is undefined, and behaves differently on nVidia
and Intel. This can reasonably happen when having inputs from a different
gamut, or just a complex chain before the LGG effect; there's nothing
in Movit that prohibits out-of-sRGB-gamut colors. Thus, we need to detect
such inputs and clamp them.
We could in theory check for the special case of y=1 (no gamma change)
and allow negative values through then, but this wouldn't seem like a good
solution, especially if animating gamma.
We don't use anything fancy from autoconf yet (in particular,
no config.h file), and we don't use automake or libtool.
Most likely, this will happen later.
Add a new alpha handling method, INPUT_PREMULTIPLIED_ALPHA_KEEP_BLANK.
This should fix most of the problems where you only process inputs
without alpha, but the framework still inserts an AlphaDivisionEffect
at the end because it loses track of the blank alpha state throughout
the pipeline and the output expects postmultiplied alpha.
There's one important case left, though: MixEffect will always reset
tha alpha state to premultiplied. We should probably fix that too
at some later stage.
In resizing effects, add the notion of a “virtual output size”.
This is the size that the effect wants to be perceived as for the next
effect in the chain, which is useful if you e.g. have a blur and then
padding. Even though the blur might rescale the image down from e.g.
512x512 to 128x128 before blurring (in case of a large blur), and this
size is what actually comes out in the texture at the other end,
it still wants to be treated as a 512x512 image when adding padding.
Fix a bug where intermediate phase outputs could get too low height.
Basically our aspect ratio adjustment and lack of proper roundoff
could conspire to let e.g. mix(1280x720, 939x939) = 1669x938,
which is obviously wrong. I could probably have fixed it with
an extra lrintf(), but it seems more robust to simply avoid the
extra conversion (ie., never convert height -> width -> height).
ColorspaceConversionEffect, DitherEffect, GammaExpansionEffect and GammaCompressionEffect
are all supposed to be used by EffectChain only, so make them private; I've had
reports of users trying to use these directly, leaving the framework in a confused state.
Sometimes an effect can be used by two other effects that both demand
the same conversion. If so, we should simply insert a conversion after
that effect and connect _all_ outputs to that conversion, since
conversions to linear/sRGB/premultiplied never hurt for us.
Add unit tests for the gamma and colorspace cases. I could have added
for the alpha case, too, but it got very tedious. :-)
This struck me suddenly one evening as a fix for the issues with alpha in glow,
and seems to work incredibly well for unsharp mask, too. The rationale is
outlined in the comment in the frag.
I'll probably be adding some tests for GlowEffect to make sure that it keeps
working fine, but visual tests so far look very good. The only issue is that
with destination alpha always being in linear light (as it should be),
programs that don't blend in linear light, like GIMP and ImageMagick,
get somewhat dull-looking results with e.g. glow.
Add an assert saying that if an input has premultiplied alpha, it must also have linear gamma.
This holds true for nodes in general, but I'm not sure enough about all sorts of intermediate
states that could cause this to be temporarily untrue for other nodes.
Fix two issues related to non-treelike (diamond) effect graphs.
First of all, we could have an assert failure when an input was used twice.
Work around it by simply ignoring the input the second time.
This, however, would expose an issue where effects could be emitted in the
.glsl file out-of-order. Refactor the topological sort code so that it can
be reused for arbitrary subgraphs, and then use it to topologically sort
the list of effects in each pass.
This is a pretty big change, even though the most visible change right now
is that OverlayEffect looks better in the edges of upscaled material
(which you won't really notice too much, given that our handling of
different resolutions already sucks). Since most material is going to
assume postmultiplied alpha, we need to track the status around the graph
pretty much as we already do with gamma and colorspaces, so it's quite
a lot of new code (and associated test complexity). It really does look
better, though.
Negative sides: MixEffect has gotten less flexible since it now also
handles the alpha; for instance, you can't really use it to subtract
things the same way anymore. Also, I think the glow effect has been broken by
the changes to MixEffect, so I'll need to fix it and then add a test so it
doesn't break again.
OverlayEffect needs working alpha, so this cropped up. We don't
really have full alpha handling everywhere, but this is a good
start; I added some tests here and there to tighten it up a bit.