Simple Java image-scaling library implementing Chris Campbell's incremental scaling algorithm as well as Java2D's "best-practices" image-scaling techniques.

imgscalr - Java Image-Scaling Library

	* Added support for a new Method.ULTRA_QUALITY scaling method.
	This new method uses 3.5x more incremental steps when scaling an image down
	than the QUALITY method, providing a much more accurate result. This is
	especially noticeable in thumbnails that have diagonal lines that get jagged
	during down-sizing with QUALITY or lower methods.
	The quality of the ULTRA_QUALITY scaling method is almost on par with the
	image resize functionality built into Mac OS X; that is to say it is better
	than GIMP's Lancsoz3 and Windows 7 built-in resize.
	* Fixed subtle bug with incremental scaling and Mode.FIT_EXACT causing the
	incremental scaling to stop too soon resulting in the wrong-sized result
	The stop-condition for incremental scaling assumed that in every case the
	width AND height would be shrinking each iteration; when using 
	Mode.FIT_EXACT this is not necessarily true as one dimension may not change
	at all or stop changing before another. 

	* Fixed NullPointerException that occurred when debugging was enabled
	Required a patch-release due to the show-stopping nature of the bug.

	* [BREAKING] Package has changed from com.thebuzzmedia.imgscalr to 
	org.imgscalr - I am sorry for the inconvenience of this, but this is
	necessary. There will be a family of imgscalr-based Java utilities coming
	out in the future (ExifTool is next) that will all be under this umbrella.
	* [BREAKING] Java 6 is now required for using imgscalr. 
	The reason for this is because imgscalr includes specific types of 
	ResizeOp and ColorConvertOps that actually segfault the latest Java 5 VM 
	when applied, but run fine in Java 6 and 7.
	imgscalr cannot knowingly ship VM-segfaulting code that could would 
	introduce a potentially	devastating situation into client applications.
	This decision was not made lightly, but with Java 5 end-of-lifed and Java 6
	being out for 5 years, it seemed like a reasonable requirement.

	* [BREAKING] Rotation enum was totally redefined. All rotations were 
	redefined in terms of 90,180,270 quadrant rotations as well as h/v FLIP.
	* [BREAKING] All resize(...) methods that accepted Rotation enums are 
	removed. All graphic operations are now separate and discrete, but can be
	easily combined when multiple effects are wanted.
	* Added apply() support for applying an arbitrary list of BufferedImageOps
	SAFELY and efficiently working around all the bugs in the JDK pertaining
	to BufferedImageOps (also used internally when applying any optionally 
	specified ops).
	* Added crop() support.
	* Added pad() support.
	* Added rotate() support.
	* All graphic operations (even new ones) were modified to allow the 
	application of 1 or more BufferedImageOps to a final image result before
	returning it for convenience.
	* Support for all the new operations (apply, crop, pad, rotate) were all 
	added to AsyncScalr so these operations can all be asynchronously performed 
	as well.
	* Added support for horizontal and vertical flipping of the image via the
	Rotation enum and new rotate() method.
	* Added pre-defined OP_DARKER and OP_BRIGHTER operations that can be applied
	to any image to make them darker or brighter (respectively) by 10%.
	* Added Mode.FIT_EXACT to support (for the first time) scaling images 
	forced into a specific given dimension instead of honoring the image's
	orientation and proportions automatically. 
	* AsyncScalr's use of ExecutorService was rewritten; no more support for
	passing in custom ExecutorService implementations or modifying existing ones
	on the fly and having the class do something magic to them under the
	covers (that was bad) -- just extend the class and specify your own logic.
	* AsyncScalr can be easily customized now through a single method:
		- createService()
		- createService(ThreadFactory)
	* AsyncScalr provides two custom ThreadFactory implementations for subclasses
	to use if they want to customize the types of Threads generated and used 
	internally for async scale operations.
		- DefaultThreadFactory creates default threads with all default settings.
		- ServerThreadFactory generates threads that are optimized to execute in
		  a server environment (daemon threads w/ LOW_PRIORITY).
	* AsyncScalr.DEFAULT_THREAD_COUNT was removed and replaced with THREAD_COUNT
	that can be customized and set via system properties.
	* AsyncScalr.THREAD_COUNT's property name was separated into a String constant
	to make it easier to work with.
	* Simplified the resize() calls as a result of making all operations discrete;
	8 duplicate methods accepting "rotation" arguments were removed.
	* Optimized the application of BufferedImageOps.
	* Fixed a bug in the application of BufferedImageOps which could have led
	to an ImagingOpException bubbling up from native Java2D or a corrupt (black)
	image for poorly supported image types.
	* Memory optimized the application of 2 or more BufferedImageOps (interim
	images are explicitly cleaned up just like in incremental scaling).
	* Optimized log() implementation to avoid StringBuilder creation and string
	concatenation. Should be significant run-time savings over time if you are
	running in an environment with debugging turned on.
	* Removed the identity-return functionality in each method to throw an 
	exception instead of silently returning "src" unchanged.
	This was done intentionally to avoid users getting caught in the situation
	where they have code that automatically calls flush() on "src" after an
	imgscalr method has returned (assuming they NOW have a modified copy to work
	In the case of sending in invalid or null arguments, previously imgscalr
	would return "src" unchanged, which means the caller would be calling
	flush() on a perfectly good image they still needed and not a copy as was
	assumed by using imgscalr (And there would be no way to tell if imgscalr had
	created a copy or not without using an == check with EVERY returned image
	Instead, invalid or missing arguments passed to any imgscalr method are
	now considered an exception so the caller knows IMMEDIATELY when something
	is wrong and won't get magically different/unexpected behavior.
	* Exposed the potential for every method to fire an ImagingOpException if
	one of the BufferedImageOps fails to apply using the hardware-accelerated
	underlying Java2D code path. These exceptions were previously hidden in the
	guts of Java2D and could bubble up unexpectedly, now they are clearly defined
	directly on the imgscalr API so they can be cause and handled IF the caller
	wants or needs to do that when using custom BufferedImageOps.
	* Detailed notations about performance optimizations the caller can make to
	ensure their handling of images are as performant as possible were added to
	all the methods as a convenience.
	* Defined DEBUG system property name as a public constant that can be used
	to help avoid misspellings when trying to set debugging on.
	* Modified LOG_PREFIX so it can now be set via the "imgscalr.logPrefix" 
	system property value now.
	* Rewrote imgscalr test suite to specifically test all discrete operations
	and all variations of the operations as well.
	* Added AllTests test suite so all tests can be easily run at one time to
	verify the release.
	* Rewrote Javadoc covering a lot of the return and exception conditions for
	all the methods to more clearly communicate what is happening inside the
	method and to the original images.

	* Added support for asynchronous & rate-limited scaling operations via the
	AsyncScalr class.
	The AsyncScalr class wraps the parent Scalr class and submits scale jobs to
	an internal ExecutorService. The executor service can be used to serialize
	and queue up scaling operations to avoid blowing the heap and overloading the
	underlying host on a busy, multi-user system (e.g. a web app running imgscalr).
	AsyncScalr by default uses a fixed-size ThreadPoolExecutor that can be modified
	at run time to any tuned level of threads the caller desires (default 2). The
	default settings are intended to be safe/efficient to use out of the box on 
	most all systems.
	Additionally, AsyncScalr can be configured to use *any* ExecutorService 
	implementation passed to it so callers have ultimate control over how the 
	AsyncScalr processes jobs if they need/want it.
	Typically it is a good idea to roughly map # of Scaling Threads to the # of 
	Cores on the server, especially on a server with plenty of memory and a large
	heap for the VM.
	If you are running inside of a smaller VM heap or lower-memory server (regardless
	of core count) you will want to limit the number of simultaneous scale operations
	so as not to saturate the heap during scaling when the images are read into
	internal BufferedImage instances in VM memory.

	* Added support for Rotation to the library. You can now specify the following
	rotations to be applied to your image:
	Rotation.NONE - No rotation.
	Rotation.CLOCKWISE - Clockwise (90 degrees to the right) rotation.
	Rotation.COUNTER_CLOCKWISE - Counter-clockwise (90 degrees to the left) rotation.
	Rotation.FLIP - Flip the image (180 degrees rotation).
	The rotation is performed as tightly and efficiently as possible, explicitly
	cleaning up temporary resources created during the operation.
	* API was simplified as duplicate methods without the vararg parameter were
	removed (these were effectively duplicates of the vararg methods make the
	API longer than it needed to be).
	* Corrected a multitude of incorrect Javadoc comments pertaining to @throws
	* Rewrote the method Javadoc. Manually reviewing uncovered too many copy-paste
	discrepancies that left out important information that would be helpful in
	a  Javadoc popup in an IDE while using imgscalr.
	* All new code heavily commented.

	* You can now specify Mode.FIT_TO_WIDTH or Mode.FIT_TO_HEIGHT behaviors
	when resizing an image to get imgscalr to treat one dimension as the primary
	and recalculate the other dimension to best fit it, regardless of the image's
	orientation. Previously this was decided automatically for you by the
	orientation of the image.
	* resize methods now accept 0 or more BufferedImageOps as var-arg arguments.
	* Workaround for a 10-year-old JDK bug that causes RasterExceptions to get
	thrown from inside of Java2D when using BufferedImageOps was built directly
	into imgscalr so you don't have to worry about RasterExceptions. More
	info here:
	* API was made more strict and an IAE is thrown if 'src' is null to any of
	the resize operations; a user reported that he spent a while debugging why
	"imgscalr wasn't working" only to find out it was silently returning due to
	a null source image. Would have been helpful if imgscalr had notified him of
	the issue immediately.

	* Big thanks to Magnus Kvalheim from for help with
	this release!
	* Support for hardware-accelerated BufferedImageOp's was added to the library.
	You can now provide an optional BufferedImageOp to many of the methods in the
	imgscalr library and it will be applied to the resultant image before returning
	* Most common request was for imgscalr to apply an "anti-aliasing" filter to
	results before returning them; this was achieved by adding support for
	BufferedImageOps and providing a hand-tuned ConvolveOp to provide a good
	default that can be applied easily by folks that want the effect but don't
	want to learn all about BufferedImageOps and what "convolve" even means.
	* Speed/Balance/Quality THRESHOLD values were adjusted for more optimal results
	when relying on Method.AUTOMATIC to give good-looking results.
	* Javadoc was updated to clarify hardware acceleration behaviors.

	* Scaling of certain image types (and byte layouts) could result in very poor
	looking scaled images ("pixelated" look, discolored dithering, etc.). This was
	corrected by imgscalr forcibly scaling all source images into the most well-supported
	image types by Java2D, resulting in excellent scale result quality regardless
	of the Method specified.
	* The issue of scaling of poorly supported (by Java2D) image-types can lead 
	to unexpectedly poor performance was also corrected as a side-effect of this
	because all source images are converted to the most commonly supported image
	type for Java2D.

	* API-break: resize(BufferedImage, Method, int, int, boolean, boolean) was removed and
	replaced by resize(BufferedImage, Method, int, int).
	* DEBUG system variable added; set 'imgscalr.debug' to true to trigger debugging output
	in the console. The boolean debug and elapsedTime arguments to the resize method
	have been removed.
	* New BALANCED method added. Provides a better result than SPEED faster than QUALITY.
	* Added 2 optimized thresholds (in pixels) that the API uses to select the best Method
	for scaling when the user specifies AUTOMATIC (or doesn't specify a method). This helps
	provide much better results out of the box by default and tightens up the performance of the
	API a bit more.
	* Image comparison generator utility (ComparisonGenerator test class) added.
	* Functional portions of API broken into static protected methods that can be
	easily overridden by implementors to customize the API without needing to rewrite
	the resize methods.
	* Consolidated 5 locations of duplicated rendering code into a single method (scaleImage).
	* Tightened up image scaling operation to do everything possible to avoid memory leaks (every native
	resource is disposed or released explicitly)
	* Detailed logging information integrated. If the 'imgscalr.debug' system property is
	true, the API outputs exactly what it's doing, what argument values it is processing and
	how long it is taking to do each scale operation.
	* When AUTOMATIC method is specified, the API is more intelligent about selecting
	SPEED, BALANCED or QUALITY based on the images primary dimension only (more accurate).
	* Copious amounts of Javadoc added to new methods, new code and existing code. 
	Issues Resolved in 2.0:

	* Default proportional-scaling logic is more straight forward. If an image is
	landscape then width is the preferred dimension and the given height is ignored
	(and recalculated) and visa-versa if the image is portrait oriented. This gives
	much better "default behavior" results.
	* Added new convenience method resize(BufferedImage,int,int)
	* Modified build.xml to output Maven-friendly artifact names.
	* Library now available from the Maven repo, see
	"Maven" section on this page for more information:
	* Javadoc is now available on the web at:
	Issues Resolved in 1.2:

	* Initial public release.

This library is released under the Apache 2 License. See LICENSE.

A class implementing performant (hardware accelerated), good-looking and 
intelligent image-scaling algorithms in pure Java 2D. This class implements the 
Java2D "best practices" when it comes to scaling images as well as Chris 
Campbell's incremental scaling algorithm proposed as the best method for 
down-sizes images for use as thumbnails (along with some additional minor 

imgscalr also provides support for applying arbitrary BufferedImageOps against
resultant images directly in the library.

TIP: imgscalr provides a default "anti-aliasing" Op that will very lightly soften
an image; this was a common request. Check Scalr.OP_ANTIALIAS

TIP: All resizing operations maintain the original images proportions.

TIP: You can ask imgscalr to fit an image to a specific width or height regardless 
of its orientation using a Mode argument.

This class attempts to make scaling images in Java as simple as possible by providing
a handful of approaches tuned for scaling as fast as possible or as best-looking 
as possible and the ability to let the algorithm choose for you to optionally create 
the best-looking scaled image as fast as possible without boring you with the details 
if you don't want them.

In the simplest use-case where an image needs to be scaled to proportionally fit 
a specific width (say 150px for a thumbnail) and the class is left to decide which 
method will look the best, the code would look like this:

  BufferedImage srcImage =; // Load image
  BufferedImage scaledImage = Scalr.resize(srcImage, 150); // Scale image

You could even flatten that out further if you simply wanted to scale the image 
and write out the scaled result immediately to a single line:

  ImageIO.write(Scalr.resize(, 150));

Working with GIFs
Java's support for writing GIF is... terrible. In Java 5 is was patent-encumbered
which made it mostly totally broken. In Java 6 the quantizer used to downsample
colors to the most accurate 256 colors was fast but inaccurate, yielding 
poor-looking results. The handling of an alpha channel (transparency) while writing
out GIF files (e.g. ImageIO.write(...)) was non-existent in Java 5 and in Java 6
would remove the alpha channel completely and replace it with solid BLACK.

In Java 7, support for writing out the alpha channel was added but unfortunately
many of the remaining image operations (like ConvoleOp) still corrupt the
resulting image when written out as a GIF.

NOTE: Support for scaling animated GIFs don't work at all in any version.

My recommendation for working with GIFs is as follows in order of preference:

1. Save the resulting BufferedImage from imgscalr as a PNG; it looks
better as no quantizer needs to be used to cull down the color space and 
transparency is maintained. 

2. If you mostly need GIF, check the resulting BufferedImage.getType() to see
if it is TYPE_INT_RGB (no transparency) or TYPE_INT_ARGB (transparency); if the
type is ARGB, then save the image as a PNG to maintain the alpha channel, if not,
you can safely save it as a GIF.

3. If you MUST have GIF, upgrade your runtime to Java 7 and save your images as
GIF. If you run Java 6, any GIF using transparency will have the transparent
channel replaced with BLACK and in Java 5 I think the images will most all be

REMINDER: Even in Java 7, applying some BufferedImageOps (like ConvolveOp) to
the scaled GIF before saving it totally corrupts it; so you would need to avoid
that if you didn't want to save it as a PNG. If you decide to save as a PNG, you
can apply any Ops you want.

Image-manipulation in Java can take more memory than the size of the source image
because the image has to be "decoded" into raw ARGB bytes when loaded into the
BufferedImage instance; fortunately on most platforms this is a hardware-accelerated
operation by the video card.

If you are running into OutOfMemoryExceptions when using this library (e.g. if you
dealing with 10+ MB source images from an ultra-high-MP DSLR) try and up the 
heap size using the "-Xmx" command line argument to your Java process.

An example of how to do this looks like:

  java -Xmx128m

Chris Campbell Incremental Scaling -

Related Projects
ExifTool for Java -

If you have questions, comments or bug reports for this software please contact
us at: [email protected]
  • Jagged outlines when shrinking a picture

    Jagged outlines when shrinking a picture

    I tried to resize pictures using the imgscalr library, code:

    BufferedImage resized = Scalr.resize(original, Scalr.Method.QUALITY, newWidth, newHeight);

    ImageIO.write(resized, "png", fileOut);

    Using Scalr.OP_ANTIALIAS resulted in a bit blurred image, but the edges of the display remained jagged.

    The original image is 500px * 500px and the result was 136px * 136px.

    The same behaviour can be seen on imgscalr CDN service:

    • original:
    • resized:
    opened by exebar 16
  • Add FIT_BOTH Mode that honors both Width and Height sizes.

    Add FIT_BOTH Mode that honors both Width and Height sizes.

    Requested by a few folks, a mode that honors both the dimensions not just the primary one or the preferred one.

    From Olli Kallioinen:

    I have a certain size area reserved for displaying an image. For example 500x300 pixels. In no case must either of the image dimensions be larger than this area.

    Now if an image is for example 500x400 pixels the automatic scaling sees it's landscape, and that it fits the width of 500 so it does nothing. Clearly the image still does not fit the area that was reserved for it.

    opened by ghost 8
  • no resize when source image's width equals target image's width

    no resize when source image's width equals target image's width

    no resize when source image's width equals target image's width.

    the condition in the method scaleImageIncrementally

    if (prevCurrentWidth == currentWidth || prevCurrentHeight == currentHeight) break;

    is true,so break out;

    no resize when source image's height equals target image's height.

    opened by jimlaren 8
  • Potential thread locking in AsyncScalr

    Potential thread locking in AsyncScalr

    I created a Java servlet with multiple threads that are responsible to load and save data on an embedded system with only one processor and limited amount of memory. One of these threads is responsible to scale images. Currently, no other threads scales images. To experiment with AsyncScalr.resize, I set imgscalr.async.threadCount to 1 via system property. After running the servlet for a couple of days, the image scaling thread appeared to have locked indefinitely. Here is a thread dump using Java VisualVM:

    "Thread-9" - Thread [email protected] java.lang.Thread.State: WAITING at sun.misc.Unsafe.park(Native Method) - parking to wait for <19d6984> (a java.util.concurrent.FutureTask$Sync) at java.util.concurrent.locks.LockSupport.park( at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt( at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly( at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly( at java.util.concurrent.FutureTask$Sync.innerGet( at java.util.concurrent.FutureTask.get( ... at

    Locked ownable synchronizers: - None

    Please note that there is only one thread that called AsyncScalr.resize. Thank you.

    opened by thianpeng 7
  • JPEG metadata is lost for resized images

    JPEG metadata is lost for resized images

    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.

    opened by ghost 6
  • Resized JPG image gets Pink background

    Resized JPG image gets Pink background

    I resized several images from this website:

    For example the attached file.

    I resized the image(s) with imgscalr and the result was broken (pink background).

    Also replicable with the online demo:

    Input Image: bugged

    Bugged Result: GwgGKaAuv-M

    opened by nickrussler 5
  • jagged lines

    jagged lines

    Try resizing

    i get output like:

    I used the following and also get jagged lines along the tennis court lines

            Scalr.resize(img, scalrQuality, Scalr.Mode.FIT_EXACT, targetWidth, targetHeight, Scalr.OP_ANTIALIAS)
    opened by tc 5
  • Java crash on Scalr.resize

    Java crash on Scalr.resize


    I'm getting a Java crash when trying to resize a TIFF image to a large size (31875x20625).

    Here is a link to the file:

    Here is the partial log: JRE version: 7.0_17-b02 Java VM: Java HotSpot(TM) 64-Bit Server VM (23.7-b01 mixed mode windows-amd64 compressed oops) Problematic frame: C [awt.dll+0x4574d] Java_sun_java2d_loops_TransformHelper_Transform+0x352ed

    Full log here:

    Here is the call I'm using: Scalr.resize( imageConverted, Method.SPEED, Scalr.Mode.AUTOMATIC, width, height, (BufferedImageOp[])null );

    Were: width = 31875, height = 20625 and imageConverted is the TIFF as a BufferedImage object.

    This call works well if the width and/or height are reduced, any help or advice debugging would be greatly appreciated.


    opened by darcyd 3
  • File size grows when resizing images

    File size grows when resizing images

    I have noticed that the file size grows dramatically when resizing an image. This is most noticeable when resizing to a dimension very close (or equal to) the original size of the image.

    I am using this code:

    Scalr.resize(, 1024);

    When I start with a file that is 103kb on disk, (1222x574 px) it ends up being over 800k after it is resized to a final dimension of 1024x481 px. Is this expected? ( I have tried this with several JPGs from different sources and the results are consistent)

    opened by JoeJErnst 3
  • Support/Tested on OpenJDK 7?

    Support/Tested on OpenJDK 7?

    I'm currently using imgscalr serverside for image processing. Since Oracle will no longer allow easy jdk 1.6 packaging for Ubuntu, OpenJDK 7 seems to be the only option for Ubuntu.

    Is imgscalr supported on openjdk 7?

    opened by tc 3
  • resize() not resizing image

    resize() not resizing image

    When calling resize(BufferedImage src, int targetWidth, int targetHeight, BufferedImageOp... ops) with a 200x200 image, targetWidth=200, targetHeight=80 and no ops, Scalr does not resize the image.

    This is due to code on line 1599, which returns the original image if the targetWidth matches the source width and the source image is a square. However, since the target dimension are not square, the image should be resized to fit in the targetHeight.

    opened by bgooren 3
  • Fastest Method for Downscaling Large Image

    Fastest Method for Downscaling Large Image

    Hi, I'm using imgscalr to downscale large images(4k+) and on certain large images the scaling takes ~8+ seconds. I have tried using METHOD.SPEED but it only took off ~100-200ms. If I scale the image using ImageMagick it takes around 2-2.5 seconds. I know there will be differences in image manipulation software, but is there any way to achieve similar results using imgscalr?

    ImageMagick: time convert -resize 150x 20210927_OHR.Susuki__JA-JP6548971154_UHD.jpg -quality 10 susuki.jpg real 0m1.649s user 0m2.312s sys 0m0.244s

    I'm using OpenJDK 16.0.2 on windows 10 x64 with these two images:

    Here is the relevant code(in kotlin):

    fun generateThumbnailScalr(fullSizeImagePath: File) { val startTime = System.currentTimeMillis() val srcImage = val scaledImage = Scalr.resize(srcImage, Scalr.Method.SPEED , 150) val thumbFileExt = fullSizeImagePath.extension val thumbImagePath = "Images/thumbs/scalr_${fullSizeImagePath.nameWithoutExtension}_thumb.$thumbFileExt" val thumbFile = File(thumbImagePath) ImageIO.write(scaledImage, "jpg", thumbFile) println("[${System.currentTimeMillis() - startTime}ms] for $fullSizeImagePath") }

    Which outputs: [8906ms] for Images\20210927_OHR.Susuki__JA-JP6548971154_UHD.jpg [6694ms] for Images\20210929_OHR.TokyoSkyTree__JA-JP0701062199_UHD.jpg

    opened by Ep0chalypse 0
  • [ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test (default-test) on project imgscalr-lib: There are test failures.

    [ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test (default-test) on project imgscalr-lib: There are test failures.

    Dear imgscalr team, I am getting the error bellow when running mvn package using Apache Maven 3.8.2.

    Thread Finished 19200
    Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 65.258 sec - in org.imgscalr.AsyncScalrMultiThreadTest
    Running org.imgscalr.ScalrPadTest
    Tests run: 5, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.521 sec <<< FAILURE! - in org.imgscalr.ScalrPadTest
    testPadAlphaOps(org.imgscalr.ScalrPadTest)  Time elapsed: 0.26 sec  <<< FAILURE!
    java.lang.AssertionError: expected:<-11711155> but was:<-11776948>
    	at org.imgscalr.ScalrPadTest.testPadAlphaOps(
    Running org.imgscalr.ScalrApplyTest
    Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.364 sec <<< FAILURE! - in org.imgscalr.ScalrApplyTest
    testApply4(org.imgscalr.ScalrApplyTest)  Time elapsed: 0.234 sec  <<< FAILURE!
    java.lang.AssertionError: expected:<-11842741> but was:<-11908534>
    	at org.imgscalr.ScalrApplyTest.testApply4(
    Running org.imgscalr.ScalrResizeTest
    Tests run: 13, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.838 sec <<< FAILURE! - in org.imgscalr.ScalrResizeTest
    testResizeWHSpeedExactOps(org.imgscalr.ScalrResizeTest)  Time elapsed: 0.187 sec  <<< FAILURE!
    java.lang.AssertionError: expected:<-11711155> but was:<-11776948>
    	at org.imgscalr.ScalrResizeTest.testResizeWHSpeedExactOps(
    Running org.imgscalr.ScalrRotateTest
    Tests run: 7, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.744 sec <<< FAILURE! - in org.imgscalr.ScalrRotateTest
    testRotateFlipHOps(org.imgscalr.ScalrRotateTest)  Time elapsed: 0.251 sec  <<< FAILURE!
    java.lang.AssertionError: expected:<-15461356> but was:<-15527149>
    	at org.imgscalr.ScalrRotateTest.testRotateFlipHOps(
    Results :
    Failed tests: 
      ScalrApplyTest.testApply4:47->AbstractScalrTest.assertEquals:77 expected:<-11842741> but was:<-11908534>
      ScalrCropTest.testCropXYWHOps:61->AbstractScalrTest.assertEquals:77 expected:<-14079703> but was:<-14145496>
      ScalrPadTest.testPadAlphaOps:64->AbstractScalrTest.assertEquals:77 expected:<-11711155> but was:<-11776948>
      ScalrResizeTest.testResizeWHSpeedExactOps:136->AbstractScalrTest.assertEquals:77 expected:<-11711155> but was:<-11776948>
      ScalrRotateTest.testRotateFlipHOps:65->AbstractScalrTest.assertEquals:77 expected:<-15461356> but was:<-15527149>
    Tests run: 34, Failures: 5, Errors: 0, Skipped: 0
    [INFO] ------------------------------------------------------------------------
    [INFO] ------------------------------------------------------------------------
    [INFO] Total time:  05:28 min
    [INFO] Finished at: 2021-09-02T21:48:32+01:00
    [INFO] ------------------------------------------------------------------------
    [ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test (default-test) on project imgscalr-lib: There are test failures.
    [ERROR] Please refer to /home/pedro/repositories/imgscalr/target/surefire-reports for the individual test results.
    [ERROR] -> [Help 1]
    [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
    [ERROR] Re-run Maven using the -X switch to enable full debug logging.
    [ERROR] For more information about the errors and possible solutions, please read the following articles:
    [ERROR] [Help 1]
    opened by pedrombmachado 2
  • Update pom.xml

    Update pom.xml

    Fix error Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.12.4:test (default-test) on project imgscalr-lib: There are test failures.

    opened by pedrombmachado 0
  • Using imagescarl throws error

    Using imagescarl throws error

    I downloaded imagescalr and added it to the project. When trying to rezise a image withScalr.resize(this.chessImg, Scalr.Method.SPEED, Scalr.Mode.FIT_TO_WIDTH,

    I get the following error:

    Exception in thread "main" java.lang.NoClassDefFoundError: org/imgscalr/Scalr$Method
    	at main.ChessField.<init>(
    	at main.GameRenderAWT.<init>(
    	at main.Main.<init>(
    	at main.Main.main(
    Caused by: java.lang.ClassNotFoundException: org.imgscalr.Scalr$Method
    	at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(
    	at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(
    	at java.base/java.lang.ClassLoader.loadClass(
    	... 4 more

    I am sure that I have added th jar ro the project so i dont know why classes would be missing.

    opened by LuposX 0
  • Resize randomly gets stuck for very long time

    Resize randomly gets stuck for very long time

    Experiencing a weird issue where randomly resize takes very long time. In the most recent occurrence it took around 30 mins. One additional thing I have observed is that if imgscalr seems to be stuck, logging into the machine causes the issue to resolve.

    I have changed macOS Settings but to no avail. Here are relevant settings:

    Screen Saver -> Starts After: Never Energy Saver -> Turn Display Off: Never Energy Saver -> Prevent Computer from Sleeping when display is off: Checked Energy Saver -> (remaining settings are unchecked)

    The code that invokes resize is as follows:

    public static BufferedImage resizeImage(BufferedImage image, Integer width, Integer height) throws Exception {"Resizing image to :: " + width + " x " + height);
    		BufferedImage scaled = Scalr.resize(image, Scalr.Method.AUTOMATIC, width, height);"Done Resizing");
    		return scaled;

    Logs from the above code:

    2018-09-26 01:21:08 [pool-2-thread-1] [INFO ] [ScreenShotUtils     ] [222] - Resizing image to :: 375 x 667
    [imgscalr] Debug output ENABLED
    [imgscalr] Resizing Image [size=750x1334, resizeMode=AUTOMATIC, orientation=Portrait, ratio(H/W)=1.778667] to [targetSize=375x667]
    [imgscalr] 		AUTOMATIC scaling method selected: QUALITY
    [imgscalr] 	Using Scaling Method: QUALITY
    [imgscalr] 	QUALITY scale-down, incremental scaling will be used...
    [imgscalr] 		Scaling from [750 x 1334] to [375 x 667]
    2018-09-26 01:54:20 [pool-5-thread-1] [INFO ] [xxxxxxx] [47] - <A lot of logs from other thread in between, so process is definitely still running>
    [imgscalr] 		Incrementally Scaled Image in 1 steps.
    [imgscalr] Resized Image in 2000611 ms
    2018-09-26 01:54:29 [pool-2-thread-1] [INFO ] [ScreenShotUtils     ] [224] - Done Resizing


    Machine: Mac mini (Late 2014) OS: macOS 10.13.6 Processor: 2.8 GHz Intel Core i5 Memory: 16 GB 1600 MHz DDR3 Graphics: Intel Iris 1536 MB

    Java Version:

    java version "1.8.0_144"
    Java(TM) SE Runtime Environment (build 1.8.0_144-b01)
    Java HotSpot(TM) 64-Bit Server VM (build 25.144-b01, mixed mode)

    imgscalr(included through mvn):

    opened by tahasamad 1
A well-designed local image and video selector for Android

Matisse Matisse is a well-designed local image and video selector for Android. You can Use it in Activity or Fragment Select images including JPEG, PN

Zhihu 12.3k Sep 30, 2022
Roman Beskrovnyi 236 Sep 19, 2022
Fast computer vision library for SFM, calibration, fiducials, tracking, image processing, and more.

Table of Contents Introduction Cloning Repository Quick Start Gradle and Maven Building from Source Dependencies Help/Contact Introduction BoofCV is a

Peter Abeles 895 Oct 2, 2022
Diagrams as code is a term used for storing the source of a diagram image as a text file.

Diagrams as code Diagrams as code is a term used for storing the source of a diagram image as a text file. Examples are architecture diagrams, or diag

null 25 Aug 3, 2022
Custom Image Server for use with ShareX

rImageServer How to use: Normal Instalation: Download .jar Start: javar -jar [filename].jar Edit: imageserver.propierties Check if web works -> Go to

Ryzeon 11 May 21, 2022
Luban—Image compression with efficiency very close to WeChat Moments

Luban—Image compression with efficiency very close to WeChat Moments

郑梓斌 13.1k Sep 29, 2022
Provide image storage and access services.

Provide image storage and access services.

shiyq 2 Jan 23, 2022
Traditional roguelike game with pixel-art graphics and simple interface

Traditional roguelike game with pixel-art graphics and simple interface

Evan Debenham 2.3k Sep 27, 2022
Thumbnailator - a thumbnail generation library for Java

March 11, 2021: Thumbnailator 0.4.14 has been released! See Changes for details. Thumbnailator is now available through Maven! What is Thumbnailator?

Chris Kroells 4.3k Sep 30, 2022
ZXing ("Zebra Crossing") barcode scanning library for Java, Android

Project in Maintenance Mode Only The project is in maintenance mode, meaning, changes are driven by contributed patches. Only bug fixes and minor enha

ZXing Project 30.1k Sep 24, 2022
Java library for remapper JARs

Pocolifo's JAR Remapper Making remapping JARs easy, organized, and painless Features Remapping Class remapping Method remapping Field remapping Parame

null 8 Oct 2, 2022
A Java Visualization Library based on Apache ECharts.

ECharts Java "We bring better visualization into Java with ECharts" ?? Introduction ECharts Java is a lightweight but comprehensive library for Java d

ECharts Java Open Source Project 123 Sep 22, 2022
Java interface to OpenCV, FFmpeg, and more

JavaCV Commercial support: Introduction JavaCV uses wrappers from the JavaCPP Presets of commonly used libraries by researchers in the field of comput

Bytedeco 6.2k Sep 29, 2022
Java JNA wrapper for Tesseract OCR API

Tess4J A Java JNA wrapper for Tesseract OCR API. Tess4J is released and distributed under the Apache License, v2.0. Features The library provides opti

Quan Nguyen 1.2k Sep 27, 2022
TwelveMonkeys ImageIO: Additional plug-ins and extensions for Java's ImageIO

About TwelveMonkeys ImageIO is a collection of plugins and extensions for Java's ImageIO. These plugins extend the number of image file formats suppor

Harald Kuhr 1.5k Sep 27, 2022
Creates ASCII art in Java from Images

Creates ASCII art in Java from Images. It can also save the ASCII art as image (.png) as well

Navjot Singh Rakhra 4 Jul 12, 2022
A powerful 🚀 Android chart view / graph view library, supporting line- bar- pie- radar- bubble- and candlestick charts as well as scaling, panning and animations.

⚡ A powerful & easy to use chart library for Android ⚡ Charts is the iOS version of this library Table of Contents Quick Start Gradle Maven Documentat

Philipp Jahoda 35.6k Sep 27, 2022
This project allows the exchange of files between your local disk and a D64 image (Commodore 64 image disk) . Ce projet permet l'échange de fichiers entre votre disque local et une image D64 (Image de disquette du Commodore 64).

DiskToolC64 Ce projet permet l'échange de fichiers entre votre disque local et une image D64 (Image de disquette du Commodore 64). Introduction Les fi

Eddy BRIERE 3 May 13, 2021