Open ripytide opened 3 months ago
The imageops
module was added long before my time and has gotten very little attention in the last few years. It contains some methods like crop
or resize
that totally make belong in the crate, but also has others like huerotate
that probably aren't necessary. I'd be open to moving functionality, but we should discuss on a case-by-case basis first
Great, https://github.com/image-rs/imageproc/issues/7 is the corresponding issue on the imageprocs
crate.
My current action plan is to write up a list of all the functions in imageops
and then individually integrate each one into imageprocs
. After each function is integrated and released that would give you the ability to deprecate those individual functions and point users at the corresponding functions in the imageprocs
crate. Then at some point in the future you would have an easier time deleting the deprecated functions hoping most users will have migrated.
How does that sound?
As the image crate has a huge number of users and very little activity happens on the imageops
code, the cost of maintaining duplicated functionality is low but the impact of breaking changes is potentially high.
I'm in favour of:
imageops
functionality to imageproc
, either vs re-exports or re-implementations depending on whether we want to tweak anything.imageops
module (via code comments/readme/PR template/whatever) that new image processing functionality belongs in imageproc
.The question of deprecation or retiring existing imageops
functionality is trickier and thankfully not up to me!
(Edit to add context for other readers: Iβm the maintainer of the imageproc
crate.)
Yeah, this would involve deprecating the methods now and only removing in the next major release (which won't be any time soon given we haven't even started planning it yet)
During this process it is also worth looking at whether these methods are using internal functionality / are tightly tied to the image crate. Like the invert
method only works because one of the required methods on the Pixel
trait is Pixel::invert
. The APIs around writing image processing code that's generic across image type is something I've held off working on because it seemed like there were no elegant options and any changes would just cause a lot of breakage
I've written up the list in a tracking table in the top comment which can be updated as we make progress toward this larger goal. Let me know if you'd like to change anything or if I've missed anything.
To clarify, the last step should probably be deprecated from image crate. We'll remove all the depreciated items in one batch when we do the 0.26 release in 6-12 months (or whenever it happens... haven't started planning that release yet)
I've finished my case-by-case analysis of the current state of things and it doesn't look great, 1/43 functions has an equivalent version in imageproc
. This might be more work than I anticipated :smile:
As the image crate has a huge number of users and very little activity happens on the imageops code, the cost of maintaining duplicated functionality is low but the impact of breaking changes is potentially high.
This is true, but removing that functionality still has great value for simplifications across the library. For example, the Pixel::invert
functionality is only required for image processing, but it is not helpful when trying to integrate non-standard decoders for niche pixel formats.
Tracking Table
Key
imageproc
imageproc
but not yet released.imageproc
but still inimage
image
imageproc
SubImage
that does no processing)SubImage
that does no processing, compose::crop can be used instead but returns a new imageoverlay
andreplace
so I don't see the point migrating this a public functionOriginal Comment
At the moment the
image
crate has several image processing functions in theimageops
module which seems a bit strange to me as they look like they would better belong in theimageproc
crate. Is there a reason why such functionality is in this crate, or is perhaps a holdover from long ago?I would be happy to do the work migrating/integrating the functionality into
imageproc
if you'd like.