We are constantly transferring gigabytes of compressed Tiffs overseas and it takes a long time for each batch of images to transfer. It is not uncommon for a batch to take over 6 hours to transfer. I would like to reduce the time to transfer a batch of images.
I understand that videos compress really well because most of the time each frame is generally very similar to the one before it and compression algorithms take advantage of that. In our scenario, the images often look similar to one another. Are there any image compression libraries I can use to take advantage of the fact that there is a lot of redundancy across images? Ideally I would want lossless compression.
Would it work if I turned the images into a video before transferring them and then turned them back to images on the other side? If this would work, what libraries would you recommend? I need to be able to call this from Java and preferably run it on Linux, but the library does not need to be written in Java. Windows could also be a possibility.
What I would try first:
Start from uncompressed tiffs (otherwise, it will be hard to find similarities).
tar them together (so they are contained within a single file, can be a specific range of images off course).
Then use a compression algorithm of your choice to see which one yields the best results (on the single file).
Easy enough to try out without much effort. How well it works depends on the source images themselves (and the compression algorithm used).
Alternative approach if the above does not yield enough results:
Make sure you have all uncompressed images.
Send over the first image.
Do a binary diff (or maybe diffing the hexdump) towards the next image.
Send over the diff file and apply it at the receiving end to reconstruct the image.
Repeat 3-4 for every image.
I personally don't think you will easily get good (lossless) results by using video compression algorithms (after all, they are specifically tailored to a different purpose).
Related
Having an ecommerce website, We have thousands of product images. On checking pagespeed on google it shows me something like this:
I was wondering, if there is any built in feature in Java or any third party library is available with which we can losslessly compress all the images that we host. Hence we can save few KBs of our customers.
On searching through internet I found few like punnypng and kraken which are paid, hence we do not have heavy image uploaded every month, subscribing to them is not worth. I would prefer any built in feature in Java or any open source third party library.
I came across JAI, but not sure about whether it addresses this problem or not. Anyone with hands-on experience with this?
P.S. We are using Java 8
Have you looked at classes in the javax.imageio package (http://docs.oracle.com/javase/7/docs/api/javax/imageio/package-summary.html) ?
You can do decoding and re-encoding of the images. The class ImageWriteParam (http://docs.oracle.com/javase/7/docs/api/javax/imageio/ImageWriteParam.html) lets you customize the compression settings.
~600 KB jpeg images are quite large for screen, though not for print. Having several images on a page would mean making more or less "thumb" views being smaller. And provide an individual product page with higher resolution, say 600 KB JPEG.
Standard ImageIO suffices for conversion, see #NicolaFerraro.
Faster page loading can be achieved on the overview page with multiple images, by storing the smaller views into one large image. PNG might then be appriopriate to prevent JPEG artifacts.
To provide a higher resolution for a print, one can use the CSS media setting.
Check thumbnailator. It is great at making smaller images from larger images.
Besides you should consider when you are going to make these smaller images. At each call, at the first call (any keeping a cache), ...
I'm writing a Java program and I'd like to convert a ogg file into mp3 file.
I've spend a lot of time trying to find a good library to do that, but without success for the moment.
I think I'll need a ogg decoder (jorbis ?) and a mp3 encoder (lameOnJ ?).
Moreover, once the conversion is done, I need to set some tags in the file (artist/track tag, etc).
This is a windows and OS X app.
Could you give me any hint about how to process, with examples if possible.
Thanks
You have lots of choices, and it depends on how much effort you want to put in, and what constraints you have regarding the execution platform.
Many developers would simply make System.exec() calls to external decode/encode/label executables, writing the intermediate files to disk. This is slightly clunky, but once it's set up properly, it works.
A more sophisticated option is to use libraries such as the ones you've found. You can still use the filesystem to temporarily store the uncompressed version.
You can, however, avoid storing the intermediate step -- and maybe make it faster -- by pipelining. You need to feed the output of the decoder as the input of the encoder, and set them both going.
The details of this depends on the API. If you're lucky, they can work with chunks, and you may be able to manage them in a single thread.
If they work with streams, you might need to get your hands dirty and work with threads. One thread for the encoder, one for the decoder.
The application I'm trying to build will have a lot of images displayed (in ImageViews), and I'm not fetching them from a server/online service as it will need to be used offline. I know I can just dump them in the res/drawable directories, but I was wondering if there's any way to optimize this. Is there a way to somehow compress these images (besides making them smaller, they're already as small as I need) or use some other sort of android tool to better store them locally on the device?
I could just be overlooking a well used feature, and if so, it'd be great if someone could point me to that.
Edit: If I were to compress the images somehow, I would need to decompress at runtime or something, and that would take another thread/loading time. I'm not sure how to do that either, so I'm just brainstorming various ways, and I thought someone here would've come across this at some point.
If you haven't already, this is a good read - http://developer.android.com/guide/practices/ui_guidelines/icon_design.html#design-tips
When saving image assets, remove unnecessary metadata
Although the Android SDK tools will automatically compress PNGs when
packaging application resources into the application binary, a good
practice is to remove unnecessary headers and metadata from your PNG
assets. Tools such as OptiPNG or Pngcrush can ensure that this
metadata is removed and that your image asset file sizes are
optimized.
Outside of all other compression logic the above would be the place to start. Also when you say "optimize" - do you mean optimize the way images/drawables are loaded in your app or just the amount of space (on disk) the app will consume?
I am creating an application that requires a lot of image thumbnails (~3000, 5-25KB). Because speed is essential I plan on loading these images into memory when the application starts. At runtime, new thumbnails will be downloaded and added to the collective.
I could store them all in a folder, but reading thousands of files into memory when a program starts hardly seems efficient.
My second option would be to save them in some kind of (compressed) archive. This would make storage itself and loading more efficient (I think). However, new files will be added regularly, and that will probably not go as smoothly as just saving them in a folder.
Is storing a cache of small files in a (compressed) archive a bad idea or not? Are ZIP files the way to go? Would I be better off using uncompressed archives (and if so, what kind)?
All image files will be JPEG's.
Thanks in advance!
EDIT: I am considering to drop the "load everything into memory on application start" thing. This would simplify my question a little. My initial idea to put everything in one big file now seems less beneficial, since the problem of many files in one directory can be solved by hashing into subdirectories.
Small files don't compress especially well, so you may not gain much compression.
While loading the files will be fast because they are smaller, decompression adds time. You'd have to experiment to see which is faster.
I would think the real issues would relate to the efficiency of the file system when it comes to iterating over all the little files, especially if they are all in one folder. Windows is notorious for being pretty inefficient when folders contain lots of files.
I would consider doing something like writing them out into one file, uncompressed, that could be streamed into memory -- maybe not necessarily contiguous memory, as that might be a problem. But the idea would be to put them all in one file. Then write some kind of index that ties a file name or other identifier to an offset from which the location of the image in memory could be determined.
New images could be added at the end, and the index updated appropriately.
It isn't fancy but that's what you're trying to avoid. An archive or even a file system gives you lots of power and flexibility but at the cost of efficiency. When you know what you want to do, sometimes simple is better.
I would consider implementing a solution that reads files from a folder, another that divides the files into subfolders and subsubfolders so there are no more than 100 or so files in any given folder, then time those solutions so you have something to compare to. I would think a simple indexed file would be fast enough that you wouldn't even need to pre-load the images like you're suggesting -- just retrieve them as you need them and keep them around once they're in memory.
All disk based storage, and most database, allocate space in chunks. The chunks on large capacity disks can be large. If you have 5kb files and a 32kb disk chunk you end up with 85% wasted space on your storage.
Using an archive won't compress jpeg much because the jpeg encoding algorithm already does that. It will however save you the wasted space on the storage media. It does make things more complicated and perhaps a little slower.
In my opinion I think that the zip file way it´s a bad idea, because you will slowdown everything with the process to load the zip file and unzip it to extract each image.
I think that the purpose of a thumbnail image is that by nature is small so your app plus hardware can load it as fast as possible. So I believe that it is a better idea to load each image as you need it.
Well, if you have small, "geometric" pictures, you may implement them as objects of type javax.swing.Icon rather than images to load from the filesystem.
http://download.oracle.com/javase/6/docs/api/javax/swing/Icon.html
http://download.oracle.com/javase/tutorial/uiswing/components/icon.html
So you will implement one or more objects which draw themselves onto a Graphics surface using the Graphics drawing primitives, instead of copying pixels.
If this is a web-application then the best performance boost you can get is setting good HTTP caching headers. Having a unique URL for every image (also different URLs for different versions of the same image) makes it possible to set VERY far future expire headers, because changing the image changes the URL leading into refetch.
I won't compress, because JPEG cannot be good compressed and it only costs CPU time.
I would recommend to simply store the images into filesystem and consider the use of libraries like jawr or implement your own caching strategy.
I know this question has already answered but I think you need more options other than zipping.
While zip is good, It's not really affect much for JPEG since JPEG has already compressed.
Other thing you may want to consider is :
Put the image in Content Delivery Network (CDN)
Compress components with gzip ( mean the server will automatically zip every response ) and you dont need to write any code to unzip it later - it's handled by the browser automatically.
Since you mention JPEG, you may want to use JPEGTran.Run jpegtran on all your JPEGs.
This tool does lossless JPEG operations such as rotation and can also be used to optimize and remove comments and other useless information (such as EXIF information) from your images.
jpegtran -copy none -optimize -perfect src.jpg dest.jpg
Use Image Sprites. Instead of asking browser to download many image at same time, ask the browser to only download one.
For the details read : http://developer.yahoo.com/performance/rules.html#opt_images
For the basic examination how to improve your website performance you can try install YSlow ( plugin to detect uneffecient code ) in Firefox.
Hope that helps.
I'm designing a server-side application that takes an image from a user, processes it, and sends it back over the network. Since the network connection might be quite slow, I'd like to speed things up by starting to process parts of the image while it is still being sent over the network and send parts of the processed image back to the client while other parts are still being processed.
Is this possible, preferably using the javax.imageio classes?
EDIT: I am mostly interested in writing PNGfiles. Wikipedia says: "IDAT contains the image, which may be split among multiple IDAT chunks. Doing so increases filesize slightly, but makes it possible to generate a PNG in a streaming manner."
This strongly depends on the encoding of the image. Some image formats require the whole file to be available before you can decode it. Others - like GIF and some PNG encodings (as far as I remember) decode to indvidual blocks which can then be processed.
You most likely need to write custom decoders, which may be quite a bit of work if you are not intimately familiar with the formats, and you need to support several.
I think you perhaps should work on an upload bar instead?