Skip to content
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

Initial scaling/quality #454

Open
grahamTIA opened this issue Mar 27, 2024 · 17 comments
Open

Initial scaling/quality #454

grahamTIA opened this issue Mar 27, 2024 · 17 comments
Labels
invalid This doesn't seem right TBD To Be Defined means that issue needs to be checked and re-labeled after checking

Comments

@grahamTIA
Copy link

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
Copy link

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
Copy link

Zhigalin commented May 3, 2024

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
Copy link
Author

@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
Copy link

Zhigalin commented May 3, 2024

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

@grahamTIA
Copy link
Author

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

@Zhigalin
Copy link

Zhigalin commented May 3, 2024

@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
Copy link
Author

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

@AhmeeedMostafa
Copy link
Collaborator

AhmeeedMostafa commented May 13, 2024

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

@AhmeeedMostafa AhmeeedMostafa added TBD To Be Defined means that issue needs to be checked and re-labeled after checking invalid This doesn't seem right labels May 13, 2024
@sergio-dd
Copy link

sergio-dd commented Jun 11, 2024

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
Copy link

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
Copy link

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
Copy link

sean-mystyle commented Jun 11, 2024

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,

  1. 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
Copy link

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
Copy link

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
Copy link

@sean-mystyle i see. doesn't fix my problem tho. is the bug maybe related to this? @AhmeeedMostafa

// This timeout is a workaround when re-initializing

@AhmeeedMostafa
Copy link
Collaborator

@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
Copy link

haitranviet96 commented Jul 31, 2024

@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 #454 (comment)

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
invalid This doesn't seem right TBD To Be Defined means that issue needs to be checked and re-labeled after checking
Projects
None yet
Development

No branches or pull requests

7 participants