Image.replace_color seems be to lowing the DPI
Closed this issue · 3 comments
I noticed when using Image.replace_color
the images DPI is much lower after writing it to the file system.
"original_file.jpg"
|> Image.from_binary!()
|> Image.replace_color!(replace_with: 255)
|> Image.write!("imaged.jpg", quality: 100)`
My original_file.jpg
image is 300 DPI and when I check the DPI of imaged.jpg
it's 72
That's totally unexpected for sure. Thanks for the report. It appears the underlying libvips operation Operation.ifthenelse/4
doesn't set the x-resolution or y-resolution. I've forced them to be set in commit 16aa588.
Would you consider checking this works correctly for you by configuring image
from GitHub
before I publish to hex?
I'm also a big curious about:
"original_file.jpg"
|> Image.from_binary!()
I would have expected:
"original_file.jpg"
|> Image.open!()
But perhaps this is just example proto-code?
That's totally unexpected for sure. Thanks for the report. It appears the underlying libvips operation
Operation.ifthenelse/4
doesn't set the x-resolution or y-resolution. I've forced them to be set in commit 16aa588.Would you consider checking this works correctly for you by configuring
image
fromGitHub
before I publish to hex?
Just tested it with the master branch on github, it works!
Thanks for the quick reply and fix!
I'm also a big curious about:
"original_file.jpg" |> Image.from_binary!()I would have expected:
"original_file.jpg" |> Image.open!()But perhaps this is just example proto-code?
Yeah I was loading the file via File.read!/1
prior, so just bad pseudo code example
Thanks again!
Yeah I was loading the file via File.read!/1 prior
I recommend Image.open/
primarily because libvips
streams image data on demand. Effectively it builds an operation pipeline until you call Image.write1/2
(or other functions that materialise the pipeline).
Therefore Image.open/2
doesn't read the whole image into memory (unlike File.read!) - it only streams image data as it needs it.
I'll publish the new version of image
now.