I'm having difficulty locating a Java 2D based library for developing a paint program.
All the libraries I find seem to be for:
animation
graphing
games
None of which are useful to me for a paint program. (This particular project is primarily for webcomics and print comic books.)
I'm mostly interested in something that abstracts file IO for images that are practically too large to load into a BufferedImage object.
Adobe's tools for example are probably not loading whole 10MB (compressed) image files into memory -- once decompressed, that's just too much physical memory to devote to caching the image (especially if you open a dozen of them at once), so there must be a framework in those applications for managing the files on disk and buffering just the currently relevant areas in memory.
I imagine it would at least have an Image subclass that works the
same way as BufferedImage while abstracting away the fact that the
image is coming and going from the file instead of memory.
An additional wrapper that allows me to zoom in on a rectangular
area or zoom out and buffer up the scaled, visible portion (for
display) would be extra nice.
A layering system with blending modes would be super-sweet, although
I expect I'll have to build that myself.
Have you tried looking at StdDraw? It's got some basic drawing in it. StdDraw can be downloaded here
Related
How reliable is ZXing's barcode localization for DataMatrix decoding compared to libdmtx?
I have a set of png image files of stickers (proprietary, so unfortunately I'm not able to share them) containing DataMatrix barcodes. These stickers sit on flat surfaces, have very nice quiet zones and are generally centered in the image, but suffer from inequal lighting conditions and slight dust, likely the largest obstacle to reliable decoding.
I'd like to use a modifiable Java library to decode them and it seems that ZXing is the only open-source option (open to other suggestions). However, upon running these images through the ZXing online decoder, I consistently get NO BARCODE FOUND, even on the cleanest images. In contrast, when I run the same images through proprietary online decoders, like Inlite's Free Online Barcode Reader, I get reliable decodes for all the images. My company has implemented a library in C that also reliable decodes the barcode images by processing them and calling libdmtx. Similarly, this online DataMatrix decoder built on libdmtx can also reliably read my image files.
Is the barcode localization in ZXing significantly inferior to libdmtx?
If I attempt the same preprocessing on the image files before I run them through ZXing, could I achieve similar results? I have a strong preference for a Java library (ZXing), but I may have no choice but to use libdmtx. Would appreciate any insight, thanks!
I had similar problem as you but on encoding side. As per my findings Zxing is certainly inferior to Libdmtx. We are using both libraries in house in C++ and Java project.
There is a case when Zxing breaks while generating barcode look at my comments here:
https://github.com/zxing/zxing/issues/624
However Libdmtx works flowless. The other free options you have in java world are (they are for encoding):
barcode4j
OkapiBarcode
Another alternative is the relatively new ZXing cpp port here: https://github.com/nu-book/zxing-cpp.
It contains a completely new DataMatrix detector that was meant to fix serious limitations of the Java upstream version. It was specifically designed to deal with low resolution images (module size as low as around 2 pixels) and symbols that have just the required 1 module quite zone and a busy background.
The following comparison is certainly not 'fair' but I just had the dmtxread utility of the libdmtx try my test set of images and it missed 3 of 17 samples and took a whooping 300 times as long compared to my code :).
I am currently working on a website which involves a lot of images. The problem is all the images are uploaded by the user so I can't do anything to alter the images. The website runs quiet ok on local system but the speed drops too much on the server,it becomes too slow
I'd suggest you to use Timthumb. It creates a thumbnail by generating a URL on the fly and uses very minimal disk space.
If the users of your website are uploading the images, then I presume (there must be) an upload script. Inside of that script or directly after its execution you could compress or rescale the image to size needed on the website, shortening loading time. There is a PHP image processing library called ImageMagick here:
http://php.net/manual/en/book.imagick.php
There is the PHP GD image processing library here:
http://php.net/manual/en/book.image.php
I don't have much personal experience with them, but from my knowledge it looks like one will do the job. Off the top of my head, that's the best solution I can think of, and hopefully it works. There is not a lot you can change about your problem if you don't compress/scale the images, and these are probably your best options. Wish you the best.
I'm currently using the gdx-freetype library to generate the BitmapFonts for my game. It's really convenient since I can use it to handle the different screen sizes on Android. The problem is that it takes a long time for a font to be made. At startup I generate some BitmapFonts in a few different sizes (from the same .ttf file), so the time spent generating fonts, adds to my loading time. This is a problem, since it can easily take 5-6 seconds to generate the fonts.
Is there anything I can do to speed up the process or should I try some alternative to gdx-freetype? Perhaps I'm approaching this problem in a wrong way?
As Tenfour04 correctly points out in the comments, the way to do this is to only generate the fonts once when the game first loads, then save them as files. Subsequent runs will simply load them from the files which will be much faster.
I've heard good things about the gdx-smart-font project which does exactly this, although I should add that I've never actually tried it myself...
This class provides several benefits:
Creating fonts for different screen sizes using Hiero or BMFont can be
troublesome, if you have 4 fonts of different sizes and are targeting
5-6 different screen sizes, you then must generate 20-24 bitmap font
pngs. By using generated fonts they can be dynamically scaled at the
time of creation based on screen size.
Generating fonts cuts down on app download size, no need to include
pngs.
Generating fonts can add significant time to app startup time. Caching
the generated fonts to file, and only regenerating when needed allows
for fast app startup most of the time.
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 have Java Swing application with maximized bounds for JFrame. The application is distributed as jar file up to now.
Initially for background image I have used some large arbitrary image file of png-format. And I do have a code which can load and set image as background for JFrame.
Now, I got a new image from designer in both cdr and png format. Png image is 5 by 4 thousand pixels now.
My requirements:
to minimize image file size
to support different screen resolutions
What would be the best option to meet requirements?
Resize file to 1920x1080 and keep as png, and resize at runtime to smaller images if needed according to resolution
Keep file as cdr or some other vector format. But I am not sure Java can easily read and convert it to BufferedImage
If you have the opportunity to get the file in .svg this will fit your needs the best. You could then have a look at Apache's Batik library and its rasterizer to render the image.
What would be the best option to meet requirements?
Resize file to 1920x1080 and keep as png, and resize at runtime to smaller images ..
..or larger - time goes on, screen resolutions get bigger (& bigger)..
.. if needed according to resolution.
Yes. I think that is the best option.
Loading a library to render an SVG or EPS to BufferedImage at run-time seems like overkill for a BG image.
Deployment
The application is distributed as jar file..
Applications that use images often have a GUI. Does this app. have a GUI?
If so, it would be optimal to deploy it using Java Web Start.
The Jars for JWS can be downloaded lazily and programmatically, and are refreshed when updated, so the image should probably be in a separate Jar of its own to avoid downloading a new version every time there is a bug fix. When putting an image (or compressed media files in general - sound, video,..) use 'no compression'. Zip does nothing good for these already highly optimized, or at least very specialized, data formats.