Am 02.03.2015 um 09:54 schrieb Torsten Bronger:
> We may introduce a new struct lfImage.  It is contains no methods,
> but lfLens and lfCamera object, width, height (in px), the pixel
> format, focal length, aperture, and distance.  The constructor of
> lfModifier gets this signature:
> 
>     lfModifier(lfImage, reverse)
> 
> Then, lfModifier gets the methods:
> 
>     lfModifier::PrepareDistortionCorrection()
>     lfModifier::PrepareTCACorrection()
>     lfModifier::PrepareVignettingCorrection()
>     lfModifier::PrepareProjectionTransform(target_projection)
>     lfModifier::PrepareScaling(scale)
> 

Difficult, I have to write this down as an example program and I will
try at the weekend. But I like the PrepareXX prefix better than Initialize.

> with lensfun.h.in completely.  As a very first step, @Sebastian:
> Please review my branch lensfunprv-refactoring and merge it if it's
> okay.
> 

Looks good, I have merged it.

> In order to have real constructors, we need to merge the two
> lfExt... classes with their parents.  The two GLib types here are
> GPtrArray and gchar.
> 

One thing I have never really understood is why lensfun is C++ but
relies on glib (C libray) for array and list handling... Can you imagine
any good reason for that? If no, maybe it is best to replace GPtrArry by
a std::vector or something similar.

Sebastian


------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Lensfun-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/lensfun-users

Reply via email to