boostorg / gil Goto Github PK

Boost.GIL - Generic Image Library | Requires C++14 since Boost 1.80

Home Page: https://boostorg.github.io/gil

License: Boost Software License 1.0

C++ 98.36% HTML 0.01% CMake 1.53% Shell 0.10%

boost generic-image-library gil image-processing-library image-processing raster-processing image raster cplusplus cplusplus-11

gil's Introduction

Documentation	GitHub Actions	AppVeyor	Regression	Codecov

Boost.GIL

Introduction
Documentation
Requirements
Branches
Community
Contributing
License

Introduction

Boost.GIL is a part of the Boost C++ Libraries.

The Boost Generic Image Library (GIL) is a C++14 header-only library that abstracts image representations from algorithms and allows writing code that can work on a variety of images with performance similar to hand-writing for a specific image type.

Documentation

Latest release
Branch master (latest release with minor changes)
Branch develop

See RELEASES.md for release notes.

See CONTRIBUTING.md for instructions about how to build and run tests and examples using Boost.Build or CMake.

See example/README.md for GIL usage examples.

See example/b2/README.md for Boost.Build configuration examples.

See example/cmake/README.md for CMake configuration examples.

Requirements

The Boost Generic Image Library (GIL) requires:

C++14 compiler (GCC 6, clang 3.9, MSVC++ 14.1 (1910) or any later version)
Boost header-only libraries

Optionally, in order to build and run tests and examples:

Boost.Filesystem
Boost.Test
Headers and libraries of libjpeg, libpng, libtiff, libraw for the I/O extension and some of examples.

Branches

The official repository contains the following branches:

master This holds the most recent snapshot with code that is known to be stable.
develop This holds the most recent snapshot. It may contain unstable code.

Community

There is number of communication channels to ask questions and discuss Boost.GIL issues:

GitHub Discussions
Mailing lists (Boost discussion policy)
- boost-gil (recommended) official Boost.GIL mailing list (archive)
- boost-users for all Boost users
- boost for all Boost developers
Slack at cpplang.slack.com with Boost channels:
- #boost-gil (recommended) official Boost.GIL channel
- #boost-user for all Boost users
- #boost for all Boost developers
Gitter room boostorg/gil (old real-time chat space)
You can also ask questions via GitHub issue.

Contributing (We Need Your Help!)

If you would like to contribute to Boost.GIL, help us improve the library and maintain high quality, there is number of ways to do it.

If you would like to test the library, contribute new feature or a bug fix, see the CONTRIBUTING.md where the whole development infrastructure and the contributing workflow is explained in details.

You may consider performing code reviews on active pull requests or help with solving reported issues, especially those labelled with:

Any feedback from users and developers, even simple questions about how things work or why they were done a certain way, carries value and can be used to improve the library.

License

Distributed under the Boost Software License, Version 1.0.

gil's People

Contributors

Stargazers

Watchers

Forkers

externpro uikit0 peschmae0 sanderbog danieljames gallafent apolukhin martin-osborne niklasangare limbolily ncrookston crossbuild caomw hiroki-kyoto autodesk-forks danielae xltools bazelboost kojoley nizvoo zgsxwsdxg myestro mloskot gitter-badger stefanseefeld chhenning gmoryes mike-devel buckaroo-pm sdebionne yaghya sid19991 antropovi raghuchandra123 justanotherdevel sadeepdarshana simmplecoder boostgsoc19 rh-chen miralshah365 t-deuty lpranam xjhouska renaissance69 simber macmade tomihasa vsricharan16 minasgorgi jinhang2008 very-cool-name parthsarthi1 pranaykanjolia sourabhdharpure arbitcode kriss21 ayushbansal07 codejaeger hridayraj aman-roy mrityunjay-tripathi ashishgit7 j268sing akshit-gaur mocabe abhipachorkar296 rrajivramachandran vishnuedavarath nedjimabelgacem adityasanthosh ibrahim-akrab nitimodi99 himanshusainie manav-yb abdelrahmanelsherif martin-carrasco leantk fettlehub parthsarthiprasad shotaochi ezhangle f3rm4rf3r eugene-kulak vivekyadavgithub zoq ag-piyush giomasce-throwaway gaurav-singh1998 thesstefan cepiloth pranay711 rayburrows thedhruvrawat samd2 siddhant2001 devanshsgit scramjet911 chmodawk meshtag kapilkd13

gil's Issues

How to add tests for PNG grayalpha fix in #118

@adrianbroher I've created this issue as task to address and your #118 questions:

Regarding the test cases:
I tried to run a cmake build, which failed during the linking stage of the gil_test_ext_io_tiff test
executable because of a undefined symbol boost::system::generic_category() so almost
all of the io-based test executables are missing and I can't run ctest.

You should be aware, CMake configuration is still an experimental build configuration for Boost.GIL.
The CONTRIBUTING.md tries to explain all necessary steps, but some may be missing. I will look into your issues.

Meanwhile, you may want to try b2 which is the Boost official build system.

Also could someone give me advise about writing a test a proper test for the linked issue?
I used Boost Test a few times, but the existing io tests don't seem to assert anything about
correctly loading an image and I can't think of any proper test assertions, maybe sampling
some pixel for the expected values?

I'd try to add a simple test case similar to this one, accompanied with a small test .png file:

gil/io/test/png_read_test.cpp

Lines 93 to 116 in ed67f9a

 BOOST_AUTO_TEST_CASE( read_header_test ) 

 { 

 typedef get_reader_backend< const std::string 

 , tag_t 

 >::type backend_t; 

 backend_t backend = read_image_info( png_filename 

 , tag_t() 

 ); 

 BOOST_CHECK_EQUAL( backend._info._width , 1000u ); 

 BOOST_CHECK_EQUAL( backend._info._height, 600u ); 

 BOOST_CHECK_EQUAL( backend._info._num_channels, 4 ); 

 BOOST_CHECK_EQUAL( backend._info._bit_depth , 8 ); 

 BOOST_CHECK_EQUAL( backend._info._color_type , PNG_COLOR_TYPE_RGBA ); 

 BOOST_CHECK_EQUAL( backend._info._interlace_method , PNG_INTERLACE_NONE ); 

 BOOST_CHECK_EQUAL( backend._info._compression_method, PNG_COMPRESSION_TYPE_BASE ); 

 BOOST_CHECK_EQUAL( backend._info._filter_method , PNG_FILTER_TYPE_BASE ); 

 BOOST_CHECK_EQUAL( backend._info._file_gamma, 1 ); 

 }

Is this helpful?

Document status of CMake configuration

In the docs or README

Explain status of CMake configuration as unofficial, complementary, unsupported, volatile, purely for convenience
Explain how to use it to build and run tests (but, we do not teach CMake here!)

Test of channel_invert<int> failing with clang 5.x and variant=release

This issue reproduces failure of CircleCI build https://circleci.com/gh/boostorg/gil/829 with clang 5 due to failure in line 22 of this test targetting channel_invert<int>:

gil/test/channel/algorithm_channel_invert.cpp

Lines 19 to 24 in e9b2a68

 void test_channel_invert() 

 { 

 fixture::channel<ChannelFixtureBase> f; 

 BOOST_TEST(gil::channel_invert(f.min_v_) == f.max_v_); 

 BOOST_TEST(gil::channel_invert(f.max_v_) == f.min_v_); 

 }

Minimal Working Example (in C++)

#include <limits>
#include <iostream>
#include <typeinfo>

template <typename C>
inline C channel_invert(C x)
{
    return std::numeric_limits<C>::max() - x + std::numeric_limits<C>::min();
}

template <typename C>
inline C channel_invert2(C x)
{
    // alternative equivalent implementation
    return (x - std::numeric_limits<C>::max()) * (-1) + std::numeric_limits<C>::min();
}

template <typename C>
void test()
{
    std::cout << "--- C type: " << typeid(C).name() << std::endl;

    C x1{0}, x2{0};
    x1 = channel_invert(std::numeric_limits<C>::min());
    x2 = channel_invert2(std::numeric_limits<C>::min());
    std::cout << x1 << std::endl;
    std::cout << x2 << std::endl;
}

int main()
{
    test<int>();
    test<unsigned int>();
    test<short>();
    test<unsigned short>();
}

Actual behavior

clang 5 - notice the negative one for int

$ clang++ --version
clang version 5.0.0-3~16.04.1 (tags/RELEASE_500/final)
$ clang++ -std=c++11 -O2 test_channel_invert_for_int.cpp
$ ./a.out
--- C type: i
-1
-1
--- C type: j
4294967295
4294967295
--- C type: s
32767
32767
--- C type: t
65535
65535

Expected behavior

GCC 7

$ g++ --version
g++ (Ubuntu 7.3.0-16ubuntu3~16.04.1) 7.3.0
$ g++ -std=c++11 -O2 test_channel_invert_for_int.cpp
$ ./a.out
--- C type: i
2147483647
2147483647
--- C type: j
4294967295
4294967295
--- C type: s
32767
32767
--- C type: t
65535
65535

GCC 5

$ g++-5 --version
g++-5 (Ubuntu 5.5.0-12ubuntu1~16.04) 5.5.0 20171010
$ g++-5 -std=c++11 -O2 test_channel_invert_for_int.cpp
$ ./a.out
--- C type: i
2147483647
2147483647
--- C type: j
4294967295
4294967295
--- C type: s
32767
32767
--- C type: t
65535
65535

Question

For x = -2147483648, this value inverting expression

std::numeric_limits<C>::max() - x + std::numeric_limits<C>::min();

does seem to promote int to unsigned int at least due to the partial value of 2147483647 - (-2147483648) = 4294967295

Let's consider that:

The channel_invert tests are not failing for Travis CI or AppVeyor.
The CircleCI build workflow targets 18 GCC/clang versions in total, see latest workflow results at https://circleci.com/workflow-run/3a14dd64-6c38-46b2-a6da-678c0075ca27.
Only clang 5.0 is failing.

Are we experiencing a compiler bug or nasty UB? Your bets @chhenning @stefanseefeld?

References

This may be directly related to the issue #51

Replace boost::mpl::if_c with std::conditional

There are ~20 uses of boost::mpl::if_c which can be replaced with std::conditional as direct equivalent.

Dead link to video tutorial

From https://svn.boost.org/trac10/ticket/13033:

The link for 'video tutorial' on the following page does not lead to a video tutorial : http://www.boost.org/doc/libs/1_64_0/libs/gil/doc/index.html

This is supposed to lead here : http://opensource.adobe.com/gil/presentation/index.htm

However when clicked, it redirects here : https://sourceforge.net/adobe/wiki/Home/

Find pnm test images

"Unsupported descriptor for targa file"

Resized by macOS image viewer.

gresized.tga.zip

PNG IO doesn't load alpha palette for palette based PNG file

In the FreeOrion project we use boost.gil to load PNG textures for our game. Previously we patched our own support for gray-alpha PNG images into the gil library. However with merging the old development branch into master we now can finally rely on gil again.

When porting the old FreeOrion code to the new v2 IO implementation for PNG I realized that it doesn't convert PNG files with a grayscale or indexed palette and an alpha palette (tRNS chunk) to a regular RGBA image as the previous implementation did.

For example https://github.com/freeorion/freeorion/blob/master/default/data/art/icons/fleet/big-head-colony.png is a gray-alpha texture, which doesn't load properly.

Actual behavior

Expected behavior

Environment

Boost version: boostorg/gil master (c192814)

Seems like querying this->_info._num_trans > 0 is not the proper way to identify transparency information.

gil/include/boost/gil/extension/io/png/detail/read.hpp

Lines 124 to 127 in c192814

 if( this->_info._num_trans > 0 ) 

 { 

 png_set_tRNS_to_alpha( this->get_struct() ); 

 }

In the FreeOrion project the corresponding code looks like:

https://github.com/freeorion/freeorion/blob/a5eae2763800caa8dc322c8630bb9e9d975762a1/GG/src/gilext/io/png_io_private.hpp#L305-L312

Is there a way to fix this before 1.68 release? Should I create a pull request to fix this?

Document locator and cached_location_t

(moved from https://svn.boost.org/trac10/ticket/8144)

I've stumbled upon old thread on locator and cached_location_t. There are some interesting explanations which I believe is worth to add to Boost.GIL docs.

Particularly, I believe the following Lubomir's clarification should be added as first paragraph documenting cached location:

Cached location is meant to be used as a quick way to get to neighborhood pixels
if you need to read or write a neighboring location frequently relative to a given locator.

Currently, notion of cached location is documented in the GIL design guide but it makes users to deduce answer to question What the cached locator is for?

TGA

I found this code and think it maybe useful. In case you need TGA its right here:

//
// Book:      OpenGL(R) ES 2.0 Programming Guide
// Authors:   Aaftab Munshi, Dan Ginsburg, Dave Shreiner
// ISBN-10:   0321502795
// ISBN-13:   9780321502797
// Publisher: Addison-Wesley Professional
// URLs:      http://safari.informit.com/9780321563835
//            http://www.opengles-book.com
//

// esUtil_TGA.c
//
//    This file contains the Win32 implementation of a TGA image loader

#define WIN32_LEAN_AND_MEAN
#include <windows.h>
#include <stdio.h>
#include <stdlib.h>

///
//  Macros
//
#define INVERTED_BIT            (1 << 5)

///
//  Types
//
#pragma pack(push,x1)                            // Byte alignment (8-bit)
#pragma pack(1)

typedef struct
{
   unsigned char  IdSize,
                  MapType,
                  ImageType;
   unsigned short PaletteStart,
                  PaletteSize;
   unsigned char  PaletteEntryDepth;
   unsigned short X,
                  Y,
                  Width,
                  Height;
   unsigned char  ColorDepth,
                  Descriptor;
         
} TGA_HEADER;

#pragma pack(pop,x1)

////////////////////////////////////////////////////////////////////////////////////
//
//  Private Functions
//

////////////////////////////////////////////////////////////////////////////////////
//
//  Public Functions
//
//


///
//  WinTGALoad()
//
int WinTGALoad( const char *fileName, char **buffer, int *width, int *height )
{
   FILE        *fp;
   TGA_HEADER   Header;

   if ( fopen_s ( &fp, fileName, "rb" ) != 0 )
   {
      return FALSE;
   }

   if ( fp == NULL )
   {
      return FALSE;
   }

   fread ( &Header, sizeof(TGA_HEADER), 1, fp );

   *width = Header.Width;
   *height = Header.Height;
   
   if ( Header.ColorDepth == 24 )
   {
      RGBTRIPLE *Buffer24;

      Buffer24= (RGBTRIPLE*)malloc(sizeof(RGBTRIPLE) * (*width) * (*height));

      if(Buffer24)
      {
         int i=0;
         int x,
             y;

         fread(Buffer24, sizeof(RGBTRIPLE), (*width) * (*height), fp);

         *buffer= (LPSTR) malloc(3 * (*width) * (*height));

         for ( y = 0; y < *height; y++ )
            for( x = 0; x < *width; x++ )
            {
               int Index= y * (*width) + x;

               if(!(Header.Descriptor & INVERTED_BIT))
                  Index= ((*height) - 1 - y) * (*width) + x;

               (*buffer)[(i * 3)]=      Buffer24[Index].rgbtRed;
               (*buffer)[(i * 3) + 1]=  Buffer24[Index].rgbtGreen;
               (*buffer)[(i * 3) + 2]=  Buffer24[Index].rgbtBlue;
        
               i++;
            }
         
         fclose(fp);
         free(Buffer24);
         return(TRUE);
      }		
   }

   return(FALSE);
}

Move operations only relevant for test out of main CMakeLists.txt

Just a comment based on my person preference and experience:

I'd recommend moving all the compiler-flags and other machinery that are not necessary for using the library itself into the respective CMakeLists.txt files where they are actually needed.

This is more relevant, when you provide a cmake target (see #167) and/or have to compile your library, but even if not, I generally prefer to put compiler options next to the targets they are actually relevant for. E.g. Boost::unit_test_framework is afaik only needed when you want to run the unit-tests. So it imho should only be looked up when gil/test/CMakeLists.txt gets actually included (e.g. not if GIL_BUILD_TESTS == OFF). Same with things like /Wall or CMAKE_CXX_STANDARD 11.

Even if you are not defining a cmake library target (for which you should definetifely not set public warning level flags) it makes it easier for me to discover, which flags I have to set in my project when I want to use this library, vs what flags you are using in order to find bugs in the implementation.

Boost.GIL 3 ideas from the past

These ideas are old and might be obsolete.

make sure not only integral types can the base type when creating a pixel type. See packed_pixel_t
outsource io_new's bit_operations
outsource io_new's io_devices
use boost::fusion for defining pixel and color spaces. See emails
- using variadic templates will help
make use of overlapping functionality with boost::geometry, like point type registration. See Andrew Hundt's email from 2013/03/13
pixel should have a begin() and end() members.
make Alignment a template parameter for image class
make use of c++11 features, like delegating constructor
look at the cairo proposal: https://groups.google.com/a/isocpp.org/forum/#!msg/graphics/UfvaqOyQbQ4/mv0CJS2mRtYJ
reference implementation: https://github.com/mikebmcl/N3888_RefImpl
pixman
http://developers.slashdot.org/story/14/01/04/2115249/cairo-2d-graphics-may-become-part-of-iso-c

Travis CI build job DOC failing due to Sphinx 1.8.0 bug

https://travis-ci.org/boostorg/gil/jobs/430177568 is failing with

sphinx-build -b html -d _build/doctrees   . html
Running Sphinx v1.8.0
Exception occurred:
  File "/home/travis/.local/lib/python2.7/site-packages/sphinx/highlighting.py", line 26, in <module>
    from sphinx.ext import doctest
SyntaxError: unqualified exec is not allowed in function 'run' it contains a nested function with free variables (doctest.py, line 97)
The full traceback has been saved in /tmp/sphinx-err-nuw4C0.log, if you want to report the issue to the developers.
Please also report this if it was a user error, so that a better error message can be provided next time.
A bug report can be filed in the tracker at <https://github.com/sphinx-doc/sphinx/issues>. Thanks!
make: *** [html] Error 2

Sphinx bug sphinx-doc/sphinx#5417 was fixed three days ago sphinx-doc/sphinx#5443

Channel tests failing for variant=release with GCC

Following addition of variant=debug,release to Travis CI in #50, the GCC 5.4.1 build job is failing due to failing channel tests, see https://travis-ci.org/boostorg/gil/jobs/355009262

testing.capture-output bin.v2/libs/gil/test/channel.test/gcc-5.4.1/release/channel.run
====== BEGIN OUTPUT ======
std::exception
EXIT STATUS: 1
====== END OUTPUT ======

Interestingly, the same tests built with clang 4.2.1 are passing without any failures, see https://travis-ci.org/boostorg/gil/jobs/355009263

I confirmed this issue locally, on Ubuntu with GCC 5.4.0

b2 variant=debug,release cxxflags="-Wno-unused-local-typedefs" test
...
testing.capture-output ../../bin.v2/libs/gil/test/channel.test/gcc-5.4.0/debug/channel.run
**passed** ../../bin.v2/libs/gil/test/channel.test/gcc-5.4.0/debug/channel.test
...
testing.capture-output ../../bin.v2/libs/gil/test/channel.test/gcc-5.4.0/release/channel.run
====== BEGIN OUTPUT ======
std::exception

EXIT STATUS: 1
====== END OUTPUT ======

References

Yet another issue revealed by variant=release build configuration.
Previous one was the image checksum tests, see #49

Clean up UBSan integer false positives

This is #108 follow-up.

Problem

For example, variant=ubsan_integer failures like in build 375.9, may be revealing some issues regarding actual unsigned type used in conversion routines.

The following UBSan integer runtime error

channel_algorithm.hpp:344:64:
  runtime error: unsigned integer overflow:
    4294967287 + 128 cannot be represented in type 'unsigned int'

It is reported for channel_convert_to_unsigned utility

gil/include/boost/gil/channel_algorithm.hpp

Lines 339 to 346 in d882b84

 template <> struct channel_convert_to_unsigned<int8_t> { 

 typedef int8_t argument_type; 

 typedef uint8_t result_type; 

 typedef uint8_t type; 

 type operator()(int8_t val) const { 

 return static_cast<uint8_t>(static_cast<uint32_t>(val) + 128u); 

 } 

 };

For val = -9 input, the result is calculated as:

((4294967295 - 8) + 128) % 256 = 119

Obviously, changing the intermediate conversion to
static_cast<uint16_t>(val)
or
static_cast<uint64_t>(val)
yield equivalent results:

((65535 - 8) +128) % 256 = 119
((18446744073709551615 - 8) + 128) % 256 = 119

However, it may be a good idea to inspect all the ubsan_integer failures for any unexpected results.

MacOS viewer resized bmp save.

Height read -20
g.bmp.zip

Examples in develop branch use old IO extension

There examples in the current develop branch have not been ported to the new IO v2 extension, so they still include the old IO headers. For example:

dynamic_image.cpp(20):#include <boost/gil/extension/io/jpeg_dynamic_io.hpp>
interleaved_ptr.cpp(35):#include <boost/gil/extension/io/jpeg_dynamic_io.hpp>
x_gradient.cpp(18):#include <boost/gil/extension/io/jpeg_dynamic_io.hpp>

affine.cpp(25):#include <boost/gil/extension/io/jpeg_io.hpp>
convolution.cpp(25):#include <boost/gil/extension/io/jpeg_io.hpp>
histogram.cpp(23):#include <boost/gil/extension/io/jpeg_io.hpp>
mandelbrot.cpp(20):#include <boost/gil/extension/io/jpeg_io.hpp>
packed_pixel.cpp(36):#include <boost/gil/extension/io/jpeg_io.hpp>
resize.cpp(25):#include <boost/gil/extension/io/jpeg_io.hpp>

Removing dependency on Boost.StaticAssert

Problem

Currently, we use BOOST_STATIC_ASSERT. In C++11, there is static_assert.

Obvious choice to replace BOOST_STATIC_ASSERT with static_assert, but this will require tedious or artificial generation of assertion messages, since the static_assert(exp) variant is available since C++17. The BOOST_STATIC_ASSERT(x) has one nice feature - error message is a stringized version of x.

Solutions

Switch to to static_assert manually adding error messages
Define BOOST_GIL_STATIC_ASSERT in the same way as BOOST_STATIC_ASSERT with implicit message.
Do nothing and keep #include <boost/static_assert.hpp>.

Question

What shall we prefer?

/cc @chhenning, @stefanseefeld

argb_layout_t wrong layout

typedef layout<rgba_t, mpl::vector4_c<int,1,2,3,0> > argb_layout_t;
I guess it should be typedef layout<rgba_t, mpl::vector4_c<int,3,0,1,2> > argb_layout_t;
sure it does not matter if use get_color(d,alpha_t()) but frustrates everyone who use a(i,j) = px[0];

Gimp BMP load

Trying to load Gimp-saved BMP throws.
io_error( "Invalid BMP info header." );
The BMP:
gradient.bmp.zip

Source PNG:

Using latest Gimp 2 at the moment 2.8.22 for MacOS

Define CMake target Boost::gil in CMakeLists.txt

Could you please add a (interface library) cmake target for gil, that specifies the include directory and dependencies.

E.g something like:

add_library(boost_gil INTERFACE)
target_include_directories(boost_gil INTERFACE include)  
target_compile_options(boost_gil INTERFACE include ...) 
add_library(Boost::gil ALIAS boost_gil)

target_link_libraries(boost_gil INTERFACE
  Boost::filesystem
  Boost::boost
  JPEG::JPEG
  PNG::PNG
  TIFF::TIFF
)

Cmake targets depending on Boost.Gil (like your examples and test, or a user progam doing a add_subdirectory(libs/gil)) could then just use target_link_libraries( my_exec Boost::gil) and automatically get all the relevant information like include directory, transitive dependencies and any required compilation flags.

List cxx11 requirements in Jamfile

For example, mp11/test/Jamfile:

project :
  requirements [ requires cxx11_variadic_templates cxx11_template_aliases cxx11_decltype cxx11_hdr_tuple ] ;

Alternatively, as explained by @pdimov on cpplang.slack.com:

if you add cxxstd=11, they are satisfied, if you add cxxstd=03, they aren't
so if your test requires f.ex. decltype, it's run with cxxstd=11 and not run with cxxstd=03
but you can have tests that don't need decltype, which are run under cxxstd=03 as well, in principle

This will also help to skip the always failing builds in the regression waterfall ie. VS 2005, 2008, 2010, 2012, 2013:

Incorporate unsupported images from new BMP test image suite

There is a source code available in test suite.

read_image bmp 8 bit returns "Image types aren't compatible"

version: boost 1.68

It is possible to read easily a 24 bit BMP with:

rgb8_image_t  runtime_image;
read_image(filename, runtime_image, boost::gil::bmp_tag());

With 8 bit bmp (gray color) image, it fails with this message "Image types aren't compatible"
lena_gray.zip

I tried:

    typedef boost::mpl::vector<gray1_image_t, gray2_image_t, gray4_image_t, gray6_image_t,
        gray10_image_t, gray12_image_t, gray14_image_t, gray24_image_t,
        gray8_image_t, rgb8_image_t, bgr8_image_t, rgb64f_image_t, rgb64f_planar_image_t,
        rgba64f_image_t, rgba64f_planar_image_t, gray64f_image_t>
        my_img_types;
    any_image<my_img_types> runtime_image;

    read_image(filename, runtime_image, boost::gil::bmp_tag());

Please provide an easy working example
(sorry, I did not find a easy tutorial about this)

Request stlab.adobe.com/gil/ removal

The Boost.GIL documentation has been reworked, the video lecture captured (#112) and everything now lives at https://www.boost.org/libs/gil/

We should contact Lubomir or whoever is reachable at Adobe asking to remove the old and outdated GIL docs dangling at http://stlab.adobe.com/gil/. It may be doing a bad publicity job for GIL. By the way, the whole site at http://stlab.adobe.com/gil/ seems dead anyway. The Adove STLab moved to http://stlab.cc/ and there are no traces of GIL.

Perhaps we should ask @sean-parent for help with removal of the old site.

std::bind2nd is removed in c++17

It used here:

include/boost/gil/planar_pixel_iterator.hpp
include/boost/gil/extension/numeric/pixel_numeric_operations.hpp
It was deprecated in c++17. Could you use std::bind + std::placeholders instead std::bind2nd?

Thanks.

Add configuration for builds on Azure Pipelines

Current CI builds

Currently, we have CI builds configured to run minimal core and extensions tests

libs/gil/test
libs/gil/toolbox/test
libs/gil/numeric/test
libs/gil/io/test//simple

.travis.yml - Linux using GCC 5, 6, 7 and clang 3.9, 4.0
.appveyor.yml - on Windows using VS2017
.circleci/config.yml - on Linux using ~20 versions of GCC 4.8-8.2 and clang 3.9-5.0

for variant=debug,release, address-model=64 only and C++11 compilation mode only.

The three CI services are already heavily occupied.

More CI builds needed

Due to the limited resources on currently used CI services, we do not run

libs/gil/io/test//full which extensively covers the IO implementation
headers tests (self-contained, all-in-one)
linting analysis (e.g. clang-tidy, see aff86c2).

In future, we also may split the long-lived monolithic tests into smaller suites, for better coverage, clearer reports and easier maintenance. That, will likely increase compilation times. So, more resources for CI builds will be required.

Azure Pipelines

Basic steps to set the Pipelines for GIL:

Add Azure Pipelines from https://github.com/marketplace/azure-pipelines
Create azure-pipelines.yml (see Azure Pipelines YAML).
Decide

which targets/tests to build
how to build (variants, architectures)
how to configure (e.g. it would be nice to have equivalent builds for all Boost.Build, CMake, faber)
on what OS-es/images

Design the pipelines, jobs and steps accordingly.

Help wanted!

References

https://lists.boost.org/boost-gil/2018/12/0122.php

Replace assert macro with BOOST_ASSERT

This is a C++ common sense and to respect GIL user requirements and policies as well as Boost own guidelines, https://www.boost.org/development/requirements.html

Avoid C's assert macro and use Boost's BOOST_ASSERT macro (in boost/assert.hpp ) instead.
It is more configurable. Use BOOST_ASSERT in public headers and in library source code
(for separately compiled libraries). Use of C's assert macro is ok in examples and in documentation.

Building IO documentation

We do have the quickbook documentation here:

https://github.com/boostorg/gil/tree/develop/io/doc

Does someone know how to build this into html?

Create tests for premultiply patch

Integrate toolbox extension into GIL core

Some of the IO support code in boost/gil/io/ depends on the toolbox extension (i.e., includes boost/gil/extension/toolbox/*.hpp).
Break out the relevant bits from the toolbox extension and integrate them into the GIL core library itself.

for_each_pixel do not compile with lambdas

Minimal Working Example (in C++)

#include <boost/gil.hpp>

int main()
{
  using namespace boost::gil;
  for_each_pixel(gray8_view_t(), [](auto pix) { });
}

gives:

boost\gil\algorithm.hpp(768): error C2280: 'main::<lambda_3ff3948> &main::<lambda_3ff3948>::operator =(const main::<lambda_3ff3948> &)': attempting to reference a deleted function

Actual behavior

Fails to compile because from 5.1.2:

[19] The closure type associated with a lambda-expression has a deleted (8.4.3) default constructor and a deleted copy assignment operator. It has an implicitly-declared copy constructor (12.8) and may have an implicitly declared move constructor (12.8). [ Note: The copy/move constructor is implicitly defined in the same way as any other implicitly declared copy/move constructor would be implicitly defined. —end note ]

Expected behavior

Should compile fine.

Environment

Boost 1.68, tested on MSVC 2017 15.9+

Add new io test images

Add images from

http://homepages.cae.wisc.edu/~ece533/images/

and test if the resulting gil images for the same filename are equal.

Find test image for read_pixel_per_meter test

Cannot find original test image.

Refine integer conversions in unsigned_integral_max_value

As per Andrey Semashev's suggestion https://lists.boost.org/Archives/boost/2018/04/242013.php,

since we switched to C++11, it may be a good idea to

use the standard constexpr std::numeric_limits<UnsignedIntegralChannel>::max()
remove dependenc on #include <boost/integer_traits.hpp>

Comments?

[task] Port all tests to Boost.Test

Currently, there is mixture of simple C++ programs used as tests with test suites/cases based on the Boost testing facilities.

I think the library should aim for unification of the tests to:

have simpler, manageable tests organisation
make it easier for contributors to add test cas
receive detailed and usable failure reports from CI builds that pin-points problem, not just boolean answer pass/fail.

Timeline: some time after the new IO extension is released, near Boost.GIL 3 :

operator / for point2 is hard coded to operate on type double (Trac 11739)

https://svn.boost.org/trac10/ticket/11739 description:

When using boost::gil::point2, applying a division operation results in a point2.
This is undesirable.
The fix appears to be easy, change this code
template <typename T> BOOST_FORCEINLINE
point2<double> operator/(const point2<T>& p, double t)      { return t==0 ? point2<double>(0,0):point2<double>(p.x/t,p.y/t); }
to operate on T instead of double.
But, that seems overly simple so I am trying to figure out why this code was written this way in the first place.

A possibly safer alternative is to cast the result back to point2<T>, ie;
template <typename T> BOOST_FORCEINLINE
point2<double> operator/(const point2<T>& p, double t)      { return t==0 ? point2<T>(0,0):point2<T>(T(p.x/t),T(p.y/t)); }
This change makes the / operator act the same as the /= operator,
which is also hard coded to double, but because it's a member, doesn't yield a new type,
so it's probably fine (other than the fact that I asked for floats and am getting double operations).

While we're at it, I also find it weird that this code is protecting against division by zero,
but that's a different problem.

Let's discuss the proposed modification (/cc @chhenning & @stefanseefeld)

Provide base() member for adapted views or locators (Trac 2229)

Moved from https://svn.boost.org/trac10/ticket/2229 description:

I would like the result of typename View::template add_deref<fn>::type to include a member function View& base(), much like the iterator adapters currently do (and std::reverse_iterator).
Imagine I have an rgb-to-hsv converted view, and then want to convert it back to rgb. All I should have to do is call base().

The actual use case: I have a deref function that exposes a reference to the element in a gray pixel.
I also have a function that takes a view to regular types and creates an adapted view to gray pixels with that element type.

I want to be ample to write them so that: same_types(make_pixel(remove_pixel(T)), T)

Merge develop with master

Hi. Are you planning to merge develop branch with master, so all new features will be available in the official boost release?

gil/gil_all.hpp is not available any more

Some of the tests in CI stopped compiling https://travis-ci.org/apolukhin/Boost-Cookbook/jobs/447029784#L3175 because of the missing <boost/gil/gil_all.hpp> header.

Is that intended removal? What header should be used instead?

Minimal Working Example (in C++)

https://github.com/apolukhin/Boost-Cookbook/tree/second_edition/Chapter12/07_gil

Actual behavior

Does not compile

Expected behavior

Should compile and run

Environment

All relevant information like:

Boost version (see <boost/version.hpp>): trunk
Compiler version: gcc-6
Build settings:

Include CONTRIBUTING.md in documentation

The document is detailed and helpful, not only for GIL but for Boost contributors.
I think, it should become a chapter of the GIL docs, somehow, automatically.

Anyone Sphinx wizards who know how to do it?

kth_channel_view fails when used with virtual views (Trac 9020)

Moved from https://svn.boost.org/trac10/ticket/9020 description:

Given an image_view with a virtual_2d_locator that returns a planar_pixel_reference, kth_channel_view produces a kth_channel_deref_fn with an incorrect result_type which may result an invalid pointer dereference.

For example, consider a virtual_2d_locator instantiated with a dereference functor that returns a planar_pixel_reference<bits8&, rgb_t>

An image_view instantiated with such a locator will have a reference type of planar_pixel_reference<bits8&,rgb_t>. Now suppose this image_view is passed to kth_channel_view(). This results in the instantiation of a kth_channel_deref_fn with a result_type of pixel<bits8&, gray_layout_t>& however, the deref functor will initialize this result_type with a pixel<bits8,gray_layout_t>&.

detail::kth_channel_deref_fn needs to ensure the channel type of its result_type is not a reference type.

Patch:

--- image_view_factory.hpp.orig	2013-08-19 12:20:06.000000000 -0500
+++ image_view_factory.hpp	2013-08-19 13:11:49.000000000 -0500
@@ -479,7 +479,8 @@
         BOOST_STATIC_CONSTANT(bool, is_mutable=pixel_is_reference<SrcP>::value && pixel_reference_is_mutable<SrcP>::value);
     private:
         typedef typename remove_reference<SrcP>::type src_pixel_t;
-        typedef typename kth_element_type<src_pixel_t, K>::type channel_t;
+        typedef typename kth_element_type<src_pixel_t, K>::type channel_ref_t;
+        typedef typename remove_reference<channel_ref_t>::type channel_t;
         typedef typename src_pixel_t::const_reference const_ref_t;
         typedef typename pixel_reference_type<channel_t,gray_layout_t,false,is_mutable>::type ref_t;
     public:

Example program illustrating the issue:

#include <iostream>
#include <boost/gil/gil_all.hpp>
using namespace boost;
using namespace gil;

//
// Do-nothing dereference adaptor
//
template <typename View>
struct deref_fn {
    BOOST_STATIC_CONSTANT(bool, is_mutable=false);
    typedef deref_fn<typename View::const_t> const_t;
    typedef typename View::value_type value_type;
    typedef typename View::reference reference;
    typedef typename View::point_t argument_type;
    typedef reference result_type;

    deref_fn() {;}
    deref_fn(const View& v) : mView(v) { ; }
    result_type operator()(const argument_type& p) const {
        return mView(p);
    }

    View mView;
};

typedef rgb8_planar_image_t image_t;
typedef image_t::view_t view_t;
typedef deref_fn<view_t> fn_t; 
typedef virtual_2d_locator<fn_t, false> loc_t;
typedef image_view<loc_t> virt_view_t;
typedef kth_channel_view_type<0, virt_view_t>::type chan0_view_t;

int main(int argc, char **argv) {
    image_t img(4,4,rgb8_pixel_t(1,2,3),0);
    view_t v(view(img));

    fn_t fn(v);
    loc_t loc(view_t::point_t(0,0), view_t::point_t(1,1), fn);
    virt_view_t virtView(v.dimensions(), loc);

    //
    // Here detail::kth_channel_deref_fn<K,SrcP> is instantiated with
    // SrcP = 'planar_pixel_reference<bits8&, rgb_t>'. The  
    // kth_channel_deref_fn then declares its result_type (and thereby 
    // the chan0_view_t:reference) to be a
    // 'pixel<bits8&, gray_layout_t>&'
    //
    chan0_view_t chan0View(kth_channel_view<0,virt_view_t>(virtView));

    assert((is_same<chan0_view_t::reference, 
                    pixel<bits8&, gray_layout_t>& >::value));

    //
    // This will typically cause a bus error because the result_type
    // of the deref adaptor is a 'pixel<bits8&, gray_layout_t>&'
    // which gets initialized in the deref function by a 
    // 'pixel<bits8, gray_layout_t>&'
    //
    assert(chan0View(0,0) == gray8_pixel_t(1));
    return 0;
}

Compilation of extension/dynamic_image/apply_operation_base.hpp takes ages with GCC 7 or 8

The compilation of the io jpeg extension takes ages with g++ (boost 1.68.0):

Minimal Working Example (in C++)

#include <boost/gil/extension/io/jpeg.hpp>
int main() {
  return 0;
}

Actual behavior

compiles on my x86_64 linux system:

in 2 min 37 s with g++ 8.2.0 in release mode:
-O2 -DNDEBUG -Wall -Wextra -Wnon-virtual-dtor -Werror=delete-non-virtual-dtor -pipe -march=native -std=c++14 -DBOOST_DISABLE_ASSERTS
in 2 min 37 s with g++ 8.2.0 in debug mode:
-g3 -Wall -Wextra -Wnon-virtual-dtor -Werror=delete-non-virtual-dtor -pipe -march=native -std=c++14

But it is very fast with clang 5.0.2

in 5 s with clang 5.0.2 in release mode:
-O2 -DNDEBUG -Wall -Wextra -Wnon-virtual-dtor -Werror=delete-non-virtual-dtor -pipe -march=native -std=c++14 -DBOOST_DISABLE_ASSERTS
in 5 s with clang 5.0.2 in debug mode:
-g3 -Wall -Wextra -Wnon-virtual-dtor -Werror=delete-non-virtual-dtor -pipe -march=native -std=c++14

-ftime-report gives the following time breakdown:

Time variable                                   usr           sys          wall               GGC
 phase setup                        :   0.01 (  0%)   0.00 (  0%)   0.01 (  0%)    1646 kB (  0%)
 phase parsing                      : 154.97 (100%)   2.28 ( 99%) 157.74 (100%)  412923 kB ( 98%)
 phase lang. deferred               :   0.06 (  0%)   0.01 (  0%)   0.07 (  0%)    6184 kB (  1%)
 phase opt and generate             :   0.01 (  0%)   0.01 (  0%)   0.01 (  0%)     561 kB (  0%)
 |name lookup                       :   0.47 (  0%)   0.13 (  6%)   0.69 (  0%)   13160 kB (  3%)
 |overload resolution               :   0.06 (  0%)   0.01 (  0%)   0.11 (  0%)    7204 kB (  2%)
 garbage collection                 :   0.08 (  0%)   0.00 (  0%)   0.08 (  0%)       0 kB (  0%)
 callgraph construction             :   0.01 (  0%)   0.01 (  0%)   0.00 (  0%)     484 kB (  0%)
 preprocessing                      :   1.07 (  1%)   0.65 ( 28%)   1.89 (  1%)  190652 kB ( 45%)
 parser (global)                    :   0.55 (  0%)   0.50 ( 22%)   0.90 (  1%)   91965 kB ( 22%)
 parser struct body                 :   0.34 (  0%)   0.05 (  2%)   0.40 (  0%)   36645 kB (  9%)
 parser function body               :   0.08 (  0%)   0.03 (  1%)   0.12 (  0%)    3138 kB (  1%)
 parser inl. func. body             :   0.05 (  0%)   0.02 (  1%)   0.05 (  0%)    3248 kB (  1%)
 parser inl. meth. body             :   1.39 (  1%)   0.10 (  4%)   1.49 (  1%)   55566 kB ( 13%)
 template instantiation             : 151.46 ( 98%)   0.93 ( 40%) 152.87 ( 97%)   37564 kB (  9%)
 constant expression evaluation     :   0.01 (  0%)   0.01 (  0%)   0.01 (  0%)     134 kB (  0%)
 tree PTA                           :   0.00 (  0%)   0.00 (  0%)   0.01 (  0%)       0 kB (  0%)
 TOTAL                              : 155.05          2.30        157.83         421325 kB

So it is mostly template instantiation although nothing is instantiated.

Expected behavior

I would hope that such file compile within a few seconds.

Environment

Fedora 27 x86_64 linux

All relevant information like:

Boost version (see <boost/version.hpp>): 1.68.0

Is there anything that can be done to improve the compile time with g++?

Remove GIL_VERSION

Since 200eecb we now use version.hpp, so this GIL_VERSION macro should be removed from

gil/include/boost/gil/gil_config.hpp

Line 26 in 04bc0ea

#define GIL_VERSION "2.1.2"

Conflicting definitions in io/dynamic_io_new.hpp and extension/toolbox/dynamic_images.hpp

Including the two headers in single TU prevents compilation due to redefinitions of

any_image_channel_t
any_image_color_space_t
any_image_pixel_t

and possibly more.

Minimal Working Example (in C++)

#include <boost/gil/io/dynamic_io_new.hpp>
#include <boost/gil/extension/toolbox/dynamic_images.hpp>
int main() { return 0; }

Actual behavior

$ g++ -std=c++11 -I/mnt/d/boost.wsl test.cpp
In file included from test.cpp:2:0:
/mnt/d/boost.wsl/boost/gil/extension/toolbox/dynamic_images.hpp:19:8: error: redefinition of ‘struct boost::gil::any_image_pixel_t’
 struct any_image_pixel_t       {};
        ^
In file included from test.cpp:1:0:
/mnt/d/boost.wsl/boost/gil/io/dynamic_io_new.hpp:21:8: error: previous definition of ‘struct boost::gil::any_image_pixel_t’
 struct any_image_pixel_t       {};
        ^
In file included from test.cpp:2:0:
/mnt/d/boost.wsl/boost/gil/extension/toolbox/dynamic_images.hpp:20:8: error: redefinition of ‘struct boost::gil::any_image_channel_t’
 struct any_image_channel_t     {};
        ^
In file included from test.cpp:1:0:
/mnt/d/boost.wsl/boost/gil/io/dynamic_io_new.hpp:22:8: error: previous definition of ‘struct boost::gil::any_image_channel_t’
 struct any_image_channel_t     {};
        ^
In file included from test.cpp:2:0:
/mnt/d/boost.wsl/boost/gil/extension/toolbox/dynamic_images.hpp:21:8: error: redefinition of ‘struct boost::gil::any_image_color_space_t’
 struct any_image_color_space_t {};
        ^
In file included from test.cpp:1:0:
/mnt/d/boost.wsl/boost/gil/io/dynamic_io_new.hpp:23:8: error: previous definition of ‘struct boost::gil::any_image_color_space_t’
 struct any_image_color_space_t {};
        ^
In file included from test.cpp:2:0:
/mnt/d/boost.wsl/boost/gil/extension/toolbox/dynamic_images.hpp:26:8: error: redefinition of ‘struct boost::gil::detail::construct_matched_t<N>’
 struct construct_matched_t {
        ^
In file included from test.cpp:1:0:
/mnt/d/boost.wsl/boost/gil/io/dynamic_io_new.hpp:28:8: error: previous definition of ‘struct boost::gil::detail::construct_matched_t<N>’
 struct construct_matched_t {
        ^
In file included from test.cpp:2:0:
/mnt/d/boost.wsl/boost/gil/extension/toolbox/dynamic_images.hpp:37:8: error: redefinition of ‘struct boost::gil::detail::construct_matched_t<0l>’
 struct construct_matched_t<0> {
        ^
In file included from test.cpp:1:0:
/mnt/d/boost.wsl/boost/gil/io/dynamic_io_new.hpp:39:8: error: previous definition of ‘struct boost::gil::detail::construct_matched_t<0l>’
 struct construct_matched_t<0> {
        ^
In file included from test.cpp:2:0:
/mnt/d/boost.wsl/boost/gil/extension/toolbox/dynamic_images.hpp:46:7: error: redefinition of ‘class boost::gil::detail::dynamic_io_fnobj<IsSupported, OpClass>’
 class dynamic_io_fnobj {
       ^
In file included from test.cpp:1:0:
/mnt/d/boost.wsl/boost/gil/io/dynamic_io_new.hpp:48:7: error: previous definition of ‘class boost::gil::detail::dynamic_io_fnobj<IsSupported, OpClass>’
 class dynamic_io_fnobj {
       ^
In file included from test.cpp:2:0:
/mnt/d/boost.wsl/boost/gil/extension/toolbox/dynamic_images.hpp:100:13: error: redefinition of ‘template<class Images, class Pred> bool boost::gil::construct_matched(boost::gil::any_image<Types>&, Pred)’
 inline bool construct_matched(any_image<Images>& im,Pred pred) {
             ^
In file included from test.cpp:1:0:
/mnt/d/boost.wsl/boost/gil/io/dynamic_io_new.hpp:99:13: note: ‘template<class Images, class Pred> bool boost::gil::construct_matched(boost::gil::any_image<Types>&, Pred)’ previously declared here
 inline bool construct_matched(any_image<Images>& im,Pred pred) {
             ^

Expected behavior

Successful compilation.

Rename io/dynamic_io_new.hpp to io/dynamic.hpp

(/cc @stefanseefeld @chhenning)

@sdebionne suggested in #185 (comment)

should io/dynamic_io_new.hpp be io/dynamic_io.hpp really?

I think it is a valid suggestion since the current name is unnecessarily complex, may be confusing:

new is obscure: as in new implementation or as in new-allocated dynamic memory, etc.
io is redundant, since all core IO headers live in dedicated directory

I'd expect renaming it is safe from compatibility point, majority of the file is boost:gil::detail namespace and just this one lives outside

gil/include/boost/gil/io/dynamic_io_new.hpp

Lines 91 to 96 in 2250b71

 /// \brief Within the any_image, constructs an image with the given dimensions 

 /// and a type that satisfies the given predicate 

 template <typename Images,typename Pred> 

 inline bool construct_matched(any_image<Images>& im,Pred pred) { 

 return detail::construct_matched_t<mpl::size<Images>::value>::apply(im,pred); 

 }

but possibly it should live in the detail as well.

Comments?

error: memunit_step was not declared in this scope

(follow-up to #173 (comment))

Actual behavior

Compile tests and examples with with -DBOOST_GIL_USE_CONCEPT_CHECK=1. For example, add the define to the GIL's top-level Jamfile:

project boost-gil
    :
    requirements
        <define>BOOST_GIL_USE_CONCEPT_CHECK
...

Run b2 -d 2 to confirm the define is included in the compiler command line:

Observer numerous compiler errors:

boost/gil/concepts/pixel_iterator.hpp:87:41: error: ‘memunit_step’ was not declared in this scope
boost/gil/concepts/pixel_iterator.hpp:90:30: error: ‘memunit_advanced’ was not declared in this scope
...

None of the memunit_* functions have ever been (forward) declared in any way, for example:

https://github.com/boostorg/gil/blob/boost-1.35.0/include/boost/gil/gil_concept.hpp
https://github.com/boostorg/gil/blob/boost-1.60.0/include/boost/gil/gil_concept.hpp
https://github.com/boostorg/gil/blob/boost-1.65.0/include/boost/gil/gil_concept.hpp

Expected behavior

No compilation error.

Environment

All relevant information like:

Boost version (see <boost/version.hpp>): from 1.35 until 1.69
Compiler version: GCC 5.5.0 but any C++11 compiler should fail

Image checksum tests failing for variant=release and x64 arch

Adding b2 variant=release build jobs to AppVeyor in #46 which revealed that test/image.cpp is failing on optimised x64 only builds:

Checksum error in bgr121_basic_red_x (crc=2009802095 != 2137924839)

Here is the build https://ci.appveyor.com/project/stefanseefeld/gil/build/1.0.182-develop

This issue does not occur on Travis using GCC 5.4.1 and clang 4.2.1.
I also was not able to reproduce it locally, on Ubuntu with GCC 5.4.0.

Failing checksum test cases

Modifying test/image.cpp to skip cases with missing CRC-s:

 // Create a checksum for the given view and compare it with the reference checksum. Throw exception if different
 void checksum_image_test::check_view_impl(const rgb8c_view_t& img_view, const string& name) {
+    if (_crc_map[name] == 0)
+    {
+        cerr << "no checksum, skipping " << name << endl;
+        return;
+    }
+
     boost::crc_32_type checksum_acumulator;
     checksum_acumulator.process_bytes(img_view.row_begin(0),img_view.size()*3);

allowed to iterate over the test cases in test/gil_reference_checksums.txt (remove failing entry, run the test, repeat until all remaining cases pass) and identify the failing ones:

bgr121_basic_red_x 7f6e24e7
bgr121_basic_white_x e4aaa1d3
bgr121_views_90cw 8565efd8
bgr121_views_flipped_ud 8f7f7d00

warning: unused parameter

Minimal Working Example (in C++)

When I compile this small program

#include <boost/gil/extension/io/jpeg.hpp>
int main() {
  return 0;
}

with clang 5.0.2 on linux x86_64
clang++ -o gil.o -c -O2 -Wall -Wextra -std=c++14 -I/softs/lin64-clang-5.0.2/release/boost/include gil.cpp

Actual behavior

I get the following warnings:

In file included from gil.cpp:1:
In file included from /softs/lin64-clang-5.0.2/release/boost/include/boost/gil/extension/io/jpeg.hpp:22:
In file included from /softs/lin64-clang-5.0.2/release/boost/include/boost/gil/extension/io/jpeg/read.hpp:24:
In file included from /softs/lin64-clang-5.0.2/release/boost/include/boost/gil/extension/io/jpeg/tags.hpp:45:
In file included from /softs/lin64-clang-5.0.2/release/boost/include/boost/gil/io/base.hpp:34:
In file included from /softs/lin64-clang-5.0.2/release/boost/include/boost/gil/extension/toolbox/toolbox.hpp:24:
In file included from /softs/lin64-clang-5.0.2/release/boost/include/boost/gil/extension/toolbox/image_types.hpp:22:
/softs/lin64-clang-5.0.2/release/boost/include/boost/gil/extension/toolbox/image_types/indexed_image.hpp:190:5: warning: 'const' type qualifier on return type has no effect [-Wignored-qualifiers]
    const std::size_t num_colors() const { return _num_colors; }
    ^~~~~~
In file included from gil.cpp:1:
In file included from /softs/lin64-clang-5.0.2/release/boost/include/boost/gil/extension/io/jpeg.hpp:22:
In file included from /softs/lin64-clang-5.0.2/release/boost/include/boost/gil/extension/io/jpeg/read.hpp:24:
In file included from /softs/lin64-clang-5.0.2/release/boost/include/boost/gil/extension/io/jpeg/tags.hpp:45:
In file included from /softs/lin64-clang-5.0.2/release/boost/include/boost/gil/io/base.hpp:34:
In file included from /softs/lin64-clang-5.0.2/release/boost/include/boost/gil/extension/toolbox/toolbox.hpp:25:
In file included from /softs/lin64-clang-5.0.2/release/boost/include/boost/gil/extension/toolbox/metafunctions.hpp:22:
In file included from /softs/lin64-clang-5.0.2/release/boost/include/boost/gil/extension/toolbox/metafunctions/channel_type.hpp:29:
In file included from /softs/lin64-clang-5.0.2/release/boost/include/boost/gil/extension/toolbox/dynamic_images.hpp:27:
In file included from /softs/lin64-clang-5.0.2/release/boost/include/boost/gil/extension/dynamic_image/dynamic_image_all.hpp:26:
In file included from /softs/lin64-clang-5.0.2/release/boost/include/boost/gil/extension/dynamic_image/algorithm.hpp:16:
In file included from /softs/lin64-clang-5.0.2/release/boost/include/boost/gil/extension/dynamic_image/any_image.hpp:24:
/softs/lin64-clang-5.0.2/release/boost/include/boost/gil/extension/dynamic_image/any_image_view.hpp:41:63: warning: unused parameter 'v' [-Wunused-parameter]
        template <typename T> result_type operator()(const T& v) const { return num_channels<T>::value; }
                                                              ^
In file included from gil.cpp:1:
In file included from /softs/lin64-clang-5.0.2/release/boost/include/boost/gil/extension/io/jpeg.hpp:22:
In file included from /softs/lin64-clang-5.0.2/release/boost/include/boost/gil/extension/io/jpeg/read.hpp:24:
In file included from /softs/lin64-clang-5.0.2/release/boost/include/boost/gil/extension/io/jpeg/tags.hpp:45:
In file included from /softs/lin64-clang-5.0.2/release/boost/include/boost/gil/io/base.hpp:34:
In file included from /softs/lin64-clang-5.0.2/release/boost/include/boost/gil/extension/toolbox/toolbox.hpp:25:
In file included from /softs/lin64-clang-5.0.2/release/boost/include/boost/gil/extension/toolbox/metafunctions.hpp:22:
In file included from /softs/lin64-clang-5.0.2/release/boost/include/boost/gil/extension/toolbox/metafunctions/channel_type.hpp:29:
In file included from /softs/lin64-clang-5.0.2/release/boost/include/boost/gil/extension/toolbox/dynamic_images.hpp:27:
In file included from /softs/lin64-clang-5.0.2/release/boost/include/boost/gil/extension/dynamic_image/dynamic_image_all.hpp:26:
/softs/lin64-clang-5.0.2/release/boost/include/boost/gil/extension/dynamic_image/algorithm.hpp:147:70: warning: unused parameter 'src' [-Wunused-parameter]
    template <typename V, typename Value> static void apply(const V& src, const Value& val) { throw std::bad_cast();}
                                                                     ^
/softs/lin64-clang-5.0.2/release/boost/include/boost/gil/extension/dynamic_image/algorithm.hpp:147:88: warning: unused parameter 'val' [-Wunused-parameter]
    template <typename V, typename Value> static void apply(const V& src, const Value& val) { throw std::bad_cast();}
                                                                                       ^
In file included from gil.cpp:1:
In file included from /softs/lin64-clang-5.0.2/release/boost/include/boost/gil/extension/io/jpeg.hpp:22:
In file included from /softs/lin64-clang-5.0.2/release/boost/include/boost/gil/extension/io/jpeg/read.hpp:24:
In file included from /softs/lin64-clang-5.0.2/release/boost/include/boost/gil/extension/io/jpeg/tags.hpp:45:
In file included from /softs/lin64-clang-5.0.2/release/boost/include/boost/gil/io/base.hpp:34:
In file included from /softs/lin64-clang-5.0.2/release/boost/include/boost/gil/extension/toolbox/toolbox.hpp:25:
In file included from /softs/lin64-clang-5.0.2/release/boost/include/boost/gil/extension/toolbox/metafunctions.hpp:22:
In file included from /softs/lin64-clang-5.0.2/release/boost/include/boost/gil/extension/toolbox/metafunctions/channel_type.hpp:29:
In file included from /softs/lin64-clang-5.0.2/release/boost/include/boost/gil/extension/toolbox/dynamic_images.hpp:27:
In file included from /softs/lin64-clang-5.0.2/release/boost/include/boost/gil/extension/dynamic_image/dynamic_image_all.hpp:30:
/softs/lin64-clang-5.0.2/release/boost/include/boost/gil/extension/dynamic_image/image_view_factory.hpp:178:140: warning: unused parameter 'cc' [-Wunused-parameter]
typename color_converted_view_type<any_image_view<ViewTypes>, DstP, CC>::type color_converted_view(const any_image_view<ViewTypes>& src,CC cc) { 
                                                                                                                                           ^
/softs/lin64-clang-5.0.2/release/boost/include/boost/gil/extension/dynamic_image/image_view_factory.hpp:201:144: warning: unused parameter 'cc' [-Wunused-parameter]
typename color_converted_view_type<any_image_view<ViewTypes>, DstP, CC>::type any_color_converted_view(const any_image_view<ViewTypes>& src,CC cc) { 
                                                                                                                                               ^
In file included from gil.cpp:1:
In file included from /softs/lin64-clang-5.0.2/release/boost/include/boost/gil/extension/io/jpeg.hpp:22:
In file included from /softs/lin64-clang-5.0.2/release/boost/include/boost/gil/extension/io/jpeg/read.hpp:26:
In file included from /softs/lin64-clang-5.0.2/release/boost/include/boost/gil/extension/io/jpeg/detail/read.hpp:29:
/softs/lin64-clang-5.0.2/release/boost/include/boost/gil/io/device.hpp:446:31: warning: unused parameter 'data' [-Wunused-parameter]
    void write( const byte_t* data
                              ^
/softs/lin64-clang-5.0.2/release/boost/include/boost/gil/io/device.hpp:447:31: warning: unused parameter 'count' [-Wunused-parameter]
              , std::size_t   count )
                              ^
/softs/lin64-clang-5.0.2/release/boost/include/boost/gil/io/device.hpp:471:35: warning: unused parameter 'data' [-Wunused-parameter]
    std::size_t read( byte_t*     data
                                  ^
/softs/lin64-clang-5.0.2/release/boost/include/boost/gil/io/device.hpp:472:35: warning: unused parameter 'count' [-Wunused-parameter]
                    , std::size_t count )
                                  ^
10 warnings generated.

Expected behavior

no warnings.

Environment

All relevant information like:

Boost version (see <boost/version.hpp>): 1.68.0 beta1
Compiler version: clang++ 5.0.2
Build settings: -O2 -Wall -Wextra -std=c++14

static_size is not a member of boost::gil::kernel_1d_fixed

/cc @chhenning, @stefanseefeld

Apart from required I/O updates, convolution.cpp example does not compile:

convolution.cpp:74:85:   required from here                                                                                                 
../../../boost/gil/extension/numeric/convolve.hpp:187:43:
  error: ‘static_size’ is not a member of ‘boost::gil::kernel_1d_fixed<float, 9ul>’ 
     detail::correlate_rows_imp<PixelAccum>(src,ker,dst,option,detail::correlator_k<Kernel::static_size,PixelAccum>());

The Numeric extension uses Kernel::static_size which seems indeed not defined anywhere:

gil/include/boost/gil/extension/numeric/convolve.hpp

Lines 183 to 188 in 18d5ecb

 template <typename PixelAccum,typename SrcView,typename Kernel,typename DstView> 

 BOOST_FORCEINLINE 

 void correlate_rows_fixed(const SrcView& src, const Kernel& ker, const DstView& dst, 

 convolve_boundary_option option=convolve_option_extend_zero) { 

 detail::correlate_rows_imp<PixelAccum>(src,ker,dst,option,detail::correlator_k<Kernel::static_size,PixelAccum>()); 

 }

Who knows where did the static_size used to come from?

	BOOST_AUTO_TEST_CASE( read_header_test )
	{
	typedef get_reader_backend< const std::string
	, tag_t
	>::type backend_t;

	backend_t backend = read_image_info( png_filename
	, tag_t()
	);

	BOOST_CHECK_EQUAL( backend._info._width , 1000u );
	BOOST_CHECK_EQUAL( backend._info._height, 600u );

	BOOST_CHECK_EQUAL( backend._info._num_channels, 4 );
	BOOST_CHECK_EQUAL( backend._info._bit_depth , 8 );
	BOOST_CHECK_EQUAL( backend._info._color_type , PNG_COLOR_TYPE_RGBA );

	BOOST_CHECK_EQUAL( backend._info._interlace_method , PNG_INTERLACE_NONE );
	BOOST_CHECK_EQUAL( backend._info._compression_method, PNG_COMPRESSION_TYPE_BASE );
	BOOST_CHECK_EQUAL( backend._info._filter_method , PNG_FILTER_TYPE_BASE );


	BOOST_CHECK_EQUAL( backend._info._file_gamma, 1 );
	}

	void test_channel_invert()
	{
	fixture::channel<ChannelFixtureBase> f;
	BOOST_TEST(gil::channel_invert(f.min_v_) == f.max_v_);
	BOOST_TEST(gil::channel_invert(f.max_v_) == f.min_v_);
	}

	if( this->_info._num_trans > 0 )
	{
	png_set_tRNS_to_alpha( this->get_struct() );
	}

	template <> struct channel_convert_to_unsigned<int8_t> {
	typedef int8_t argument_type;
	typedef uint8_t result_type;
	typedef uint8_t type;
	type operator()(int8_t val) const {
	return static_cast<uint8_t>(static_cast<uint32_t>(val) + 128u);
	}
	};

	/// \brief Within the any_image, constructs an image with the given dimensions
	/// and a type that satisfies the given predicate
	template <typename Images,typename Pred>
	inline bool construct_matched(any_image<Images>& im,Pred pred) {
	return detail::construct_matched_t<mpl::size<Images>::value>::apply(im,pred);
	}

	template <typename PixelAccum,typename SrcView,typename Kernel,typename DstView>
	BOOST_FORCEINLINE
	void correlate_rows_fixed(const SrcView& src, const Kernel& ker, const DstView& dst,
	convolve_boundary_option option=convolve_option_extend_zero) {
	detail::correlate_rows_imp<PixelAccum>(src,ker,dst,option,detail::correlator_k<Kernel::static_size,PixelAccum>());
	}

boostorg / gil Goto Github PK

gil's Introduction

Boost.GIL

Introduction

Documentation

Requirements

Branches

Community

Contributing (We Need Your Help!)

License

gil's People

Contributors

Stargazers

Watchers

Forkers

gil's Issues

Minimal Working Example (in C++)

Actual behavior

Expected behavior

Question

References

Actual behavior

Expected behavior

Environment

References

Problem

Problem

Solutions

Question

Current CI builds

More CI builds needed

Azure Pipelines

References

Minimal Working Example (in C++)

Actual behavior

Expected behavior

Environment

Minimal Working Example (in C++)

Actual behavior

Expected behavior

Environment

Minimal Working Example (in C++)

Actual behavior

Expected behavior

Environment

Minimal Working Example (in C++)

Actual behavior

Expected behavior

Actual behavior

Expected behavior

Environment

Failing checksum test cases

Minimal Working Example (in C++)

Actual behavior

Expected behavior

Environment

References

Recommend Projects

Recommend Topics

Recommend Org