pixelclasser: A Package for Classifying Pixels by Colour

[CarlosRealR]

Submitting Author: Carlos Real (https://github.com/CarlosRealR)
Repository: https://github.com/CarlosRealR/pixelclasser
Version submitted: 0.5.0
Editor: @ldecicco-USGS
Reviewer 1: @qdread
Reviewer 2:
Archive: TBD
Version accepted: January 28, 2021

---

• Paste the full DESCRIPTION file inside a code block below:

Package: pixelclasser
Type: Package
Title: A Package for Classifying Pixels by Colour
Version: 0.5.0
Authors@R: person("Carlos", "Real", email = "carlos.real@usc.es",  role = c("aut", "cre"), comment = c(ORCID = "0000-0002-5433-6728"))
Description: Contains functions to classify the pixels of an image file
    (jpeg or tiff) by its colour. It implements a simple form of the techniques 
    known as Support Vector Machine adapted to this particular problem.
Encoding: UTF-8
License: GPL-3
LazyData: true
RoxygenNote: 7.1.1
Imports:
    graphics,
    grDevices,
    jpeg,
    tiff,
Suggests: 
    knitr,
    rmarkdown,
    testthat
VignetteBuilder: knitr
URL: https://github.com/CarlosRealR/pixelclasser
BugReports: https://github.com/CarlosRealR/pixelclasser

Scope

• Please indicate which category or categories from our package fit policies this package falls under: (Please check an appropriate box below. If you are unsure, we suggest you make a pre-submission inquiry.):

  • data retrieval
  • data extraction
  • data munging
  • data deposition
  • workflow automation
  • version control
  • citation management and bibliometrics
  • scientific software wrappers
  • field and lab reproducibility tools
  • database software bindings
  • geospatial data
  • text analysis

• Explain how and why the package falls under these categories (briefly, 1-2 sentences):
  The package allows to extract information from digital images based on the colours of the pixels. It is a simplified form of the machine learning technique known as Support Vector Machines. The original Red-Green-Blue data contained in the image is transformed into colour proportions and in this way the problem is reduced to 2 dimensions. This allows the representation of the pixels of the image on a plane and the arbitrary selection of classification rules by the user. The transformation also eliminates colour differences due to uneven illumination of the scene. The functions in the package allow for the plotting of the image pixels, the definition and plotting of classification rules, the classification of the pixels in categories and the creation of classified images.
  The method lacks the optimization procedures and the possibility of defining non-linear rules that are present in more complex code, but allows the user to directly observe the existence of clusters of points in her images and create ad-hoc rules in a simple way.

• Who is the target audience and what are scientific applications of this package?
  Any person that needs to classify digital (RGB) images. Not addressed to a particular field or scientific activity. It processes the colours in common digital images, taken with any type of software, and without any particular requirement about their content. In the paper which will be sent to Methods in Ecology and Evolution a couple of examples of how to distinguish plant material from background (one of them is the example detailed in the vignette) are presented, but I used them because they come from our own research. It can be readily adapted to other types of research.

• Are there other R packages that accomplish the same thing? If so, how does yours differ or meet our criteria for best-in-category?
  I am not aware of similar packages. Full SVM can be done with packages like caret or mlr, which implement many machine learning techniques for multivariate problems. The complexity of these packages is not necessary for image classification in many cases, and can be a deterrent for many researches that do not need such "big gun" tools. The simplicity of pixelclasser allows its use without a large mathematical background.

• (If applicable) Does your package comply with our guidance around Ethics, Data Privacy and Human Subjects Research?
  Not applicable

• If you made a pre-submission enquiry, please paste the link to the corresponding issue, forum post, or other discussion, or @tag the editor you contacted.

Technical checks

Confirm each of the following by checking the box.

• I have read the guide for authors and rOpenSci packaging guide.

This package:

• does not violate the Terms of Service of any service it interacts with.
• has a CRAN and OSI accepted license.
• contains a README with instructions for installing the development version.
• includes documentation with examples for all functions, created with roxygen2.
• contains a vignette with examples of its essential functions and uses.
• has a test suite.
• has continuous integration, including reporting of test coverage using services such as Travis CI, Coveralls and/or CodeCov.

Publication options

• Do you intend for this package to go on CRAN?
• Do you intend for this package to go on Bioconductor?
• Do you wish to automatically submit to the Journal of Open Source Software? If so:

JOSS Options

• The package has an obvious research application according to JOSS's definition.
  • The package contains a paper.md matching JOSS's requirements with a high-level description in the package root or in inst/.
  • The package is deposited in a long-term repository with the DOI:
  • (Do not submit your package separately to JOSS)

• Do you wish to submit an Applications Article about your package to Methods in Ecology and Evolution? If so:

MEE Options

• The package is novel and will be of interest to the broad readership of the journal.
• The manuscript describing the package is no longer than 3000 words.
• You intend to archive the code for the package in a long-term repository which meets the requirements of the journal (see MEE's Policy on Publishing Code)
• (Scope: Do consider MEE's Aims and Scope for your manuscript. We make no guarantee that your manuscript will be within MEE scope.)
• (Although not required, we strongly recommend having a full manuscript prepared when you submit here.)
• (Please do not submit your package separately to Methods in Ecology and Evolution)

Code of conduct

• I agree to abide by rOpenSci's Code of Conduct during the review process and in maintaining my package should it be accepted.

[melvidoni]

Hello @CarlosRealR, thanks for submitting. We will assign you a handling editor soon. In the meantime, can you please elaborate on the answers to the questions of the Scope section? (in the opening post)

[CarlosRealR]

Hello @CarlosRealR, thanks for submitting. We will assign you a handling editor soon. In the meantime, can you please elaborate on the answers to the questions of the Scope section? (in the opening post)

Hello @melvidoni, done. I hope my answers would be clear enough now.

[melvidoni]

It does, thank you kindly @CarlosRealR. Your Handling Editor will be @ldecicco-USGS.

[ldecicco-USGS]

Hi @CarlosRealR , I'll begin asking around for 2 reviewers and running the automated package checks. Thanks for expanding on the questions above 👍

One thing that would be helpful while I'm asking around for reviewers would be to "Knit" the Readme.Rmd, and then check-in the Readme.md. The main difference is that Github will then render the file. You could copy a few of the examples in the vignette to showcase the main idea of the package in a pretty/rendered way. So, not required, I'm just thinking it might help the potential reviewers decide if they are a good fit for taking on the review.

Also, not sure how responsive my American colleagues are going to be this week. I'd be prepared for a slightly slower response for the next couple of days than maybe usual.

[CarlosRealR]

Hi @ldecicco-USGS , excuse me, but this is the first time I make a package and send software to GitHub and I'm a a bit confused with the procedure and the best way to do things. What do you mean with "check-in the Readme.md"? I would be grateful if you could tell me a package with a readme that way to understand what I have to do exactly.

[ldecicco-USGS]

Once you knit the Rmd file, it will create an md file, so now on your computer there will be 2 files, the "Rmd" one is specific to the "R" programming language, the "md" is a markdown file (more universal). So not only do you need to generate the "md" file, you need to get it up to Github. If you are in RStudio using the "Git" tab, that will mean clicking on the checkbox next to the new file, hitting "commit", writing a little message, then clicking the "Push" button.

Probably "check-in" was the wrong term, sorry! If you are doing it in the Terminal, it would be something like:

git add README.md
git commit  -m "Adding the md file"
git push origin master

[CarlosRealR]

Hi, I expanded the README.rd including some images as you suggested. Thanks for the advice.

[CarlosRealR]

Hi, I expanded the README.rd including some images as you suggested. Thanks for the advice.

[CarlosRealR]

Hi @melvidoni. sorry, but I closed this by error, I do not know how