rodousse / stbipp Goto Github PK

Describe the bug
TypeTraits has not been removed of the main CMakeLists.txt

To Reproduce

• Run cmake

Is your feature request related to a problem? Please describe.
Well this is pretty clear... Let's implement some tests!

Describe the bug
The file StbippConfigVersion.cmake is located at the root of the CMAKE_BINARY_DIR whereas the StbippConfig.cmake file is in ${CMAKE_BINARY_DIR}/cmake. Those two are supposed to be located in the generated cmake folder.

Is your feature request related to a problem? Please describe.
The sampling is made as follow :

auto color = image(1,20) ;
auto sameColor = image(1.01,20.1) ; // equivalent to 'image(int(1.01), int(20.1))'

The color returned in both case will be the same.

Describe the solution you'd like
Using floating point in pixel accessor would perform a linear sampling, a nearest pixel sampling, or a custom made sampler.

Describe alternatives you've considered
A convenient way would be to use a functor to sample the image as follow :

auto color = image.at<LinearSamplingFunctor>(10.01,20.1);

Is your feature request related to a problem? Please describe.
The same way OpenCV is doing it, we can change at runtime the "Color" underlying type.
For the moment it is fixed to Color<float,4>. But what if we want it to be encoded with 3 unsigned chars, or 26 doubles...

It would get rid of the castData() templated member function and will come very handy in some cases.

Is your feature request related to a problem? Please describe.
When we want to operate on all color values at once, we have to instantiate a new color of the same size filled with the so called value... That's painful...

Describe the bug
missing std::tolower header include <cctype>

Describe the bug

explicit Color(DataType value)
    {
        std::fill(m_data.begin(), m_data.end(), DataType(0));
    }

Well this doesn't work as expected

Is your feature request related to a problem? Please describe.
The color code handles only lvalues, except for the basic operations such as move assignment and move construction.
But when it comes to Color instantiated only in calculus... Well it is not that optimized.
Let's take a concrete example:

stbipp::Color4f col{0.0f};
col += 1.0f + stbipp::Color4f{1.0f, 2.0f, 3.0f, 4.0f} / 2.0f;

This gives us the right computation result on line 2, although the way the calculus is achieved:

1. Instantiate Color4f and initialize with parameters {1.0f, 2.0f, 3.0f, 4.0f}
2. Create a temporary Color4f that stores the result of the division by 2.0f and return it
3. Create a temporary Color4f that stores the result of the previous operation and add 1.0f to it, then return it.
4. Add the result to col.

As we can see there are 2 temporary allocation that are avoidable in steps 2 and 3.

Describe the solution you'd like
Well we can use the C++ wonderful rvalue feature, and have operator specialized when we manipulate rvalues in such operations (ref-qualified member functions):

stbipp::Color operator/(Real val) &&
{
  for(auto& val: m_data)
  {
    val /= 2.0;
  }
  return std::move(*this);
}

Et voila, no copy, no useless allocation!

Is your feature request related to a problem? Please describe.
The cmake install process goes with hardcoded variables in the StbippConfig.cmake.in...

Describe the solution you'd like
Use features such as write_basic_package_version_file or check_required_components to make things cleaner

Describe the bug
When saving an image to a non HDR format, and having channel color values greater than 1.0, the saved image looks... Let's say wrong. If you look at the result image from the example, the fractal patterns shall be using gray shades.

Expected behavior
As the title of the issue let suppose... Crop value greater than 1.0 for non hdr format

Screenshots

Is your feature request related to a problem? Please describe.
To insure that the project builds on all platforms and at any time, it is now time to implement a continuous integration that perform build operations, and later launch the tests (when implemented).

Describe the solution you'd like
A classic github action implementation will do the trick. Test on PR and add the little label in the readme (it's kinda cool imo)

Is your feature request related to a problem? Please describe.
The Color class uses a lot the SFINAE principle in maybe too verbose way

Describe the solution you'd like
Make some type traits that are meaningful to the developer such as :

template<class DataType, class ODataType>
struct is_float_to_integer_cast
{
    static const bool value = (std::is_floating_point<DataType>::value && std::is_integral<ODataType>::value) &&
                              !std::is_same<DataType, ODataType>::value;
};

Is your feature request related to a problem? Please describe.
Instead of having huge and imposing template files, let's just break it into several cute little files

Description

A document relating all the features of the library as part of the README or a separate file would be much appreciate for new comers.