scaleflex / filerobot-image-editor

Edit, resize, and filter any image! Any questions or issues, please report to https://github.com/scaleflex/filerobot-image-editor/issues
MIT License
1.35k stars 342 forks source link

Initial scaling/quality #454

Open grahamTIA opened 6 months ago

grahamTIA commented 6 months ago

When the editor opens for the first time, the image is scaled down to fit the container which is fine, but when it zooms in/out the quality is atrocious. It seems that the quality of the preview image is entirely dependent on how big the container is.

Is there any way to have the preview image load in at 100% zoom, and just have it be cut off or something? This is unacceptable:

Original: image

In the editor image

I have tried the preview pixel ratio, with values from 2 to 20, and absolutely no change at all in percieved quality

<FilerobotImageEditor
      showBackButton
      source={attachment.src}
      defaultSavedImageName={attachment.name}
      onSave={(a, b) => { onSave(a, b, attachment); onClose(); }}
      annotationsCommon={
        {
          fill: '#ff0000',
        }
      }
      Text={{ text: 'PDI...' }}
      tabsIds={[TABS.ANNOTATE]}
      defaultTabId={TABS.ANNOTATE}
      defaultToolId={TOOLS.PEN}
      onClose={onClose}
      defaultSavedImageQuality={1}
      savingPixelRatio={20}
      previewPixelRatio={20}
    />
sean-mystyle commented 5 months ago

I have a similar issue, the "original image" preview looks great, the active image in the cropper UI is horribly low res. The original image is around 3000px. In editor it looks like a 100px image scaled up to 1000px, super pixelated. Also the image element I am using has base64 image data as it's href, not sure if that could be related...

Zhigalin commented 5 months ago

previewPixelRatio actually works with vanilla js approach (the default setting is appalling though), but the higher you set the slower everything becomes and even crashes the tab easily, at 20 its unworkable even with a pretty good PC and between 10 and 20 it's quite slow, if your app is supposed to be used with a normal computer I suggest not setting it above 5

grahamTIA commented 5 months ago

@Zhigalin Having it set to 20 did absolutely nothing. It was neither slow, nor crash-prone, nor any better in quality. No value I set had any effect

Zhigalin commented 5 months ago

@grahamTIA as I mentioned it works in vanilla js approach, while you're trying with react approach

grahamTIA commented 5 months ago

@Zhigalin uh ok and where is that stated in the documentation? How can I fix this absolutely unacceptable quality in the React version?

Zhigalin commented 5 months ago

@grahamTIA oh I only ended up here because I got the same horrible quality problem and was searching for a solution, I'm not a developer of this component.

Since there is no answer from a maintainer over a month I suggest you to create a simple plain js demo which is fairy fast to do and try to follow what previewPixelRatio does with a debugger and then do the same with your react app (or screw this and find an another editor)...

grahamTIA commented 5 months ago

@Zhigalin Ah I'm sorry, my mistake. Yes, good idea to just find a different editor, this one is not so good

AhmeeedMostafa commented 4 months ago

Hello @Zhigalin & @grahamTIA I have checked the issue from my side, and couldn't find quality loss as u mentioned if u could provide a demo and mention your OS & screen resolution, that would be helpful otherwise if u prefer to choose a different editor it's for sure back to you. we would even appreciate your contribution to the product if u have some issues and have time to fix them if u won't consider another product.

and just as a note please be aware the zooming ratio starts from the wrapping container fit, so if it started with 50%, it means this is the proper ratio for fitting inside the current container, so whatever after 100% will be the pixelation zone (for zooming in more than the image's original quality) increasing the previewPixelRatio would solve ur issue till reaching 100% after that it is expected to start pixelation depending on the image's quality

sergio-dd commented 3 months ago

I have the same problem in react js, the original image is 871x1343, when inserted into the filerobot with the container of size 398x613 the image loses its quality in a brutal way, it becomes totally ineligible, it seems that the final quality of the edition depends entirely on the height and container width, has anyone solved this problem?

sean-mystyle commented 3 months ago

I have the same problem in react js, the original image is 871x1343, when inserted into the filerobot with the container of size 398x613 the image loses its quality in a brutal way, it becomes totally ineligible, it seems that the final quality of the edition depends entirely on the height and container width, has anyone solved this problem?

I was finally able to fix this. It was loading as if it had a thumbnail when I was passing full print quality images in but I think it was passing the image data itself, I'm not sure now if it was partially due to a race condition (I added callbacks) or the format (base64 image data and I changed this around alot until it worked) but I know I rewrote what I was doing in that section better with those two things in mind and it worked without the quality degradation issue. For example if you're using base64 try changing to blob url instead, or vice versa, I think that's where I must have solved it but I can't recall now, but also make sure you're using async callbacks properly with image data and not passing it too soon before its loaded etc.

sergio-dd commented 3 months ago

I've been stuck with this problem for days, so if you could share how yours is configured <FilerobotImageEditor source={currentFileEdition.fileMessage.blobURL} ....

or remember any information that could help me, thank you very much in advance

sean-mystyle commented 3 months ago

I've been stuck with this problem for days, so if you could share how yours is configured <FilerobotImageEditor source={currentFileEdition.fileMessage.blobURL} ....

or remember any information that could help me, thank you very much in advance

Ok I checked the src and two things -

1) image elements on page with base64 image data is being used and it looks like I switched from trying to use base64 data directly to using an image element on page containing the data as its src attribute. If you're using blob try base64 this way as it's working OK for me.

and apparently,

2) Make sure nothing is going on with the image or the elements it's in while passing to the photo editor render function.

I have a note that jQuery is doing a .show('slow') transition on the image element or parent of the image element, and I added a timeout with a note that not waiting for jQuery to complete this causes a smaller low-res version of the image to show in the filerobot editor:

// show editor - wait for jquery show to finish or it will display as low res for some reason
    setTimeout(function(){
        photoEditor.render({ 
            source: imgSrcUrlOrEl,
            onClose: (closingReason) => {
                console.log('Closing reason', closingReason);
                onPhotoEditorClosed(); 
            },
        });
    }, 1000);
danielpilotfindiq commented 3 months ago

i have similar problems using vanilla JS in a svelte project. i've tried using a base64 htmlImageElement instead of passing the source directly from an url as @sean-mystyle suggested. no luck. only the initial Loading is pixelated, when i import a new image into the editor view, it looks good.

sean-mystyle commented 3 months ago

in my code example imgSrcUrlOrEl is pointing to an image element with base64 image data set to src. Like

imgSrcOrEl = jQuery('#sourceImage')[0];

It only loads pixelated for me if I call .render before the jquery "show" is complete. Adding a timeout for 1 sec worked, since jquery transition is less than a second.

That said, none of this code runs until after the image data preloader is complete, and the event for img.oncomplete has triggered this to move forward with passing to the preloaded filerobot editor. If you were to just create the image on one line and the try to load the editor on the next line, the image hasn't loaded fully yet, so you might get some pixelated version that way too possibly, maybe if it's a progressive jpg? Idk if you'd get anything at all doing it that way, but you def need to wait for the event that the js includes are all loaded, and same for the source image, before doing the render. Even if it's base64 it's still time spent loading the data in the background that you have to wait for asynchronously.

danielpilotfindiq commented 3 months ago

@sean-mystyle i see. doesn't fix my problem tho. is the bug maybe related to this? @AhmeeedMostafa https://github.com/scaleflex/filerobot-image-editor/blob/6bffb79af9391ee228fd3f50aced2c1e584ea1f8/packages/react-filerobot-image-editor/src/components/App/index.jsx#L131

AhmeeedMostafa commented 2 months ago

@danielpilotfindiq I couldn't produce the issue from my-side depending on the info mentioned in the issue, so I couldn't say whether it is related to this part or not. if some codesandbox provided that re-produces the issue then I'd be able to check.

haitranviet96 commented 2 months ago

@AhmeeedMostafa Here are CodeBox to reproduce the issue. https://codesandbox.io/p/devbox/codepen-with-react-forked-92l9k9?welcome=true

I think you may find the problem exists in react-filerobot-image-editor lib. Because, I encounter it in ReactJS environment.

sergio-dd https://github.com/scaleflex/filerobot-image-editor/issues/454#issuecomment-2161454043

And, I think @sergio-dd has a point, when I test, the blurriness depends on the size of the photo editor and the image.