I was wondering what image formats (aside from the basic JPEG, GIF, PNG) the major browsers would support, especially Chrome, Firefox, and Webkit. If anyone can provide a link to a list somewhere (that is updated frequently to cope with the frequent updates recently) that would be great. Support for other formats (like document and video) would also be nice.
I feel like this information should be listed somewhere, but I didn't find any such thing when I searched.
Here is a nice resource: http://en.wikipedia.org/wiki/Comparison_of_web_browsers#Image_format_support
Major image file support
.bmp, .jpg, .jpeg, .png, .gif
New
.webp
The image format supported in popular browsers: BMP, SVG, JPG, PNG and GIF. There is no two format jpeg or jpg, it's one with multiple extensions used due to see here.
Note: SVG(Simple Vector Graphics) can produced much smaller images but allows only vector images(no raster).
Next, the other formats used are webp and jpeg2000.
Webp:- Supported by many browsers such as Chrome, Opera. There is an issue running for Firefox support here. Note that, Webp can reduce the image memory size to around 30-40% of the original size(in our experiments) on an average. This doesn't means always as sometimes we have seen transcoded webp from jpegs to go beyond the original jpeg size. The output image had no visual difference compared to original jpegs. My suggestion: serve webp where possible, i.e. Chrome, Android, Opera.
JPEG2000:- This format is great. Resizing an image does not drop quality as much as JPEG. The problem is it's too computation intensive for decoding and the fact it came over a decade ago when hardware wasn't great(especially not meant for mobile). It still is used in some cameras as it results in smaller images.
Less popular but worth mentioning: BPG and FLIF. This will require using JS or other library to serve on web/app.
JPEG and PNG are supported by the every browser. But the new image format which is webP is only supported by the Chrome, and partially by the Firefox and not at all supported by the Safari at all. Thou WebP is really good as it does not compromise with the quality of the image and also reduce it to 25-35% less. But we cant still use it because it is less flexible in the different browser environment.
But you can look for the other image format also which are available and compatible for each browser type.
Related
I'm trying to create a small PDF file, embedding one optimized PNG image displayed as a header and footer on a 3 page PDF (same image must appear 6x in the PDF)
My optimized PNG image is only 2.3KB. It looks very sharp.
Failed with libreoffice
When I insert just one instance of the 2.3KB PNG image into a Libreoffice Writer doc containing only text, then export as PDF I can see that the image gets re-compressed to JPG and the resulting PDF file grows by about 40KB after adding the image. It also loses quality, the PNG also gets JPG fuzzy edges.
If I right click the image and select compression, there is no way to disable recompressing the image (it's already optimized better than libreoffice could do it) I've tried setting a compression level of 0,1,9 etc. Choosing JPG, no resize, lossless, etc but there was no improvement.
Failed with wkhtmltopdf
I also tried making a test page and used wkhtml2pdf but it did the same thing. Adding the low quality flag made no difference.
PDF Spec suggests PNG is supported?
From skimming the PDF spec, it looks like PNG images are supported.
Even plain text PDF files are surprisingly large
The disappointing thing is also when I take a 7KB HTML file which is basically just <html><body><p>foo...</p><p>bar...</p> (only about 15 paragraphs) with no CSS. The resulting 2 page PDF file is 30KB. Why should a 7kb (almost plain text) file become 30kb as a PDF?
Suggestions?
Can someone please suggest how to make a small PDF file in Linux?
I need to include 7KB of text and repeat one PNG image 6 times.
Manually or programatically. I'll take whatever I can get at this point.
PDF Spec suggests PNG is supported?
PNG isn't supported per se; PDF allows embedding JPEG images as-is, but not PNG images. PDF does borrow a set of features of the PNG format, however.
rinohtype (full disclosure: I'm the author) tries to embed as much as possible from PNG images as-is into the PDF. This does involve some bit-juggling to separate the alpha channel from the color data for example, but no reencoding of the image is performed. It does not (yet) support interlaced PNGs.
rinohtype should be able to do what you want to achieve. But please note that it currently is in a beta stage, so you might encounter some bugs.
Even plain text PDF files are surprisingly large
To keep the PDF size as small as possible, make sure not to embed/subset any of the fonts. Use only the fonts from the base 14 PDF fonts which are provided by PDF readers.
What you want is certainly achievable. Regarding the image quality, I would recommend making your image twice the size that you want it to actually display at in the PDF to keep it looking sharp.
As to the size, I've just modified a test in my PDF writer module (WIP..) to include a 7.2K png, 200px x 70px, in a PDF twice and the PDF came out at 6.8K 8). There's not much text included, but more text will only add what it's worth + a small percentage.
You can see the module and original test here.. https://github.com/DoccaPDF/docca-pdf-writer/blob/master/src/tests/writer.js#L40
That test adds ~112K of images to the PDF and results in a 103K PDF.
Of course not all images are created equal so you milage may vary..
*the images are only actually added to the PDF once, but are displayed multiple time.
I use Abbyy FineReader for ScanSnap to OCR a couple of scanned PDF files. The software claims it retains the original PDF images. The PDF file sizes pre-OCR and post-OCR are almost identical, which is good.
After the software is done, all PDF images appear anti-aliased in Acrobat X. Page navigation is much slower than before, and when I zoom in/out, the images first go to what looks like the pre-anti-aliasing version before quickly changing to anti-aliased images.
Left: Scanned PDF / Right: after OCR with Abbyy
I would like to get the original images without anti-aliasing back. Interestingly, when I open a single page from the anti-aliased PDF in Photoshop, there is no anti-aliasing and the image looks like the left one.
My limited PDF programming experience leads me to believe that Abbyy likely sets some kind of anti-alias flag for each image during OCR processing. How do I un-set this flag?
Any pointers to useful ideas would be much appreciated.
After the software is done, all PDF images appear anti-aliased in Acrobat X. Page navigation is much slower than before, and when I zoom in/out, the images first go to what looks like the pre-anti-aliasing version before quickly changing to anti-aliased images.
Actually in the original file 2013_11_15_22_51_31.pdf contains a JPEG image while the OCR'ed file 2013_11_15_22_51_31_OCR.pdf contains a JPEG2000 image.
Comparing them in third party viewers, it becomes clear that the image in the OCR'ed file is not inherently anti-alias'ed. Furthermore there is no evident flag in the PDF instructing PDF viewers to apply anti-aliasing to the JPEG2000 image. Thus, Adobe Reader seems to automatically render JPEG and JPEG2000 images differently, applying anti-aliasing to the latter but not to the former.
Comparing both images in detail, though, it becomes clear that these images are not identical but instead the image in the OCR'ed PDF is slightly rotated.
I assume Abbyy FineReader recognized that the original scanned image is not correctly oriented. Thus, it rotated it slightly to correct this orientation.
Thus, replacing the image in the OCR'ed version with the one from the original one is no option: Due to the rotation the OCR information would partially be somewhat off.
What you might want to try is to recode the JPEG2000 image to JPEG and replace the image in the OCR'ed version with this recoded one. This will mean some loss of quality but most likely you can get rid of the anti-aliasing this way.
Be aware, though, that the JPEG2000 image is slightly larger than the JPEG image to accomodate for the rotation.
PS: As #VadimR pointed out, there is indeed an /Interpolate true entry in the image dictionary of the OCR-ed version I missed when looking at the file. This does not seem to be the major issue slowing down the rendering.
There is /Interpolate true entry in image dictionary of OCR-ed version, and that's what causes 'anti-aliasing'. Whether that (and not JPEG2000 instead of JPEG compression) is a cause of slow-down, you check on large enough files.
To un-set this key, the best would be to turn it off while creating a file, and if that's not possible, to write and run a small program in suitable language.
But, since your file doesn't sport 'compressed objects' and offending key is in plain view inside a file, in the spirit of 'job done quickly' you can simply process your file e.g. like this:
perl -M-encoding -0777pe "s!/Interpolate true!' 'x17!ge" <in.pdf >out.pdf
In a webappp I am currently creating the user has to provide images that get stored server side in a database. To minimize server load I am handling image resizing client-side courtesy of the HTML5 Canvas and getting the user to pre-approve the quality of the resized image.
The issue I have run into is this - the file size of the resized image is big. If I resize the same image with Paint.NET I can get a perfectly decent light weight 8 bit PNG image. Even the 32 bit Paint.NET image is smaller than the one that turns up on the server via toDataURL. I tried playing around with the toDataURL quality parameter but changing it has no effect whatsoever - exactly the same data size.
I should mention tha t I am testing with Chrome 20.0.1132.57 m and that the only browsers that are relevant to the app are the desktop versions of Chrome and Safari.
I know I could do some server side image processing but I want to avoid that if possible. Question - what, if anything can I do to cut down on the image file size sent out from the browser?
Browsers may happily ignore any quality parameter given for the toDataUrl and such. I don't believe honoring it is mandatory by the specification.
The only way to control the quality exactly would be
Write your own PNG compressor in JS or use something you can steal from the internets https://github.com/imaya/CanvasTool.PngEncoder
Dump <canvas> data to ArrayBuffer
Pass this to WebWorker
Let WebWorker compress it using your PNG compressor library
I believe there exist JPEG/PNG encoding and decoding solutions already.
Alternative you may try canvas.mozGetAsFile() / canvas.toBlob(), but I'll believe browsers still won't honour quality parameters.
https://developer.mozilla.org/en/DOM/HTMLCanvasElement/
If i am making a image sharing service website using the standard file upload form what images can i say it supports, other then jpg, png, gif. Is there a list that shows what browsers supports what? I know that jpg png and gif are most common but what are the others. I want to be sure.
Honestly, that's pretty much all you should be concerned with. Any other file formats (like svg) are not widely supported enough.
I would suggest converting other types of files to those 3
Examples:
jpeg (simple renaming)
bmp
tiff
pcx
I'm beginning with WML development, but I hate that the only option that we have for images are the WBMP format, that is only grayscale, then I want to know if there is any way to have colored images using WAP 1.x(not the new 2.x versions of it).
Standard colour image formats such as BMP, PNG, JPEG, GIF and animated GIF were supported in the Openwave browsers (certainly Openwave Mobile Browser v6), which were shipped on a huge number of WAP mobile phones. I think it a reasonable assumption that other WAP browsers have similar support.
Beware that some browsers may not support certain advanced features of these formats e.g. progressive display/download in GIF, PNG and JPEG.
So you should be able to do e.g.:
<img alt="text" src="url" />
where the URL specifies a BMP, PNG, JPEG, GIF, animated GIF etc.
The Openwave browsers also allowed img elements within do and option elements as a non-standard extension to WML.