[IPOL discuss] The Hatchery: an informal index of available code within our community.

[Daniel Kondermann]

Hi guys!

I am very much interested what you think about the software and I would
like to encourage other list members to join this discussion!
It is well-related to IPOL and I plan to use it extensively to get some
of our methods published on IPOL in the long run ;)

> I mostly agree with this, but we all know what happens when we try to
> be comprehensive with a software library. You end tied up to it, like
> what happened with megawave.
I think a *very* important distinction is that our software is *no*
image processing library ;) We found the same problems and therefore
focused on the simplest possible framework while maintaining good
project management to create reusable code.
CMake and SVN are perfectly suited and widely distributed for the
project management, so even large groups on heterogenous systems can
jointly work on the same project.
Having too many mini-files and snippets of code, I think the granularity
becomes to fine which creates new problems.

> So if we go this way, we should be sure that every pieces of the
> library is independent and can be used separately in our programs.
Definitely. Currently charon-core is a wrapper to load and save
parameters from a file and to encapsulate the different ways to
implement dynamic libraries under Linux/Windows. This minimal code is
very simple to understand and was in fact written by a undergraduate
student two years ago (and remained almost untouched since then).

> If every code in this framework will depend on a image type and the
> image type will depend on other things, we will end up with a mess.
Absolutely. We solved this problem by writing modules that simply
convert one type to the other. Currently, we use CImg, Vigra, OpenCV and
HDF5 image structures. Of course this slows down code, but the system is
not made for speed - it is made for code-maintenance, interface-sharing
and prototyping.

> It will also be nice to be able to compile this "fragments" without
> complicated build systems, i.e. like taking file.{h,c} and compiling
> it alone.
Each module only has an "execute"-method. If you like to use the code in
there somewhere else, you can just copy that code to get rid of the
charon-core-includes. On the other hand I do not think that this is
useful, because charon-core is lightweight and enables the user to save
a text-file containing information about how a number of modules is
connected to create a full algorithm.

> I will take a look at your library, maybe we can define some tests to
> do to a framework to see how complicated it is. For instance, how many
> files (and lines of code) should I compile to open an image, threshold
> it and save it again.
Currently, you need to write only the loop over the pixels and the
assignement of the output image size. Creating the plugin, writing and
compiling the code took no more than 10 minutes in various test cases
with students and myself.
On the other hand you initially need to read an intorductory article
which has not yet been written and download the code-base. My current
aim is to be able to learn everything within 4 hours. Many of my
students achieved this goal already, but I had to brief them personally ;)

> The ease of use from the programmer's side is always paid with
> complexity in the library itself. Although "if (I[i] < th) I[i] = 0"
> is appealing, I wonder how many thousands lines of code are required
> to achieve that level of abstraction.
> It is a dangerous path, which led many us to considerable headaches in the past.
I absolutely agree with you! (This is why I am so sceptical about image
processing *libraries* - CImg is dead-simple. If it wouldn't change its
interface every version, I would clearly favour it.)

Cheers,
Daniel

> 
> 
> On Mon, Sep 26, 2011 at 12:38 PM, Miguel Colom
> <Miguel.Colom at cmla.ens-cachan.fr> wrote:
>>> Hi Miguel,
>>>
>>> at our lab, I implemented something similar:
>>> http://charon-suite.sourceforge.net
>>> * The idea is NOT to create a library or a complicated framework;
>>> instead the idea is to archive code from my students in a common format
>>> and to enable new students to reuse existing code in a modular manner. *
>>> Everybody can either use existing code or write his/her own modules
>>> which can be plugged together in a visual environment. (The same code
>>> can also be executed from the command line).
>>> * It works under Windows and Linux environments and the user can choose
>>> his/her own development environment (thanks to CMake).
>>> * The mini-framework for writing modules (charon-core) has been stable
>>> for two years now. There even is a code-generating wizard to create new
>>> modules without writing code.
>>> * The number of existing algorithms and helper code such as file reading
>>> and writing is steadily increasing.
>>> * From a supervisor's perspective it is also very useful for
>>> experimenting with the methods your students implemented.
>>
>> Thank you for the information, Daniel.
>>
>> This kind of framework is what I mean. Perhaps making it a little less
>> typed, but I think it's great.
>>
>> For example, let's think about a very simple denoising algoritm that puts
>> to zero those DCT coefficients that are below a given threshold.
>>
>> To implement it means using a library to parse the input parameters and
>> options, open a PNG file, to handle the possible errors (file not found,
>> read failure, memory issues, etc), look for code to compute fast the DCT,
>> do the denoising and saving the file.
>>
>> It's a lot of work that has to be coded and tested for every new algorithm
>> application. In this example, the code shouldn't be larger than a line
>> that says something like "if (I[i] < th) I[i] = 0" inside a loop.
>>
>> Putting all processing that doesn't really has to do with the algorithm
>> itself makes the applications easier to develop, faster to develop, the
>> code is clearer and also one can isolate problems in the code easier.
>>
>> Best,
>> Miguel
>>
>>
>> _______________________________________________
>> discuss mailing list
>> discuss at list.ipol.im
>> http://tools.ipol.im/mailman/listinfo/discuss
>>
> _______________________________________________
> discuss mailing list
> discuss at list.ipol.im
> http://tools.ipol.im/mailman/listinfo/discuss


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 552 bytes
Desc: OpenPGP digital signature
URL: <http://tools.ipol.im/mailman/archive/discuss/attachments/20110927/ed74eaa4/attachment.pgp>