Hii
On Wed, Aug 14, 2013 at 8:50 AM, Christopher Sean Morrison
<[email protected]>wrote:
>
> Conceptually, there's no difference between bwrect and pixrect other than
> the number of bytes-per-pixel. How might the ICV API be designed/changed
> to describe that feature? I count 13 other tools that have a
> bytes-per-pixel option and while I'm not opposed, what would it take to
> keep that flexibility?
>
The icv struct is designed such that it accommodates a separate value for
number of channels. (bif->channels).
All ICV APIs are general in nature. Thus it can process image of any number
of channels. For instance
icv_rect(..) // handles both 1 channel image (demonstrated in bwrect) and 3
channel image (demonstrated in pixrect.)
> Long term, I anticipate that we'd merge tools that group together (like
> bwrect and pixrect) into just one generalized tool (maybe 'imgrect') at
> which point we will need additional flexibility anyways. Another
> consideration is that we support the notion of 'dpix' files, which are
> double-precision floating point image files (24bpp) -- very close to ICV's
> internal format.
>
I anticipated this plan. Thus i created a generic icv_rect, or for that
matter all the api's which can handle variable number of channels.
Regarding dpix format I will be implementing read and write functions which
indeed will enable all the utilities to handle dpix data.
Cheers!
Mohit Daga
IRC_NICK zero_level
GSOC'13 student.
------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
_______________________________________________
BRL-CAD Developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/brlcad-devel
