The imgnoiser (IMaGe NOISE) R package contains tools for the measurement, analysis and characterization of raw image noise from digital CMOS sensor cameras.
The focus of imgnoiser is to factorize most of the software environment, configuration concepts, data definitions and conventions required for image noise analysis, in one single point, to easily share and reuse noise analysis papers without the need to deliver, define and explain repeatedly the software environment and instructions to reproduce most of the results.
You can use the devtools R package to install the current version from Github:
devtools::install_github('oscardelama/imgnoiser')In the wiki pages you will find detailed documentation and examples of the general workflow using imgnoiser.
- The imgnoiser R Package
- Introduction to the
vvmClass - Introduction to the
hvdvmClass hvdvmandvvmClass Usage- Collecting Image Samples
These wiki pages are based on the package vignettes. If you install the package, you will be able to access this documentation from your R session using:
browseVignettes('imgnoiser')The article "Introducing the imgnoiser R package" is a good introduction of this package. It presents the package reusing and extending the documentation in the wiki pages of this package. If you havent read yet those wiki pages we encorage you to read the article.
Other articles using the imgnoiser package and including detailed code of its usage are:
- Noise Analysis: From raw to sRGB
- Profiling the Noise in Nikon D7000 Using the imgnoiser R Package
- Developing a RAW Photo by hand Using Imgnoiser
Most software, including imgnoiser is developed in an iterative way: you decide to include some functionality or service in the product, you design the interface, develop the service, and during the tests you find some rough edges to polish and unhandled situations, so you iterate all over again until you are satisfied. Then you start to document the new functionality.
In this context, most of the package documentation is complete and accurate, but recently added features may not be complete or exists yet.
The package is continuously tested, but the tests neither include every package feature nor all their possible usage combinations. Notice for example that a function with 4 parameters and an average of 3 substantially different possible values per parameter, requires 4^3 = 64 tests. If in addition to that, you take into account that this function output is the input of another similar function (4 parameters, 3 values per parameter), now we need 64*64 = 4,096 tests just to be 100% sure this two functions work, individually and together, as expected. All of this explains the real software tester is the final user, and that is the reason for periodic software updates.
However, all of this do not dismiss a developer to make its best reasonable effort to ensure the quality of its product. To be honest, nowadays, the Travis CI badge above does not reflect the quality assurance I wish to reach when this product is more mature and stable in its features and interfaces.
In the iterative development effort, most of the package functionality is reasonable well tested but yet not stressed in real life intensive use; some recently added code is still in test phase.
If you have found an issue please file it here.
This package is free and open source software, licensed under GPL.