OpenCV imwrite gives washed-out result for jpeg images - image

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.

Related

How Do I Convert Palette-Based PNG with Transparency To RGB in PIL?

I'm currently building a site in app engine that uploads images to google cloud storage and to complete basic manipulations I'm using python's PIL
I've been having problems with the following image which another stackoverflow member has mentioned is a palette-based PNG with transparency, which I've been reading may be a bit buggy in PIL
My question is really a back to basics one: What is the best way to convert this to an RGB format with transparent pixels set to #FFF? I've been able to get it to work through a combined RGBA then RGB paste but that seems redundant
However, for a direct conversion I'm getting a bad transparency mask i.e. using the solution from PIL Convert PNG or GIF with Transparency to JPG without
Also if anybody has ideas why the image degrades to terrible quality after conversion, that's entirely a bonus for me!
A way to do this is to first convert the file to jpg -- seems like a problem with the png encoding (or something related to that)
Check out this link that I used and got smooth conversion from transparent PNG to GIF:
Convert RGBA PNG to RGB with PIL
The function you are looking for is pure_pil_alpha_to_color_v2.
I also used for my image conversion tool PySmile:
https://github.com/vietlq/PySmile/blob/master/pysmile.py

Matlab cpselect with RGB fixed image

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:

Uncrush PNG image on ubuntu?

IPA image uses pngcrush to compress PNG image, but I want to uncrush a PNG image on Ubuntu.
Can anyone give me any idea?
The standard PNG utility pngcrush has been modified by Apple, which makes it produce technically invalid PNGs: a new chunk is inserted before the mandatory first chunk IHDR, RGB(A) order of pixel data is inverted, and RGB pixels get premultiplied with their alpha.
Hence, I'd rather call these PNGs "fried", rather than just "crushed".
Try my own pngdefry. The source code is written on a Mac OSX machine but it should be compilable for other OSes as well; it's pretty straightforward C code.

Compositing PNG onto JPEG fails (colors are all rendered as black) on only one particular JPEG file

I'm building an application which uses Ruby+RMagick to composite PNG images onto various JPEG backgrounds. Everything is working, but we have found one particular JPEG background for which the PNG is composited as a black spot. PNG transparency is respected; the shape of the "spot" is correct, but the colors are being lost and becoming black.
I have tried many JPEGs to try to find another which yields the same result, but (so far) have failed.
I suspect that it may have something to do with the bit depth or some other parameter of the JPEG file in question. I have been searching the Internet, looking for a tool which can analyze this JPEG and tell me all the parameters which might be relevant, but haven't found anything yet.
Has anything like this ever happened to you? What was the cause?
Based on your knowledge of the JPEG format, are there any other parameters which might be relevant?
Do you know of any tool which can analyze JPEG files, and tell me the bit depth and other parameters? Or if I open the JPEG in a hex editor, can you tell me how to find this information?
I still haven't found what is special about that one JPG which the composite operation doesn't work correctly on, but I worked around it using this code:
back = Magick::Image.from_blob(jpg_data).first
png = Magick::Image.from_blob(png_data).first
page1 = Magick::Image.new(back.columns, back.rows)
page1.composite!(back, 0, 0, Magick::OverCompositeOp)
page1.composite!(png, png_x, png_y, Magick::OverCompositeOp)
Rather than:
back = Magick::Image.from_blob(jpg_data).first
png = Magick::Image.from_blob(png_data).first
page1 = back.composite(png, png_x, png_y, Magick::OverCompositeOp)

Alpha transparency in indexed-png images

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.

Resources