Review Request 119201: Be explicit with OpenCV components

[Vadim Zhukov]

This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119201/

Review request for Digikam.

By Vadim Zhukov.

Repository: digikam

Description

This makes Digikam being explicit in what OpenCV components are needed. This results in less number of libraries to be linked to. As a result, Digikam starts a bit faster, eats a bit less memory and makes downstream (packagers) a bit more happy. Also it helps in cases when OpenCV package is split (for example, with non-free components separated) - without explicit mentioning of what components are needed, it's not clear will Digikam link to some components or not.

Testing

OpenBSD/i386-CURRENT, KDE 4.11.5+Digikam 3.x and KDE 4.13.2+Digikam 4.x

Diffs

• CMakeLists.txt (d591a2f)

View Diff

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119201/

Which CmakeFiles do you patch exactly ?
There are 3 parts in digiKam which use OpenCV :
1/ digiKam core

2/ Kipi-plugins (RemoveRedEyes tool)

3/ libkface
For 1 and 2 i think it's fine. But for libkface, i'm sure no, because i tried to reduce OpenCV fingerprint to speed up compilation on my computer (2.4.9 version), and digiKam crash due to a side effect in OpenCV (through a simple std::memcpy() call). With all default components, OpenCV do not crash.
See my comment here :
https://bugs.kde.org/show_bug.cgi?id=336650#c3
Gilles Caulier

- Gilles Caulier

On July 9th, 2014, 5:26 p.m. UTC, Vadim Zhukov wrote:

Review request for Digikam.

By Vadim Zhukov.

Updated July 9, 2014, 5:26 p.m.

Repository: digikam

Description

This makes Digikam being explicit in what OpenCV components are needed. This results in less number of libraries to be linked to. As a result, Digikam starts a bit faster, eats a bit less memory and makes downstream (packagers) a bit more happy. Also it helps in cases when OpenCV package is split (for example, with non-free components separated) - without explicit mentioning of what components are needed, it's not clear will Digikam link to some components or not.

Testing

OpenBSD/i386-CURRENT, KDE 4.11.5+Digikam 3.x and KDE 4.13.2+Digikam 4.x

Diffs

• CMakeLists.txt (d591a2f)

View Diff

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Vadim Zhukov]

This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119201/

On Июль 9th, 2014, 9:52 п.п. MSK, Gilles Caulier wrote:

Which CmakeFiles do you patch exactly ?
There are 3 parts in digiKam which use OpenCV :
1/ digiKam core

2/ Kipi-plugins (RemoveRedEyes tool)

3/ libkface
For 1 and 2 i think it's fine. But for libkface, i'm sure no, because i tried to reduce OpenCV fingerprint to speed up compilation on my computer (2.4.9 version), and digiKam crash due to a side effect in OpenCV (through a simple std::memcpy() call). With all default components, OpenCV do not crash.
See my comment here :
https://bugs.kde.org/show_bug.cgi?id=336650#c3
Gilles Caulier

I agree that OpenCV components are a mess. I was not aware about a problem with libkface and will take a closer look then.
In OpenBSD, we have separate packages for (1), (2) and (3), so it still makes sense for us to have explicit dependencies. But it looks like we need to separate OpenCV detection somehow. Probably calling find_package(OpenCV [...]) on lower layers should be enough, but this needs verification. I'll update review after some experiments.
Thank you for input!

- Vadim

On Июль 9th, 2014, 9:26 п.п. MSK, Vadim Zhukov wrote:

Review request for Digikam.

By Vadim Zhukov.

Updated Июль 9, 2014, 9:26 п.п.

Repository: digikam

Description

This makes Digikam being explicit in what OpenCV components are needed. This results in less number of libraries to be linked to. As a result, Digikam starts a bit faster, eats a bit less memory and makes downstream (packagers) a bit more happy. Also it helps in cases when OpenCV package is split (for example, with non-free components separated) - without explicit mentioning of what components are needed, it's not clear will Digikam link to some components or not.

Testing

OpenBSD/i386-CURRENT, KDE 4.11.5+Digikam 3.x and KDE 4.13.2+Digikam 4.x

Diffs

• CMakeLists.txt (d591a2f)

View Diff

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119201/

As I said previously, wit libkface we have a problem about OpenCV components to active or not. 
The problem is that i don't yet identified which components must still present or not.
The problem is with Face Detection. Running it crash violently digiKam when OpenCV components is missing. So it's simple to check.
To be sure that problem is not on other side, just enable all OpenCV component and run F&ce Detection. If it so not crash, your test env is fine, and you can start to disable OpenCV step by step.
Gilles Caulier

- Gilles Caulier

On July 9th, 2014, 5:26 p.m. UTC, Vadim Zhukov wrote:

Review request for Digikam.

By Vadim Zhukov.

Updated July 9, 2014, 5:26 p.m.

Repository: digikam

Description

This makes Digikam being explicit in what OpenCV components are needed. This results in less number of libraries to be linked to. As a result, Digikam starts a bit faster, eats a bit less memory and makes downstream (packagers) a bit more happy. Also it helps in cases when OpenCV package is split (for example, with non-free components separated) - without explicit mentioning of what components are needed, it's not clear will Digikam link to some components or not.

Testing

OpenBSD/i386-CURRENT, KDE 4.11.5+Digikam 3.x and KDE 4.13.2+Digikam 4.x

Diffs

• CMakeLists.txt (d591a2f)

View Diff

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Vadim Zhukov]

This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119201/

On Июль 9th, 2014, 11:25 п.п. MSK, Gilles Caulier wrote:

As I said previously, wit libkface we have a problem about OpenCV components to active or not. 
The problem is that i don't yet identified which components must still present or not.
The problem is with Face Detection. Running it crash violently digiKam when OpenCV components is missing. So it's simple to check.
To be sure that problem is not on other side, just enable all OpenCV component and run F&ce Detection. If it so not crash, your test env is fine, and you can start to disable OpenCV step by step.
Gilles Caulier

Last time I tested libkface, it was working with the following line:
find_package(OpenCV REQUIRED COMPONENTS core contrib highgui)
But that was not a Digikam 4.x... I'm finishing 4.1.0 build as of now, let's see how it goes.

- Vadim

On Июль 9th, 2014, 9:26 п.п. MSK, Vadim Zhukov wrote:

Review request for Digikam.

By Vadim Zhukov.

Updated Июль 9, 2014, 9:26 п.п.

Repository: digikam

Description

This makes Digikam being explicit in what OpenCV components are needed. This results in less number of libraries to be linked to. As a result, Digikam starts a bit faster, eats a bit less memory and makes downstream (packagers) a bit more happy. Also it helps in cases when OpenCV package is split (for example, with non-free components separated) - without explicit mentioning of what components are needed, it's not clear will Digikam link to some components or not.

Testing

OpenBSD/i386-CURRENT, KDE 4.11.5+Digikam 3.x and KDE 4.13.2+Digikam 4.x

Diffs

• CMakeLists.txt (d591a2f)

View Diff

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119201/

Ok, interresting. I'm waiting your final investiguation to apply these OpenCV rules

- Gilles Caulier

On July 9th, 2014, 5:26 p.m. UTC, Vadim Zhukov wrote:

Review request for Digikam.

By Vadim Zhukov.

Updated July 9, 2014, 5:26 p.m.

Repository: digikam

Description

This makes Digikam being explicit in what OpenCV components are needed. This results in less number of libraries to be linked to. As a result, Digikam starts a bit faster, eats a bit less memory and makes downstream (packagers) a bit more happy. Also it helps in cases when OpenCV package is split (for example, with non-free components separated) - without explicit mentioning of what components are needed, it's not clear will Digikam link to some components or not.

Testing

OpenBSD/i386-CURRENT, KDE 4.11.5+Digikam 3.x and KDE 4.13.2+Digikam 4.x

Diffs

• CMakeLists.txt (d591a2f)

View Diff

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Vadim Zhukov]

This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119201/

On Июль 10th, 2014, 1:30 д.п. MSK, Gilles Caulier wrote:

Ok, interresting. I'm waiting your final investiguation to apply these OpenCV rules

So with 4.1.0 the libkface picked up everything anyway. Something really fishy happens here. Still investigating...

- Vadim

On Июль 9th, 2014, 9:26 п.п. MSK, Vadim Zhukov wrote:

Review request for Digikam.

By Vadim Zhukov.

Updated Июль 9, 2014, 9:26 п.п.

Repository: digikam

Description

This makes Digikam being explicit in what OpenCV components are needed. This results in less number of libraries to be linked to. As a result, Digikam starts a bit faster, eats a bit less memory and makes downstream (packagers) a bit more happy. Also it helps in cases when OpenCV package is split (for example, with non-free components separated) - without explicit mentioning of what components are needed, it's not clear will Digikam link to some components or not.

Testing

OpenBSD/i386-CURRENT, KDE 4.11.5+Digikam 3.x and KDE 4.13.2+Digikam 4.x

Diffs

• CMakeLists.txt (d591a2f)

View Diff

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119201/

On July 9th, 2014, 9:30 p.m. UTC, Gilles Caulier wrote:

Ok, interresting. I'm waiting your final investiguation to apply these OpenCV rules

On July 10th, 2014, 9:16 a.m. UTC, Vadim Zhukov wrote:

So with 4.1.0 the libkface picked up everything anyway. Something really fishy happens here. Still investigating...

Some progress here ?

- Gilles

On July 9th, 2014, 5:26 p.m. UTC, Vadim Zhukov wrote:

Review request for Digikam.

By Vadim Zhukov.

Updated July 9, 2014, 5:26 p.m.

Repository: digikam

Description

This makes Digikam being explicit in what OpenCV components are needed. This results in less number of libraries to be linked to. As a result, Digikam starts a bit faster, eats a bit less memory and makes downstream (packagers) a bit more happy. Also it helps in cases when OpenCV package is split (for example, with non-free components separated) - without explicit mentioning of what components are needed, it's not clear will Digikam link to some components or not.

Testing

OpenBSD/i386-CURRENT, KDE 4.11.5+Digikam 3.x and KDE 4.13.2+Digikam 4.x

Diffs

• CMakeLists.txt (d591a2f)

View Diff

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Vadim Zhukov]

This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119201/

On Июль 10th, 2014, 1:30 д.п. MSK, Gilles Caulier wrote:

Ok, interresting. I'm waiting your final investiguation to apply these OpenCV rules

On Июль 10th, 2014, 1:16 п.п. MSK, Vadim Zhukov wrote:

So with 4.1.0 the libkface picked up everything anyway. Something really fishy happens here. Still investigating...

On Июль 18th, 2014, 11:38 д.п. MSK, Gilles Caulier wrote:

Some progress here ?

Not yet, sorry; I had some troubles during geting back home to Moscow and just arranged them. I plan to finish my investigations at the weekend.

- Vadim

On Июль 9th, 2014, 9:26 п.п. MSK, Vadim Zhukov wrote:

Review request for Digikam.

By Vadim Zhukov.

Updated Июль 9, 2014, 9:26 п.п.

Repository: digikam

Description

This makes Digikam being explicit in what OpenCV components are needed. This results in less number of libraries to be linked to. As a result, Digikam starts a bit faster, eats a bit less memory and makes downstream (packagers) a bit more happy. Also it helps in cases when OpenCV package is split (for example, with non-free components separated) - without explicit mentioning of what components are needed, it's not clear will Digikam link to some components or not.

Testing

OpenBSD/i386-CURRENT, KDE 4.11.5+Digikam 3.x and KDE 4.13.2+Digikam 4.x

Diffs

• CMakeLists.txt (d591a2f)

View Diff

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Vadim Zhukov]

This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119201/

On Июль 10th, 2014, 1:30 д.п. MSK, Gilles Caulier wrote:

Ok, interresting. I'm waiting your final investiguation to apply these OpenCV rules

On Июль 10th, 2014, 1:16 п.п. MSK, Vadim Zhukov wrote:

So with 4.1.0 the libkface picked up everything anyway. Something really fishy happens here. Still investigating...

On Июль 18th, 2014, 11:38 д.п. MSK, Gilles Caulier wrote:

Some progress here ?

On Июль 18th, 2014, 11:56 д.п. MSK, Vadim Zhukov wrote:

Not yet, sorry; I had some troubles during geting back home to Moscow and just arranged them. I plan to finish my investigations at the weekend.

It looks like I got all pieces of puzzle right now. Because the actual problem is a complex one, I'm moving discussion to an [hidden email] mailing list, CC'ing you as you'll likely be interested in the whole picture anyway. If you're against this, I'll duplicate critical parts here.

- Vadim

On Июль 9th, 2014, 9:26 п.п. MSK, Vadim Zhukov wrote:

Review request for Digikam.

By Vadim Zhukov.

Updated Июль 9, 2014, 9:26 п.п.

Repository: digikam

Description

This makes Digikam being explicit in what OpenCV components are needed. This results in less number of libraries to be linked to. As a result, Digikam starts a bit faster, eats a bit less memory and makes downstream (packagers) a bit more happy. Also it helps in cases when OpenCV package is split (for example, with non-free components separated) - without explicit mentioning of what components are needed, it's not clear will Digikam link to some components or not.

Testing

OpenBSD/i386-CURRENT, KDE 4.11.5+Digikam 3.x and KDE 4.13.2+Digikam 4.x

Diffs

• CMakeLists.txt (d591a2f)

View Diff

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Vadim Zhukov]

This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119201/

On Июль 10th, 2014, 1:30 д.п. MSK, Gilles Caulier wrote:

Ok, interresting. I'm waiting your final investiguation to apply these OpenCV rules

On Июль 10th, 2014, 1:16 п.п. MSK, Vadim Zhukov wrote:

So with 4.1.0 the libkface picked up everything anyway. Something really fishy happens here. Still investigating...

On Июль 18th, 2014, 11:38 д.п. MSK, Gilles Caulier wrote:

Some progress here ?

On Июль 18th, 2014, 11:56 д.п. MSK, Vadim Zhukov wrote:

Not yet, sorry; I had some troubles during geting back home to Moscow and just arranged them. I plan to finish my investigations at the weekend.

On Июль 19th, 2014, 11:33 п.п. MSK, Vadim Zhukov wrote:

It looks like I got all pieces of puzzle right now. Because the actual problem is a complex one, I'm moving discussion to an [hidden email] mailing list, CC'ing you as you'll likely be interested in the whole picture anyway. If you're against this, I'll duplicate critical parts here.

(link to maillist archive for reference: http://marc.info/?l=openbsd-ports&m=140579940518209&w=2 )

- Vadim

On Июль 9th, 2014, 9:26 п.п. MSK, Vadim Zhukov wrote:

Review request for Digikam.

By Vadim Zhukov.

Updated Июль 9, 2014, 9:26 п.п.

Repository: digikam

Description

This makes Digikam being explicit in what OpenCV components are needed. This results in less number of libraries to be linked to. As a result, Digikam starts a bit faster, eats a bit less memory and makes downstream (packagers) a bit more happy. Also it helps in cases when OpenCV package is split (for example, with non-free components separated) - without explicit mentioning of what components are needed, it's not clear will Digikam link to some components or not.

Testing

OpenBSD/i386-CURRENT, KDE 4.11.5+Digikam 3.x and KDE 4.13.2+Digikam 4.x

Diffs

• CMakeLists.txt (d591a2f)

View Diff

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Vadim Zhukov]

This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119201/

Review request for Digikam.

By Vadim Zhukov.

Updated Июль 23, 2014, 12:34 д.п.

Changes

Force resetting OpenCV_LIBS before calling find_package() to make sure no extra libraries sneak in target_link_libraries() calls.
Limit Digikam core to only OpenCV components it really uses.

This, in particular, unbreaks building Digikam on OpenBSD, where different OpenCV components live in different packages. Before the patch, this forced to always have all OpenCV components installed, even if they aren't really needed while neither building or running Digikam.

Related reviews: https://git.reviewboard.kde.org/r/119413/ and https://git.reviewboard.kde.org/r/119414/ . All those three patches should be applied to have an effect on Digikam SC build.

Repository: digikam

Description

This makes Digikam being explicit in what OpenCV components are needed. This results in less number of libraries to be linked to. As a result, Digikam starts a bit faster, eats a bit less memory and makes downstream (packagers) a bit more happy. Also it helps in cases when OpenCV package is split (for example, with non-free components separated) - without explicit mentioning of what components are needed, it's not clear will Digikam link to some components or not.

Testing

OpenBSD/i386-CURRENT, KDE 4.11.5+Digikam 3.x and KDE 4.13.2+Digikam 4.x

Diffs (updated)

• tests/imgqsort/detectnoise/CMakeLists.txt (18ead8a)
• CMakeLists.txt (d591a2f)
• tests/imgqsort/detectblur/CMakeLists.txt (29df499)
• tests/imgqsort/detectcompression/CMakeLists.txt (73ba98d)

View Diff

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119201/

Sound like it miss something to link digiKam against OpenCV. I got an error under OSX at linking time :
In file included from /Users/gilles/Devel/GIT/4.x/core/libs/database/imgqsort/imgqsort.cpp:25:

In file included from /Users/gilles/Devel/GIT/4.x/core/digikam/utils/libopencv.h:38:

In file included from /opt/local/include/opencv2/opencv.hpp:47:

In file included from /opt/local/include/opencv2/core/core.hpp:4856:

/opt/local/include/opencv2/core/mat.hpp:538:13: warning: cast from 'uchar ' (aka 'unsigned char ') to 'short ' increases required alignment from 1 to 2 [-Wcast-align]

    return ((_Tp)(data + step.p[0]i0))[i1];

            ^~~~~~~~~~~~~~~~~~~~~~~~~~~

/Users/gilles/Devel/GIT/4.x/core/libs/database/imgqsort/imgqsort.cpp:366:31: note: in instantiation of function template specialization 'cv::Mat::at<short>' requested here

            short value = out.at<short>(i,j);

                              ^

6 warnings generated.

Linking CXX executable digikam.app/Contents/MacOS/digikam

Undefined symbols for architecture x86_64:

  "cv::GaussianBlur(cv::InputArray const&, cv::_OutputArray const&, cv::Size<int>, double, double, int)", referenced from:

      Digikam::ImgQSort::blurdetector2() const in imgqsort.cpp.o

  "cv::blur(cv::InputArray const&, cv::_OutputArray const&, cv::Size<int>, cv::Point_<int>, int)", referenced from:

      Digikam::ImgQSort::CannyThreshold(int, void) const in imgqsort.cpp.o

  "cv::Canny(cv::_InputArray const&, cv::_OutputArray const&, double, double, int, bool)", referenced from:

      Digikam::ImgQSort::CannyThreshold(int, void) const in imgqsort.cpp.o

  "cv::calcHist(cv::Mat const, int, int const, cv::_InputArray const&, cv::_OutputArray const&, int, int const, float const, bool, bool)", referenced from:

      Digikam::ImgQSort::exposureamount() const in imgqsort.cpp.o

  "cv::Laplacian(cv::_InputArray const&, cv::_OutputArray const&, int, int, double, double, int)", referenced from:

      Digikam::ImgQSort::blurdetector2() const in imgqsort.cpp.o

ld: symbol(s) not found for architecture x86_64

clang: error: linker command failed with exit code 1 (use -v to see invocation)

make[2]:  [core/digikam/digikam.app/Contents/MacOS/digikam] Error 1

make[1]:  [core/digikam/CMakeFiles/digikam.dir/all] Error 2

make: * [all] Error 2

- Gilles Caulier

On July 22nd, 2014, 8:34 p.m. UTC, Vadim Zhukov wrote:

Review request for Digikam.

By Vadim Zhukov.

Updated July 22, 2014, 8:34 p.m.

Repository: digikam

Description

This makes Digikam being explicit in what OpenCV components are needed. This results in less number of libraries to be linked to. As a result, Digikam starts a bit faster, eats a bit less memory and makes downstream (packagers) a bit more happy. Also it helps in cases when OpenCV package is split (for example, with non-free components separated) - without explicit mentioning of what components are needed, it's not clear will Digikam link to some components or not.

Testing

OpenBSD/i386-CURRENT, KDE 4.11.5+Digikam 3.x and KDE 4.13.2+Digikam 4.x

Diffs

• tests/imgqsort/detectnoise/CMakeLists.txt (18ead8a)
• CMakeLists.txt (d591a2f)
• tests/imgqsort/detectblur/CMakeLists.txt (29df499)
• tests/imgqsort/detectcompression/CMakeLists.txt (73ba98d)

View Diff

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Vadim Zhukov]

This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119201/

On Июль 23rd, 2014, 11:47 д.п. MSK, Gilles Caulier wrote:

Sound like it miss something to link digiKam against OpenCV. I got an error under OSX at linking time :
In file included from /Users/gilles/Devel/GIT/4.x/core/libs/database/imgqsort/imgqsort.cpp:25:

In file included from /Users/gilles/Devel/GIT/4.x/core/digikam/utils/libopencv.h:38:

In file included from /opt/local/include/opencv2/opencv.hpp:47:

In file included from /opt/local/include/opencv2/core/core.hpp:4856:

/opt/local/include/opencv2/core/mat.hpp:538:13: warning: cast from 'uchar ' (aka 'unsigned char ') to 'short ' increases required alignment from 1 to 2 [-Wcast-align]

    return ((_Tp)(data + step.p[0]i0))[i1];

            ^~~~~~~~~~~~~~~~~~~~~~~~~~~

/Users/gilles/Devel/GIT/4.x/core/libs/database/imgqsort/imgqsort.cpp:366:31: note: in instantiation of function template specialization 'cv::Mat::at<short>' requested here

            short value = out.at<short>(i,j);

                              ^

6 warnings generated.

Linking CXX executable digikam.app/Contents/MacOS/digikam

Undefined symbols for architecture x86_64:

  "cv::GaussianBlur(cv::InputArray const&, cv::_OutputArray const&, cv::Size<int>, double, double, int)", referenced from:

      Digikam::ImgQSort::blurdetector2() const in imgqsort.cpp.o

  "cv::blur(cv::InputArray const&, cv::_OutputArray const&, cv::Size<int>, cv::Point_<int>, int)", referenced from:

      Digikam::ImgQSort::CannyThreshold(int, void) const in imgqsort.cpp.o

  "cv::Canny(cv::_InputArray const&, cv::_OutputArray const&, double, double, int, bool)", referenced from:

      Digikam::ImgQSort::CannyThreshold(int, void) const in imgqsort.cpp.o

  "cv::calcHist(cv::Mat const, int, int const, cv::_InputArray const&, cv::_OutputArray const&, int, int const, float const, bool, bool)", referenced from:

      Digikam::ImgQSort::exposureamount() const in imgqsort.cpp.o

  "cv::Laplacian(cv::_InputArray const&, cv::_OutputArray const&, int, int, double, double, int)", referenced from:

      Digikam::ImgQSort::blurdetector2() const in imgqsort.cpp.o

ld: symbol(s) not found for architecture x86_64

clang: error: linker command failed with exit code 1 (use -v to see invocation)

make[2]:  [core/digikam/digikam.app/Contents/MacOS/digikam] Error 1

make[1]:  [core/digikam/CMakeFiles/digikam.dir/all] Error 2

make: * [all] Error 2

Probably this code is only getting compiled on OS X... I'll update the patch in a few minutes, adding "imgproc" to OpenCV COMPONENTS. The better solution would be separate linking for imgqsort, but I'm not ready to do that now.

- Vadim

On Июль 23rd, 2014, 12:34 д.п. MSK, Vadim Zhukov wrote:

Review request for Digikam.

By Vadim Zhukov.

Updated Июль 23, 2014, 12:34 д.п.

Repository: digikam

Description

This makes Digikam being explicit in what OpenCV components are needed. This results in less number of libraries to be linked to. As a result, Digikam starts a bit faster, eats a bit less memory and makes downstream (packagers) a bit more happy. Also it helps in cases when OpenCV package is split (for example, with non-free components separated) - without explicit mentioning of what components are needed, it's not clear will Digikam link to some components or not.

Testing

OpenBSD/i386-CURRENT, KDE 4.11.5+Digikam 3.x and KDE 4.13.2+Digikam 4.x

Diffs

• tests/imgqsort/detectnoise/CMakeLists.txt (18ead8a)
• CMakeLists.txt (d591a2f)
• tests/imgqsort/detectblur/CMakeLists.txt (29df499)
• tests/imgqsort/detectcompression/CMakeLists.txt (73ba98d)

View Diff

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Vadim Zhukov]

This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119201/

Review request for Digikam.

By Vadim Zhukov.

Updated Июль 23, 2014, 1:22 п.п.

Changes

Add imgproc to list of OpenCV components, should unbreak build on OS X.

Repository: digikam

Description

This makes Digikam being explicit in what OpenCV components are needed. This results in less number of libraries to be linked to. As a result, Digikam starts a bit faster, eats a bit less memory and makes downstream (packagers) a bit more happy. Also it helps in cases when OpenCV package is split (for example, with non-free components separated) - without explicit mentioning of what components are needed, it's not clear will Digikam link to some components or not.

Testing

OpenBSD/i386-CURRENT, KDE 4.11.5+Digikam 3.x and KDE 4.13.2+Digikam 4.x

Diffs (updated)

• CMakeLists.txt (d591a2f)
• tests/imgqsort/detectblur/CMakeLists.txt (29df499)
• tests/imgqsort/detectcompression/CMakeLists.txt (73ba98d)
• tests/imgqsort/detectnoise/CMakeLists.txt (18ead8a)

View Diff

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Vadim Zhukov]

This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119201/

This change has been marked as submitted.

Review request for Digikam.

By Vadim Zhukov.

Updated July 23, 2014, 10:10 a.m.

Repository: digikam

Description

This makes Digikam being explicit in what OpenCV components are needed. This results in less number of libraries to be linked to. As a result, Digikam starts a bit faster, eats a bit less memory and makes downstream (packagers) a bit more happy. Also it helps in cases when OpenCV package is split (for example, with non-free components separated) - without explicit mentioning of what components are needed, it's not clear will Digikam link to some components or not.

Testing

OpenBSD/i386-CURRENT, KDE 4.11.5+Digikam 3.x and KDE 4.13.2+Digikam 4.x

Diffs

• CMakeLists.txt (d591a2f)
• tests/imgqsort/detectblur/CMakeLists.txt (29df499)
• tests/imgqsort/detectcompression/CMakeLists.txt (73ba98d)
• tests/imgqsort/detectnoise/CMakeLists.txt (18ead8a)

View Diff

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel