On 21.02.19 22:32, Graeme Leese wrote:
Hi Sebastian,
Thanks for all the work you've done on Lensfun over the years. I'd be
happy to get involved in continuing the project. I currently have
calibrations in the database that I can't use because of (2), so I'd be
interested in helping fix that,
Dear list,
the Lensfun project was started by Andrew Zabolotny in 2007 to lay the
foundation of a free and open source database for the correction of
photographic lens errors. After Lensfun did not receive any more fixes
and database updates, I more or less took over the maintenance from
Hi Christoph,
there is no date set for a next stable release. The latest alpha release
from June needs further testing and some minor changes before it is ready.
A list of open issues is in the wiki
https://sourceforge.net/p/lensfun/wiki/Release%20schedule/
It's not much that has to be
On 30.06.2018 00:53, jys wrote:
On Fri, Jun 29, 2018, at 04:10, Sebastian Kraft wrote:
we decided to release a snapshot of the current development as alpha
release 0.3.95. This is meant to show what was done in the background in
the past years and to share a state where others can step
Dear list,
we decided to release a snapshot of the current development as alpha
release 0.3.95. This is meant to show what was done in the background in
the past years and to share a state where others can step in to help
finishing a new stable Lensfun release.
During the last years, major
On 28.06.2018 22:35, Maik Riechert wrote:
Why not https://github.com/lensfun/lensfun? It seems this is kept up to
date anyway so there probably wouldn't be an urgent need for automatic
mirroring. Are the commits to this repo pushed back to sourceforge?
Yes, from time to time this is pushed
o you want to set it up on your GitHub account? I can
then regularly check the build state and reports if you share the link
to the Travis CI logs.
Thanks,
Sebastian
Cheers
Maik
On 22/06/2018 03:24, Sebastian Kraft wrote:
Hi Maik,
I like the idea of using a continuous integration servi
that the Darktable is also implemented at a suboptimal stage, but it is
better than RawThwrapee.
Sent from my iPad
On Jun 27, 2018, at 5:26 PM, Sebastian Kraft wrote:
Am 27. Juni 2018 22:55:55 schrieb jys :
In the commercial sector, I'm also aware of:
On1 Photo Raw
Affinity Photo
ACDSee
Am 27. Juni 2018 22:55:55 schrieb jys :
In the commercial sector, I'm also aware of:
On1 Photo Raw
Affinity Photo
ACDSee
Aftershot Pro
Exposure X3 (but you knew that)
Oh, some of them I was not aware of. I will add them to the list on the
website.
Robert, this should be a mostly
Hi Maik,
I like the idea of using a continuous integration service to test Lensfun
with different compilers and platforms. In the past I have looked at Travis
and others, but couldnt find something that nicely integrates with
Sourceforge. From my point of view we are not bound to Sourceforge
Hi Robert,
thanks for offering your help! The best way to submit a bunch of new
profiles to the Lensfun database is to either send a pull request on
GitHub (https://github.com/lensfun/lensfun) or a merge request on
Sourceforge (https://sourceforge.net/projects/lensfun/).
There is also a
Hi Roman,
thanks for reporting this. It is now fixed in the release_0.3.x branch.
The modifier_api branch already had that fix and will be merged to
master before the next release.
Sebastian
On 20.07.2017 18:39, Roman Lebedev wrote:
Hi.
darktable user <|beowulf|> has reported a problem,
On 11.12.2016 12:56, Roman Lebedev wrote:
>> That's what we were thinking. Maybe Alexander can be a bit more specific
>> about which platform he is working on and which application was missing
>> support for the updates?
> darktable on osx.
> https://redmine.darktable.org/issues/11352
> There is
On 11.12.2016 12:44, Roman Lebedev wrote:
>
>> 1) Application developers take the latest stable release and bundle it
>> with the backported database from master which can be downloaded here:
>> http://lensfun.sourceforge.net/db/version_1.tar.bz2
> So each app that uses lensfun should bundle it?
>
Hi Roman,
thank you very much for the patches. The lcov tool offers a really great
visualisation of the test coverage. Very interesting and helpful!
Sebastian
On 12.07.2016 21:52, Roman Lebedev wrote:
> Hi.
>
> The first patch fixes build issue that i encountered while using custom
> prefix.
On 16.07.2016 00:44, Hartmut Knaack wrote:
> Appearance
> ==
> In my test case, ufraw crashes with the message "Segmentation fault (core
> dumped)", when I open a Raw image of a camera which is unsupported by
> lensfun, and select in the lens correction tab the model "PanoTools Lens
>
On 16.06.2016 14:39, Torsten Bronger wrote:
> Hallöchen!
>
> Roman Lebedev writes:
>
>> This will allow to do *some* verification of the database XML's
>> at the build time. Well, each time make is run.
>
> Thank your for your contribution! @seek: I merged Roman's changes
> to master and pushed
On 28.05.2016 18:17, Karl Stevens wrote:
> Hi All,
>
> I have a new camera for inclusion; the lens calibration page mentions I
> can submit lense data here - I'm assuming new cameras are allowed as well?
>
Yes, mailing list or bug report at Sourceforge are both fine. Just be
warned that it
On 24.05.2016 23:31, Owen Mays wrote:
Thank you for adding the vignetting and TCA information. Where should I
check to see the earlier entry distortion calibration? The lists I can
find do not show this lens as being supported:
http://lensfun.sourceforge.net/lenslist/ and
Hi Roman,
thanks for the patches and sorry that we did not yet answer. I was too
busy in the last months and did not find the time to test it. However,
they will not be forgotten and are on the todo list for the next release.
Sebastian
On 02.03.2016 21:01, Roman Lebedev wrote:
> This will
On 18.04.2016 20:49, Christian Kapeller wrote:
> Hi,
>
> attached you'll find distortion parameters for the
> GoPro Hero3+ Black Edition in 4:3 mode.
>
Thank you! It is now part of the official database.
Sebastian
--
On 27.03.2016 11:51, Martin Jones wrote:
> Hi All,
>
> just managed to update my lensfun to version 0.3.0 which apparently
> offers the update data facility. I have tried entering the command, with
> and without sudo but the only response i get is an error as follows:
>
> Traceback (most recent
On 28.11.2015 17:42, Jan Beich wrote:
> It seems the conversion from old python-based configure to cmake has
> some rough edges. Here're a few fixes to avoid downstream growing
> suboptimal versions. Except merge conflicts they can be applied or
> discarded independently.
>
Sorry, the patches
>
> We fixed an issue with the Python package yesterday in the branch
> "debian-packaging". Please test this branch for your use case.
>
Additionally, please note that we have changed the setting of install
paths and prefixes to the GNUInstallDirs pattern as it was requested by
several
I have changed the setting of the install paths again. The version in
git HEAD should now comply with the CMake standard where all paths can
be set individually by CMAKE_INSTALL_XXX. Please check if this works for
you and report back. Thanks!
Sebastian
On 27.10.2015 21:01, Sebastian Kraft
Hello Roman,
thanks a lot for your patches. During commit, I had to slightly modify
patch 1 and 2. The glib minimal version is now set to 2.40 and the
include problem was fixed at another position. Please check the
patches-roman branch at Sourceforge and tell me if that's still working
for
On 05.06.2015 06:22, Walter Dnes wrote:
The next problem is how to do it from the command line. After
shooting a lot of photos in a day, I do not want to have to...
* manually open each CR2 in gimp via the ufraw plugin
* Click OK to accept the ufraw load
* manually apply lensfun
...100
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.
How do you like the following?
// Constructor with image/camera parameters
lfModifier (
int width,
int height,
Am 02.03.2015 um 21:44 schrieb Sebastian Kraft:
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
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:
Am 26.02.2015 um 08:01 schrieb Torsten Bronger:
Let's start with the toughest one: Lensfun makes no distinction
between lens and calibration. [...] Lensfun is currently unable
to take calibration data from different calibration entries for
one lens. This means that in a lot of cases, data is
Am 12.02.2015 um 08:27 schrieb Carl von Einem:
I'm no developer but Apr 30 2014 is some while ago. The current official
Hugin release actually comes with lensfun:
hugin-2014.0.0.tar.bz2
date: 2014-10-08
So from my user's point of view http://lensfun.sourceforge.net/usage/
Am 09.02.2015 um 01:13 schrieb Alex Mandel:
So I'm applying a distortion correction using the the lensfun database
for my lens and camera parameters. But it occurred to me after the
correction, I'm not really sure what the effective focal length, field
of view, and crop factor is. This
Am 26.12.2014 um 12:02 schrieb sjb:
On 26/12/14 10:35, m...@sebastiankraft.net wrote:
Yes please send it to the mailing list or upload it to the bug tracker
at Sourceforge and we will include it for the next release. Thank you!
I've attached the patch file to this Email. If the attachment
That's it so far. Torsten, maybe if you have some time and ideas
for further test cases it would be great if you could contribute
some. I think you have the best knowledge about the really
critical cases.
I fixed test_modifier. It (rightfully) fails now, because the
centre pixel (x=y=0)
Am 12.10.2014 um 23:48 schrieb Roman Lebedev:
Was found by ASan http://clang.llvm.org/docs/AddressSanitizer.html when
implementing (still WIP) test for vignetting correction.
https://github.com/LebedevRI/lensfun/tree/tests-test-mod-color
Thanks!
Sebastian
Well, as far as i am aware, i will need to modify lensfun/tests
https://github.com/LebedevRI/lensfun/blob/master/tests/tmod/tmod.cpp
/tmod/tmod.cc
https://github.com/LebedevRI/lensfun/blob/master/tests/tmod/tmod.cpp anyway,
when i'm done with lf_f32 pixel type and ready to move on to others
Not sure if the d parameter is necessary. The linked wiki entry says,
that d is calculated implicitly by pano12 (used by PTOptimizer,
PTStitcher and the GUIs) in order to keep the same image size. So I
assume this is redundant to the scaling parameter that can be set in a
different way in lensfun
Isn't it the other way round?
When you calibrate a lens with a crop 1.0 camera you have information about the
distortion inside and outside of the crop 1.5 region of the same lens. So
fitting of the parameters should be more accurate.
When calibration is done with a crop 1.5 image you don't
39 matches
Mail list logo
