GitLab

copies of libpng or libjpeg, instead, use the copies what come with dlib.  We
are doing this because too many Visual Studio users have busted copies of these
libraries on their machines.  This will make things just always work.

* Problem: see #1513 (https://github.com/davisking/dlib/issues/1513)
Candidate solution: busy-loop until cudaStreamQuery returns cudaSuccess

* Make the suggested fix a Windows-only thing

* Fix for "warning C4724: potential mod by 0" in matrix.h

* Fixed random_forest_regression.h warnings

* Added weighted labels to loss_binary_log

* Added weighted labels to loss_binary_log

* Clarified docs.

* clarified docs

* added scale_image python binding which returns an image resized by the provided scale factor

* added scale_rect for rectangle and drectangle. returns a rectangle scaled by the provided scaling factor

* - do not cast scale_rect coordinates to long for drectangle
- document scale_rect for drectangle and rectangle in _abstract.h
- change python binding scale_image to resize_image
- update documentation for resize_image to describe behaviour

Add the __virtual_inheritance keyword to dummy struct when compiling with MSVC.

the asserts that DLIB_USE_CUDA must be defined.  This only matters for users who try to
install dlib and use some build system that doesn't define DLIB_USE_CUDA, and so therefore need
dlib/config.h to define it for them.

With C++17 enabled on VS15.6+, this triggered a nodiscard warning which led to failed builds when warnings as errors is enabled.

have_same_dimensions() to be uncallable for images, so that's fixed now too.

particular, it wasn't being used in some parts of the Python API.  So this
change makes the HOG detector run like 10% faster for instance.