Re: [boost] [gil] What is the status of the Gil extension numeric?
2013/2/21 Krzysztof Czainski <1czajnik@gmail.com>
Hello,
During my first steps wit Boost.Gil I bumped onto an example [1], that uses the numeric extension. For this extension, the the example [1] and a ling from Boost.Gil docs [4] point to [2], where I couldn't find any Gil extensions to download. Most Google links pointed to the same page, but I finally found [3].
So my questions are: a) Is there a plan to add the extension numeric to Boost? b) Is [3] the newest version? And could the Boost.Gil docs be updated to point to the right place? c) I corrected a few bugs in boost/gil/extension/numeric/sampler.hpp -- is this list the right place to discuss modifications to the numeric extension?
Regards, Kris
[1] http://www.boost.org/doc/libs/1_53_0/libs/gil/example/resize.cpp [2] http://opensource.adobe.com/gil [3] http://code.google.com/p/gil-contributions/ [4] http://www.boost.org/doc/libs/1_53_0/libs/gil/doc/index.html
Hello, Any word about above questions? Regards, Kris
I've been using gil for about 2 years now, and it appears the only development being done on the library itself is being done by Christian Henning in the io_library and some of the extensions he has created, in addition to some minor fixes. I think his latest is at: https://code.google.com/p/gil-contributions/ As far as I can tell Adobe has completely dropped support for the library aside from continuing to host the pages as they were when they were last updated around 2007-2008. If someone else knows otherwise I would also like to hear about it. Cheers! Andrew Hundt On Wed, Mar 13, 2013 at 4:31 PM, Krzysztof Czainski <1czajnik@gmail.com>wrote:
2013/2/21 Krzysztof Czainski <1czajnik@gmail.com>
Hello,
During my first steps wit Boost.Gil I bumped onto an example [1], that uses the numeric extension. For this extension, the the example [1] and a ling from Boost.Gil docs [4] point to [2], where I couldn't find any Gil extensions to download. Most Google links pointed to the same page, but I finally found [3].
So my questions are: a) Is there a plan to add the extension numeric to Boost? b) Is [3] the newest version? And could the Boost.Gil docs be updated to point to the right place? c) I corrected a few bugs in boost/gil/extension/numeric/sampler.hpp -- is this list the right place to discuss modifications to the numeric extension?
Regards, Kris
[1] http://www.boost.org/doc/libs/1_53_0/libs/gil/example/resize.cpp [2] http://opensource.adobe.com/gil [3] http://code.google.com/p/gil-contributions/ [4] http://www.boost.org/doc/libs/1_53_0/libs/gil/doc/index.html
Hello,
Any word about above questions?
Regards, Kris
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Wed, Mar 13, 2013 at 4:53 PM, Andrew Hundt <athundt@gmail.com> wrote:
I've been using gil for about 2 years now, and it appears the only development being done on the library itself is being done by Christian Henning in the io_library and some of the extensions he has created, in addition to some minor fixes. I think his latest is at: https://code.google.com/p/gil-contributions/
The latest is on the boost trunk. The new io extension will be released either with 1.53 or 1.54. I have been travelling and I might have missed the deadline to include gil::io into the release branch. Need to check with the release team.
As far as I can tell Adobe has completely dropped support for the library aside from continuing to host the pages as they were when they were last updated around 2007-2008.
If someone else knows otherwise I would also like to hear about it.
I accordance with the original creators we have decided that I'm the official maintainer. Regards, Christian
On Wed, Mar 13, 2013 at 4:59 PM, Christian Henning <chhenning@gmail.com>wrote:
On Wed, Mar 13, 2013 at 4:53 PM, Andrew Hundt <athundt@gmail.com> wrote:
I've been using gil for about 2 years now, and it appears the only development being done on the library itself is being done by Christian Henning in the io_library and some of the extensions he has created, in addition to some minor fixes. I think his latest is at: https://code.google.com/p/gil-contributions/
The latest is on the boost trunk. The new io extension will be released either with 1.53 or 1.54. I have been travelling and I might have missed the deadline to include gil::io into the release branch. Need to check with the release team.
Apologies for my fast and loose wording. I meant to refer to extensions rather than gil itself. Where would be the best place to get things like the opencv extensions that are not in trunk?
As far as I can tell Adobe has completely dropped support for the library aside from continuing to host the pages as they were when they were last updated around 2007-2008.
If someone else knows otherwise I would also like to hear about it.
I accordance with the original creators we have decided that I'm the official maintainer.
Great! I'm very glad it is being maintained now. Cheers! Andrew Hundt
Apologies for my fast and loose wording. I meant to refer to extensions rather than gil itself. Where would be the best place to get things like the opencv extensions that are not in trunk?
That would be at https://code.google.com/p/gil-contributions/ . Although, I should state that everything on this website is work in progress and not an official gil extension. As usual, every comment or feedback is very welcome. Regards, Christian
2013/3/13 Christian Henning <chhenning@gmail.com>
On Wed, Mar 13, 2013 at 4:53 PM, Andrew Hundt <athundt@gmail.com> wrote:
I've been using gil for about 2 years now, and it appears the only development being done on the library itself is being done by Christian Henning in the io_library and some of the extensions he has created, in addition to some minor fixes. I think his latest is at: https://code.google.com/p/gil-contributions/
The latest is on the boost trunk.
Christian, you mean the io extension, do you? I don't see numeric in trunk.
The new io extension will be released either with 1.53 or 1.54. I have been travelling and I might have missed the deadline to include gil::io into the release branch. Need to check with the release team.
I accordance with the original creators we have decided that I'm the official maintainer.
I also have some comments about point2 from gil/utilities.hpp: {{{ template <typename T> class point2 { public: [...] //--- these 3 functions don't add anything, do they? why not remove them rely on defaults? point2(const point2& p) : x(p.x), y(p.y) {} ~point2() {} point2& operator=(const point2& p) { x=p.x; y=p.y; return *this; } [...] point2& operator/=(double t) { x/=t; y/=t; return *this; } T x,y; [...] }; [...] template <typename T> GIL_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); } /// \ingroup PointModel template <typename T> GIL_FORCEINLINE point2<T> operator*(const point2<T>& p, std::ptrdiff_t t) { return point2<T>(p.x*t,p.y*t); } /// \ingroup PointModel template <typename T> GIL_FORCEINLINE point2<T> operator*(std::ptrdiff_t t, const point2<T>& p) { return point2<T>(p.x*t,p.y*t); } }}} So point2 has miltiplication by ptrdiff_t, and division by double. This was very confusing for me - that multiplying point2<double> by 0.5 gave me point2(0,0). But this probably is as it is for a reason, so I'm not sure if my idea for fixing this is the right way to go: I'd just add * and / for point2<T> and T, and add multiplication by double. I'd be happy to try to implement this change with some tests, if you think it's the right way to go ;-) Cheers, Kris
Hi Kris,
Christian, you mean the io extension, do you? I don't see numeric in trunk.
I have yet to add it. Probably this weekend.
I also have some comments about point2 from gil/utilities.hpp:
{{{ template <typename T> class point2 { public: [...] //--- these 3 functions don't add anything, do they? why not remove them rely on defaults? point2(const point2& p) : x(p.x), y(p.y) {} ~point2() {} point2& operator=(const point2& p) { x=p.x; y=p.y; return *this; }
You mean that these functions are usually generated by the compiler?
[...] point2& operator/=(double t) { x/=t; y/=t; return *this; } T x,y; [...] };
[...] template <typename T> GIL_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); } /// \ingroup PointModel template <typename T> GIL_FORCEINLINE point2<T> operator*(const point2<T>& p, std::ptrdiff_t t) { return point2<T>(p.x*t,p.y*t); } /// \ingroup PointModel template <typename T> GIL_FORCEINLINE point2<T> operator*(std::ptrdiff_t t, const point2<T>& p) { return point2<T>(p.x*t,p.y*t); } }}}
So point2 has miltiplication by ptrdiff_t, and division by double. This was very confusing for me - that multiplying point2<double> by 0.5 gave me point2(0,0).
But this probably is as it is for a reason, so I'm not sure if my idea for fixing this is the right way to go: I'd just add * and / for point2<T> and T, and add multiplication by double. I'd be happy to try to implement this change with some tests, if you think it's the right way to go ;-)
I don't quite get the reasoning myself. I would just use T instead of std::ptrdiff_t or double. This way the user has to make sure what he is passing. Maybe someone else can shed some light? Regards, Christian
2013/3/14 Christian Henning <chhenning@gmail.com>
Hi Kris,
Christian, you mean the io extension, do you? I don't see numeric in
trunk.
I have yet to add it. Probably this weekend.
I also have some comments about point2 from gil/utilities.hpp:
{{{ template <typename T> class point2 { public: [...] //--- these 3 functions don't add anything, do they? why not remove them rely on defaults? point2(const point2& p) : x(p.x), y(p.y) {} ~point2() {} point2& operator=(const point2& p) { x=p.x; y=p.y; return *this; }
You mean that these functions are usually generated by the compiler?
I wouldn't say 'usually' ;-) I'd say they are guaranteed to be generated, and do the same thing, as the ones provided above ;-)
[...]
point2& operator/=(double t) { x/=t; y/=t; return *this; } T x,y; [...] };
[...] template <typename T> GIL_FORCEINLINE point2<double> operator/(const point2<T>& p, double t) { return
point2<double>(0,0):point2<double>(p.x/t,p.y/t); } /// \ingroup PointModel template <typename T> GIL_FORCEINLINE point2<T> operator*(const point2<T>& p, std::ptrdiff_t t) { return point2<T>(p.x*t,p.y*t); } /// \ingroup PointModel template <typename T> GIL_FORCEINLINE point2<T> operator*(std::ptrdiff_t t, const point2<T>& p) { return point2<T>(p.x*t,p.y*t); } }}}
So point2 has miltiplication by ptrdiff_t, and division by double. This was very confusing for me - that multiplying point2<double> by 0.5 gave me point2(0,0).
But this probably is as it is for a reason, so I'm not sure if my idea for fixing this is the right way to go: I'd just add * and / for point2<T> and T, and add multiplication by double. I'd be happy to try to implement
t==0 ? this
change with some tests, if you think it's the right way to go ;-)
I don't quite get the reasoning myself. I would just use T instead of std::ptrdiff_t or double. This way the user has to make sure what he is passing. Maybe someone else can shed some light?
That would be fine with me. But * and / by double for integral T's might be useful, and since /double is here, I suspect removing it can break some code... Regards, Kris
Sorry, I must have missed this message.
During my first steps wit Boost.Gil I bumped onto an example [1], that uses the numeric extension. For this extension, the the example [1] and a ling from Boost.Gil docs [4] point to [2], where I couldn't find any Gil extensions to download. Most Google links pointed to the same page, but I finally found [3].
So my questions are: a) Is there a plan to add the extension numeric to Boost?
Unless there are any objections to add this extension I'll add it to Boost over the next weekend. It's probably better to have it out and in case there are bugs to submit changes.
b) Is [3] the newest version? And could the Boost.Gil docs be updated to point to the right place?
[3] has one change regarding headers. Otherwise it should be the one released by gil creators from Adobe.
c) I corrected a few bugs in boost/gil/extension/numeric/sampler.hpp -- is this list the right place to discuss modifications to the numeric extension?
Yes. Please send me patches or links to patches. Some test cases would be nice too! Regards, Christian
2013/3/13 Christian Henning <chhenning@gmail.com>
Unless there are any objections to add this extension I'll add it to Boost over the next weekend. It's probably better to have it out and in case there are bugs to submit changes.
:-)
b) Is [3] the newest version? And could the Boost.Gil docs be updated to
point to the right place?
[3] has one change regarding headers. Otherwise it should be the one released by gil creators from Adobe.
c) I corrected a few bugs in boost/gil/extension/numeric/sampler.hpp -- is this list the right place to discuss modifications to the numeric extension?
Yes. Please send me patches or links to patches. Some test cases would be nice too!
My patch attached. I didn't write any tests (yet?). Thanks for great work on Gil! Regards, Kris [3] http://code.google.com/p/gil-contributions/
2013/3/14 Christian Henning <chhenning@gmail.com>
> > My patch attached. I didn't write any tests (yet?).
>
> Could you give me a short description what this patch does.
> Thanks!
> Christian
>
Sure:
Index: boost/gil/extension/numeric/sampler.hpp
===================================================================
--- boost/gil/extension/numeric/sampler.hpp (revision 796)
+++ boost/gil/extension/numeric/sampler.hpp (working copy)
### This fixed a compile error on platforms, where ptrdiff_t isn't int:
@@ -45,7 +45,7 @@
template <typename DstP, typename SrcView, typename F>
bool sample(nearest_neighbor_sampler, const SrcView& src, const point2<F>&
p, DstP& result) {
- point2<int> center(iround(p));
+ typename SrcView::point_t center(iround(p));
if (center.x>=0 && center.y>=0 && center.x<src.width() &&
center.y<src.height()) {
result=src(center.x,center.y);
return true;
### Here some comments were wrong, and border cases were handled
incorrectly:
@@ -118,33 +118,35 @@
{
if (p0.y == -1)
{
### Added comment
+ // the top-left corner pixel
++loc.y();
### corrected the formula; the old one caused a dark line in the
destination image
- detail::add_dst_mul_src<SrcP,F,pixel<F,devicen_layout_t<num_channels<SrcView>::value>
> >()(loc.x()[1], frac.x * frac.y ,mp);
+ detail::add_dst_mul_src<SrcP,F,pixel<F,devicen_layout_t<num_channels<SrcView>::value>
> >()(loc.x()[1], 1 ,mp);
}
else if (p0.y+1<src.height())
{
### wrong comment and formula;
- // most common case - inside the image, not on the last row or column
- detail::add_dst_mul_src<SrcP,F,pixel<F,devicen_layout_t<num_channels<SrcView>::value>
> >()(loc.x()[1], frac.x *(1-frac.y),mp);
+ // on the first column, but not the top-left nor bottom-left
corner pixel
+ detail::add_dst_mul_src<SrcP,F,pixel<F,devicen_layout_t<num_channels<SrcView>::value>
> >()(loc.x()[1], (1-frac.y),mp);
++loc.y();
- detail::add_dst_mul_src<SrcP,F,pixel<F,devicen_layout_t<num_channels<SrcView>::value>
> >()(loc.x()[1], frac.x * frac.y ,mp);
+ detail::add_dst_mul_src<SrcP,F,pixel<F,devicen_layout_t<num_channels<SrcView>::value>
> >()(loc.x()[1], frac.y ,mp);
}
else
{
### wrong comment and formula
- // on the last row, but not the bottom-right corner pixel
- detail::add_dst_mul_src<SrcP,F,pixel<F,devicen_layout_t<num_channels<SrcView>::value>
> >()(loc.x()[1], frac.x ,mp);
+ // the bottom-left corner pixel
+ detail::add_dst_mul_src<SrcP,F,pixel<F,devicen_layout_t<num_channels<SrcView>::value>
> >()(loc.x()[1], 1 ,mp);
}
}
else if (p0.x+1<src.width())
{
if (p0.y == -1)
{
### lacking comment, wrong formula
+ // on the first row, but not the top-left nor top-right corner pixel
++loc.y();
- detail::add_dst_mul_src<SrcP,F,pixel<F,devicen_layout_t<num_channels<SrcView>::value>
> >()(*loc, (1-frac.x)* frac.y ,mp);
- detail::add_dst_mul_src<SrcP,F,pixel<F,devicen_layout_t<num_channels<SrcView>::value>
> >()(loc.x()[1], frac.x * frac.y ,mp);
+ detail::add_dst_mul_src<SrcP,F,pixel<F,devicen_layout_t<num_channels<SrcView>::value>
> >()(*loc, (1-frac.x) ,mp);
+ detail::add_dst_mul_src<SrcP,F,pixel<F,devicen_layout_t<num_channels<SrcView>::value>
> >()(loc.x()[1], frac.x ,mp);
}
else if (p0.y+1<src.height())
{
### comment slightly elaborated
- // most common case - inside the image, not on the last row or column
+ // most common case - inside the image, not on the frist nor last
row/column
detail::add_dst_mul_src<SrcP,F,pixel<F,devicen_layout_t<num_channels<SrcView>::value>
> >()(*loc, (1-frac.x)*(1-frac.y),mp);
detail::add_dst_mul_src<SrcP,F,pixel<F,devicen_layout_t<num_channels<SrcView>::value>
> >()(loc.x()[1], frac.x *(1-frac.y),mp);
++loc.y();
@@ -153,24 +155,30 @@
}
else
{
### comment elaborated a bit, and formula unchanged, reformated only
- // on the last row, but not the bottom-right corner pixel
- detail::add_dst_mul_src<SrcP,F,pixel<F,devicen_layout_t<num_channels<SrcView>::value>
> >()(*loc, (1-frac.x),mp);
- detail::add_dst_mul_src<SrcP,F,pixel<F,devicen_layout_t<num_channels<SrcView>::value>
> >()(loc.x()[1], frac.x ,mp);
+ // on the last row, but not the bottom-left nor bottom-right corner pixel
+ detail::add_dst_mul_src<SrcP,F,pixel<F,devicen_layout_t<num_channels<SrcView>::value>
> >()(*loc, (1-frac.x) ,mp);
+ detail::add_dst_mul_src<SrcP,F,pixel<F,devicen_layout_t<num_channels<SrcView>::value>
> >()(loc.x()[1], frac.x ,mp);
}
}
else
{
### added the top-right corner pixel case
- if (p0.y+1<src.height())
+ if (p0.y == -1)
{
- // on the last column, but not the bottom-right corner pixel
- detail::add_dst_mul_src<SrcP,F,pixel<F,devicen_layout_t<num_channels<SrcView>::value>
> >()(*loc, (1-frac.y),mp);
+ // the top-right corner pixel
+ ++loc.y();
+
detail::add_dst_mul_src<SrcP,F,pixel<F,devicen_layout_t<num_channels<SrcView>::value>
> >()(*loc, 1 ,mp);
+ }
### elaborated the comment and the formula unchanged (formated only)
+ else if (p0.y+1<src.height())
+ {
+ // on the last column, but not the top-right nor bottom-right corner pixel
+ detail::add_dst_mul_src<SrcP,F,pixel<F,devicen_layout_t<num_channels<SrcView>::value>
> >()(*loc, (1-frac.y),mp);
++loc.y();
- detail::add_dst_mul_src<SrcP,F,pixel<F,devicen_layout_t<num_channels<SrcView>::value>
> >()(*loc, frac.y ,mp);
+ detail::add_dst_mul_src<SrcP,F,pixel<F,devicen_layout_t<num_channels<SrcView>::value>
> >()(*loc, frac.y ,mp);
}
else
{
// the bottom-right corner pixel
### formated only
- detail::add_dst_mul_src<SrcP,F,pixel<F,devicen_layout_t<num_channels<SrcView>::value>
> >()(*loc,1,mp);
+ detail::add_dst_mul_src<SrcP,F,pixel<F,devicen_layout_t<num_channels<SrcView>::value>
> >()(*loc, 1 ,mp);
}
}
Regards,
Kris
Could you give me a short description what this patch does. Thanks! Christian
Sure:
Index: boost/gil/extension/numeric/sampler.hpp =================================================================== [snip]
This is great. Thanks! By any chance do you have a test case? Christian
2013/3/14 Christian Henning <chhenning@gmail.com>
Could you give me a short description what this patch does. Thanks! Christian
Sure:
Index: boost/gil/extension/numeric/sampler.hpp =================================================================== [snip]
This is great. Thanks!
By any chance do you have a test case?
Christian
You're right, I should have started with a test case, but I just wrote one now ;-) Please see the attachment. Thanks for looking into this, Christian Regards, Kris
Hi, I have added the numeric extension to boost trunk. Christian On Fri, Mar 15, 2013 at 10:15 AM, Krzysztof Czainski <1czajnik@gmail.com> wrote:
2013/3/14 Christian Henning <chhenning@gmail.com>
Could you give me a short description what this patch does. Thanks! Christian
Sure:
Index: boost/gil/extension/numeric/sampler.hpp =================================================================== [snip]
This is great. Thanks!
By any chance do you have a test case?
Christian
You're right, I should have started with a test case, but I just wrote one now ;-) Please see the attachment.
Thanks for looking into this, Christian
Regards, Kris
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
participants (3)
-
Andrew Hundt -
Christian Henning -
Krzysztof Czainski