GIL - Breeze presentation posted
FYI - we just posted a 55 minute Flash presentation regarding GIL. You may find watching it more convenient than reading the tutorial. http://opensource.adobe.com/gil/documentation.html Lubomir
Lubomir Bourdev said: (by the date of Tue, 27 Jun 2006 17:40:41 -0700)
FYI - we just posted a 55 minute Flash presentation regarding GIL. You may find watching it more convenient than reading the tutorial.
does it have sound? I can't hear any, but maybe it's my browser's fault. -- Janek Kozicki |
On Wed, 28 Jun 2006 09:33:12 +0200, Janek Kozicki <janek_listy@wp.pl> wrote:
Lubomir Bourdev said: (by the date of Tue, 27 Jun 2006 17:40:41 -0700)
FYI - we just posted a 55 minute Flash presentation regarding GIL. You may find watching it more convenient than reading the tutorial.
does it have sound? I can't hear any, but maybe it's my browser's fault.
Yes, it has. --Gennaro.
Hi Lubomir, "Lubomir Bourdev"wrote
FYI - we just posted a 55 minute Flash presentation regarding GIL. You may find watching it more convenient than reading the tutorial.
The flash tutorial was excellent and very informative. I hope you provide a link in the submitted documentation. AFAICS Its a very good demonstration of Generic programming, as well as use of metafunctions and boost lambda. and bringing compile time entities into runtime Below are some quick thoughts from a very amteur perspective. Note comments based on GIL in release version of ASL.1.0.17 - Rather than int width, int height for image why not image_size(width, height). - What is point used for <adobe/gil/core/utilities.hpp> ? - Isnt point2<T> always an Integer? Why is it converted to a float: #include <iterator> // shouldnt be necessary here #include <adobe/gil/core/utilities.hpp> #include <iostream> int main() { adobe::gil::point2<std::size_t> p; std::cout << typeid(p * 2).name() <<'\n'; } /* output: class adobe::gil::point2<double> */ - Is point2 * point2 useful? - Is point2 << point2 useful? - point2[] may not be legal C++ as written FWIW: http://tinyurl.com/lvufg - Arent point2's actually position vectors? - Boost.Numeric.Converter can be used for rounding and conversion of float to int. Adds range checking too, but slower, is that why you dont use it? http://www.boost.org/libs/numeric/conversion/doc/index.html - utility.hpp needs to include <iterator> - locator might be renamed cursor.
Rather than int width, int height for image why not image_size(width, height).
When you need 2D value you can specify it either as two numbers or as a point: rgb8_image_t image(300,200); is the same as rgb8_image_t image(rgb8_image_t::point_t(300,200)); or in this case: rgb8_image_t image(point2<int>(300,200));
What is point used for <adobe/gil/core/utilities.hpp> ?
Hopefully that answers your question. Any time you have 2D coordinates, such as image dimensions, 2D location in an image, 2D difference, etc, you can represent them with a point.
Isnt point2<T> always an Integer? Why is it converted to a float:
point2<T> is an integer if T is an integer. Multiplying it with a float will make it a float point. But integer multiplication should keep it an integer. We forgot to add this overload. We will fix that.
Is point2 * point2 useful?
It could be. For example, the step of two nested subsampled views is the product of their steps. But as it appears we are not currently using it. We could remove it. Besides, it is unclear whether the above syntax should do a dot product instead.
Is point2 << point2 useful?
This is not currently defined. You can shift an integer point by an integral type, but not by another point.
point2[] may not be legal C++ as written FWIW: http://tinyurl.com/lvufg
Using a switch statement at that low level is prohibitively expensive. I couldn't get MSVC8 to generate the same assembly for a switch statement as for my cast. Besides, in the highly unlikely scenario where T would require some padding to be aligned, I think the math still works out. Can you give me a concrete example (as far fetched as you want, but legal) that breaks the code?
Arent point2's actually position vectors?
Yes, they can be used as such. Why?
Boost.Numeric.Converter can be used for rounding and conversion of float to >int. Adds range checking too, but slower, is that why you dont use it?
I am not actually familiar with all Boost libraries. But yes, in low-level code, such as channel-level code, speed is instrumental.
utility.hpp needs to include <iterator>
You mean gil/core/utilities.hpp? Why?
locator might be renamed cursor.
What is the precedent? Lubomir
Lubomir Bourdev wrote:
FYI - we just posted a 55 minute Flash presentation regarding GIL. You may find watching it more convenient than reading the tutorial.
Didn't watch it through, would prefer the toot if only.... The breakdown of the type-naming system ("gray_8c_view_t" etc) was very instructive, it might be good to have it this clearly in the beginning of the tutorial. It seems this would imply a (brief!) walk-through of the models, quite early in the tutorial. This would also be useful. It is not instructive to have discussion of optimization right in the beginning. First get the concepts settled, then offer a page on how to do things the best way. If that's at all important - we know how to write loops, so your main argument is (should be) that we're already winning if we use your library, as it's very generic, and practical. (And you may be right.) Here's where the tutorial is lacking IMO: A good tutorial gives a (nifty) solution to a problem (like gradient, that's fine), *and* it links to the higher-level parts of reference docs. (*) So by re-reading and clicking links we get a tour of the most important classes or concepts, and coming from a worked-out example we see how they fit together. The body of the toot has two links in the first 4-5 screenfuls of text+code: one to the include-all header *source-code* (what are we supposed to do with that??) and one to interleaved_view, which is... well, something I'm not ready to understand at that point. A link to the image_view class would be better, or at least gives something to read. When you next discuss Locators, there's no link at all. A link to class pixel_2d_locator might be a good idea at that point, because it has a description of what locators are. And so on. The presentation gives a little more high-level stuff, and suddenly it makes sense. This allowed me to get to the good parts of your library quickly, earlier attempts just failed, couldn't see where to begin. (But then I'm not top of the class, just a potential user...) Maybe I'm just saying that the descriptions in the classes I mentioned (and maybe some other I didn't see) should be moved higher up the documentation hierarchy, to places where new visitors will find them. Good luck with reviews etc, and thanks for the opportunity to study (and indeed perhaps make use of) a good generic library! re (*) I made up that definition of "good tutorial" just now, but think it almost makes sense. (A little bit?)
"Lubomir Bourdev" <lbourdev@adobe.com> wrote in message news:B55F4112A7B48C44AF51E442990015C00107C95B@namail1.corp.adobe.com... : FYI - we just posted a 55 minute Flash presentation regarding GIL. You : may find watching it more convenient than reading the tutorial. : : http://opensource.adobe.com/gil/documentation.html Great job and excellent presentation ! Now there is one reason I probably won't be using GIL which I haven't seen mentioned: I develop an internal application. For validation purposes, my preference so far has been to release "debug" builds (i.e. with all runtime checks enabled and without aggressive compiler optimizations). In this scenario, abstraction penalty can be huge, because inlining is weak/inexistent. Writing a "C-style" version of the basic algorithms I need (e.g. erosions etc), there is only a minor difference between debug and optimized builds (e.g. often less than x 2). Using generic GIL code ... I suspect that the difference would be of an order of magnitude. Anyway, I'm all for seeing GIL into boost soon ! Ivan -- http://ivan.vecerina.com/contact/?subject=NG_POST <- email contact form
"Ivan Vecerina" wrote
: FYI - we just posted a 55 minute Flash presentation regarding GIL. You : may find watching it more convenient than reading the tutorial. : : http://opensource.adobe.com/gil/documentation.html
Great job and excellent presentation !
Now there is one reason I probably won't be using GIL which I haven't seen mentioned:
I develop an internal application. For validation purposes, my preference so far has been to release "debug" builds (i.e. with all runtime checks enabled and without aggressive compiler optimizations). In this scenario, abstraction penalty can be huge, because inlining is weak/inexistent.
Writing a "C-style" version of the basic algorithms I need (e.g. erosions etc), there is only a minor difference between debug and optimized builds (e.g. often less than x 2). Using generic GIL code ... I suspect that the difference would be of an order of magnitude.
What is stopping you adding checks in an optimised version? regards Andy Little
"Andy Little" <andy@servocomm.freeserve.co.uk> wrote in message news:e82q57$4i4$1@sea.gmane.org... : "Ivan Vecerina" wrote ... : > I develop an internal application. For validation purposes, : > my preference so far has been to release "debug" builds : > (i.e. with all runtime checks enabled and without aggressive : > compiler optimizations). : > In this scenario, abstraction penalty can be huge, because : > inlining is weak/inexistent. : > : > Writing a "C-style" version of the basic algorithms I need : > (e.g. erosions etc), there is only a minor difference : > between debug and optimized builds (e.g. often less than x 2). : > Using generic GIL code ... I suspect that the difference : > would be of an order of magnitude. : : What is stopping you adding checks in an optimised version? Error 1 Command line error D8016 : '/O2' and '/RTC1' command-line options are incompatible cl This is about automatic range-checking and other runtime checks that can automatically be generated by Visual C++ into the generated code. They interfere with optimization, and inlining. Granted, I could either: - Work on finding a compromize between optimizations & tuning, and enabling library runtime checks. - Modify compiler options for specific code modules only ... but for now the software has been doing well without this, and the "full runtime checks" approach helps give an extra level of confidence when facing the regulatory guys. Over time, as our confidence level (experience with audits) increases, I might move towards more aggressive optimization [ in practice I have never had a problem detected in the field ] Anyway, the point is: In debug mode, abstraction penalty can be quite high. It can get even worse if your standard library implementation includes built-in runtime checks, as the one that ships with VS2005 (checked iterators can be excruciatingly expensive within an inner loop). And mixing runtime check options within the same target application does not work well (different in-memory representations...). It would help if compilers would already start by get better at inlining functions (especially single-statement functions) when generating code in debug mode. [ The same would apply when comparing boost::spirit to parsers based on code generators, such as flex ] -- Ivan http://ivan.vecerina.com/contact/?subject=NG_POST <- email contact form
It would help if compilers would already start by get better at inlining functions (especially single-statement functions) when generating code in debug mode.
This seems odd to me, at least in Visual Studio the compiler commands for debugging information and inlining are orthogonal and as such virtually all of our builds including a release build (with inlining and other optimisations on) are built with debug info. So just turn on inlining in your debug build if thats what you want. Martin -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.9.8/380 - Release Date: 30/06/2006
participants (7)
-
Andy Little -
Gennaro Prota -
Ivan Vecerina -
Janek Kozicki -
Lubomir Bourdev -
Martin Slater -
rasmus ekman