Adaptive-resize is actually just a resize using a hardcorded Mesh Interpolation (in IMv6), which is not available as a filter. and is ment for use with very very small image size changes.
However the IMv7 (alpha) version now have it using the current -interpolate setting, without even a fallback to Mesh if interpolate is not defined. As such it now defaults to bilinear interpolating instead of mesh when interpolate is not set by the user.
The operator was originally created in a fast response to a user request, but without discussion. It is was it would probably have been more like what is now in IMv7. As such in my view it is a miss-named operator. As I am currently working on IMv7 CLI interface, I need to decide whether to fix this (back to using Mesh), OR rename the operator to something like -interpolated-resize, which correctly described what the operator is now doing.
My preference is for the later, and rename the operator more appropriately (including the library function), perhaps with the change and a depreciation warning for the old operator migrated back to IMv6 (but without library API change)
What do other developers think?
Adaptive Resize - and IMv7 CLI development.
- anthony
- Posts: 8883
- Joined: 2004-05-31T19:27:03-07:00
- Authentication code: 8675308
- Location: Brisbane, Australia
Adaptive Resize - and IMv7 CLI development.
Anthony Thyssen -- Webmaster for ImageMagick Example Pages
https://imagemagick.org/Usage/
https://imagemagick.org/Usage/
Re: Adaptive Resize - and IMv7 CLI development.
Feel free to change the option name and revert to Mesh interpolation. That is the point of the alpha release, we have the opportunity to fix any misguided decisions we made in V6.
- anthony
- Posts: 8883
- Joined: 2004-05-31T19:27:03-07:00
- Authentication code: 8675308
- Location: Brisbane, Australia
Re: Adaptive Resize - and IMv7 CLI development.
Thanks...
Looks like I'll be renaming -adaptive-resize and its internal function. A depreciated option may be left behind.
however some options will be removed, these I know about already...
-linewidth -pen (both depreciated since IMv5)
-affine -transform (replaced by -distort)
Also I hope to merge specialised blurs -radial-blur (which is really a rotational blur!) and -motion-blur into some form that allows for more variety. EG true radial blur and both symmetric (like radial) and asymmetric (motion) in either direction.
If any C programmer likes to volunteer to work on this, either in core library, or in the CLI syntax, or some other aspect, there is lots of interesting stuff to do.
For example see Future Development Notes for an example.
Looks like I'll be renaming -adaptive-resize and its internal function. A depreciated option may be left behind.
however some options will be removed, these I know about already...
-linewidth -pen (both depreciated since IMv5)
-affine -transform (replaced by -distort)
Also I hope to merge specialised blurs -radial-blur (which is really a rotational blur!) and -motion-blur into some form that allows for more variety. EG true radial blur and both symmetric (like radial) and asymmetric (motion) in either direction.
If any C programmer likes to volunteer to work on this, either in core library, or in the CLI syntax, or some other aspect, there is lots of interesting stuff to do.
For example see Future Development Notes for an example.
Anthony Thyssen -- Webmaster for ImageMagick Example Pages
https://imagemagick.org/Usage/
https://imagemagick.org/Usage/