Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adds more documentation and examples for padarray, Fill and Pad #54

Merged
merged 2 commits into from
Feb 27, 2018

Conversation

zygmuntszpak
Copy link
Member

No description provided.

@zygmuntszpak
Copy link
Member Author

@timholy I'm working my way through the code base trying to improve the documentation by adding explanations and examples. When you have a moment, please could you review this pull-request and also take a look at #53 ?

@codecov
Copy link

codecov bot commented Jan 17, 2018

Codecov Report

Merging #54 into master will not change coverage.
The diff coverage is 100%.

Impacted file tree graph

@@           Coverage Diff           @@
##           master      #54   +/-   ##
=======================================
  Coverage   90.84%   90.84%           
=======================================
  Files           8        8           
  Lines        1070     1070           
=======================================
  Hits          972      972           
  Misses         98       98
Impacted Files Coverage Δ
src/border.jl 96.87% <100%> (ø) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 0186e50...0341977. Read the comment docs.

@zygmuntszpak
Copy link
Member Author

Found a typo and fixed an emdash in my original commit.

@zygmuntszpak
Copy link
Member Author

@timholy bump :)

Copy link
Contributor

@kmsquire kmsquire left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Generally looks good! I have one small change request and a couple of comments. If possible, it would be great if @timholy took a quick look, but I can merge if he doesn't get to it soon.

src/border.jl Outdated

#### Usage illustration
Use `Pad(:replicate,2,2)` to designate that the top and bottom border should be
replicated by two pixels, and the left and right border by four pixels.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should be Pad(:replicate, 2, 4) to match the text.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done—Thank you!


It's worth emphasizing that padding is most straightforwardly specified as a string,

imfilter(img, kernel, "replicate")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess that this information is available in the imfilter docs, but wondering if it's also useful here still.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I removed it because there isn't actually any method in Pad or Fill which takes a string. It seems odd to mention it here, since it is a description of how to use the imfilter API. I am in the process of reworking and extending the imfilter documentation in a different branch.

src/border.jl Outdated
6 & 6 & 6 & 6 & 6 & 12 & 18 & 24 & 30 & 36 & 36 & 36 & 36 & 36 \\\\
6 & 6 & 6 & 6 & 6 & 12 & 18 & 24 & 30 & 36 & 36 & 36 & 36 & 36 \\\\
6 & 6 & 6 & 6 & 6 & 12 & 18 & 24 & 30 & 36 & 36 & 36 & 36 & 36 \\\\
6 & 6 & 6 & 6 & 6 & 12 & 18 & 24 & 30 & 36 & 36 & 36 & 36 & 36
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These examples look really nice when rendered, but unfortunately, at the REPL, the raw latex is returned (try ?padarray at the julia prompt). I'm not sure if there's a nice way around this.

I posted a question about this at https://discourse.julialang.org/t/showing-latex-docstrings-at-the-repl/8573.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the solution to this conundrum is to implement software to render latex to ascii-art so that mathematics can be printed in the console. See this post for some examples.

Here is another good example.

I have started working on a Julia package to do this type of thing. If I works out, then perhaps it can be incorporated into Base.

In the meantime, I have adjusted the indentation of the matrices in the docstring so that when they are printed in the console they align well and are more visually pleasing. You should find the latest commit more readable.

Thanks for posting the question on discourse. There is a precedent for having Latex in docstring in Base. See ?fft for example.

Copy link
Member

@timholy timholy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for the long absence. This and your other documentation improvements are truly extraordinary, so nice that I'm definitely going to merge it.

Bigger picture, the only thing I worry about (can't remember if I brought this up before) is that experienced users might often use ?imgradients just to be reminded what arguments should be supplied in what order. Unfortunately with more documentation there's some scrolling involved to go back up to the top and see the signature. I wonder if Julia needs to have a notion of "brief docs" and "thorough docs", perhaps triggering the brief one with ??imgradients or something (note the 2 ? marks).

src/border.jl Outdated
extrapolation scheme.

You can specify a different amount of padding for the top, left, bottom and
right border of an image.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I definitely think of 2d as the "default," but one of the features of JuliaImages is that it generalizes to 3d and 4d imaging (e.g., biomedical imaging). I don't want to convey too strong of an impression that these constructs are 2d-only; conversely, I don't want to explain things in an unnecessarily complicated way for the majority of folks who are doing 2d image processing. Would something like "You can specify a different amount of padding at the lower and upper borders of each dimension of the image (top, left, bottom and right in two dimensions)" be acceptable?

It's fine if all of your examples are 2d.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've followed your suggestion and also added some extra phrases to emphasize that the types support multi-dimensional arrays.

I've also added three-dimensional examples for Pad and Fill to the padarray function.

src/border.jl Outdated
refer to the documentation of [`Pad`](@ref).

You can specify a different amount of padding for the top, left, bottom and
right border of an image.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here too.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

src/border.jl Outdated
Fill(value::T, lo::Dims{N}, hi::Dims{N})
```
Construct an instance of [`Fill`](@ref) designating a `value` and tuples
`lo` and `hi` which stipulate the number of row and columns which will be predended
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

prepended?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for spotting that---fixed.

src/border.jl Outdated

"""
```julia
Fill(value, lo::AbstractVector, hi::AbstractVector)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here you say lo is an AbstractVector but the text talks about a tuple. The code accepts either. Perhaps just don't put a type on these arguments? Then you only need to document one of them. Here too you could alternatively use the style

    Fill(value::T, lo::Dims{N}, hi::Dims{N})
    Fill(value::T, lo::AbstractVector, hi::AbstractVector)

Construct an instance...

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

src/border.jl Outdated
Pad(style::Symbol, (m,n))
```
Construct an instance of [`Pad`](@ref) such that the image is prepended and appended symmetrically with `m` pixels at the lower and upper edge of dimension 1, and `n` pixels for dimension 2.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One option you can consider is to write the docstring like this:

"""
    Pad(style::Symbol, m, n, ...)
    Pad(style::Symbol, (m, n, ...))

Construct an instance of ...
"""

One of the things I like about this style is that is reduces the amount of text that users have to read, because the main explanation is stated only once.

But this is your choice, and I'll merge whatever you prefer.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I followed your suggestion.

@zygmuntszpak
Copy link
Member Author

zygmuntszpak commented Feb 7, 2018

Thanks for the great feedback and useful suggestions on the pull-request. I've tried to incorporate all your suggestions, and added text to emphasize that padding is also supported on multi-dimensional arrays. I've also included some 3D examples in padarray to ensure that people can see at a glance that the scope of the function and types extends beyond 2D.

I agree that a 'brief docs' would be useful when working in the REPL. In IJulia one automatically gets a scroll window, so one can still see the function signature. Similarly, Atom's documentation browser also ensures that the function signature appears. The problem is definitely the REPL and your ?? suggestion could help address the problem.

@zygmuntszpak
Copy link
Member Author

@timholy Just a reminder that I've amended this pull request with the changes you requested.

@zygmuntszpak
Copy link
Member Author

@kmsquire Hi Kevin, I think it might be a while before Tim has a moment to return to this thread. Would you mind merging this pull-request?

@kmsquire
Copy link
Contributor

Hi Zygmunt, I would be happy to, but unfortunately, there are merge conflicts right now. I might be able to resolve them myself when I get to a computer, but if you see this before I do, can you take a look?

@zygmuntszpak
Copy link
Member Author

@kmsquire I've pulled Julia master into my forked repository, and then merged my up-to-date forked repository with my padarray branch. I didn't experience any merge conflicts. I've pushed this latest version, so presumably there should be no conflicts since it matches the latest version of master.

@zygmuntszpak
Copy link
Member Author

@kmsquire ping :)

@kmsquire
Copy link
Contributor

Sorry, haven't had many spare moments recently. Thanks for the additional ping, and for the contribution!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants