It would be good to be able to specify a rotation angle (in multiples of 90 degrees) to be applied to the image before resizing.

We have a use case where on upload we need to read exif orientation data, rotate the image correctly, resize, and then send to the server.

Currently we have to do this by reading the image into a canvas on the main UI thread which negates the point of using pica and webworkers. By only supporting 4 angles for rotation it shouldn't be too hard to read the pixel data out in a different order and skip using CanvasRenderingContext2D.rotate().

Hi. First of all - many thanks for that library! We've been using it quite a lot but recently faced several images that result in broken output when using Chrome and <img> element as source. If used in Firefox - everything's fine. If used in Chrome with <canvas> element as source (without any transformation, just drawing image) - everything's fine. Options and features don't affect this.

Original image (one of) - https://dl.dropboxusercontent.com/1/view/zjnu3kgtyzq6zv3/pica/original.jpg Corrupted result (<img> source) - https://dl.dropboxusercontent.com/1/view/c6s817ypu7uibgi/pica/from%20image.png Correct result (<canvas> source) - https://dl.dropboxusercontent.com/1/view/kh4cisii050o4gn/pica/from%20canvas.png Playground for testing - https://codepen.io/msidorov/full/PoPdVjV

All these were taken from Chrome 81, different OSes

Many thanks in advance.

https://jsfiddle.net/uyczfLdk/21/

• open jsfiddle in chrome 64
• click resize button
• wait 2 - 10 seconds
• observe browser tab crash

The above JS fiddle is taking an 800px wide image and resizing it down to 4 pixels.

This seems to cause Chrome 64 on mac os 10.12.6 (Sierra) to crash with a warning in the Sources tab that there is an out of memory problem. Safari 11 seems to just spin a beach ball. Firefox 58 seems to work fine.

I think it is some what related to the multiple of the resize. I've seen making something 100x smaller work but not when it reaches 150+ smaller.

Hi, I've been doing some comparisons of pica's USM output to Photoshop and ImageMagick. Photoshop and ImageMagick seem to produce similar results to each other (with comparable USM parameters) but pica is not really comparable to either. It seems to me that pica sharpens significantly more, and there seems to be some color shift.

The color shift is the bigger issue for me, and it's very different from Photoshop and ImageMagick which seem more natural. At first I wasn't sure if the color shift was a byproduct of canvas conversion and/or resizing, so I resized with pica using no sharpening (only canvas resize) and the results are comparable to Photoshop / ImageMagick, so I'm pretty sure the color shift is coming from pica's USM recipe (and it seems to add a bluish tint, although it may depend on image).

I tried looking at the code to see what pica is doing and of course it is well beyond my area of expertise, ha. I did a search on SO and found this thread where Vitaly refers to color shift, so maybe this is to be expected?

https://stackoverflow.com/questions/13296645/opencv-and-unsharp-masking-like-adobe-photoshop/23322820#23322820

Is this just "how it is" with pica? Has anyone developed alternative USM recipes for pica that come closer to Photoshop / ImageMagick?

Here is my test image (not my image, but it seemed to be a good one to test various things like chroma sampling, USM, etc.)

https://live.staticflickr.com/65535/51137845528_83bd94d4bf_o.jpg

If you run it thru photoshop USM you can see color of the water stays somewhat neutral and golden, but pica USM tends to replace the golden highlights in the water with more blue.

I'm heavily using Pica to resize images in an application, but after doing too many in sequence I get the following JavaScript error:

RangeError: Failed to execute 'getImageData' on 'CanvasRenderingContext2D': Out of memory at ImageData creation

I've got it locked down to single-threaded operation so invocations of Pica are sequential instead of parallel, but I'm not sure what else I can do apart from not use Pica.

Right now you’re using a standard kernel + blur filter. Would be cool to use the magic kernel in order to get better image quality. See this post for the explanation of how that work: http://www.johncostella.com/magic/

Thanks for all the great work in your lib <3

Hi, Can we avoid the grey outlines that appear on the edges of the image content when re-sizing transparent images?

Source: http://i.share.pho.to/5c98cbcc_o.png

Result: http://i.share.pho.to/55d46162_o.png

Settings used for the above example http://i.share.pho.to/7bac2d68_o.jpeg

Since this happen when alphas are used, an option to change the black color that is filled when alphas are not used would be nice!

So I'm using this resize to upload images to my server, but after resizing, the colors change a bit, or maybe the brightness. For example, a full white image, after resizing, the white turns a bit dark (#fdfdfd). I really need that the output image is equal to the source image, but size.

Thanks anyway, this proect is old! But still useful, good work!

I'm using image-blob-reduce in a next.js app. In dev mode it works fine, but in prod mode, I get this error:

Uncaught ReferenceError: n is not defined

It happens in the pica source:

I already tried turning off Terser, did not change anything.

Do you have any ideas what I could change to get this to work?

https://developer.mozilla.org/en-US/docs/Web/API/ImageBitmapFactories/createImageBitmap

I was hoping pica would solve my performance issues, but it does not. Resizing in a web worker is great, but the problem is decoding the image data on the UI thread. My test image is 7200x4800 and 4.5 MB (https://hd.unsplash.com/photo-1414396938948-81a7045e336f).

The UI is blocked for about 700ms due to "Image Decode" triggered by getImageData.

Do you think we can use a File/Blob object, pass it to the web worker and decode the image there?

Note: you can not see this on the demo page, because you are rendering the images and the timeline doesn't show "Image Decode" separately but as part of "Composite Layers". If you hide the elements in the demo (display: none) you can see it. For the demo it's unavoidable to have image decoding on the UI thread, as you display the original image. But in the real world you might use pica to resize the image and then upload it, while never displaying the original to the user.

Hi,

I have been trying to debug this for some time and I would like to get your insight on this.

On my app, users can upload a lot of pictures, and I am using pica to resize them before uploading. On Firefox (saw this happening for users on mac, linux and windows) some images, not always the same when I try multiple times, are not correct once on the server. As I am calculating the checksum before upload, it is not caused by a network error.

Here is an example:

• Original image: https://www.dropbox.com/s/go5tra5czulbfsm/IMGL7717.jpg?dl=0
• Image after processing: https://www.dropbox.com/s/37n7ba5qhcl8vfq/314luvAL9s5OcI0ugieEKK-3cf7b61d9e.jpg?dl=0

I am using a code inspired by https://github.com/nodeca/nodeca.users/blob/master/client/users/uploader/uploader.js to extract the EXIF data, resize the image using pica, and then put it back together. For each file:

• Read it using readAsArrayBuffer
• call filterJPEG
• create a new Image
• set the src using window.URL.createObjectURL(file)
• create 2 canvas elements, set their size
• draw the image on the first one
• call pica to resize on the second canvas (one shared pica instance, using const pica = Pica({ idle: 10000 }))
• get a blob from the dst canvas
• put back together the JPEG header (from filterJPEG) and the body from the blob

Once this is done, I use a webworker to calculate the MD5 checksum of the previously created blob, and upload it to my server (where the MD5 checksum is checked again).

Do you have an idea of what can cause this? There are a lot of moving parts and I am only seeing the issue on Firefox. I would estimate than less than 0.5% of the files are corrupted like this, and retrying a corrupted file usually works fine. I havent seen this problem on Safari / Chrome.

I know this may not be related to Pica, but I spent quite a lot of time trying to understand where it may come from, and I am not sure of how to pin it down.

Thanks!

UPD: probably a browser bug https://github.com/nodeca/pica/issues/130#issuecomment-371617724

This could be a bug in Firefox (version 108.0.1) but I'm getting this error sometimes while processing a sequence of image resizes:

Exception { name: "NS_ERROR_FAILURE", message: "", result: 2147500037, filename: "webpack-internal:///./node_modules/pica/dist/pica.js", lineNumber: 2203, columnNumber: 0, data: null, stack: "[\"/index.js\"]</Pica.prototype.__landTileData@webpack-internal:///./node_modules/pica/dist/pica.js:2203:20\nprocessTile/</<@webpack-internal:///./node_modules/pica/dist/pica.js:2248:23\npromise callback*processTile/<@webpack-internal:///./node_modules/pica/dist/pica.js:2245:10\nlimit/</<@webpack-internal:///./node_modules/pica/dist/pica.js:1103:9\nroll@webpack-internal:///./node_modules/pica/dist/pica.js:1096:20\nlimit/<@webpack-internal:///./node_modules/pica/dist/pica.js:1113:7\nlimit@webpack-internal:///./node_modules/pica/dist/pica.js:1101:12\nprocessTile@webpack-internal:///./node_modules/pica/dist/pica.js:2220:19\n[\"/index.js\"]</Pica.prototype.__tileAndResize/</jobs<@webpack-internal:///./node_modules/pica/dist/pica.js:2302:14\n[\"/index.js\"]</Pica.prototype.__tileAndResize/<@webpack-internal:///./node_modules/pica/dist/pica.js:2301:24\npromise callback*[\"/index.js\"]</Pica.prototype.__tileAndResize@webpack-internal:///./node_modules/pica/dist/pica.js:2284:6\n[\"/index.js\"]</Pica.prototype.__processStages@webpack-internal:///./node_modules/pica/dist/pica.js:2358:15\n[\"/index.js\"]</Pica.prototype.resize/<@webpack-internal:///./node_modules/pica/dist/pica.js:2489:19\npromise callback*[\"/index.js\"]</Pica.prototype.resize@webpack-internal:///./node_modules/pica/dist/pica.js:2468:22\n_callee5$@webpack-internal:///./src/util.js:975:52\ntryCatch@webpack-internal:///./node_modules/@babel/runtime/helpers/esm/regeneratorRuntime.js:119:17\nwrap/generator._invoke</<@webpack-internal:///./node_modules/@babel/runtime/helpers/esm/regeneratorRuntime.js:99:32\ndefineIteratorMethods/

There's no proper message attached to the exception, just a stacktrace.

The code doing the resizing is pretty simple:

  let canv = document.createElement("canvas");
  canv.width = width;
  canv.height = height;
  let newCanv = pica.resize(img, canv);
  return pica.toBlob(newCanv, "image/jpeg", 0.9);

Thanks for sharing this great library, it really helps us and our multiple 100k customers in the world out there! :)

I would like to propose a small improvement as you can see in my PR. It would give a great benefit, if the users of the library could do some action, if a single Tile was resized.

• Then it is possible to react on it, e.g. show the resized Tile in some fancy looking UI
• It would then be also possible to validate the resized Tile for some criterias

You may be wondering what the concrete use-case for us is?

• On low memory devices(phones, old devices, ...) there is the problem, that sometimes downescaled images are just black, and there is no error being thrown (this for example also happens [very unlikely and rarely] when loading original images, so it is a very underlying problem.
• The callback would help us, with validating if the resized Tile is fine, as we then can check if the Tile is black or not, and we can properly react on that case

When doing resizes with Pica, we sometimes get an error when pica calls getImageData.

The error that Safari throws is:

InvalidStateError · The object is in an invalid state.

It's called on this line:

https://github.com/nodeca/pica/blob/6.1.1/index.js#L362

So it's the canvas we're passing into pica. In other words, this could very well be an issue outside pica, since the canvas in question wasn't created by pica.

In any case, I wanted to open this issue to see if others had the same problem, and to store some of my thoughts around this.

Possible causes

I've done some searching and found these two blog posts:

https://pqina.nl/blog/canvas-area-exceeds-the-maximum-limit/ https://pqina.nl/blog/total-canvas-memory-use-exceeds-the-maximum-limit/

According to them this could be caused by using using a too large canvas (max width/height is 4096 x 4096), however I know pica does tiling, so that shouldn't happen. Another possible cause mentioned in that blog post, is that Safari has trouble with releasing memory allocated to canvas after they're discarded.

They offer a suggestion to remedy this:

function releaseCanvas(canvas) {
    canvas.width = 1;
    canvas.height = 1;
    const ctx = canvas.getContext('2d');
    ctx && ctx.clearRect(0, 0, 1, 1);
}

Quoting from the blog post:

We’re going to have to help out Safari to clean up its mess. Get rid of the things it can’t or won’t throw away.

When we’re done with a element we have to manually “release” it.

Meaning we resize the canvas to a very small size and clear its contents, this tricks Safari in to replacing the canvas in its storage with our compressed version.

The [above] function will do just that.

Safari will still hold on to the for a while, but at least now it won’t blow the roof of its storage depot.

Possible fixes

Applying the releaseCanvas method above may help. I checked the source and pica already sort of does this:

https://github.com/nodeca/pica/blob/e4e661623a14160a824087c6a66059e3b6dba5a0/index.js#L526-L530

Apparently I'm the one who suggested it 2 years ago (https://github.com/nodeca/pica/issues/199). Memory is short 😅

But maybe also calling clearRect would help further.

Basically enhance the existing fix to do what releaseCanvas above does. The author of that blog post has built an image editor based on canvas, so hopefully knows this area pretty well.

Versions

Pica Version: 6.1.1 Safari Version: 15.3.1, 15.4.0, 15.4.1 (we've seen this issue across ~250 users during the past few months)

TODO

• [ ] We're going to try passing in something other than a canvas, and see if that helps.

Your library is great, but I have some problems

I don't know what I did wrong, and occasionally some pictures will be misplaced. I framed them with a red frame.

The probability of error is about 5%, and our testers and developers cannot reproduce it. But users can always have this situation. It should be related to the type of phone, but I don't have definite evidence. I want to know why.

The following code is my compression method. Accept a File type and return the compressed File.

const pica = require('pica')();

const maxSize = 2097152 // 2M
// const maxSize = 1000000
const isLarge = (size) => {
    return size > 2097152 * 3 // 6M
}
/*
* @params myFile: type is File
* */
export default (myFile) => {
    try {
        return new Promise((res, rej) => {
            let reader = new FileReader();
            reader.readAsDataURL(myFile);
            reader.onload = function (theFile) {
                let image = new Image();
                image.src = theFile.target.result;
                image.onload = function () {
                    const offScreenCanvas = document.createElement('canvas')
                    const big = this.width > 2000 || this.height > 2000
                    const veryBig = this.width > 4000 || this.height > 4000
                    offScreenCanvas.width = veryBig ? this.width * 0.3 : (big ? this.width * 0.5 : this.width)
                    offScreenCanvas.height = veryBig ? this.height * 0.3 : (big ? this.height * 0.5 : this.height)
                    pica.resize(image, offScreenCanvas, {
                        quality: 1,
                    }).then(result => pica.toBlob(result, 'image/jpeg', isLarge(myFile.size) ? 0.4 : 0.6))
                        .then(blob => {
                            let files = new window.File([blob], myFile.name, {type: 'image/jpeg'})
                            if (files.size > maxSize) {
                                rej('图片太大：' + files.size)
                            }
                            res(files) // return new File
                        });
                };
            };
        })
    } catch (e) {
        if (myFile.size > maxSize) {
            return false
        }
        return myFile
    }
}