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.
We could have done this on Windows only, but it's just as simple to
keep the dependency list equal on all platforms. This subsumes our
own extension-checking logic, too.
Allow the EffectChainTester framebuffer to be in something else than float. This is useful since Mesa's glReadPixels() does not round, but the Intel hardware does.