I'm currently using FreeImage to load PFMs into a program that otherwise uses IplImages (the old data type for OpenCV). Here's a sample of what I'm doing (ignore the part about img being an array of Mats, that's related to some other code).
FIBITMAP *src;
// Load a PFM file using freeimage
src = FreeImage_Load(FIF_PFM, "test0.pfm", 0);
Mat* img;
img = new Mat[3];
// Create a copy of the image in an OpenCV matrix (using .clone() copies the data)
img[1] = Mat(FreeImage_GetHeight(src), FreeImage_GetWidth(src), CV_32FC3, FreeImage_GetScanLine(src, 0)).clone();
// Flip the image verticall because OpenCV row ordering is reverse of FreeImage
flip(img[1], img[1], 0);
// Save a copy
imwrite("OpenCV_converted_image.jpg", img[1]);
What's strange is that if I use FreeImage to load JPEGs instead by changing FIF_PFM to FIF_JPEG and CV_32FC3 to CV_8U, this works fine, i.e. the copied picture comes out unchanged. This makes me think that OpenCV and FreeImage generally agree on the ordering of RGB channels, and that the problem is related to PFMs specifically and their being a non-standardized format.
The PFMs I'm loading were written with this code (under "Local Histogram Equalization"), which appears to write them in RGB order although I could be wrong about that. It just takes the data from a MATLAB 3D matrix of doubles and dumps it into a file using fwrite. Also, if I modify that code to write PPMs instead, then view them in IrfanView, they look correct.
So, that leaves me thinking FreeImage is taking the file data to be BGR ordered on disk already which it is not, and should not be.
Any thoughts? Is there an error in FreeImage's reading of PFMs, or is there something more subtle going on here? Thanks.
Well, I never really got this one sorted out; long story short, FreeImage and OpenCV agree on color channel order (BGR) when loading most image formats, but not when loading PFMs. I can only assume that the makers of FreeImage have therefore misinterpreted the admittedly not very solidified specs for PFMs. Since I was only using FreeImage to read/write PFMs, and it was proving quite complicated to get data back into a FreeImage structure after processing with OpenCV functions, I wrote my own PFM read/write code which turned out to be very simple.
Related
I'm working with fastai, trying to pass some images to a dataloader. The original images are kind of pinkish, but after passing them they appear mostly as green-black (see image in link below):
Original pinkish image (up) and example images (down) after passing them to dataloader, and the code.
The code I've used for the datablock and to show the images is:
example = DataBlock(
blocks=(ImageBlock, CategoryBlock),
get_items=get_image_files,
splitter=GrandparentSplitter(),
get_y=parent_label,
item_tfms=Resize(128)) #already tried it without item_tfms just in case, still black-green
dls = example.dataloaders(path)
dls.show_batch(nrows=1, ncols=3)
I tried with .tif and .jpeg images, and both show the same problem. The only thing that comes to my mind is that somewhat somewhere is not reading correctly the color format (RGB according to my original files), or maybe transforming it; but I'm not able to figure it out.
Just in case it's important, I'm working in a Jupyter notebook with a MackBook Air M1.
Thanks!
Irene
can anyone help me to save my resulted images by using imwrite
source = 'C:\Y\';
im_number=5;
for i=1:5
image{i}=im2double(imread([source,'Carbon_', num2str(i)],'tif'));
image{i}=double(image{i});
B{i}= Sftfun(image{i});
B{i}=uint32(B{i});
imwrite(B{i},[source,'face_', num2str(i)],'tif');
end
The problem with your code is that you are casting your image to uint32. If you are trying to save your image as a TIF file, you can only save it as 8-bit or 16-bit. Consulting the MATLAB documentation, you can only save with these two bit depths. 32-bit depths are not supported.
Consult the MATLAB documentation for more details: http://www.mathworks.com/help/matlab/ref/imwrite.html
As such, either cast the image as 8-bit or 16-bit (through im2uint8 or im2uint16), or normalize your image so that it goes from [0,1] (through im2double).
I also have some comments about your code that do need fixing for readability:
Do not save your images to a cell array called image. MATLAB has a built-in command called image which takes in a matrix and displays it to the screen for you as an image. Bear in mind this is not the same as imshow. By doing this assignment, you will shadow over the actual image command, and so any scripts that rely on this function will result in an error.
im_number seems to be an unused variable. I'm not sure what its purpose is, but I'd say it's safe to remove this statement as well.
Get rid of the following statement as you are already converting the image to a double type in the previous line:
image{i} = double(image{i});
Aside
It seems that you have asked a similar question here: save tif 32 bit images by using imwrite
This question has already been resolved in that you are not able to save 32-bit images using imwrite. However, someone in this thread has posted a workaround for you to use in MATLAB. Try using that instead of imwrite.
I want to put/wrap images to 3D objects. To keep things simple and fast, instead of using(and learning) a 3D library I want to use mapping images. Mapping images are used in such a way:
So you generate the mapping images once for each object and use the same mapping for all images you want to wrap.
My question is how can I generate such mapping images (given the 3D model)? Since I don't know about the terminology my searches failed me. Sorry if I am using the wrong jargon.
Below you can see a description of the workflow.
I have the 3D model of the object and the input image, i want to generate mapping images that I can use to generate the textured image.
I don't even know where to start, any pointers are appreciated.
More info
My initial idea was to somehow wrap a identity mappings (see below) using an external program. I have generated horizontal and vertical gradient images in Photoshop just to see if mapping works using photoshop generated images. The result doesn't look good. I wasn't hopeful but it was worth a shot.
input
mappings (x and y), they just resize the image, they don't do anything fancy.
result
as you can see there are lots of artifacts. Custom mapping images I have generated by warping the gradients even looks worse.
Here is some more information on mappings: http://www.imagemagick.org/Usage/mapping/#distortion_maps
I am using OpenCV remap() function for mapping.
if i understand you right here, you want to do all of it in 2D ?
calling warpPerspective() for each of your cube surfaces will be much more successful, than using remap()
pseudocode outline:
// for each surface:
// get the desired src and dst polygon
// the src one is your texture-image, so that's:
vector<Point> p_src(4), p_dst(4);
p_src[0] = Point(0,0);
p_src[1] = Point(0,src.rows-1);
p_src[2] = Point(src.cols-1,0);
p_src[3] = Point(src.cols-1,src.rows-1);
// the dst poly is the one you want textured, a 3d->2d projection of the cube surface.
// sorry, you've got to do that on your own ;(
// let's say, you've come up with this for the cube - top:
p_dst[0] = Point(15,15);
p_dst[1] = Point(44,19);
p_dst[2] = Point(56,30);
p_dst[3] = Point(33,44);
// now you need the projection matrix to transform from one to another:
Mat proj = getPerspectiveTransform( p_src, p_dst );
// finally, you can warp your texture to the dst-polygon:
warpPerspective(src, dst, proj, dst.size());
if you can get hold of the 'Learning Opencv' book, it's described around p 170.
final word of warning, since youre complaining about artefacts, - yes, it'll all look pretty cheesy, 'real' 3d engines do a lot of work here, subpixel-uv mapping, filtering,
mipmapping, etc. if you want it to look nice, consider using the 'real' thing.
btw, there's nice opengl support built into opencv
To achieve what you are trying to do, you need to render the 3D-models UV to a texture. It will be easier to learn to render 3D than to do things this way. Especially since there are a lot of weaknesses in your aproach. difficult to to lighting and problems til the depth-buffer will be abundant.
Assuming all your objects shul ever only be viewed from one angle, you need to render each of them to 3 textures:
UV-map
Normal-map
Depth-map (to correct the depth-buffer)
You will still have to do shading in order to draw these to look like your object, and I don't even know how to do the depth-buffer-thing, I just know it can be done.
So in order to avoid learning 3D, your will have to learn all the difficult parts of 3D-rendering. Does not seem the easier route...
I know how to do it the other way around. But how can I create a CIImage from a texture, without having to copy into CPU memory? [CIImage imageWithData]? CVOpenGLESTextureCache?
Unfortunately, I don't think there's any way to avoid having to read back pixel data using glReadPixels(). All of the inputs for a CIImage (data, CGImageRef, CVPixelBufferRef) are CPU-side, so I don't see a fast path to deliver that to a CIImage. It looks like your best alternative there would be to use glReadPixels() to pull in the raw RGBA data from your texture and send it into the CIImage using -initWithData:options: and an kCIFormatRGBA8 pixel format. (Update: 3/14/2012) On iOS 5.0, there is now a faster way to grab OpenGL ES frame data, using the new texture caches. I describe this in detail in this answer.
However, there might be another way to achieve what you want. If you simply want to apply filters on a texture for output to the screen, you might be able to use my GPUImage framework to do the processing. It already uses OpenGL ES 2.0 as the core of its rendering pipeline, with textures as the way that frames of images or video are passed from one filter to the next. It's also much faster than Core Image, in my benchmarks.
You can supply your texture as an input here, so that it never has to touch the CPU. I don't have a stock class for grabbing raw textures from OpenGL ES yet, but you can modify the code for one of the existing GPUImageOutput subclasses to use this as a source fairly easily. You can then chain filters on to that, and direct the output to the screen or to a still image. At some point, I'll add a class for this kind of data source, but the project's still fairly new.
As of iOS 6, you can use a built-in init method for this situation:
initWithTexture:size:flipped:colorSpace:
See the docs:
http://developer.apple.com/library/ios/#DOCUMENTATION/GraphicsImaging/Reference/QuartzCoreFramework/Classes/CIImage_Class/Reference/Reference.html
You might find these helpful:
https://developer.apple.com/library/ios/#samplecode/RosyWriter/Introduction/Intro.html
https://developer.apple.com/library/ios/#samplecode/GLCameraRipple/Listings/GLCameraRipple_RippleViewController_m.html
In general I think the image data will need to be copied from the GPU to the CPU. However the iOS features mentioned above might make this easier and more efficient.
I have an OpenCV matrix of double (CV_32F) values. I'd like to save it to the disk. I know, I could convert it to an 1-Channel 8-bit IplImage and save it. But that way, I loose precision. Is there a way to save it directly in the 32-bit format, without having to convert it first? It also would be nice, if the resulting file would have an image format, so I can view the result as an image.
You can always save any "object" (CvMat, IplImage, anything..) from OpenCV "as is" by using cvSave() and loading it back with cvLoad(). As to my experience, most floating-point image stuff does not work correctly, I usually save my floating point data this way.
However, you cannot directly view the stored data.
Another possibility we have used frequently is including an own built of OpenEXR. You can easily store full precision floating point images using this library and many third party applications are able to open EXR files. Note that OpenCV includes OpenEXR, if i am not mistaken, but the last time i've tried, saving/loading floating point images did not work correctly. However, you should first try to save an fp image as *.exr, maybe that already does the magic with recent versions.
You could always iterate over the matrix and write it out yourself. If you want it to be viewable as an image, you can use a variant of PPM. I'm not sure what programs would be able to natively read your image format if you use values out of the 0-255 range though.
This is old, but thought I'd throw in my two cents.
If you just want to save float images to disk, and you don't need to view them, you may want to look at Portable Float Map (PFM) image format. Very simple format, just saves floats to disk, no compression, minimal header. You can write your own read/write code for this very quickly. That's what I'm using for HDR research.
As the others pointed out, to "view" float images you need to ask yourself some questions about their contents and how to sensibly scale them back into an 8-bit range you can display on your monitor. You might consider Matlab's image viewer (imshow function) which offers some double scaling functionality.
You might also consider saving to either EXR or HDR format and using Photomatix's built-in HDR image viewer which gives you a little separate window that shows you a real-time tonemapped window around your current cursor position. It's a good way to navigate an HDR or floating point image to get a sense of "what's really there" without tonemapping the whole thing.