title: OpenCV cv::imwrite causes memory leak
body: <p>I'm writing some OpenCV code to write any <code>cv::Mat</code>(s) in a queue to a file. Unfortunately, the calls to <code>cv::imread</code> seem to be causing a memory leak. When those lines are commented out, no memory leak occurs.</p>
  
  <pre><code>void ck::file_pipe_handler() {
      std::vector&lt;int&gt; compression_params;
      compression_params.push_back(CV_IMWRITE_PNG_COMPRESSION);
      compression_params.push_back(0);
      while (true) {
          std::unique_lock&lt;std::mutex&gt; pop_lock(
              file_pipe_mutex, std::defer_lock);
          if (file_pipe.empty()) {
              usleep(10);
              continue;
          }
          pop_lock.lock();
          frame_details frame_deets = file_pipe.front();
          file_pipe.pop();
          pop_lock.unlock();
  
          auto base_dir = output_file_name + "/" + frame_deets.serial_number;
          auto rgb_reg_dir = base_dir + "/rgb_registered/";
          auto rgb_raw_dir = base_dir + "/rgb_raw/";
          auto depth_dir = base_dir + "/depth/";
  
          // If you comment out the imwrite calls here,
          // the memory leak does not occur
          if (register_rgb)
              cv::imwrite(rgb_reg_dir + std::to_string(frame_deets.timestamp_rgb)
                          + ".png", frame_deets.frame_registered.first);
          cv::imwrite(rgb_raw_dir + std::to_string(frame_deets.timestamp_rgb)
                      + ".png", frame_deets.raw_rgb);
          cv::imwrite(depth_dir + std::to_string(frame_deets.timestamp_depth)
                      + ".png", frame_deets.frame_registered.second, compression_params);
  
          frame_deets.raw_rgb.release();
          frame_deets.frame_registered.first.release();
          frame_deets.frame_registered.second.release();
      }
  }
  </code></pre>
  
  <p>I added the release calls to the end just to make sure that the <code>cv::Mat</code>(s) are correctly freed. Also I'm certain that the queue isn't filling up. I'm using OpenCV 3.1.</p>