As a challenge and practicality, I have a few images I want to include inside my jar for a mod I'm developing. But as is the compiled jar with the images ends up weighing over 25 MBs, which is not ideal. So my idea is to simply compress them and add that compressed package as a resource. But doing so doesn't appear to shrink the file size that much. So the two questions I want to ask (if that plan makes sense) what's the best way to compress a bunch of images and then being able to utilize them while running the game/program?
Lossy image compression is one way to reduce file size, but when dealing with images that cover the entire screen the drop in quality can easily be noticed, which is not what I want.
Another solution is to simply not have it part of the mod and instead needs to be downloaded individually and read from it. But that's a little cheap and still would have to download the same amount of MBs to get the full experience.
Note. I don't need to compress them in my program, just read from them when they are compressed.
Related
We need to be able to load large (typically >10,000px in one dimension but potential larger) images into Java. The user will need to zoom/pan the image and then click points which the program then uses to make distance measurements.
As always I'd rather not reinvent the wheel so would like a library that will handle reading popular formats (JPG and TIF), but also take care of memory handling, tiling etc. I'm assuming proper image editing programs like GIMP and Photoshop don't read large images directly into memory but rather read subsets of the data as needed?
The solution needs to be open source as this is an academic project. It also needs to be cross-platform so native libs are out unless they are available for Windows, Linux and OSX.
I have been going through to achieve Multi-Resolution in android built in eclipse.
I have this app where i have used a lot of images, firstly the only limitation i have is size, i cannot exceed 5MB size for the app, surprisingly i was able to do this by just storing only in the xxhdpi folder, not all of the dpi folders, such as ldpi, mdpi and above xxhdpi devices dont support the app.
As you can see if i store all the folders with the respective images, it makes the app of size almost 15MB. I have read in forums that in cocos2dx there is a function to which only image is provided, which automatically scales the image with the device, and returns it to be set respectively,
i was wondering if there is a way to do this in android as well, thanx in advance
You'd better use SVG (vectorial images) files, through a 3rd party library.
SVGs are scalable (up or down, doesn't really matter) without loosing definition, due to their vectorial nature (it's just an xml file with geometrical definitions and color transitions).
This way, you'd have only 1 version of the graphical file and then only get the desired bitmap from it, with no ugly pixellation.
The most used libraries so far are android-svg and svg-android, primarily (there are a few other ones, and some variants to the proposed ones too).
Scaling is what they are meant to: you provide the SVG file (possibly in your raw or assets folder) and the needed dimensions (in pixels).
And get your bitmapped image out of the vectors.
Fantastic.
Our user Paul LeBeau is the author of AndroidSVG and he always lends a friendly support to whom needs a hand with his library.
I have REST service that allows users to upload images and then serves those images. The images are stored to a database. I'd like to do JPG optimization for these images.
There's several command line tools to do this but I'd like to do it without first saving them to disk and then running some command-line tools. I'd rather use some Java library to directly operate on a binary stream that contains the image data.
What I'm after is a treatment similar to what for example Trimage does:
Remove all EXIF metadata from the image
Losslessy (re)compressed to the highest available compression levels
Is this possible?
It is possible to remove extraneous APPn and COM markers from the data stream. You can do that without expanding and recompressing.
Each time you expand and decompress with different quantization tables, you loose data in JPEG. There is no real point in decompression.
Yes to question #1. No to question #2.
I developed a mass file up loader (a swing application) recently.One of the new requirements is to support uploading thousands of documents (GIF,JPG,PNG,DOCX,XLSX), each of these are like 3MB-10MB of size and we don't want to upload these huge files, we generally support TIFF files which has small byte size like 60KB-100KB. We are not concerned about the image quality, all we need to upload these docs for future reference. Right now I don't have any idea how to solve this problem, I started researching it. Please point me in right direction.
-PD
My first approach would be to convert them to pdf files. Everything that can be printed can be converted to pdf. This also allows for image compression. Tiff won't be a good idea for doc/xls I think, it might make them bigger.
a .doc or .xlsx can be gzipped very quickly for decent savings.
Images are more risky, depends on what the data is. Pictures of people? Pictures of text?
I wanted to find out how can one capture screencast using java. I know that using Robot class one can get a screenshot but how do I go about capturing it as a video and then uploading it to the server? How exactly would that work?
ideas?
With a pure Java solution, I doubt that it will work, but it depends of course on what your interpretation of "video".
On my desktop with a 1920x1200 resolution, I am able to get about 20 frames per second when using the Java Robot to capture the entire screen. Since each image contains >6 MByte of uncompressed data, I would need more than 1 Gbps bandwidth to transmit the raw data of these images to a server. Most probably, requiring so much bandwidth is not acceptable, so you either have to decrease the number of frames per second or apply some kind of compression to the images.
One possibility is to compress each image using one of the image formats supported by ImageIO. The size of the compressed images will of course depend heavily on what is actually shown on the screen, but the performance of the compressors is not particularly good. Compressing to PNG ought to give the best lossless compression ratio for most desktop content, but at least my computer is only able to process just about 2 frames per second. Using the JPEG compressor with default quality settings reaches about 5 frames per second.
Using common video codecs through an abstraction layer like jffmpeg will probably achieve both better performance and better compression ratio, but I doubt that mainstream video codecs like WMV or H.264 are suitable for common desktop content.
If you really require a pure Java solution (and are not able to use any of the available standalone software, which do what you're asking for), I would make an attempt to implement my own, simple compression algorithm. With common desktop activity, there ought to be very little difference between most consecutive screen shots, so what might work quite well is to transmit the first frame completely and after that implement an algorithm to roughly detect rectangles, in which changes have been made and then transmit only these combined with JPG or preferrably (quality) PNG compression.
Or use Xuggler, a better wrapper for FFmpeg in Java. In fact, the code for capturing the screen and encoding the video is one of the standard tutorials.
I'm also curious about this. https://www.screencast.com/ is currently doing just this with a pure java (or at least straight out of the browser) experience.
You can just use something like Java to a native FFMPEG build, and execute the command line at runtime. Here is an applet that I made that does just that: http://have2chat.net/screencast/
I have downloaded the main capture *.JAR file for the Screencast-O-Matic.com. To download the file:
Go to http://screencast-o-matic.com/jars/ScreencastOMaticRun-1.0.5.jar
Save the file
Extract the contents (I DO NOT intend to use this commercially!)