On Aug 13, 2013, at 6:23 PM, Mohit Daga wrote:
> pixrect modified to use icv api. It now no longer supports bytes_per pixel
> option and assumes 3 bytes for .pix files. Also prompting has been removed.
> Supports only command line arguments.
>
> Please check this revision for pixrect. I have removed bytes per pixel option
> in pixrect.
>
> As per .pix files are considered, I assume that they will be 3bytes per
> pixels always.
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?
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.
Again, it's fine to "lose" that feature, but since we're just getting started
and there are more to go, it's a perfect time to think this through.
tl;dr it's fine for now.
Cheers!
Sean
------------------------------------------------------------------------------
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
