JPEGs are smaller in size than PNGs. So, I thought that if I can make a specific region in a JPEG-file transparent, with some code, maybe I can save some bytes.
So does anyone know how to achieve this with for example PHP or JavaScript?
No. You can't do this. JPGs do not support alpha channels and have no capacity to designate certain colors as transparent either (GIF-style).
There's several issues with this, all of them have to do with that JPEG is a lossy compression format. The JPEG format is optimized for natural images and sharp edges will get blurred. If you intend that a specific pixel should have the value #d67fff there's no guarantee that after color conversion, FDCT, quantization, IDCT and color conversion, the pixel still will have that value. There's also a strong possibility that that pixel value will occur in areas that you don't want.
No. JPEG does not support transparency and is not likely to do so any time
soon. http://www.faqs.org/faqs/jpeg-faq/part1/section-12.html
You cannot do that, the client renders the image and doesn't know that you want it to treat that color as transparent (plus various compression methods on jpeg wouldn't work well with transparencies anyway).
I believe you can go with an 8-bit custom-pallet png, should save you a lot of space. Otherwise 24-bit PNG is your only high color option.
You can convert your image to SVG containing a color information as JPEG and an alpha channel as grayscale mask. Here is a tool I wrote to do it https://github.com/igrmk/transpeg
Related
Can a PNG file's data be loaded in a certain order, say beginning with one RGBA channel, then the rest?
Perhaps similar to how JPG files can, sometimes using custom codecs, store their data as "scans" or "slices", that are loaded progressively, sequentially or interleaved, at first displaying black and white, followed by red, green, and finally blue.
It seems very unlikely, but can PNG files have a way of behaving like this?
References:
https://cloudinary.com/blog/progressive_jpegs_and_green_martians
Besides standard/progressive, the 3rd kind of JPEG compression: load by channel?
https://graphicdesign.stackexchange.com/a/55570/97317
PNG's equivalent to JPEG's progressive display is interlacing. Rather than interlacing lines, it interlaces pixels using a pattern the PNG standard calls ADAM7.
We all know that converting from jpg to jpg makes an image lose quality, and that the same doesn't happen when it's png to png, but what about jpg to png ?
In my mind it makes sense that it doesn't, but still I'm not sure.
I think that good answer to this question probably would be an article in which there would be a good explanation of why it happens or not. Do you now of any ? I couldn't find such article.
It doesn't, but it's complicated.
Reading of JPEG is not a precisely defined process. Different JPEG decoders are allowed to produce slightly different results from the same file.
Converting JPEG to PNG makes pixels forever represent the particular method that was used to decode the JPEG, even if it wasn't the best one. If you use a "bad" JPEG decoder for the conversion you lose ability to use a "better" JPEG decoder later.
The differences are:
Chroma upsampling. JPEG may store chroma (~color) at lower resolution than luma (~brightness) of the image. The spec doesn't say how the chroma channel should be resized, so some decoders use blocky nearest-neighbor scaling, some use bilinear scaling, some do even weirder things.
Numeric precision. JPEG requires calculations to be done to convert image from DCT and YCbCr representation to RGB. This can be done quickly and cheaply using integer math and 8-bit color, or a tiny bit better using floating-point math and higher-depth color.
Color profiles and CMYK. Conversion may change color space (in case of CMYK it has to convert to RGB), which is easy to get wrong.
There are other reasons to avoid the conversion:
The file will almost certainly become much larger. JPEG compression artifacts are the worst case for PNG.
The file will lose metadata (like camera info, GPS). While in theory PNG could carry the same metadata, in practice converters rarely preserve it.
And a case for conversion: jpeg2png project, which doesn't merely convert the file, but also uses quite advanced post-processing to smooth out JPEG compression distortions. In that case you might salvage a low-quality blocky JPEG and get a smoother image instead.
The process you describe is:
JPEG Stream => JPEG DECODER => BITMAP
=> PNG ENCODER => PNG Stream
There is no change in step #2. Step #1 might have rounding errors inherent in JPEG.
I have a matlab code and it generates a .png image of 1024*768 resolution. The images are about 450KB in size and I need to know how to optimise and compress these images using matlab.
Can't I play with the quality as in JPEG ?
I read the imwrite manual and don`t seem to find a good way to do this.
Is there any way to achieve it in matlab ?
By design PNG files are lossless - there is no 'quality' to be adjusted (it's probably why a mod changed your question title).
You can reduce the number of colors in the image (the color depth) which will in turn reduce filesize (PNG-8 instead of PNG-24, for example), but the whole point of PNG is it produces lossless images, so there is simple no quality value a la JPEG.
Taken from the manual :
A parameter of input in case it is JPEG:
'Quality' - A number between 0 and 100; higher numbers mean higher quality (less image degradation due to compression), but the resulting file size is larger.
imwrite(x,'c:\1.jpg','Quality',10)
edit: Sorry, I answered this one while the title was JPEG and not PNG.
PNG doesn't support any quality settings - it is a lossless format. The compression it applies is generally as good as possible.
I am trying to implement a histogram equalization method (HE) for a UIImage in my iphone app.
I read the following:
http://en.wikipedia.org/wiki/Histogram_equalization
But it says:
Still, it should be noted that applying the same method on the Red, Green, and Blue components of an RGB image may yield dramatic changes in the image's color balance since the relative distributions of the color channels change as a result of applying the algorithm. However, if the image is first converted to another color space, Lab color space, or HSL/HSV color space in particular, then the algorithm can be applied to the luminance or value channel without resulting in changes to the hue and saturation of the image.
So would this be a feasible approach?
Grab UIImage data and convert from RGB to HSL
Apply HE on luminance channel
convert data back to RGB
Create new UIImage from data
Will this be slow, I wonder? Also, will I have to deal with 8/16/24 bit data differently, as I have no idea what kind of image will be used with my app? Or can I assume 24 bit for images in the iPhone?
I would appreciate any pointers to objective-C code that does color corrected histogram equalization.
I have looked at the library below, but it does not do any color correction for HE:
http://code.google.com/p/simple-iphone-image-processing/source/browse/#svn/trunk/Classes%3Fstate%3Dclosed
Thanks!
Yes you can do it this way, that will work. Yes it will "cost more" since you have to do the conversion back and forth - but that's the price you will have to pay if you don't want to affect the hue and saturation. Is that worth it for the images you're correcting? It would depend on your application, are you OK with a hit in performance vs best quality? You will likely only have to deal with 8bit color components, you can assume "24 bit" for images but that's 3 x 8bit components The only way to know your answers though is to try.
I recommend using YUV Colorspace. Both for accuracy and for computation simplicity (Linear Combination).
One method would be applying the histogram equalization on the RGB image (Image2).
Then let the user to chose what he wants, Apply only on luminosity or all 3 channels.
For the first choice take UV channels of the original image with the Y channel of the equalized image and convert back to RGB.
For the second choice just leave the user with Image2.
Since after transformation, you deal with I/V as being continuous values, you will have to apply some binning strategy, which results in a step Histogram for the quantity you wish to equalize. Therefore, you might speed this up by reducing the bin size?
Just write the codes and model applying HE to each of the RGB component. Although there are much calculation for its 3 components, but programming speed is OK. In most of the cases, the contrast is improved, but the "look" of the image is changed. So agree to transform the RGB into another space then apply the HE again. I am looking for the formula and also the correct color space for the HE. Which color space is easier?
I write the HE in the iPad platform, but I find after opening a big image taken from my Canon, the whole program crashes after UIPopoverContoller, UIImagePickerController functions. I think it maybe due to I am pushing too much on the phone's OS, or the OS allocates only a limit amount of memory space for each of the apps. If apps is using more than pre-set memory, then the iOS just kills the apps right away. So must take care of the size of the input image, and the garbage collection of unused memory, and memory leak. Using XCode's instrument tool to check for leakage is a must.
I 'd like to prepare my PNGs for the best optimization, so I can get the best image quality (lossless if possible) and the smallest size.
From what I understand, I should use: PNG, 72 dpi, RGB, but what else?
Here is what we find in the iPhone HIG:
Note:*The standard bit depth for icons and images is 24 bits (8 bits each for red, green, and blue), plus an 8-bit alpha channel. The PNG format is recommended, because it preserves color depth and supports an embedded alpha channel.
I guess this mean we should save the image as PNG 24 and create them in 8 bits mode? But I also read about 32 bits for best quality ?
The interlacing scheme (witch add to the file size) allows for the PNGs to display faster. Does this applies to the iPhone?
Thanks.
I suggest using ImageAlpha (lossy) on as many images as you can, because it greatly reduces their size.
Optimize all images with ImageOptim — it will remove all invisible junk and re-compress the data.
Disable Xcode conversion, because it undoes other optimisations and can make images much slower to load.
24 bit is red, green and blue with 8 bits each. 32 bits is RGB plus an 8-bit alpha channel. So if you need (semi-)transparent images, you should go for 32bit PNG, otherwise 24bit.
You don't have to compress/crush the PNGs yourself, Xcode's build steps will automatically use pngcrush and re-order the color channels for the iPhone's BGR memory alignment.
For my background app I am using JPEG (Export for web in photoshop) with quality 70.
Last day I heard about pngcrunch, tried it but file size is the same...
http://pmt.sourceforge.net/pngcrush/
Take a look at this previous post :
Understanding 24 bit PNG generated with Photoshop