Skip to content

Add input_grayscale_image_pyramid, issue #354#1761

Merged
davisking merged 8 commits into
davisking:masterfrom
facug91:add_input_grayscale_image_pyramid
May 25, 2019
Merged

Add input_grayscale_image_pyramid, issue #354#1761
davisking merged 8 commits into
davisking:masterfrom
facug91:add_input_grayscale_image_pyramid

Conversation

@facug91
Copy link
Copy Markdown
Contributor

@facug91 facug91 commented May 9, 2019

Issue #354
I'm doing some test with it, I'll be uploading a performance comparison tomorrow using it in the mmod (the training takes several hours).
In the meantime I wanted to create the pull request, to be sure it's a good contribution, and to start reviewing the code.

@davisking
Copy link
Copy Markdown
Owner

Thanks for the PR. The code looks correct. You should use spaces instead of tabs though. And if you could figure out how to reduce the code duplication that would be good too, like making a base class that contains most of the code and is inherited from.

@facug91
Copy link
Copy Markdown
Contributor Author

facug91 commented May 10, 2019

Sorry about the tabs, I've fixed it already.
About the hierarchy, what I could do is create a base class input_image_pyramid, which implement all methods except to_tensor, and all those related to serialization, which would go to the derived classes. Does this seem better for you?
The problem is that to_tensor is a template member function, so I can not specialize it in derived classes.
One more thing. If the above is good for you, what would be the correct way to document it in the abstract?

@davisking
Copy link
Copy Markdown
Owner

Sorry for the late reply. Yeah, that sounds fine. Don't use any virtual functions, you can just publicly inherit from the base class to get all the methods. As for to_tensor, yeah, that's not really sharable. But their are parts of it that could be trivially moved into protected helper methods in the base class and called from derived classes.

I wouldn't mention this inheritance in the documentation at all. It's an implementation detail users don't need to know about.

@facug91
Copy link
Copy Markdown
Contributor Author

facug91 commented May 17, 2019

With this commit I've create a base clase input_image_pyramid, which has the common methods of the derived classes.

@facug91
Copy link
Copy Markdown
Contributor Author

facug91 commented May 17, 2019

And now I've refactored to_tensor method, to move repeated code to base class.

@facug91
Copy link
Copy Markdown
Contributor Author

facug91 commented May 17, 2019

Some benchmarking I've made:

rgb grayscale
640x360 18.14 us 16.05 us
400x300 10.31 us 9.22 us

It is around 11% faster.

Copy link
Copy Markdown
Owner

@davisking davisking left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, just a few minor things and it's ready to merge.

Comment thread dlib/dnn/input.h Outdated
Comment thread dlib/dnn/input.h
Comment thread dlib/dnn/input.h Outdated
Comment thread dlib/dnn/input.h Outdated
Comment thread dlib/dnn/input_abstract.h Outdated
@davisking
Copy link
Copy Markdown
Owner

Sweet, looks good. Thanks for the PR :)

@davisking davisking merged commit 8001b92 into davisking:master May 25, 2019
@facug91 facug91 deleted the add_input_grayscale_image_pyramid branch May 26, 2019 23:11
bkornel added a commit to bkornel/dlib that referenced this pull request Sep 18, 2019
* Fixed compiler warnings

* Include the Intel MKL's iomp dll in the output folder to reduce confusino for windows users.

* Fixed build error in newer clang on OpenBSD.

* Fixed constness for lapack functions (davisking#1737)

* disable annoying warning

* Fixed global_function_search's initialization being wrong if explicitly
given an empty list of initial function evaluations.

* Suppress compiler warnings

* Make things work in visual studio.

* fix some pedantic warnings (davisking#1756)

* fix some pedantic warnings

* remove unneeded assert

* more pedantic silencing (davisking#1763)

* prevent GCC from complaining about this unused parameter

* Even more warning silencing (davisking#1766)

These warnings occurred when building the semantic segmentation
examples

* iEnsures DLIB_FALLTHROUGH macro is only set for GCC>=7 (davisking#1770)

* Feature/upgrade libjpeg (davisking#1769)

* Upgrades dlib's included libjpeg to version 8d

* Overloads load_jpeg to read from memory buffer

* Removes "__inline__" define in jconfig, broke VC build

* Changes buffer size type to size_t

* Adds a comprehensive error message when jpeg loading fails.

* Disable use of non-memory based backing store in libjpeg.  This fixes
libjpeg not being able to open some types of jpeg file.

* Stop building parts of libjpeg we don't need.

* Add input_grayscale_image_pyramid, issue davisking#354 (davisking#1761)

Add input_grayscale_image_pyramid

* Added methods for getting keyboard and mouse clicks to image_window's pyhton API.

* Fixed pytest broken dependencies

* Fix python setup warnings

* Revert "Fixed pytest broken dependencies"

Apparently pytest is still sort of busted.

This reverts commit 5e63d01.

*  Fix setting a point's y coordinate changes x instead (Python bindings) (davisking#1795)

* Add point assignment test

* Fix setting points y coordinate changes x instead (issue davisking#1794)

* Push all include and link options needed for dlib to pkg-config.  We do this by getting them from the same list cmake uses.

* Fixed incorrect return type

* Fixed grammar in comments

* Added missing include

* fixed typo in docs

* fix mismatch between documentation and implementation (davisking#1835)

* Fixed cmake warning

* fixing grammar

* Fix the CMake BUILDING_PYTHON_IN_MSVC variable not getting picked up where it should.

* pybind11: cmake: ignore the check between host-python and cross-compiler (davisking#1848)

When dlib is compiling, cmake will compare python architecture and target
architecture. So in cross-compiling case, it is irrevelant because host and
target architecture often differs. The main problem come from checking python
architecture on host and not on target.

Here is an error when compiling dlib from x86_64 to arm 32-bit target :
```
Python config failure: Python is 64-bit, chosen compiler is 32-bit
```

So :
- Skipping the comparation when cross-compiling is enabled.

Signed-off-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Alexandre PAYEN <alexandre.payen@smile.fr>

* Const-correct a LAPACK declaration and add aarch64 as a 64-bit architecture (davisking#1859)

* Added aarch64 to list of 64-bit architechtures

* Const-corrected declaration of ssyevr

* Fix davisking#1849 by calling device_global_buffer() unconditionally (davisking#1862)

* Hold on to the CUDA buffer - second try
see: davisking#1855 (comment)

* Fix davisking#1849 by calling device_global_buffer() unconditionally

* Simplified the device_global_buffer() code and API.

* don't cast away constness (davisking#1865)

* dpoint mutates x-coord in y-property (see davisking#1794) (davisking#1866)

* add loss_mean_squared_per_channel (davisking#1863)

add loss_mean_squared_per_channel_and_pixel

* Clear truth_idxs between samples (davisking#1870)

* Clear truth_idxs between samples

* Move truth_idxs inside loop body after all

* Push to truth_idxs even when the box can't be detected; improve formatting

* Add an option to force static runtime (davisking#1847)

* dos2unix tell_visual_studio_to_use_static_runtime.cmake

* Add an option to force static runtime
nidegen pushed a commit to kapanu/dlib that referenced this pull request Sep 23, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants