Thanks Mohit! On Jun 21, 2013, at 5:49 PM, Mohit Daga wrote:
> Hi Erik, Sean and other mentors, > > Through this email I seek your advice/suggestions in implementing the image > processing functions of lib_icv. To others listening, we followed up with this discussion over IRC. Predominant direction being suggested is to start with libicv assuming in-core memory images and using a high dynamic range format (doubles). There are (obvious) upsides and downsides with both of those decisions, but I think they help position the library for our future processing needs well and distinct from other image library options. > This plans to implement the functions of libicv in the following way : > > The function caller sends the icv_image struct of the input file and also > send the pointer of the icv_image struct of the output file. Since we're going to have so much memory overhead and will almost always be processing an existing data buffer, it may make more sense to not require to icv_image structs. That is, that the input icv_image is also the output. If the caller needs to preserve the input, there can be a copy function. Separate structs make sense when they're both tied to files, but not as an in-memory construct. This has the added benefit of unambiguity in the implementation. If they're two separate buffers, we'd have to make sure or document whether each processing function made an assumption that the const input struct is not also the non-const output struct. Making them one in the same simplifies that notion. > The function caller sends the output file name and these function saves the > image according to its functionality using the input icv_image struct. and > returns only the success parameters or the icv_image structure. My general notion is that if you have some functions that are going to use the return parameter to indicate success/failure, then ALL api functions should have that form. That is simple to use and easy to explain/understand if there are no exceptions. Consistency ftw. 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 brlcad-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/brlcad-devel
