Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CV_16U support #184

Open
mlee980 opened this issue Jun 4, 2017 · 4 comments
Open

CV_16U support #184

mlee980 opened this issue Jun 4, 2017 · 4 comments

Comments

@mlee980
Copy link

mlee980 commented Jun 4, 2017

Hi, sorry to bring this up again. It was asked before: https://github.com/VisionLabs/torch-opencv/issues/94 but it seems that the fix in Torch7 (torch/torch7#566) has not been release yet, I couldn't find it in the latest release.

I am facing the same problem: write and read 16bit grayscale images. any help is appreciated.

@shrubb
Copy link
Contributor

shrubb commented Jun 5, 2017

Hi! You can read 16-bit images. Wrappers convert them to 32-bit float with [0..1] values. However, indeed, you can't save into a 16-bit image via torch-opencv. That's because right now it's impossible to handle them in Torch (data type missing).
I can implement a temporary cv.imwrite16bit() workaround if you really need to have 16-bit images saved.

@mlee980
Copy link
Author

mlee980 commented Jun 6, 2017

thanks for the feed back. I have a work-around for now: use c/c++ code to write 16U 16-bit images.
But I also noted that for reading 16U images, you converted to 32F and NORMALIZED the values to [0...1.0]:

// See #94
if (matArg.depth() == CV_16U) {
    matPtr = new cv::Mat;
    matArg.convertTo(*matPtr, CV_32F, 1.0 / 65535);
    this->typeCode = CV_32F;
} else {
    matPtr = &matArg;
    this->typeCode = static_cast<char>(matArg.depth());
}

I think it would be better to keep the values as they are, just convert from 16U to 32F, at least for me application.

@mlee980
Copy link
Author

mlee980 commented Jun 8, 2017

one other issue related to this: for single channel images, like the one above, it returns a HxW image, instead a HxWxC(=1) image. that would break the image:size(3) code. wouldn't it be better to have the HxWxC(1) format? that would be more consistent.

@shrubb
Copy link
Contributor

shrubb commented Jun 8, 2017

Hmm, yes, probably this is a good improvement, I (or someone else) should do this. Will try to work on it as possible, help appreciated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants