Added a module named proj that defines projective transformations, and means to construct, combine and apply them to images.

The module exports warp* functions that allow performing projective transformations on images. Some of the functionality of this module overlaps with the affine module.

It exports a type Proj that can be used to define projective transformations by

• Constructing them from primitive transformations
• From a given 3x3 projective matrix (in homogeneous coordinates)
• Or from a set of 4 control point pairs (for this calculation I have added a new dependency rulinalg 0.4.2 - a linear algebra crate

image dependency bumped to 0.22.1 and all functions deprecated in the image crate marked with #[allow_deprecated] to suppress warnings.

Bumped the version of the imageproc crate. Don't know if this is common practice in additions like this one.

We don't have to make this polished, just less rough than the code is now.

• ~~Try to reduce signature bloat a little. Unfortunately I think we're stuck with the I: 'static, I::Pixel: 'static, <I::Pixel as Pixel>::Subpixel: + 'static spam for now (but I'd be very happy to be shown wrong).~~
• Check the TODOs for anything easily fixable.
• Profile performance. I've still not looked at this, but I fear the performance is pretty woeful. If we're 2x slower than, say, OpenCV that's fine for now. If we're 100x slower not so much.
• ~~Make the existing functions nicer to call, probably with a mix of functions taking loads of options and functions providing sensible defaults for some of those options that forward to the verbose ones.~~
• ~~Stop spamming everything directly into master. I'll create a fork and move my future commits to go via pull requests.~~
• ~~Set up continuous integration. Anyone want to help with this one?~~
• ~~Better readme - give usage examples, and briefly discuss future plans and how to contribute.~~
• ~~Add a license.~~
• ~~Build on stable.~~

It would be interesting to look at ways to draw TTF fonts (or just any text) onto supported images. Let me know what you think!

Take a look at https://github.com/dylanede/rusttype as well

@softprops was looking for something like ImageMagick's TintImage function: https://github.com/ImageMagick/ImageMagick/blob/master/MagickCore/fx.c.

Visual effects seem like something that should eventually go in a separate crate, but for now it should be pretty easy to add a module containing some ImageMagick-y effects.

I am trying to create an image containing text with different color. But it looks like draw_text_mut always print using the first color used

the line is:

Rgba([ (fps * 20), 0u8, 0u8, 255u8]),

where fps is increased of 1 every loop (I am printing it, even with u8 cast)

edit: the full command is taken from one of the examples

imageproc::drawing::draw_text_mut(
				&mut image,
				Rgba([ (fps * 20), 0u8, 0u8, 255u8]),
				x,
				y,
				scale,
				&font,
				&c,
			);

This happens in when I try to draw a circle with small radius.

Expected

(draw by pillow)

Actual behaviour

(a more intuitive picture)

Reproduction steps

let mut circle = DynamicImage::new_luma8(21, 21);

draw_filled_circle_mut(
    &mut circle,
    (10, 10),
    10,
    Rgba([255, 255, 255, 255]),
);
circle.save(std::path::Path::new("circle.png"));

circle = Image.new('L', (21, 21), 0)
draw = ImageDraw.Draw(circle)
draw.ellipse((0, 0, 20, 20), fill=255)
circle.save('circle_py.png')

This commit adds a new module edges, which currently only contains the canny edge detection algorithm. The provided implementation is heavily based on the implementation proposed by the corresponding wikipedia article (https://en.wikipedia.org/wiki/Canny_edge_detector), with some simple optimizations.

Running the font.rs example on the latest crate outputs an error regarding the text_size function.

error[E0432]: unresolved import `imageproc::drawing::text_size`
 --> src\main.rs:4:41
  |
4 | use imageproc::drawing::{draw_text_mut, text_size};
  |                                         ^^^^^^^^^ no `text_size` in `drawing`

[dependencies]
imageproc = "0.22.0"
image = { version = "0.23.6", default-features = false }
rusttype = "0.9.2"

I have implemented a version of this. Some caveats:

• It's my first attempt at really doing anything in Rust so let me know where my code sucks :)
• It loses a pixel off the edge because of the 4x4 kernel. I want to improve edge behavior for all the affine code, but that would be a separate change.
• It's not super fast.. about 1/2 the speed of the bilinear stuff. Here are the bench results on my laptop:

test affine::tests::bench_affine_bicubic                                       ... bench:   2,054,455 ns/iter (+/- 574,716)
test affine::tests::bench_affine_bilinear                                      ... bench:     822,706 ns/iter (+/- 198,371)
test affine::tests::bench_affine_nearest                                       ... bench:     390,691 ns/iter (+/- 22,217)
test affine::tests::bench_rotate_bicubic                                       ... bench:     804,275 ns/iter (+/- 182,569)
test affine::tests::bench_rotate_bilinear                                      ... bench:     430,449 ns/iter (+/- 23,885)
test affine::tests::bench_rotate_nearest                                       ... bench:     292,266 ns/iter (+/- 26,284)

I want to be able to draw semi-transparent rectangles. I have tried doing this using colors with a suitable alpha channel. Take this code for example:

extern crate image;
extern crate imageproc;

use std::path::Path;
use image::{Rgba, RgbaImage};
use imageproc::drawing::draw_filled_rect_mut;

fn main() {
    let path = Path::new("1.png");
    let solid_white = Rgba([255u8, 255u8, 255u8, 255u8]);
    let blue = Rgba([0u8, 0u8, 255u8, 255u8]);
    let semi_red = Rgba([255u8, 0u8, 0u8, 127u8]);
    let mut img = RgbaImage::new(200, 200);
    draw_filled_rect_mut( // Solid white background
        &mut img, imageproc::rect::Rect::at(0, 0).of_size(200, 200),
        solid_white);
    draw_filled_rect_mut( // Solid blue square
        &mut img, imageproc::rect::Rect::at(25, 25).of_size(100, 100),
        blue);
    draw_filled_rect_mut( // Semi-transparent red square
        &mut img, imageproc::rect::Rect::at(75, 75).of_size(75, 75),
        semi_red);
    img.save(path).unwrap();
}

I expected this to draw a 200x200 square in solid white (which it does), then to draw a 100x100 solid blue square on top (which it does), then to draw a 75x75 semi-transparent red square that overlaps the blue and the white (which it does -- but not quite right). I expected the red to "show through" some blue where it overlaps the blue square and to "show through" some white (i.e., look pink) where it overlaps the white background.

But there is no show through at all.

Is it possible to achieve this effect? If so, where is it documented?

This is a work-in-progress, use this pull request for tracking checklist completion:

• [ ] handling of point sizes and converting between pixels and absolute sizes
• [x] positioning of font, and out-of-bounds checks
• [x] make it generic over pixel type
• [x] example
• [ ] newline support (?)
• [ ] outline support (?)
• [ ] add some regression tests
• [ ] add some unit tests - probably by writing the imageproc rendering function in terms of something with a signature like the draw function from rusttype, and then mocking out draw in the unit test ourselves

This PR is intended to facilitate discussion about a proposed refactor. It isn't a complete PR—probably won't even compile.

I suggest the gradient filter module & API be refactored to achieve the following:

• unify the API with respect to the choice of kernel
• increase orthogonality
• allow for the addition of the Roberts cross kernel, which is a $2\times 2$ kernel, not a $3\times 3$ kernel and so isn't compatible with present-day code
• reduce code duplication (DRY)

A summary of the suggested design

1. Have a GradientKernel (alt. named GradientMethod) enum with variants Sobel, Scharr, etc.
2. Change the pub static HORIZONTAL_* and pub static VERTICAL_* kernels to be actual Kernel<i32> struct instances rather than [i32; 9] arrays.
3. Member functions of GradientKernel return references to the appropriate pub static Kernel<i32> instance.
4. Move the filtering functions into member functions of GradientKernel. Optionally have free function aliases that take the GradientKernel variant as a parameter. (The Sobel kernel would no longer be distinguished.)
5. Change the function and purpose of gradient_map so that it applies a function to the gradient vector of each point to produce a single pixel result. Consequently, the member functions gradient_L1_norm, gradient_angle, gradient_L2_norm (with alias gradient_magnitude) trivially reduce to calls to gradient_map.
6. Gradient operations only work on single channel images. Do away with the functionality currently being provided by gradient_map. (Justified by replacing multichannel functionality with better, more general imageprocfeature.)

More Details

The suggestion is to have a GradientKernel (alt. name could be GradientMethod) enum:

pub enum GradientKernel {
    Sobel,
    Scharr,
    Prewitt,
    Roberts
}

4. Move the filtering functions into member functions of GradientKernel.

The free functions in gradients.rs would be brought into GradientKernel member functions:

impl GradientKernel {
    pub fn horizontal_gradient(&self, image: &GrayImage) -> Image<Luma<i16>> {…}
    pub fn vertical_gradient(&self, image: &GrayImage) -> Image<Luma<i16>> {…}
    pub fn gradient_map<P, F, Q>(&self, image: &GrayImage, f: F) -> Image<Q> where … {…}
    pub fn gradient_magnitude(&self, image: &GrayImage) -> Image<Luma<i16>> {…}
    ⋮
}

5. Change the function and purpose of gradient_map

I'll argue for the existence of a new function in this section. I will argue for the deletion of the current version of gradient_map in the next section, as these are two distinct questions.

I want a function called gradient_map, but I do not want it to do what the current definition of gradient_map does. Instead, it makes sense to me to have a gradient_map function that maps a function over the gradient vector at each point to produce an output image. This would literally map a function onto the gradient, which strikes me as linguistically more accurate. Such a function would be useful to client code and would reduce the computations of gradient_angle and gradient_magnitude to the composition of gradient_map with the appropriate function of the gradient vector, which is satisfyingly orthogonal.

6. Gradient operations only work on single channel images

The current version of gradient_map enables an arbitrary function of an n-channel pixel to produce an m-channel pixel for the output. I speculate that this function exists because gradient computations are often needed to produce a "magnitude of rate of change at a point" from a color source image, and since kernel convolution in a single channel operation, there needed to be a way to go from three channels to one. But if magnitude of perceptual rate of change is what is of interest, then the color source image should be converted to luminance before a gradient operation is ever applied. (Note also that any linear function of channels commutes with a channel-wise gradient operation.) In my view, this functionality doesn't belong in the gradients module at all, and in any case it isn't well-described by the function name gradient_map.

This refactor is agnostic to whether and to where the existing functionality to move. But I'll say a few words about that anyway. Producing an image via a function of another image's channels can be done by the client code. If it is useful functionality and/or is cumbersome for client code to implement, the functionality should be implemented in a generic way in some other module, or in its own module. In fact, I would like to draft a second feature proposal independent of this one that implements fast generic high-level elementwise mathematical operations on images: add two images, multiply two images, find the max of two images. But this is a digression.

A gradient operation is fundamentally a single channel operation. Splitting and combining channels and images is a distinct collection of operations from gradient operations.

While running the display_image function, one of the CPU's on my computer suddenly rockets up to using 100% of the CPU.

Looking into the backtraces while running gdb, it appears to be happening during sdl2 event retrieval. However, a brief investigation into sdl2's codebase yields nothing that would cause this, and I'm unsure if this issue originates in imageproc or in one of its dependencies.

Here is the program I'm using it in, although I doubt it's that.

the current text scaling system makes it needlessly difficult to define the "shape" of a character.

i feel that something more explicit than the current rusttype::Scale based system may be beneficial to the usability of this library . one possibility is taking four numeric arguments, (x, y, width, height). where x and y define the position of the top left corner of the character, and width and height define how far the character extends from x and y