-
-
Notifications
You must be signed in to change notification settings - Fork 247
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Picture misplaced #217
Comments
Same issue here. try disable wasm and ww features for you Pica instance;like new Pica({features:['js']}) |
Let me know if problem is still actual. |
@puzrin why reducing tile size may be helpful? |
@chebum, in theory, that reduces memory consumption 4x (in all concurrent workers), if device has low limits and crashes or abnormal behaviour happens. But i have no conditions to investigate behaviour of all possible hardware. 1024*1024 => 4mb per tile + ~4mb for intermetiate buffer (in v9). With 4 workers => 32mb. Not too much. The similar effect may be reached with restriction of peak workers or disabling those at all. |
@puzrin Disabling web workers also solves accidental STATUS_ACCESS_VIOLATION in Edge 96.0.1054.53. I'm able to reproduce the problem in 100% cases using specific set of images. Chrome 96.0.4664.93 is working fine, but Chrome 96.0.4664.110 crashes. Disabling WebWorkers does NOT solve the crash in Chrome 96.0.4664.110. |
@chebum i guess, that's another bug, from wasm. Try do disable it. It that helps - try to review source, may be i missed some zero division or byte/word overflow. Anyway, please report that separate, with example how to reproduce. |
That's the hardest part. I was able to reproduce it in the bigger application, but wasn't yet able to reproduce the problem separately :( I found a fix for Chrome as well - I have to clone source canvas before passing it to pica.resize. This way it worked even with web workers. Cloning source canvas solved the problem both in Edge and Chrome. I tested with 7.0.0 as well. It behaves the same way as 9.0.0, so I doubt it's the latest change. Will report in a separate issue if I find more information about it. |
Thank you for info, that's important to know for me. In our app, uploader has 2 stage resizer - client-side & server-side. If client-side code fails, image is sent "as is". |
I can reproduce this on android using the Android System Webview Dev-Channel. This only happens when Webworkers are used. Removing Maybe it is not handled correctly that the response order of webworkers is effectivly random? |
It seems this issue was introduced due to some changes coming with Chromium 131. Since this version is being shipped at this very moment, I would expect the bug to appear more frequently. Some notes that might help tracking down the cause:
I attached an image (hopefully GitHub will not alter it) that I could use to reproduce the issue 100% of the time on desktop Chrome version 131. (Make sure to use WebWorker feature). If you require any further info / a small reproduction repository, I am happy to help. |
@Airdevelopments , thanks so much for the sample image - finding a way to reproduce a problem is often a major problem on its own. It failed straight away on a desktop Chrome 131 when I used it and the output image was having its blocks misplaced. I'll see what pica setting may help avoid it. PS. Tried and confirmed that the problem in desktop Chrome 131 disappears with new Pica({features:['js']}) Cheers |
I believe I was able do track down the source of the issue. As mentioned before, I suspected EXIF Orientation to play a major role here. When I took a closer look at how the images were mangled, I realized the symmetry around the two main axis: While debugging through the pica code in Chrome and Firefox at the same time I was able to find the difference in behavior. The culprit seems to be On Chrome 131 the region parameters of the function ( I created a simple repository to show the discrepancy. Open it in Chrome 131 and the latest Firefox version (I used 132) and you should see the difference (mirrored coordinate spaces). I am not sure which behavior the ECMAScript Spec defines, but it does feel like this might be a regression in chromium. This Chromium issue had some fairly recent activity which could have introduced the regression. Although I obviously can not be sure at this point. |
I also managed to solve it with |
Thank you for your work 🙏 I've faced the same issue here, but only with one specific image size of 4,2MB 4000x3000 made on samsung s24 ultra (as well for Galaxy S22 and Galaxy TAB S9+). Removing the web worker seems to fix the issue: |
@didotsonev I would be careful with the 'cib' feature (though it technically is the fastest scaling operation afaik), as it is the root cause for the issue on Chrome >= 131 when tiling is used (not adjusted coordinate space). In practice the preconditions to use 'cib' to scale the image directly are rarely fulfilled. That means even though you have the feature in your "features" array, it will likely not be used. I have not done any testing in regard to issues with EXIF-Orientation and direct usage of 'cib'-scaling on Chrome >= 131. It may work perfectly fine since no tiling operation is used and therefore the described issue itself should not occur. Lets hope this gets fixed soon by the Chromium Team. |
@Airdevelopments thank you for sharing details. If you have time, i'd suggest experiments with disabling offscreen canvas use in ww. https://github.com/nodeca/pica/blob/master/lib/utils.js#L102 Patch this to always reject the promise. The data will be extracted in the main thread and sent to ww as a typed array. This can increase main thread blocking a bit, but maybe it will help. It's difficult to say clearly which step orientation data is missing. |
I’m experiencing an issue where, even with non-rotated images, the problem is not consistently reproducible. However, when uploading an image with rotation and EXIF orientation metadata, the output appears scrambled and tiled. Disabling Web Workers resolves the issue. Does anyone know why this is happening? Would this issue occur even if we bypass Pica and use a plain HTML Canvas for resizing? Any insights would be appreciated! |
async function createImageBitmap_WITH_RESPECT(img, x, y, width, height) {
return new Promise((res, rej) => {
const offscreenCanvas = new OffscreenCanvas(width, height);
const contextOffscreen = offscreenCanvas.getContext('2d');
contextOffscreen.drawImage(img, x, y, width, height, 0, 0, width, height);
res(offscreenCanvas.transferToImageBitmap());
});
}
async function resize() {
const file = upload.files.item(0);
if (!file) {
return;
}
const base64ImageData = await getImageDataAsBase64(file);
const img = await createHTMLImage(base64ImageData);
const tileX = tileXInput.valueAsNumber;
const tileY = tileYInput.valueAsNumber;
const tileWidth = 3072 / 4;
const tileHeight = 4080 / 4;
// const bitmap = await createImageBitmap(img, tileWidth * tileX, tileHeight * tileY, tileWidth, tileHeight);
const bitmap = await createImageBitmap_WITH_RESPECT(img, tileWidth * tileX, tileHeight * tileY, tileWidth, tileHeight);
const context = outputCanvas.getContext('2d');
context.drawImage(bitmap, 0, 0, tileWidth, tileHeight);
} @Airdevelopments If we pass it through the veil of an OffscreenCanvas, which apparently respects orientation unlike createImageBitmap(), maybe we can make it work until its resolved lol |
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.
The text was updated successfully, but these errors were encountered: