m-aXimilian
b37814204f
* get image returns optional<Mat> instead of unique_ptr<Mat> * introduce complexity * rename image load function * add example for a basic reader for binary image files * fix windows build? * add a status bar underneath the menu bar * use status bar in custom_0 example app * clang formats * packing w/ pragma push * add "Save As" functions to image views * resize over reserve * rm local override uri * add simple thread pool * rename to simple_thread_pool * get rid of useless renderlib * document version inc * extract hardcoded values to in-header * clang format patch * clone registered image in custom_0 * document binary-file header * minor fixes * clang format * rm unused render cmake
27 lines
1.0 KiB
C++
27 lines
1.0 KiB
C++
#include "PixelariumMem.hpp"
|
|
|
|
#include <filesystem>
|
|
#include <memory>
|
|
#include <opencv2/imgcodecs.hpp>
|
|
#include <string>
|
|
|
|
pixelarium::imaging::PixelariumMem::PixelariumMem(const cv::Mat& img, const std::string& name, const Log& log)
|
|
: img_(img), log_(log), name_(name)
|
|
{
|
|
this->is_empty_ = false;
|
|
this->uri_ = std::filesystem::path();
|
|
}
|
|
|
|
std::optional<cv::Mat> pixelarium::imaging::PixelariumMem::TryGetImage()
|
|
{
|
|
// ToDo: this craving for a revision of the whole concept:
|
|
// the interface requires a unique_ptr here. This concept was designed to "create an in-memory image on demand" sort
|
|
// of.
|
|
// I.e., it only makes sense for the file types that do not already manage a cv::Mat in memory.
|
|
// PixelariumMem is meant for exactly this in-memory management of a cv::Mat though.
|
|
// So, returning a unique_ptr from it in the following semantic essentially calls the
|
|
// copy constructor of cv::Mat. This is potentially not "super bad", but at least it requires attention at some
|
|
// point.
|
|
return this->img_;
|
|
}
|