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

.trim() removes 1 too many pixels #4084

Open
3 tasks done
Zirafnik opened this issue Apr 25, 2024 · 5 comments
Open
3 tasks done

.trim() removes 1 too many pixels #4084

Zirafnik opened this issue Apr 25, 2024 · 5 comments
Labels

Comments

@Zirafnik
Copy link

Possible bug: .trim() removes 1 pixel too many

When using .trim() Sharp.js will remove 1 too many pixels. I first noticed it in the metadata returned by .trim(): trimOffsetLeft and trimOffsetTop.

I also confirmed it is not just an error in the data returned, by testing it on a PNG.

Instead of only removing the border up-to (and excluding) the first pixel of color change, it also removes that first pixel of different color.

I noticed this difference, as I am porting from ImageMagick to Sharp.js. (ImageMagick willl remove the correct amount: only up-to the first changed pixel.)

Possible fix: Make .trim() remove all the border only up-to the new color.

Is this a possible bug in a feature of sharp, unrelated to installation?

  • Running npm install sharp completes without error.
  • Running node -e "require('sharp')" completes without error.

Are you using the latest version of sharp?

  • I am using the latest version of sharp as reported by npm view sharp dist-tags.latest.
@lovell lovell added question and removed triage labels Apr 25, 2024
@lovell
Copy link
Owner

lovell commented Apr 25, 2024

You've not provided an example image but the lineArt property may be more appropriate for your input images.

https://sharp.pixelplumbing.com/api-resize#trim

.trim({ lineArt: true })

@Zirafnik
Copy link
Author

My image was a PNG of some document with typed text.

What is the impact on performance of lineArt: true? Additionally, what happens if there are alternating types of PNGs (document with text VS. photograph)?

@lovell
Copy link
Owner

lovell commented Apr 25, 2024

What is the impact on performance of lineArt: true

I would expect minimal, it might be very slightly faster, you'll need to profile using samples of the type of image you're likely to have to process.

what happens if there are alternating types of PNGs

You'll need to determine which setting is most appropriate for the type of image you're likely to have to process.

@Zirafnik
Copy link
Author

Zirafnik commented Apr 26, 2024

Thank you for the answer, however, I am still confused about this setting. Could you explain a bit more what the lineArt: true setting does? Why should I use it and when?

Docs description:

Does the input more closely resemble line art (e.g. vector) rather than being photographic?

Maybe... What does this even really mean?

@lovell
Copy link
Owner

lovell commented Apr 26, 2024

If the input is best represented as in a vector format such as SVG or uses a lossless compression such as PNG then lineArt would be more suitable as there is unlikely to be "noise" around the edges between background and non-background areas.

If the input is more photographic and/or uses a lossy format such as JPEG then some smoothing of the noise is required to ensure trim() is more accurate around the edges.

The underlying libvips operation is vips_find_trim.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants