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
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
(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
(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
(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