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
