Does this image-processing library break the Single Responsibility Principle? I'm writing a small library to do some image-processing on GPU for WinRT, however, I'm not sure if such design breaks SRP.

One class loads and saves image, renders and maintains filters - isn't it too much?

Code

public class FilteredImageProvider : IDisposable
{
    public event Action ImageSourceChangedEvent;
    GPUImage currentImage;
    SharpDXRenderer renderer;
    FilterContainer filterContainer;
    ImageGPULoaderFactory loaderFactory;

    public FilteredImageProvider()
    {
        this.renderer = new SharpDXRenderer();
        this.filterContainer = new FilterContainer();
        this.loaderFactory = new ImageGPULoaderFactory();
    }

    public ImageSource Image
    {
        get { return renderer.GetRendererSource(); }
    }

    public async Task LoadFromFile(IStorageFile sourceFile)
    {
        var imageLoader = loaderFactory.GetImageLoader(sourceFile);

        if (currentImage != null)
            currentImage.Dispose();

        currentImage = await imageLoader.LoadImage();
        renderer.Load(currentImage);
        ImageSourceChangedEvent();
    }

    public async Task SaveToFile(IStorageFile destinyFile)
    {
        var imageSaver = loaderFactory.GetImageLoader(destinyFile);
        var deviceManager = renderer.GetDeviceManager();
        await imageSaver.SaveImage(currentImage, deviceManager);
    }

    public void Render()
    {
        var filterCompilator = new FilterCompilator();
        var renderedImage = currentImage.GetImageAsEffect();
        var compiledEffect = filterCompilator.CompileFiltersToEffect(renderedImage, filterContainer);

        renderer.Render(compiledEffect);
    }

    public void AddFilter(IFilter filter)
    {
        filterContainer.AddFilter(filter);
    }

    public void RemoveFilter(IFilter filter)
    {
        filterContainer.RemoveFilter(filter);
    }

    public void Undo()
    {
        filterContainer.Undo();
    }

    public void Redo()
    {
        filterContainer.Redo();
    }


    public void Dispose()
    {
        if (currentImage != null)
            currentImage.Dispose();
        renderer.Dispose();
    }
}
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).