Re: [boost] [GIL] locator and cached_location_t
Thanks for your answer.
To answer both of your questions, I don't see any particular obstacle to adding those APIs to image_view, but we didn't add them because that will be a lot of methods for something that is advanced and not frequently used (cached_location). Not to mention it doesn't make sense to use for all image views, but only "memory-based" ones, as opposed to virtual ones, for example. Ok for my first question. I understand the idea of not polluting the "image_view" class with something specific that can not be used in all cases.
But what about the second question: adding 2 functions inside the locator class. The idea is to allows to get a locator or an iterator from a locator using cached_location ? Currently we have an operator[] inside the locator class which takes a cached_location_t and returns a pixel. It seems interesting to add x_at(const cached_location_t&) and xy_at(const cached_location_t&) versions which returns respectively iterator or locator, isn't it ?
On Dec 16, 2010, at 1:24 AM, <fabien.castan@free.fr<mailto:fabien.castan@free.fr>> <fabien.castan@free.fr<mailto:fabien.castan@free.fr>> wrote: Ok for my first question. I understand the idea of not polluting the "image_view" class with something specific that can not be used in all cases. But what about the second question: adding 2 functions inside the locator class. The idea is to allows to get a locator or an iterator from a locator using cached_location ? Currently we have an operator[] inside the locator class which takes a cached_location_t and returns a pixel. It seems interesting to add x_at(const cached_location_t&) and xy_at(const cached_location_t&) versions which returns respectively iterator or locator, isn't it ? I don't see a particular reason why we shouldn't have such methods, other than polluting the interface with rarely used methods. It is not immediately obvious to me why you would use this. 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. But the only reason you would prefer an iterator instead is if you want to move it. I cannot think of a case where you want to construct millions of iterators at fixed locations relative to a current locator... Can you explain why you would need such functionality? Lubomir
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. But the only reason you would prefer an iterator instead is if you want to move it. I cannot think of a case where you want to construct millions of iterators at fixed locations relative to a current locator... Can you explain why you would need such functionality? I write a flood fill algorithm, so I often need to visit the 8 neighbors and next visit the new neighbors... So I like the idea of moving my locator with 8 cached_location. For this kind of algorithm, we often need to move with the same steps, so I think it's interesting to use cached_location. I don't think it's a so particular case.
PS: If you want to see my actual use as a concrete example. https://github.com/tuttleofx/TuttleOFX/blob/master/plugins/image/process/fil...
participants (3)
-
fabien -
fabien.castan＠free.fr
-
Lubomir Bourdev