rkalla / imgscalr Goto Github PK

Interesting article on converting images to hashes and finding thresholds of differences between two images:
http://www.hackerfactor.com/blog/index.php?/archives/432-Looks-Like-It.html

Might be an interesting addition to the library in some capacity (if it makes sense).

Right now all the image operations (resize, rotate and in the future crop/pad/etc.) are done by calling one of the resize methods.

It could be helpful to have direct access to that functionality without invoking a resize. For example, if you just want to crop an image.

At first glance it seems like simple crop(), flip(), rotate(), etc. methods added to Scalr would be the way to go (and then the matching methods added to AsyncScalr).

If the methods are all simple single-definitions, this is the way to go. If they can cause many different variations, may need to consider a separate Opr, Ops, ImageOps (whatever) class to include those in.

This will likely cause the removal of rotation-enabled methods on Scalr already which will be a breaking change for 4.0

Compared to much slower approaches like Image.getScaledInstance and using the AreaAverageScaleFilter directly, the results of scaling some image types using imgscalr end up looking down-right awful; pixelated, low-color pixels dithering the image.

Reported by Magnus Kvalheim

When scaling an image in a landscape orientation (320x240) the library does not honor the primary dimension of width (320) and instead scales the image based on the smallest dimension (240) resulting in an image that is 240xnew-height.

I'm currently using imagemagick to do a rescale given a bounded area:

  convert dragon.gif    -resize 64x64^  fill_dragon.gif
  convert terminal.gif  -resize 64x64^  fill_terminal.gif

http://www.imagemagick.org/Usage/resize/#fill

It would be great to ditch imagemagick for imgscalr if i could just crop/pad.

Need to do some in-depth testing of the library in highly threaded (e.g. server) environments and see what kinds of behaviors the library will exhibit when the heap is exhausted.

Will include a configurable test-class in the code for anyone else that wants to try it.

Besides scaling down smoothly, in the case where an image is scaled down drastically (1/10th or 1/20th its original size) smoothing of the result can become important.

Current imgscalr does not support this type of operation natively; the user would have to apply additional operations to the resulting BufferedImage to get the effect.

Allowing imgscalr to resize images directly from InputStreams would allow the library to be more easily integrated into additional usage scenarios and do more of the boilerplate work for users not wanting to work with ImageIO at all and "just resize the damn file".

Would make integration into file-based scenarios, DB-storage scenarios or even cloud-based scenarios much easier.

In the current implementation of ExifTool.Tag, no type information is stored along side the Tag or it's name; it might be handy for users if a type is stored along with the name to make parsing for them easier.

If -n is not passed to ExifTool, then the long-form/friendly names for values are used instead which will no longer make the type valid.

To account for that flexibility in a safe way, the type provided should be used more as a hint and not a defactor do-or-die type conversion. This will allow people working with custom tags or custom types (maybe an older or newer version of ExifTool down the road?) to account for changes and parse things themselves without the tool exploding in a heap of fire.

Basically, plan and design for flexibility so the world doesn't melt if the ExifTool behavior changes in the future.

TC requested this here:
https://github.com/inbox/12038905#reply

Guide here:
https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide

Reported By: [email protected]

The library is not hosted in any Maven repository. I'd suggest that
you either create your own Maven repository (not that difficult) or
get yourself listed in one of the public repos.

Right now the flip rotation is not defined correctly.

For a cleaner rotation definition consider explicity defining 90, 180, 270, flip-horz and flip-vert.

The "flip" rotation now is actually a 180 rotation which isnt necessarily a flip, depending on what the caller had in mind for the image.

This will be a breaking change so it will require a major release num chnage.

Ex http://code.google.com/appengine/docs/java/images/overview.html

In AUTOMATIC mode the API uses the size of the image as an indicator of if it should choose SPEED or QUALITY (or other modes).

Right now the code is written to compare BOTH the width and height to the threshold before selecting SPEED or QUALITY, this doesn't take into consideration the orientation (portrait or landscape) of the image.

This means that images who's dimensions are quite large in their primary orientation but smaller in others are not getting the higher-quality scaling operation selected for them.

For example, an image that is scaled to 1024x400 is always getting the SPEED method selected because not both of the dimensions are less than the threshold.

Currently the simplest method on the Scalr class only allows you to specify a "size" that is used for both width and height. All remaining methods require a specification of a Method and width/height, it would be nice to have a simple method call that took the image and width/height only.

So far during development and testing the ExifTool wrapper has not left daemon ExifTool threads laying around after exit, but in preparation for potentially needing a solution to this in the future I have found some interesting notes that I want to remember in case I need to implement this in the future, in some common library.

Approach

The only universal approach that seems to work is to get a process list before launching, then right after and then record the PID of the diff process. There is a nasty potential for mis-identifying the wrong process here in the case of a very busy system spawning processes.

On windows the command 'tasklist' can be used and on Unix/Linux/Mac "ps -ax | grep exiftool" will do the trick.

Killing Processes

'kill -9' on *nix and on Windows 'taskkill' is available.

Again, this is not a bug that will be addressed, just some notes with a potential nasty side effect (of killing the wrong child process) so not something I want to jump into right now.

Line 5: "<name>imgscalr - A Java Image Scaling Library<</name>" makes the pom invalid.

Reported by Robert Rees

All other arguments in the API cause an IllegalArgumentException to be thrown if they are null or empty and shouldn't be, except src.

This was originally done to make the API no-op on a null src and be more "exception-friendly", but as Robert's bug report shows, he spent a decent amount of time trying to figure out why imgscalr was breaking and returning null only to find out that his 'src' argument going in was null because it wasn't loading right.

The API should be pedantic and correct, not loosey-goosey.

Consider a fitto-exact mode that will stretch the picture to exactly the dimensions requested regardless of orientation or aspect ratio of the original.

Since ExifTool will at least be integrated into imgscalr proper and possibly used by a number of external code bases directly, it would be nice if there was a mechanism by which that a caller can determine if a feature they want to use (e.g. stay_open) is supported BEFORE attempting the EXIF pull and then trying to handle a mish-mash of exceptions.

Scaling images, in any language, is a memory and CPU intensive operation. In highly-scalable/threaded environments, firing off MANY scale operations at the same time (e.g. a 100 users upload images that need thumbnails generated at the same time to your web app) can result in unexpected failures with a particular sub-set of the image operations as the VM will eventually run out of memory to hold all that decoded image data in ram at the same time.

imgscalr shines on the server and to make it's use easier/safer, consider creating a ScalrService that can control for this.

Based on the research from Issue #27 (#27) and what I assume will end up being fairly bad behavior once the heap is blown, the addition of a Singleton, ThreadPoolExecutor-based ScalrService that can easily be used in heavily mulit-threaded environments to more easily trim down the number of simultaneous scale operations to avoid blowing the VM heap

In a heavily multi-threaded app, it might be easier than expected to initiate so many simultaneous scale operations at the same time, that all that image data is decided and pulled into the VM simultaneously, possibly leading to the VM heap size running out of room to grow and some of the scaling operations failing while others would succeed.

The purpose of the service is to create a simple, user-configurable, intentional "choke point" to control a worst-case scenario ceiling.

For example, for a webapp that processes image uploads, if your average image upload is (say) 1MB in size, and your heap is 64MB... you may want to set the ScalrService to never do more than 2 simultaneous scale operations as fully decoded image data is typically much larger than the compressed source files. By limiting simultaneous scale ops in your app to 2 at a time, you don't need any more complex code in your app to control this.

If you have a monster dedicated image-scaling server with 72GB of ram and some hellacious dual-CPU, quad-core, HT-enabled CPU setup, you could up the ScalrService to do 100s or 1000s of scale operations simultaneously, but in your code you wouldn't need to change anything, simply call ScalrService.resize... and it will do the right thing for you.

This design also has the added advantage of taking advantage of multi-core/multi-threaded CPUs for scaling operations as the threads in the thread pool can be scheduled onto different cores/threads by the OS as they are executed.

Another advantage is the Threads are not created/destroyed every time a call is made; they would be created at service initialization time, or lazily created at first-use, but otherwise will stay around until the app is shut down.

OPTIONAL: An asynchronous approach may be considered with the core design, returning a Future object; if the caller wants an synchronous execution pattern, they can just immediately call future.getValue which will block anyway.

To keep the API simple/consistent, the async design may be the approach; it is not worth polluting the API to double up the methods and have sync ones and async ones all on the same class; ugggg

Inside the call to AsyncScalr.setServiceThreadCount the min and max thread count sizes for the ThreadPoolExecutor are called out of order.

coreSize is upped first then maxSize is uppped -- the upper bound (max) should be adjusted first THEN core (the lower bound).

Might be nice to predefine common image filters in bufferedimage ops like the anti alising one.

Black and white
Sepia
And other common filters might be handy.

BufferedImageOps actually have an 8-year old bug in the JDK that can cause the application of certain types of manipulations to fail with an exception or return a black/empty picture and no exception.

It is maddening.

Fortunately imgscalr works around this internally so all the BufferedImageOps passed in are handled correctly and avoid that failure case in the JDK.

This functionality should be extracted out into its own discrete method so anyone can safely (and efficiently) apply BufferedImageOps against their images even if they aren't performing a resize operation.

This is in the same vein as Issue #49: #49

Documentation speaks of SPEED/BALANCED op around 800px and BALANCED/QUALITY around 1600, but values in the class don't match.

Right now when an image is scaled, the width or height is preferred by the API based on the orientation of the image; there is currently no way to have the API prefer one of the dimensions over the other by force.

A common use-case would be working with portraits, like for a company profile page, where every image should be 200px wide no matter how tall it is; currently you would have to pre-calculate the right dims to ask for before calling imgscalr because it will always prefer the height of the image over the width since they are all portrait orientation and given you back different width images if their heights vary, making your life harder.

The API should provide a mechanism by which someone can specify a mode of resizing.

I implemented the image scaling library in application using NetBeans 6.8 IDE and it worked fine.
But when i try to implement the same using JDeveloper 10.1.3.3, the imgscalr.resize method is not executed at runtime and the image is not displayed. Is there any solution?

thanks
ren

This has been asked for a few times by folks trying to integrate imgscalr into scripts or call it easily from other languages. The ability to run imgscalr from the command line could be very handy.

A common operation when dealing with images is rotation; it is not uncommon for images coming off of a digital camera or cell phone to need to be flipped or rotated.

As a "best practices" image API, imgscalr should provide these simple operations in a performant way making it easy to start with 1 image and end up with a scaled/rotated/whatever image that you want.

Currently the library only outputs to the console via System.out -- great for simple debugging purposes in simple apps, but in the case of more complex apps that need to be profiled or watched for debugging or performance metrics (like web apps) it can make it harder than necessary to find and view the output that you want to view, especially if custom logging configurations are being used by the web app.

Would be handy if the library used a standard logging mechanism that in addition to giving simple output in simple cases, can be configured to output in more complex configurations.

Phil is an amazing human being and defined the return type for EVER tag that ExifTool supports:
http://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/index.html

As a result, the java ExifTool class should probably provide an easy mechanism by which a String tag value can be easily converted into the native format defined by Phil so it is easier for callers to use.

Perfect example of why imgscalr should support this:
http://stackoverflow.com/questions/6841313/portrait-image-resizing-in-java-with-imgscalr-but-the-final-output-is-landscape

There are a handful of libraries I've evaluated for adding this support, Drew's being the most likely one. It would add a new dependency library to imgscalr unfortunately, but given the "surprise" of getting an incorrectly oriented resultant image, it can be worth it.

This isn't as simple as adding an if-condition as efficient rotation logic has to be added into imgscalr to perform the correct manipulation without burning up objects on every resize operation if avoidable.

As a safety check against dead-locking I/O streams, the ExifTool class actually verifies that the native ExifTool process is the required version for us with certain features (like -stay_open).

Right now the logic executes every time a new class of type ExifTool is created USING that feature.

Instead this version confirmation should be done once (in a static way) and never done again for the class in the VM because the external process that is being run to be checked is defined by the static EXIF_TOOL_PATH argument, which won't change.

The check should be run at the same level.

When scaling an image, say 600x800, down, it is possible to cause imgscalr to calculate a partial-pixel result.

For example, handing a 600x800 portrait picture to imgscalr and asking it to scale it down to 10x10 will calculate the correct dimension of 7.5x10 and SHOULD scale it to 7x10, but because of the use of Math.round, it scales it up to 8x10; resulting in a portion of image that won't be rendered to when the underlying Java2D drawImage call is made.

The fractional portion should be cropped to avoid the resulting image containing pixels that are not rendered to by the underlying operation.

There are no test cases or generators that can be used to quickly and easily generate a directories worth of images generating results in different sizes using the different methods so users of the API can make up their own minds about which method to use.

Would also be handy to have such a generator when tweaking the different thresholds for the most effective values that the API should auto-tune for.

Right now there is a single threshold (800px) that exists to decide if an image should be scaled using QUALITY or SPEED. More testing of the optimal threshold should be done and possibly additional thresholds to help decide between SPEED, BALANCED or QUALITY to ensure better-looking (and performing) operations from scale operations done with the AUTOMATIC method.

This was first noticed when scaling some text-heavy screenshots and noticing that the text is unreadable at average-large sizes because of the corruption the nearest-neighbor algorithm introduces.

This is not a good result for an "AUTOMATIC" mode -- people would expect a better result than this by default.

Reported By: [email protected]

There is no online JavaDoc. Most developers want to have a short
look at the API before they start using it in order to see whether the
library actually solves the problem they're facing.

REF: http://www.mail-archive.com/[email protected]/msg05621.html

It seems when using Java2D to process rare image types (BufferedImage.TYPE_*) the pipeline used to execute operations like scaling can be very un-optimized.

The recommendation from the Java2D team is to copy the source BufferedImage contents into a new BufferedImage instance with a well-supported type (e.g. RGB or ARGB) and then process the image.

It might be worth looking into which image types are not well-supported and implement that behavior for folks, abstracting away any performance issues.

NOTE: This seems to only be an issue with the rarest of image-types and is likely a non-existent issue for 95% of use-cases. This is meant as a future research TODO.

A common operation for an image library (especially one integrated into a file-management sequence) is to discover the MIME type of an image file (by looking at header bytes and not just the file extension) as well as the dimensions of the image as quickly as possible.

Unfortunately the only way to do this now is to decode and load the image completely into a BufferedImage (to get the dimensions) and guess at the mime type via the image type and file extension.

Fortunately there is a super-simple class written by Jaimon Mathew that can read the first handful of bytes from a file and determine exactly this information:
http://blog.jaimon.co.uk/simpleimageinfo/SimpleImageInfo.java.html

This functionality should be integrated into imgscalr directly (original license is Apache 2, so it's compatible).

With any library it is important to know, up-front, what the cost of certain ops are. Most methods in the JDK require you read through the source code to find out, in imgscalr because so much time has been taking reading through JDK classes to ensure the fastest routes were taken, it would be handy to add this to the Javadoc so users of the API know.

By-design, BufferedImageOps are suppose to be capable of creating their own destination image to render into if one is not provided to them (filter(src, null)). Unfortunately, thanks to this decade old bug:
http://bugs.sun.com/bugdatabase/view_bug.do;jsessionid=33b25bf937f467791ff5792cb9dc?bug_id=4965606

AffineTransferOps are incapable of doing this and always see the image they create as 0-width and then throw an exception.

When a JPEG image contains metadata (e.g. off of a digital or cell phone camera) and the original image is resized with imgscalr, the metadata is not retained from the original to the scaled copies. This is because reading and writing metadata, in all the formats used by camera companies, is a complex topic and no well-tested libraries exist that do both.

When the time is right, considering integrating a solution that maintains at least some (preferably all) of the metadata from the original to the resized copies.

It may be handy to have a tightened up crop function built into imgscalr.

Has been requested in the past.

In the 3.0 release the BufferedImageOp argument is a single optional argument; there is no reason this shouldn't be a var-arg that allows multiple ops to be applied to an image.

For example, blur & rotate, or crop & blur & rotate.

It makes imgscalr more flexible both to users with custom Ops they want to provide as well as imgscalr providing good default Ops that can be easily used by the caller.

The core issue with ANY of the exif-enabled features of imgscalr is utilizing a library that is able to correctly pull that data from most all image file types.

Looking into the issue of EXIF data in image files and you find a litany of half-finished libraries or good libraries (like Drew Noakes's Metadata Extractor) that add a large dependency footprint to the simple imgscalr library.

After researching this topic for about a month, I found that Phil Harvey's ExifTool looks to be hands down the most complete and functional image (and video) metadata file library available. The project is about 10 years old and supports not only every file format know to man but reading AND writing most every scrap of metadata a file can contain.

Given that a few of the feature enhancements requested of imgscalr pertain to maintaining EXIF data in scaled copies of images (would requiring writing metadata) I think it would be best to try and provide support for ExifTool.

While ExifTool is written in Perl, it does run on all major platforms.

Discussions with Michael Harris and the pain point that is resizing original JPEGs that loose their "Orientation" EXIF data after scaling... it might be worth re-investigating adding rotation of images keyed off of the image metadata using something like the metadata-extractor library.

Something like:
// Makes an attempt to figure out the rotation degree from the image's metadata.
Image i = Scalr.resize(Method.AUTOMATIC, Rotation.AUTOMATIC, 150);

or

Image i = Scalr.resize(Method.AUTOMATIC, Rotation.90_CW, 150);

or some such equivalent... could become very handy.

What killed this original impl was making it pre-defined rotation BufferedImageOps defined as constants on the class because of the origin re-homing required to get a good rotation and the immutable nature of the AffineTransform instances wrapped by the AffineTransformOps.

Might justify a custom AffineTransformOp impl that allows for the wrapped AffineTransform to be manipulated.

NOTES:
AffineTransformOp xform ref is private (can't get to it through subclassing) and getTransform returns a clone... damn it all.

As a compliment to the crop function being considered it may be helpful to offer a simple pad function that resizes the image but fills in the new space with a solid color (provided by the caller)

May also be helpful to consider allowing anchoring of the image, but this can open up a can of enum-worms as there are 9 potential anchor points.

Will likely just default to centering the image.

Right now all the logic and functionality is contained in a single static method -- if any implementors wanted to extend the library and replace certain portions of the logic inside the library it would be impossible without reimplementing the single master resize method completely.

Would be nice if logical functions were broken out into protected methods which could be easily overriden where appropriate.

There is no way to get slightly nicer looking images than available from the SPEED method without incurring the much higher cost of using QUALITY mode.

This was most notable when scaling some screenshots with text on them and noticing in SPEED mode, at any resolution, they look like total garbage, but simply applying a BILINEAR algorithm to them made them look immediately better.

There is no way to do that from the API right now.

Same as the debug issue filed -- these features need to be enable-able from system properties to avoid wrapper libraries from blocking the ability to see the debug information if the two boolean flags are not set in the method call.

Using a method argument (debug) as the trigger to enable debugging messages leaves the API's debug functionality up to the mercy of any wrapping convenience APIs that may build ontop of this.

It is much more flexible to allow the debugging flag to be set by a system variable.