Does this image-processing library break the Single Responsibility Principle?
Private Fields

I prefer to prefix my private fields with an underscore, and as readonly as possible. If you don't like the underscore, fine - but then be consistent with this, and don't use it only in your constructor - use this whenever you're referring to a private field. It greatly helps telling private fields from parameters.

Personally I don't like sprinkling this everywhere in my code, so I prefer the underscore; I also like my access modifiers explicit:

public class FilteredImageProvider : IDisposable
{
    private readonly SharpDXRenderer _renderer;
    private readonly FilterContainer _filterContainer;
    private readonly ImageGPULoaderFactory _loaderFactory;

    private GPUImage _currentImage;

    //...


Constructor

The readonly fields are still assigned in the constructor:


public FilteredImageProvider()
{
    _renderer = new SharpDXRenderer();
    _filterContainer = new FilterContainer();
    _loaderFactory = new ImageGPULoaderFactory();
}



These three should be injected as constructor arguments - creating these instances within the constructor breaks SRP, at least if you're applying DI principles. SRP is only the S of SOLID. By taking these instances in as constructor arguments, you greatly facilitate the rest of SOLID.



You're mostly exposing cherry-picked encapsulated methods, that works for me. However I find that you shouldn't be newing up the FilterCompilator like you're doing. It should be constructor-injected, and perhaps made a dependency of FilterContainer, or of another type that would deal with everything that can be done with a Filter.



Note: If _renderer is injected in the constructor, then you shouldn't call _renderer.Dispose() since you've put that burden onto the caller (ideally your favorite IoC container).