In certain cases processors need to know the source/destination format,
e.g. when they need to perform different operations for different
formats. So we refactor the pipeline class and initialize processors
with it.
With this we also create a separate Builder class, whose sole purpose is
to build options and call the pipeline with those options. This is an
improvement, because previously the Pipeline class was also acting like
a builder by including Chainable. This was making the Pipeline class
difficult to change, as Chainable#method_missing was swallowing any
typos. It was also making it impossible to refactor, because we would
risk the new methods clashing with VIPS/ImageMagick operation names.
This commit adds the chainable API to the MiniMagick module. The
old API should still work, but it has been deprecated and will be
removed in ImageProcessing 1.0.
The new MiniMagick module builds commands directly using
MiniMagick::Tool::Convert directly, and avoids the MiniMagick::Image
class. This makes it easier to reason about, because it doesn't have
the added complexity of the MiniMagick::Image class.
The new behaviour is that "-regard-warnings" is now automatically added,
which means that a `MiniMagick::Error` will be raised in case of any
warnings during processing (such as when image is corrupted). This is
most likely what we want.
The new `.valid_image?` method is now an order of magnitude faster than
the old `#corrupted?` method. For consistency we also add
`.valid_image?` to the Vips module as well.
The new API doesn't accept arbitrary IO objects anymore, to avoid
copying the same file to disk multiple times. The source images need to
be File objects now.
This also adds some ImageProcessing::Pipeline changes. We extract the
logic of creating Tempfiles to it, because MiniMagick module needs it as
well. It now also deletes the tempfile in case of any exceptions during
processing.
Janko Marohnić
GustavoCaso
printercu