Hi,
Thanks Sean for reiterating this to all.
After discussion of last day on IRC. I think we have now come to sync as
per the image structure is considered. Also we have discussed that the
image struct will/should not contain the file information.
That is
bif = icv_load(filename, format); or bif = icv_create(width,height,depth ..
)
... store or modify the pixels ..
icv_save(bif,filename,format);
As per the previous mail Currently I am modifying the existing usage of
libicv predominantly in rt/viewedge.c, rt/view.c ,rt/do.c rt/viewxray.c and
in libged/screengrab .
All these files uses char* data and file in formation in the icv_image_file
struct. And uses the following functions from icv.
icv_image_save_open
icv_image_save_writeline / icv_image_save_writepixel
icv_image_save_close
It seems tough to modify these current usage.
I seek guidance on steps I should follow to modify the current usage of
icv_image structure and functions.
Or should I do something alternative about this.
Cheers!
Mohit
IRC Nick zero_level
On Tue, Jun 25, 2013 at 9:49 PM, Christopher Sean Morrison
<[email protected]>wrote:
>
>
> On Jun 24, 2013, at 10:34 PM, Mohit Daga <[email protected]> wrote:
>
> hi Erik, Sean and other Mentors,
>
> I believe we are on the same platform as per the image structure is
> considered and all of us agree to using a structure of the kind struct
> pixel_s{double r,g,b,a;}; for data in the image_struct.
>
>
> Actually, I would have suggested independent named channels instead of a
> struct so that you'd have a contiguous array of memory to stride through
> without alignment issues. Basically, your image struct would hold a map of
> names to double arrays. Something like struct icv_image {... double
> **image_data; ...} where image_data[0] is the RED channel array,
> image_data[1] is the BLU channel, with GRN and alpha following.
>
> Not only should that translate easily to other processing systems (e.g.,
> GPGPU) and is similar to our vmath macros, it should be more memory
> coherent and adaptive should we later want to optimize for only holding one
> channel for BW images (for example), or holding HSV (3-channel) or CMYKA
> (5-channel) down the road. Still, even the immediate benefit is full
> generality.
>
> (Yes, used grep ;))
>
>
> grep is your friend. Use it, learn it, love it. Using grep+find is a
> powerful combination as well. :)
>
> But the development of libicv will lead to modifications of its data
> structures, functions etc. This will have issues with its current uses. One
> of the possible way could be renaming current "icv" to "_icv" and starting
> icv a fresh.
>
>
> Renaming is unnecessary. We don't want to end up with two sets of
> structures either. You should apply refactoring best principles and update
> the affected code as you modify the structures or add new ones. This is
> where coding "complete" is critical. If you do this one small step at a
> time AFTER thinking through the design fully, it should be quick and
> painless. However, you must put this thought in beforehand to consider
> what issues will be encountered so that the code does not ever end up in an
> incomplete state.
>
> Cheers!
> Sean
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> BRL-CAD Developer mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>
>
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
BRL-CAD Developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/brlcad-devel
