Hi, We tried boost gil resize example to experiment with scaling down a jpeg image file. For some images, this causes the size of the file to increase. We are using bilinear_sampler algorithm. Our aim to reduce the input image size so as to save storage/network bandwidth. Quality can be compromised to a certain extent. Which algorithm/method should we use? The code fragment is given below:- boost::gil::rgb8_image_t img; boost::gil::read_and_convert_image(InStream, img, T()); float width = (float)(img.width() * Ratio) / 100; float height = (float)(img.height() * Ratio) / 100; boost::gil::rgb8_image_t resizedImg(width, height); boost::gil::resize_view(const_view(img), view(resizedImg), boost::gil::bilinear_sampler()); boost::gil::write_view(OutStream, boost::gil::const_view(resizedImg), T()); Thanks, Lloyd
On 23/07/2020 16:33, Lloyd wrote:
We tried boost gil resize example to experiment with scaling down a jpeg image file. For some images, this causes the size of the file to increase. We are using bilinear_sampler algorithm.
Our aim to reduce the input image size so as to save storage/network bandwidth. Quality can be compromised to a certain extent. Which algorithm/method should we use?
Re-saving a JPEG file is pretty much always guaranteed to reduce quality, no matter what settings you use.
The code fragment is given below:-
boost::gil::rgb8_image_t img; boost::gil::read_and_convert_image(InStream, img, T()); float width = (float)(img.width() * Ratio) / 100; float height = (float)(img.height() * Ratio) / 100; boost::gil::rgb8_image_t resizedImg(width, height); boost::gil::resize_view(const_view(img), view(resizedImg), boost::gil::bilinear_sampler()); boost::gil::write_view(OutStream, boost::gil::const_view(resizedImg), T());
Probably the important part is what your T() is. When calling write_view, you can specify a JPEG quality explicitly via something like image_write_info<jpeg_tag>(95) -- use a lower number for a smaller file size but more artifacting. If you don't specify it, GIL uses 100 by default (which might be excessive). Other editors probably use different values by default, which might be causing the file size increase you're seeing. But there isn't really one "right" answer, it depends on the specific content of the image; values that will be acceptable for one image will perform poorly on another. But depending on your usage you might be able to safely go to 80-85% or perhaps even less. The image quality isn't actually stored in the file (or when it is, it's not always reliable), so you can't directly read what quality the image was saved at -- although it is technically possible to read other data to estimate it. I don't think GIL makes this information available, however.
Thanks a lot for your help.
Probably the important part is what your T() is.
T is the format of the source file. In the case of jpeg, it is gil::jpeg_tag
When calling write_view, you can specify a JPEG quality explicitly via something like image_write_info<jpeg_tag>(95) -- use a lower number for a smaller file size but more artifacting.
If you don't specify it, GIL uses 100 by default (which might be excessive). Other editors probably use different values by default, which might be causing the file size increase you're seeing.
May i know what do you mean by "Other editors" ?
On 23/07/2020 23:42, Lloyd wrote:
Thanks a lot for your help.
Probably the important part is what your T() is.
T is the format of the source file. In the case of jpeg, it is gil::jpeg_tag
That means you're using 100% quality by default. To reduce the file size you'd have to change this, as I said.
When calling write_view, you can specify a JPEG quality explicitly via something like image_write_info<jpeg_tag>(95) -- use a lower number for a smaller file size but more artifacting.
If you don't specify it, GIL uses 100 by default (which might be excessive). Other editors probably use different values by default, which might be causing the file size increase you're seeing.
May i know what do you mean by "Other editors" ?
Whatever image editor that originally created or last edited the file.
On Fri, Jul 24, 2020 at 4:51 AM Gavin Lambert via Boost-users < boost-users@lists.boost.org> wrote:
On 23/07/2020 23:42, Lloyd wrote:
Thanks a lot for your help.
Probably the important part is what your T() is.
T is the format of the source file. In the case of jpeg, it is
gil::jpeg_tag
That means you're using 100% quality by default. To reduce the file size you'd have to change this, as I said.
When calling write_view, you can specify a JPEG quality explicitly
via
something like image_write_info<jpeg_tag>(95) -- use a lower number
for
a smaller file size but more artifacting.
If you don't specify it, GIL uses 100 by default (which might be excessive). Other editors probably use different values by default, which might be causing the file size increase you're seeing.
May i know what do you mean by "Other editors" ?
Whatever image editor that originally created or last edited the file.
Thank you very much
participants (2)
-
Gavin Lambert
-
Lloyd