Hi there, I don't see the woods because of all the trees. Could someone get the latest code from here: http://code.google.com/p/gil-contributions/source/browse/#svn/trunk and try to compile the following code: #include <boost/gil/extension/io_new/tiff_all.hpp> using namespace std; using namespace boost; using namespace gil; int main() { typedef mpl::vector< gray8_image_t , gray16_image_t , rgb8_image_t , gil::detail::gray1_image_t > my_img_types; any_image< my_img_types > runtime_image; read_image( "C:/gil_contributions/test_images/tiff/test.tif" , runtime_image , tiff_tag() ); return 0; } Why do I have this static assertion in read.hpp[662]? I don't understand why the two buffer types are different. Any help is very welcome, Christian
On 24/10/10 20:06, Christian Henning wrote:
Hi there, I don't see the woods because of all the trees. Could someone get the latest code from here:
http://code.google.com/p/gil-contributions/source/browse/#svn/trunk
and try to compile the following code:
#include <boost/gil/extension/io_new/tiff_all.hpp>
using namespace std; using namespace boost; using namespace gil;
int main() { typedef mpl::vector< gray8_image_t , gray16_image_t , rgb8_image_t , gil::detail::gray1_image_t > my_img_types;
any_image< my_img_types > runtime_image;
read_image( "C:/gil_contributions/test_images/tiff/test.tif" , runtime_image , tiff_tag() );
return 0; }
Why do I have this static assertion in read.hpp[662]? I don't understand why the two buffer types are different.
Any help is very welcome,
Christian, I'm not sure myself, but quick look suggests me there are some related or different problems too: In gil/extension/io_new/formats/tiff/is_allowed.hpp, missing template keyword around line 65 p->template read_data< row_buffer_helper_view< View > >( plane, K ); and missing qualifier around line 800 in: parent_t::init_image( images , this->_info ); In gil/extension/io_new/formats/tiff/is_allowed.hpp, around line 126 compare_channel_sizes_fn fn( &channel_sizes.front() ); does not seem to match any ctor of compare_channel_sizes_fn. There is also mismatch of unsigned short* vs unsigned int*. I will try to continue checking tomorrow. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org
Hi Mateusz, thanks for helping. I have fixed the issues you noted in your last email. The problem still remains. I'll give it another shoot again later today. Christian On 10/24/10, Mateusz Loskot <mateusz@loskot.net> wrote:
On 24/10/10 20:06, Christian Henning wrote:
Hi there, I don't see the woods because of all the trees. Could someone get the latest code from here:
http://code.google.com/p/gil-contributions/source/browse/#svn/trunk
and try to compile the following code:
#include <boost/gil/extension/io_new/tiff_all.hpp>
using namespace std; using namespace boost; using namespace gil;
int main() { typedef mpl::vector< gray8_image_t , gray16_image_t , rgb8_image_t , gil::detail::gray1_image_t > my_img_types;
any_image< my_img_types > runtime_image;
read_image( "C:/gil_contributions/test_images/tiff/test.tif" , runtime_image , tiff_tag() );
return 0; }
Why do I have this static assertion in read.hpp[662]? I don't understand why the two buffer types are different.
Any help is very welcome,
Christian,
I'm not sure myself, but quick look suggests me there are some related or different problems too:
In gil/extension/io_new/formats/tiff/is_allowed.hpp, missing template keyword around line 65
p->template read_data< row_buffer_helper_view< View > >( plane, K );
and missing qualifier around line 800 in:
parent_t::init_image( images , this->_info );
In gil/extension/io_new/formats/tiff/is_allowed.hpp, around line 126
compare_channel_sizes_fn fn( &channel_sizes.front() );
does not seem to match any ctor of compare_channel_sizes_fn.
There is also mismatch of unsigned short* vs unsigned int*.
I will try to continue checking tomorrow.
Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org
On 25/10/10 15:25, Christian Henning wrote:
Hi Mateusz, thanks for helping. I have fixed the issues you noted in your last email. The problem still remains.
I'll give it another shoot again later today.
Christian
On 10/24/10, Mateusz Loskot <mateusz@loskot.net> wrote:
[...] I will try to continue checking tomorrow.
Christian, I've been and I am busy with some other work and have no chance to dig this now. Can't help at the moment. Regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org
No problem. Will try again tomorrow. Christian On Wed, Oct 27, 2010 at 3:36 PM, Mateusz Loskot <mateusz@loskot.net> wrote:
On 25/10/10 15:25, Christian Henning wrote:
Hi Mateusz, thanks for helping. I have fixed the issues you noted in your last email. The problem still remains.
I'll give it another shoot again later today.
Christian
On 10/24/10, Mateusz Loskot <mateusz@loskot.net> wrote:
[...] I will try to continue checking tomorrow.
Christian,
I've been and I am busy with some other work and have no chance to dig this now. Can't help at the moment.
Regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org
participants (2)
-
Christian Henning -
Mateusz Loskot