I would like to be able to use the cpselect matlab tool (or a similar one) with the capability of showing both images (moving image and reference image) in RGB (I only managed to see moving image in RGB and reference image in grayscale).
Could someone point me to an alternative for this tool that would support this or anyway to be able to display both image in rgb in cpselect?
Thanks in advance.
Not sure what you're talking about, and I'm quite confused about your statement. cpselect is image independent. You can show both of them as colour or grayscale or one or the other. The example you're probably looking at is the one that comes with MATLAB: http://www.mathworks.com/help/images/ref/cpselect.html . One image is grayscale, while the other has a pinkish hue.
Here's an example showing both the source and target image as being in colour. I used onion.png that is a colour image that is part of the MATLAB system path:
im = imread('onion.png');
im_rotate = imrotate(im, 35);
cpselect(im, im_rotate);
We get:
Related
I am using OpenCV 3.0 and whenever I read an image and write it back the result is a washed-out image.
code:
cv::Mat img = cv::imread("dir/frogImage.jpg",-1);
cv::imwrite("dir/result.jpg",img);
Does anyone know whats causing this?
Original:
Result:
You can try to increase the compression quality parameter as shown in OpenCV Documentation of cv::imwrite :
cv::Mat img = cv::imread("dir/frogImage.jpg",-1);
std::vector<int> compression_params;
compression_params.push_back(CV_IMWRITE_JPEG_QUALITY);
compression_params.push_back(100);
cv::imwrite("dir/result.jpg",img, compression_params);
Without specifying the compression quality manually, quality of 95% will be applied.
but 1. you don't know what jpeg compression quality your original image had (so maybe you might increase the image size) and 2. it will (afaik) still introduce additional minor artifacts, because after all it is a lossy compression method.
UPDATE your problem seems to be not because of compression artifacts but because of an image with Adobe RGB 1998 color format. OpenCV interprets the color values as they are, but instead it should scale the color values to fit the "real" RGB color space. Browser and some image viewers do apply the color format correctly, while others don't (e.g. irfanView). I used GIMP to verify. Using GIMP you can decide on startup how to interpret the color values by format, either getting your desired or your "washed out" image.
OpenCV definitely doesn't care about such things, since it's not a photo editing library, so neither on reading nor on writing, color format will be handled.
This is because you are saving the image as JPG. When doing this the OpenCV will compress the image.
try to save it as PNG or BMP and no difference will be exist.
However, the IMPORTANT QUESTION : I am loading the image as jpg and saving it as JPG. So, how there is a difference?!
Yes, this is because there is many not identical compression/decompression algorithms for JPG.
if you want to get into some details see this question:
Reading jpg file in OpenCV vs C# Bitmap
EDIT:
You can see what I mean exactly here:
auto bmp(cv::imread("c:/Testing/stack.bmp"));
cv::imwrite("c:/Testing/stack_OpenCV.jpg", bmp);
auto jpg_opencv(cv::imread("c:/Testing/stack_OpenCV.jpg"));
auto jpg_mspaint(cv::imread("c:/Testing/stack_mspaint.jpg"));
cv::imwrite("c:/Testing/stack_mspaint_opencv.jpg", jpg_mspaint);
jpg_mspaint=(cv::imread("c:/Testing/stack_mspaint_opencv.jpg"));
cv::Mat jpg_diff;
cv::absdiff(jpg_mspaint, jpg_opencv, jpg_diff);
std::cout << cv::mean(jpg_diff);
The Result:
[0.576938, 0.466718, 0.495106, 0]
As #Micha commented:
cv::Mat img = cv::imread("dir/frogImage.jpg",-1);
cv::imwrite("dir/result.bmp",img);
I was always annoyed when mspaint.exe did the same to jpeg images. Especially for the screenshots...it ruined them everytime.
I have grayscale satellite image which is processed from spectral data (band classifications). If i use jet colormap in imshow it will show absolute colormapped image. But if i try to imwrite in particular place it is saved like a bluish image. I saw one example in matlab central, but i didnt get. can anyone help me to write my image with colorscaled image.
Matlab central link: http://www.mathworks.in/matlabcentral/answers/25026-saving-grayscale-image-as-it-appears-in-jet-colormap-of-imagesc
there accepted answer link is : http://www.mathworks.com/matlabcentral/fileexchange/7943
I have tried many times, this will show colormaped images in plots (imshow) they didnt write anywhere with colormaped. Now i want to write my image with colormaped.
example code:
I= imread('image path');
imshow(I,'colormap',jet);
imwrite(I,'path','jpg'); /not working
or
imwrite(I,jet,'path','jpg'); /not working
Please help to solve this issue.
When you use imshow the colormap is always adjusted to the range of values in your image. imwrite however assumes your image has a value range of [0,1] if you are using single or double data types. Try to scale your image to the range [0,1] before saving.
If you provide a colormap in the call to imwrite, MATLAB assumes you are using an indexed image. Thus you will have to convert the image to the indexed format first. The following snippet worked for a test image I of mine:
% scale to [0,1]
I = I - min(I(:));
I = I ./ max(I(:));
% Create indexed image
[J,~] = gray2ind(I);
% Save image
imwrite(J,jet,'path','jpg');
Solution by hbaderts worked well for me, but later I found out that some images were still scaled slightly different way from imshow.
However, I might found a reason of an original problem. Just after Matlab starts, its default colormaps (including 'jet') are set to 64 colors (64x3). Then, if any image is shown with a colormap, for example if imshow('cameraman.tif'), colormap('jet') is executed, all default colormaps become 256x3 (can be verified with jetMap=jet; before and after). Then it might happen that an image was written with a colormap different from the one applied to image figure (for example, if a figure called after imwrite).
Finally I found this solution (no image pre-scaling needed):
% Create indexed image, explicitly using 256 colors
imInd=gray2ind(im,256);
% Convert indexed image to RGB using 256-colors jet map
jetRGB=ind2rgb(imInd,jet(256));
% Save image
imwrite(jetRGB,'jet.png');
The images I used have the same color scale now, both the saved one and the one shown in figure.
I noticed that when displaying jpg or png images they look alot like a GIF file in that there is limited colors and "banding".
You can see the original and a screenshot attached. Kinda hard to tell scaled down but you can see it.
Actually better example. See the banding around the circle?
Here is my code:
#pygame code to render an image
import pygame, os
import time
image = 'gradient-test.png' #located in same folder as this file:resized in Photoshop
pygame.init() #I assume you did this?
SCREEN = pygame.display.set_mode((1366, 768))
pygame.mouse.set_pos((1366, 768))
picture = pygame.image.load(image)
SCREEN.blit(picture,(0,0))
pygame.display.update()
time.sleep(5)
It seems like a problem with the pixel format of your surface. You can add the following lines to your script to see if there's a difference between the pixel format of your image surface and your screen surface:
print 'picture', picture.get_bitsize()
print 'screen', SCREEN.get_bitsize()
It's good practice and recommended to always change the pixel format of any new surface to the pixel format of your screen surface by calling convert():
convert()
change the pixel format of an image
convert(Surface) -> Surface
Creates a new copy of the Surface with the pixel format changed ...
If no arguments are passed the new Surface will have the same pixel format as the display Surface. This is always the fastest format for blitting. It is a good idea to convert all Surfaces before they are blitted many times.
It's simple:
picture = pygame.image.load(image).convert() # added convert() call
Also, you can try to set the color depth of your screen manually, like:
SCREEN = pygame.display.set_mode((1366, 768),0, 32) # use 32-bit color depth
I have read pixel values of an raster image using GDAL libraries in visual studio 2010(vc++).
Next is , I have to crop the image (subset) according to the grid given in shape file.
Forget about the grid this time.
I just want to clip square or rectangular area and save to new file.
I have read some documents which suggest about gdal_translate and gdal_warp function to use but it can only be run in python where as i want to use c++.
Please help me as early as possible.
I have solved the problem of cropping the image using VC++ with gdal libraries. I have created VRTDataset of my desired size of raster to be cropped and then save it using CreateCopy().
Here is an image:
This image is a simple black-to-transparent gradient saved in full RGBA PNG.
Here is the same image, converted to indexed-alpha PNG by GIMP (Photoshop produces the same result)
As you can see, the gradient is now half-opaque, half-transparent.
Here is the same image again, only this time it was converted to indexed-alpha PNG by a PHP script I wrote:
So my question is: Why are GIMP and Photoshop unable to support partial transparency in indexed images, when the PHP script clearly shows that such an image can be created with no problems?
Is there anything "wrong" with an image whose pallette contains alpha information?
A more programming-related question: Does this transparency in the last image work in Internet Explorer 6?
I've finally found the actual answer: There is a metadata entry that allows you to define the alpha value of each colour in the colour table. Most graphics programs don't make use of this, but it does exist and can be used, in particular by GD.
Another option besides fireworks is pngquant, a command line application that will convert a rgba png into an indexed png with transparency.
I found this post which talks some more about how to use it.
IE6 and earlier in windows does not support variable transparency PNGs without annoying workarounds. An indexed PNG will only show the fully opaque parts which usually works pretty well. A drop shadow would disappear but the opaque parts of the logo or icon would continue to show.
This page has a better explanation and instructions with more png compression and quantization tools: http://calendar.perfplanet.com/2010/png-that-works/
For the record, PNG does not literally support indexed images with an alpha channel. What is really happening is that PNG allows you to add additional colors to the color table (i.e. index) with alpha values in those colors... not a complete alpha channel. FWIW...
Yeah I know what you mean. Fireworks is the only image editing program that I know of that can create and edit PNG8+Alpha without problems. I wish more paint programs would support this format cause Fireworks is expensive!
I found a way in GIMP to create or convert an image with reduced color palette and alpha channel.
The trick is to add a mask to the layer.
Full steps to reproduce:
Have your image in one layer
Add a mask to the layer. Select Transfer layer's alpha channel.
Convert to Indexed (Image -> Mode -> Indexed...)
Save as PNG
Now your image has reduced colors and reduced size, but it keeps your smooth transparency.