Comments (3)
Good thoughts! The way I think about this is:
Is ImageProcessing
always going to have a single middle dependency on the underlying processor i.e. Vips
and ImageMagick
or will it be open to supporting multiple middle libraries that wrap Vips
and ImageMagick
?
If this gem will always depend on a single wrapper library then I'd go with the more accurate module names. If this gem might depend on multiple wrapper libraries, then I'd use the wrapper libraries for naming.
This applies more for MiniMagick
and RMagick
(and maybe some FutureMagick
:) ) especially if there are trade-offs in supported functionalities/performance between the wrapper libraries and we may want to support all of them.
My 2 cents.
from image_processing.
Or maybe Vips is an informal name used within the libvips community? But, even so, the official project name and branding (what little there is) use the libvips name.
The project was original named "VIPS", you can see it in the Wikipedia page (btw, it's interesting to see how long history it had 😃). Until recently the official website was http://vips.ecs.soton.ac.uk, where the official name was displayed also as "VIPS"; the website has since been moved to http://jcupitt.github.io/libvips/.
I think that the project is still called "VIPS", but it was just centralized into the libvips
library, as that's the single place that contains all the processing code, so that's why I think it's more common to reference libvips
directly. But I think we can still call it "vips", as the name libvips
originated from "vips". On the other hand, for ImageMagick the repository is named the same – "ImageMagick" – though the libraries like "MagickCore" and "MagickWand" do drop the "Image" part.
ImageProcessing::MiniMagick
is, of course, named after the minimagick gem. But that seems like an implementation detail. The main point of this module is to interface with imagemagick.
Yes, but as @hmistry said, I think it's important to communicate this implementation detail. When RMagick was revived a few years ago, I knew that I wanted to leave the doors open for ImageProcessing::RMagick
to be implemented. MiniMagick being just a CLI wrapper has it's cons, so I could see ImageProcessing supporting both MiniMagick and RMagick, and then people can choose which one they prefer.
Also note that ImageProcessing delegates all unknown methods to the ImageMagick CLI builder, and an RMagick::Image
object could respond to different methods than the options available in the CLI. So it's not technically an implementation detail, because you map directly to CLI options (an RMagick::Image
object might respond to different methods). And you can also interact directly with the MiniMagick::Tool
object via the #custom
block.
Now, regarding the ImageProcessing::LibVips
suggestion, I would prefer to stick with ImageProcessing::Vips
, because ruby-vips
is the official Ruby gem with libvips
bindings, and unlike with Minimagick/RMagick I don't see any possibility of another implementation arising. Also I would feel a bit strange naming it ImageProcessing:::RubyVips
, so I decided for just Vips
.
from image_processing.
You both make very good points, @janko-m and @hmistry. Totally makes sense.
I'm glad to know there are solid motivations for their current naming scheme and that's inherently flexible for the future.
Thanks for listening to my crazy idea! 👍
from image_processing.
Related Issues (20)
- remote shell execution in v1.12.2 HOT 1
- Can we watermark pdfs without splitting into images? HOT 1
- Translating modulate function from ImageMagick to Libvips. HOT 2
- Why depend on both vips and mini_magick? HOT 10
- rotate leaves a black line on edge of image HOT 2
- Block unfuzzed loaders with libvips 8.13+ HOT 18
- Adding white background while converting from `png` to `jpg` with `resize_and_pad!` fails with linear issue HOT 4
- Custom ImageMagick Command HOT 2
- Default appears to be ruby-vips rather than mini_magick - Rails 7, Ruby 3 HOT 2
- Size of watermark (Vips) HOT 1
- When converting PDFs, the order of arguments matters? HOT 1
- Please disable default image sharpening in the VIPS backend HOT 2
- Doc: ImageMagick `loader`, unclear how to specify input and output files! HOT 2
- No append on ImageProcessing::Vips HOT 4
- WARNING: The convert command is deprecated in IMv7, use "magick" HOT 2
- libvips cant process jpg images
- How can I adjust individual levels using ::Vips? HOT 5
- Basic image trim with background HOT 2
- VipsForeignLoad: "/tmp/ActiveStorage-28657-20220112-4-8e2faa.jpg" is not a known file format HOT 19
- Different error message in tests HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from image_processing.