libjpeg-turbo-users — libjpeg-turbo User Discussion (moved to Google Groups-- see http://www.libjpeg-turbo.org/About/MailingLists)

Re: [Libjpeg-turbo-users] libjpeg-turbo mailing lists have moved to Google Groups

[Roger P. <rog...@gm...>]

Maybe you should seed those groups with a message each? :)

On 9/11/17, DRC via Libjpeg-turbo-users
<lib...@li...> wrote:
> SourceForge removed the ability for project admins to view/manage the
> members of mailing lists, which was the final straw.  Thanks to all who
> gave their feedback, but given that my other OSS projects are using
> Google Groups and I was unable to find anything better, I decided to use
> Google Groups for this project as well.  You can join the new groups
> either using a Google account (which gives you full access to the group
> from the web interface) or a non-Google e-mail address (which gives you
> access to post from e-mail only.)  Links for joining all of the groups
> can be found here:
>
> http://www.libjpeg-turbo.org/About/MailingLists
>
> (Note that you have to be logged in with a Google account in order to
> join with that account.)
>
> To unsubscribe from the old lists, visit one or more of the following URLs:
> https://sourceforge.net/projects/libjpeg-turbo/lists/libjpeg-turbo-announce/unsubscribe
> https://sourceforge.net/projects/libjpeg-turbo/lists/libjpeg-turbo-users/unsubscribe
> https://sourceforge.net/projects/libjpeg-turbo/lists/libjpeg-turbo-devel/unsubscribe
>
> The direct addresses for e-mailing the new groups are:
> lib...@go...
> lib...@go...
>
> Other notes:
> -- If you join with a non-Google e-mail address, Google makes you go
> through a really annoying Turing test.  I apologize in advance for that.
> -- The old mailing lists will be retained on SourceForge for archival
> purposes.  Direct links to these archives are available at
> http://www.libjpeg-turbo.org/About/MailingLists.
> -- The new mailing lists have already been added to mail-archive.com.
> -- The new lists are public (anyone can join or view the messages), but
> the subscriber lists are visible only to me.
> -- As with the existing lists, only members can post (and only I can
> post to the announcement list.)
> -- The new lists are configured such that your Google profile will not
> be revealed if you post.  Only your chosen display name will be shown.
>
> Please e-mail me directly (http://www.libjpeg-turbo.org/About/Contact)
> or post a GitHub tracker issue
> (https://github.com/libjpeg-turbo/libjpeg-turbo/issues/new) should you
> have any questions, concerns, or problems subscribing to the new lists.
>
> The old lists will be closed to new messages shortly, so please transfer
> your subscriptions immediately.
>
> DRC
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Libjpeg-turbo-users mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libjpeg-turbo-users
>

[Libjpeg-turbo-users] libjpeg-turbo mailing lists have moved to Google Groups

[DRC <dco...@us...>]

SourceForge removed the ability for project admins to view/manage the
members of mailing lists, which was the final straw.  Thanks to all who
gave their feedback, but given that my other OSS projects are using
Google Groups and I was unable to find anything better, I decided to use
Google Groups for this project as well.  You can join the new groups
either using a Google account (which gives you full access to the group
from the web interface) or a non-Google e-mail address (which gives you
access to post from e-mail only.)  Links for joining all of the groups
can be found here:

http://www.libjpeg-turbo.org/About/MailingLists

(Note that you have to be logged in with a Google account in order to
join with that account.)

To unsubscribe from the old lists, visit one or more of the following URLs:
https://sourceforge.net/projects/libjpeg-turbo/lists/libjpeg-turbo-announce/unsubscribe
https://sourceforge.net/projects/libjpeg-turbo/lists/libjpeg-turbo-users/unsubscribe
https://sourceforge.net/projects/libjpeg-turbo/lists/libjpeg-turbo-devel/unsubscribe

The direct addresses for e-mailing the new groups are:
lib...@go...
lib...@go...

Other notes:
-- If you join with a non-Google e-mail address, Google makes you go
through a really annoying Turing test.  I apologize in advance for that.
-- The old mailing lists will be retained on SourceForge for archival
purposes.  Direct links to these archives are available at
http://www.libjpeg-turbo.org/About/MailingLists.
-- The new mailing lists have already been added to mail-archive.com.
-- The new lists are public (anyone can join or view the messages), but
the subscriber lists are visible only to me.
-- As with the existing lists, only members can post (and only I can
post to the announcement list.)
-- The new lists are configured such that your Google profile will not
be revealed if you post.  Only your chosen display name will be shown.

Please e-mail me directly (http://www.libjpeg-turbo.org/About/Contact)
or post a GitHub tracker issue
(https://github.com/libjpeg-turbo/libjpeg-turbo/issues/new) should you
have any questions, concerns, or problems subscribing to the new lists.

The old lists will be closed to new messages shortly, so please transfer
your subscriptions immediately.

DRC

[Libjpeg-turbo-users] Moving libjpeg-turbo mailing lists-- FEEDBACK REQUESTED

[DRC <dco...@us...>]

SourceForge removed the ability for project admins to view/manage the
members of mailing lists, which was the final straw (I had to jump
through hoops just to send this e-mail from my SourceForge e-mail
address, which for some reason was no longer subscribed or registered as
a list admin.)  I've already moved my other project mailing lists
(VirtualGL and TurboVNC) to Google Groups, but given that this project
has a much broader reach, I wanted to solicit feedback from the
community.  In particular, I realize that Google is banned in some
countries that are heavy users of libjpeg-turbo, so I welcome all
suggestions for how to migrate this aspect of our project to a platform
other than SourceForge.  Please comment here or on the following GitHub
issue:

https://github.com/libjpeg-turbo/libjpeg-turbo/issues/165

If I don't hear any feedback in a timely manner, I will proceed with
migrating to Google Groups.

DRC

[Libjpeg-turbo-users] Moving libjpeg-turbo mailing lists-- FEEDBACK REQUESTED

[DRC <dr...@vi...>]

SourceForge is being evil again.  They removed the ability for project
admins to view/manage the members of mailing lists, which was the final
straw (I can't even send mail to my own mailing lists using my
SourceForge e-mail address anymore.)  I've already moved my other
project mailing lists (VirtualGL and TurboVNC) to Google Groups, but
given that this project has a much broader reach, I wanted to solicit
feedback from the community.  In particular, I realize that Google is
banned in some countries that are heavy users of libjpeg-turbo, so I
welcome all suggestions for how to migrate this aspect of our project to
a platform other than SourceForge.  Please comment here or on the
following GitHub issue:

https://github.com/libjpeg-turbo/libjpeg-turbo/issues/165

DRC

[Libjpeg-turbo-users] libjpeg-turbo 1.5.2 has been released

[DRC <dco...@us...>]

Official binaries are here:

https://sourceforge.net/projects/libjpeg-turbo/files/1.5.2

Change log is here:

https://github.com/libjpeg-turbo/libjpeg-turbo/releases/tag/1.5.2

Re: [Libjpeg-turbo-users] Encoding of image region without writing any headers - non-JFIF, multithreading

[DRC <dco...@us...>]

I thought I had responded to this, but I can't find my reply, so maybe
it slipped my mind.  No, there is no way to do this using the exposed
libjpeg API.  You might be able to accomplish it by including jpegint.h
and calling the low-level functions in the library directly, but those
interfaces are internal and are thus subject to change without notice.
Refer to the TurboJPEG wrapper for examples of how to call these
lower-level functions directly.  We do that in order to provide
convenience functions for YCbCr conversion.

On 5/13/17 5:58 PM, Jakub Stankowski wrote:
> Hello,
> 
> Initially, I would like to thank for development of this library, I do
> appreciate the compression speed.
> 
> Currently I'm using the "raw_data_in" mode and "jpeg_write_raw_data"
> function to encode YCbCr image. It works great when creating JFIF
> conformant output, but my current requirements is to produce raw
> "scan" content. Therefore, I have few questions about libjpeg-turbo
> API:
> 
> 1. Is there any possibility to disable the writing of any markers and
> header segments? I managed to disable DQT and DHT tables, but my goal
> is to get Huffman encoded "scan" data only. Simply speaking I want
> libjpeg to perform transformation, DC prediction, entropy encoding and
> flush encoded MCUs into some buffer. The reason is to create RFC2435
> conformant RTP payload, witch forces the transmission of some
> parameters in different way than JFIF. Obviously, I can strip unwanted
> markers and segments but it's a significant waste of time.
> 
> 2. Same as 1. but encoding only a part of picture. I would like to
> divide the the work into multiple threads and at the end combine the
> content of output buffers (obviously with inclusion of restart
> markers). Currently, I'd have to provide fake image dimensions to the
> encoder (i.e. a quarter of height in case of using four threads) to
> by-pass the verification if entire picture have been encoded.
> Moreover, I'd have to perform above mentioned stripping of unwanted
> markers/segments.
> 
> Unfortunately, I didn't found such a features in API exposed in
> "jpeglib.h" but maybe I missed something.
> 

[Libjpeg-turbo-users] Encoding of image region without writing any headers - non-JFIF, multithreading

[Jakub S. <jst...@mu...>]

Hello,

Initially, I would like to thank for development of this library, I do
appreciate the compression speed.

Currently I'm using the "raw_data_in" mode and "jpeg_write_raw_data"
function to encode YCbCr image. It works great when creating JFIF
conformant output, but my current requirements is to produce raw
"scan" content. Therefore, I have few questions about libjpeg-turbo
API:

1. Is there any possibility to disable the writing of any markers and
header segments? I managed to disable DQT and DHT tables, but my goal
is to get Huffman encoded "scan" data only. Simply speaking I want
libjpeg to perform transformation, DC prediction, entropy encoding and
flush encoded MCUs into some buffer. The reason is to create RFC2435
conformant RTP payload, witch forces the transmission of some
parameters in different way than JFIF. Obviously, I can strip unwanted
markers and segments but it's a significant waste of time.

2. Same as 1. but encoding only a part of picture. I would like to
divide the the work into multiple threads and at the end combine the
content of output buffers (obviously with inclusion of restart
markers). Currently, I'd have to provide fake image dimensions to the
encoder (i.e. a quarter of height in case of using four threads) to
by-pass the verification if entire picture have been encoded.
Moreover, I'd have to perform above mentioned stripping of unwanted
markers/segments.

Unfortunately, I didn't found such a features in API exposed in
"jpeglib.h" but maybe I missed something.

-- 
Best regards
Jakub Stankowski

Re: [Libjpeg-turbo-users] Question about build static libjpeg-turbo 1.5.1 from source

[Min Su <mi...@ve...>]

It works, thanks!

On Mon, Jan 23, 2017 at 5:51 PM, DRC <dco...@us...>
wrote:

> The default installation path for libjpeg-turbo is /opt/libjpeg-turbo.
> If you want to install it in /usr/local, then pass --prefix=/usr/local
> to configure.  Or you can modify PKG_CONFIG_PATH to include
> /opt/libjpeg-turbo/lib64
>
> On 1/23/17 6:49 PM, Min Su wrote:
> > My environment is centos 7
> >
> > On Mon, Jan 23, 2017 at 4:45 PM, Min Su <mi...@ve...
> > <mailto:mi...@ve...>> wrote:
> >
> >     Hi,
> >
> >     I'm trying to build static poppler 0.50.0 from source
> >     and libjpeg-turbo is one of its dependencies. And I'm using
> >     pkgconfig to manage dependencies.
> >
> >     What I did:
> >     1. use "export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig/" to define
> >     pkgcinfig library path
> >     2. tar -xvzf libjpeg-turbo-1.5.1.tar.gz
> >     3. cd libjpeg-turbo-1.5.1/
> >     3. ./configure --enable-static
> >     4. make
> >     5. make install
> >     After these steps, I can't find a .pc file
> >     in /usr/local/lib/pkgconfig/ relate to libjpeg, I
> >     checked ./configure --help and there's only  a parameter PKG_CONFIG
> >     to set pkgconfig utility location. there's no PKG_CONFIG_PATH or
> >     with-pkgconfigdir(used by libpng).
> >
> >     So I see these when configure poppler:
> >     "checking for libjpeg6b... no
> >     checking for libjpeg... no
> >     checking jpeglib.h usability... no
> >     checking jpeglib.h presence... no
> >     checking for jpeglib.h... no
> >     configure: WARNING: libjpeg not found. disable JPEG support."
> >
> >     Is pkgconfig not supported by libjpeg-turbo? If so, how can I build
> >     it with poppler?
> >
> >     Thanks,
> >
> >     Min
> >
> >
> >
> >
> > ------------------------------------------------------------
> ------------------
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> >
> >
> >
> > _______________________________________________
> > Libjpeg-turbo-users mailing list
> > Lib...@li...
> > https://lists.sourceforge.net/lists/listinfo/libjpeg-turbo-users
> >
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Libjpeg-turbo-users mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libjpeg-turbo-users
>

Re: [Libjpeg-turbo-users] Question about build static libjpeg-turbo 1.5.1 from source

[DRC <dco...@us...>]

The default installation path for libjpeg-turbo is /opt/libjpeg-turbo.
If you want to install it in /usr/local, then pass --prefix=/usr/local
to configure.  Or you can modify PKG_CONFIG_PATH to include
/opt/libjpeg-turbo/lib64

On 1/23/17 6:49 PM, Min Su wrote:
> My environment is centos 7
> 
> On Mon, Jan 23, 2017 at 4:45 PM, Min Su <mi...@ve...
> <mailto:mi...@ve...>> wrote:
> 
>     Hi,
> 
>     I'm trying to build static poppler 0.50.0 from source
>     and libjpeg-turbo is one of its dependencies. And I'm using
>     pkgconfig to manage dependencies.
> 
>     What I did:
>     1. use "export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig/" to define
>     pkgcinfig library path
>     2. tar -xvzf libjpeg-turbo-1.5.1.tar.gz
>     3. cd libjpeg-turbo-1.5.1/
>     3. ./configure --enable-static
>     4. make
>     5. make install
>     After these steps, I can't find a .pc file
>     in /usr/local/lib/pkgconfig/ relate to libjpeg, I
>     checked ./configure --help and there's only  a parameter PKG_CONFIG
>     to set pkgconfig utility location. there's no PKG_CONFIG_PATH or
>     with-pkgconfigdir(used by libpng).
> 
>     So I see these when configure poppler:
>     "checking for libjpeg6b... no
>     checking for libjpeg... no
>     checking jpeglib.h usability... no
>     checking jpeglib.h presence... no
>     checking for jpeglib.h... no
>     configure: WARNING: libjpeg not found. disable JPEG support."
> 
>     Is pkgconfig not supported by libjpeg-turbo? If so, how can I build
>     it with poppler? 
> 
>     Thanks,
> 
>     Min
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> 
> 
> 
> _______________________________________________
> Libjpeg-turbo-users mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libjpeg-turbo-users
> 

[Libjpeg-turbo-users] Question about build static libjpeg-turbo 1.5.1 from source

[Min Su <mi...@ve...>]

Hi,

I'm trying to build static poppler 0.50.0 from source and libjpeg-turbo is
one of its dependencies. And I'm using pkgconfig to manage dependencies.

What I did:
1. use "export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig/" to define
pkgcinfig library path
2. tar -xvzf libjpeg-turbo-1.5.1.tar.gz
3. cd libjpeg-turbo-1.5.1/
3. ./configure --enable-static
4. make
5. make install
After these steps, I can't find a .pc file in /usr/local/lib/pkgconfig/
relate to libjpeg, I checked ./configure --help and there's only  a
parameter PKG_CONFIG to set pkgconfig utility location. there's no
PKG_CONFIG_PATH
or with-pkgconfigdir(used by libpng).

So I see these when configure poppler:
"checking for libjpeg6b... no
checking for libjpeg... no
checking jpeglib.h usability... no
checking jpeglib.h presence... no
checking for jpeglib.h... no
configure: WARNING: libjpeg not found. disable JPEG support."

Is pkgconfig not supported by libjpeg-turbo? If so, how can I build it with
poppler?

Thanks,

Min

Re: [Libjpeg-turbo-users] Question about build static libjpeg-turbo 1.5.1 from source

[Min Su <mi...@ve...>]

My environment is centos 7

On Mon, Jan 23, 2017 at 4:45 PM, Min Su <mi...@ve...> wrote:

> Hi,
>
> I'm trying to build static poppler 0.50.0 from source and libjpeg-turbo is
> one of its dependencies. And I'm using pkgconfig to manage dependencies.
>
> What I did:
> 1. use "export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig/" to define
> pkgcinfig library path
> 2. tar -xvzf libjpeg-turbo-1.5.1.tar.gz
> 3. cd libjpeg-turbo-1.5.1/
> 3. ./configure --enable-static
> 4. make
> 5. make install
> After these steps, I can't find a .pc file in /usr/local/lib/pkgconfig/
> relate to libjpeg, I checked ./configure --help and there's only  a
> parameter PKG_CONFIG to set pkgconfig utility location. there's no PKG_CONFIG_PATH
> or with-pkgconfigdir(used by libpng).
>
> So I see these when configure poppler:
> "checking for libjpeg6b... no
> checking for libjpeg... no
> checking jpeglib.h usability... no
> checking jpeglib.h presence... no
> checking for jpeglib.h... no
> configure: WARNING: libjpeg not found. disable JPEG support."
>
> Is pkgconfig not supported by libjpeg-turbo? If so, how can I build it
> with poppler?
>
> Thanks,
>
> Min
>

[Libjpeg-turbo-users] CMake build system

[DRC <dco...@us...>]

For those who haven't been following the discussion at

https://github.com/libjpeg-turbo/libjpeg-turbo/issues/56

the dev branch now contains a 100% CMake-based build system.  The
decision to eliminate autotools in libjpeg-turbo 1.6 was not one I took
lightly, but CMake's built-in support for assembly and Java code, as
well as other features that are generally more friendly to the needs of
our build and packaging system, solved a lot of problems for us and
eliminated a lot of hacks.  In addition, this eliminates the need to
maintain two separate build, packaging, and testing systems going
forward, which will reduce costs for new feature implementations.  I
spent something like 60 unpaid hours implementing this, but it will
probably save me much more time than that in the long run.

This will not land in libjpeg-turbo 1.6 beta for at least several
months, which should hopefully give downstream integrators enough time
to test it and make the necessary modifications to their distribution
builds.  Please take a moment to test the new build system on your
favorite platform and let me know what breaks.  The most common
cross-compilation builds (including iOS, Android, and MinGW) are
documented in BUILDING.md.

If your project or organization will benefit from this work, then please
consider making a donation using the "Donate" button at
http://www.libjpeg-turbo.org/.  I have spent hundreds of unpaid hours in
the past couple of months implementing this new build system and the
continuous integration system.  Since I don't draw a salary for my work
on open source code, donations and funded development opportunities are
the only way I can get paid for my work, and those sources of funding
are the only thing keeping libjpeg-turbo afloat as a project.

DRC

Re: [Libjpeg-turbo-users] Changing the name of the built library from libjpeg on Linux

[DRC <dco...@us...>]

Why not just install it under /opt/libjpeg-turbo?  That is the default
install prefix precisely for this reason.  You can then manipulate
LD_LIBRARY_PATH to use libjpeg-turbo in /opt/libjpeg-turbo rather than
libjpeg in /usr.

If you really need to change the name, then change all instances of
"libjpeg.la" and "libjpeg_la" in Makefile.am, but this is far from a
supported configuration.  One of the reasons why libjpeg-turbo uses the
same library name as libjpeg is so it can be substituted at run time,
which is why the default is to install it under /opt.



On 11/23/16 4:52 AM, Bob wrote:
> I'm interested in changing the name of the libjpeg.so library that gets
> built so that it doesn't clash with other libraries called libjpeg that
> are on my system. I'm afraid I don't know enough about the build process
> to do this myself but if there was a way to have the library come out
> being called libcustomjpeg.so for example that would be useful. Am
> interested in doing this on Linux and I'm assuming that simply renaming
> the libjpeg.so file is not sufficient.
> 
> 
> Thanks in advance!

[Libjpeg-turbo-users] Changing the name of the built library from libjpeg on Linux

[Bob <bob...@ho...>]

I'm interested in changing the name of the libjpeg.so library that gets built so that it doesn't clash with other libraries called libjpeg that are on my system. I'm afraid I don't know enough about the build process to do this myself but if there was a way to have the library come out being called libcustomjpeg.so for example that would be useful. Am interested in doing this on Linux and I'm assuming that simply renaming the libjpeg.so file is not sufficient.


Thanks in advance!

[Libjpeg-turbo-users] Continuous integration is now online

[DRC <dco...@us...>]

We are now spinning continuous official builds from both the master
(stable) and dev (evolving) branches, using Travis and AppVeyor:

http://www.libjpeg-turbo.org/DeveloperInfo/PreReleases

The official Linux builds are spun using a docker image
(dcommander/buildljt:latest) that closely resembles my local build
environment (recipe: https://github.com/libjpeg-turbo/docker.)  The
official OS X and Windows builds use a Travis and AppVeyor config that
is also designed to mimic my local build environment.  These pre-release
builds should resemble, as closely as possible, the official release
builds, except that the pre-release builds will not be signed using my
code certificate or GPG key.  The reason behind this is both practical
and philosophical.  Practically, there is no easy way (of which I'm
aware) to sign the builds through a CI system without risking exposure
of the private keys.  Philosophically, a signed build means that I am
personally standing behind the integrity of the binaries, and I can only
do that if I built them on my local machines.  Thus, official releases
will continue to be spun locally.  This ensures that there is no "man in
the middle", i.e. the official releases will never exist on the network
in unsigned form.  However, with the exception of signing, the build
procedure used to generate both pre-release and release binaries is
identical and reproducible (see
http://www.libjpeg-turbo.org/DeveloperInfo/BuildInstructions).

Travis is also being used to continuously run ASAN and to validate
building the source with 12-bit and jpeg-8 support.  Future enhancements
will likely include regression testing the ARM, MIPS, and PPC code as well.

Special thanks to Matthieu, who created the proof of concept for
integrating libjpeg-turbo with Travis and AppVeyor.  My work is based
heavily on his.

Any contributions or suggestions are welcome.  I'm new to the CI game,
so I'm learning as I go along.  In particular, I am open to adding any
other useful regression tests that you can think of.  It would also be
nice at some point to figure out a better means of deploying the
pre-release Linux/OS X binaries than uploading them to our SourceForge
web page.  AppVeyor has a convenient mechanism for publishing
"artifacts" with each build, and I am taking advantage of that in order
to provide the Windows pre-release binaries through their site.
Unfortunately, however, doing the same with Travis would require a paid
AWS subscription.

[Libjpeg-turbo-users] libjpeg-turbo 1.5.1 has been released

[DRC <dco...@us...>]

Official binaries are here:

https://sourceforge.net/projects/libjpeg-turbo/files/1.5.1

Change log is here:

https://github.com/libjpeg-turbo/libjpeg-turbo/releases/tag/1.5.1

[Libjpeg-turbo-users] libjpeg-turbo 1.5.0 has been released

[DRC <dco...@us...>]

Official binaries are here:

https://sourceforge.net/projects/libjpeg-turbo/files/1.5.0

Change log is here:

https://github.com/libjpeg-turbo/libjpeg-turbo/releases/tag/1.5.0

[Libjpeg-turbo-users] libjpeg-turbo is SourceForge's Project of the Month-- thanks to all who voted!

[DRC <dco...@us...>]

You can read the interview here:
https://sourceforge.net/blog/may-2016-community-choice-project-of-the-month-libjpeg-turbo/

DRC

[Libjpeg-turbo-users] Vote for libjpeg-turbo for the May, 2016 SourceForge Project of the Month

[DRC <dco...@us...>]

Hi, all.  If you have a SourceForge account, then please take a moment
to add a comment to this thread that says "VOTE: libjpeg-turbo".

https://sourceforge.net/p/potm/discussion/vote/thread/ba2aebd4/

This will add a vote for libjpeg-turbo for SourceForge Project of the
Month (NOTE: you can only vote once.)  The winning project will get an
exclusive interview and be featured on the SourceForge home page, which
could potentially attract new sponsors for our project.

As you know, the harsh reality of open source software is that, despite
the software being provided for free, almost all prominent, high-quality
open source development is done by paid developers (you get what you pay
for, essentially.)  In most cases, the developers are employees of a
corporation or other organization that is paying them to develop the
open source code in the context of that organization's broader agenda.
libjpeg-turbo is one of the few prominent open source projects that
works purely on a patronage model, which means that we can maintain the
product in a vendor-agnostic manner, free of any one organization's
agenda.  However, that also means that exposure for our project is
critical to its long-term success.

Thank you for your continued support,
DRC

Re: [Libjpeg-turbo-users] tjCompressFromYUV

[Alessio A. <ale...@gm...>]

Thank you for your quick reply.

I'm sorry my request wasn't more precise, however your first suggestion
turned out to be useful: with a smaller test program the tjCompressFromYUV
call performs as expected.
I will look into what was wrong with the first version.

Thanks for your time,

Best regards
Alessio

On Wed, Mar 23, 2016 at 3:18 PM, DRC <dco...@us...>
wrote:

> NOTE:  It's difficult to reproduce a specific problem such as this when
> you don't provide a fully working standalone test program and a test
> image that demonstrates the problem, nor do you indicate which O/S you
> are running this on, nor do you indicate which version of libjpeg-turbo
> you are using.  I was able to hack together a test program based on your
> code, and I was able to hack together a YUV420P test image with the
> exact dimensions that your image seems to have (352x288), but it works
> fine for me.  That means that one of the following are true:
>
> (1) Your test program is part of a larger program, and something outside
> of the context of the code you posted is causing the problem.  Again,
> this is why you should always provide a standalone test program that
> demonstrates the failure, not a code snippet.  This also makes me a lot
> happier, because I don't have to spend 20 or 30 minutes of my time
> creating such a program based on your code.  And in the process of
> creating that test program, you may discover that the standalone program
> works.  That will help you determine why the same code doesn't work in
> the larger program.
>
> (2) Something about your specific test image is causing the failure (but
> I can't imagine what that would be.  Bytes are bytes.)
>
> (3) Something about your build environment is messed up (but I can't
> imagine what that would be.)
>
> (4) You are somehow stomping on memory.  I suggest running your program
> through valgrind to make sure.  When compressing from YUV (as opposed to
> compressing from an RGB image), the colorspace converter is never
> invoked, so the only place where "Bogus input colorspace"
> (JERR_BAD_IN_COLORSPACE) could be encountered is in
> jpeg_default_colorspace() (jcparam.c), which is called from
> setCompDefaults() (turbojpeg.c), which is called from
> tjCompressFromYUV() (turbojpeg.c).  As you can see in the TurboJPEG
> code, setCompDefaults() will set cinfo->in_color_space to JCS_EXT_RGB if
> the pixel format parameter is TJPF_RGB, which it always is when the call
> is made from the body of tjCompressFromYUV().  So I cannot fathom why
> the JERR_BAD_IN_COLORSPACE error is being tripped unless somehow the
> jpeg_compress_struct is being corrupted.
>
>
> On 3/23/16 6:26 AM, Alessio Agneessens wrote:
> > Hello,
> >
> > may I ask a question about the tjCompressFromYUV() function?
> >
> > I'd like to compress a planar 4:2:0 YUV buffer to a jpeg image, but
> > tjCompressFromYUV() fails, and the error string returned by
> > tjGetErrorStr() is "Bogus input colorspace".
> >
> > What am I doing wrong?
> >
> > Below is my code if it can help.
> >
> > Thanks in advance,
> > Alessio
> >
> > |#define PADDING     2
> > tjhandle tjh;
> > unsigned long buf_size;
> > unsigned char *jpegBuf = NULL;
> > unsigned long jpegSize;
> > int width = 352;
> > int height = 288;
> > int quality = 70;
> > unsigned char *ucp_frame;
> > int j;
> > FILE *fp = NULL;
> >
> > ucp_frame = malloc(width * height * 3 / 2);
> > if ( NULL == ucp_frame ) {
> >     printf("malloc error ucp_frame\n");
> >     return 0;
> > }
> >
> > fp = fopen("planar_352x288.raw", "rb");
> > if( NULL == fp ) {
> >     printf("fopen error\n");
> >     return 0;
> > }
> >
> > j = fread( ucp_frame, 1, width * height * 3 / 2, fp);
> > if( j != width * height * 3 / 2 ) {
> >     printf("fread error\n");
> >     return 0;
> > }
> > fclose(fp);
> >
> > tjh = tjInitCompress();
> > if( NULL == tjh ) {
> >     printf("tjInitCompress error '%s'\n",  tjGetErrorStr() );
> >     return 0;
> > }
> >
> > buf_size = tjBufSizeYUV2( width, PADDING, height, TJSAMP_420);
> > jpegBuf = tjAlloc(buf_size);
> >
> > if( tjCompressFromYUV( tjh, ucp_frame, width, PADDING, height,
> >                        TJSAMP_420, &jpegBuf, &jpegSize, quality,
> >                        TJFLAG_NOREALLOC ) ) {
> >     printf("tjCompressFromYUV error '%s'\n",  tjGetErrorStr() );
> > }|
>
>
>
> ------------------------------------------------------------------------------
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140
> _______________________________________________
> Libjpeg-turbo-users mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libjpeg-turbo-users
>

Re: [Libjpeg-turbo-users] tjCompressFromYUV

[DRC <dco...@us...>]

NOTE:  It's difficult to reproduce a specific problem such as this when
you don't provide a fully working standalone test program and a test
image that demonstrates the problem, nor do you indicate which O/S you
are running this on, nor do you indicate which version of libjpeg-turbo
you are using.  I was able to hack together a test program based on your
code, and I was able to hack together a YUV420P test image with the
exact dimensions that your image seems to have (352x288), but it works
fine for me.  That means that one of the following are true:

(1) Your test program is part of a larger program, and something outside
of the context of the code you posted is causing the problem.  Again,
this is why you should always provide a standalone test program that
demonstrates the failure, not a code snippet.  This also makes me a lot
happier, because I don't have to spend 20 or 30 minutes of my time
creating such a program based on your code.  And in the process of
creating that test program, you may discover that the standalone program
works.  That will help you determine why the same code doesn't work in
the larger program.

(2) Something about your specific test image is causing the failure (but
I can't imagine what that would be.  Bytes are bytes.)

(3) Something about your build environment is messed up (but I can't
imagine what that would be.)

(4) You are somehow stomping on memory.  I suggest running your program
through valgrind to make sure.  When compressing from YUV (as opposed to
compressing from an RGB image), the colorspace converter is never
invoked, so the only place where "Bogus input colorspace"
(JERR_BAD_IN_COLORSPACE) could be encountered is in
jpeg_default_colorspace() (jcparam.c), which is called from
setCompDefaults() (turbojpeg.c), which is called from
tjCompressFromYUV() (turbojpeg.c).  As you can see in the TurboJPEG
code, setCompDefaults() will set cinfo->in_color_space to JCS_EXT_RGB if
the pixel format parameter is TJPF_RGB, which it always is when the call
is made from the body of tjCompressFromYUV().  So I cannot fathom why
the JERR_BAD_IN_COLORSPACE error is being tripped unless somehow the
jpeg_compress_struct is being corrupted.


On 3/23/16 6:26 AM, Alessio Agneessens wrote:
> Hello,
> 
> may I ask a question about the tjCompressFromYUV() function?
> 
> I'd like to compress a planar 4:2:0 YUV buffer to a jpeg image, but
> tjCompressFromYUV() fails, and the error string returned by
> tjGetErrorStr() is "Bogus input colorspace".
> 
> What am I doing wrong?
> 
> Below is my code if it can help.
> 
> Thanks in advance,
> Alessio
> 
> |#define PADDING     2
> tjhandle tjh;
> unsigned long buf_size;
> unsigned char *jpegBuf = NULL;
> unsigned long jpegSize;
> int width = 352;
> int height = 288;
> int quality = 70;
> unsigned char *ucp_frame;
> int j;
> FILE *fp = NULL;
> 
> ucp_frame = malloc(width * height * 3 / 2);
> if ( NULL == ucp_frame ) {
>     printf("malloc error ucp_frame\n");
>     return 0;
> }
> 
> fp = fopen("planar_352x288.raw", "rb");
> if( NULL == fp ) {
>     printf("fopen error\n");
>     return 0;
> }
> 
> j = fread( ucp_frame, 1, width * height * 3 / 2, fp);
> if( j != width * height * 3 / 2 ) {
>     printf("fread error\n");
>     return 0;
> }
> fclose(fp);
> 
> tjh = tjInitCompress();
> if( NULL == tjh ) {
>     printf("tjInitCompress error '%s'\n",  tjGetErrorStr() );
>     return 0;
> }
> 
> buf_size = tjBufSizeYUV2( width, PADDING, height, TJSAMP_420);
> jpegBuf = tjAlloc(buf_size);
> 
> if( tjCompressFromYUV( tjh, ucp_frame, width, PADDING, height,
>                        TJSAMP_420, &jpegBuf, &jpegSize, quality,
>                        TJFLAG_NOREALLOC ) ) {
>     printf("tjCompressFromYUV error '%s'\n",  tjGetErrorStr() );
> }|

[Libjpeg-turbo-users] tjCompressFromYUV

[Alessio A. <ale...@gm...>]

Hello,

may I ask a question about the tjCompressFromYUV() function?

I'd like to compress a planar 4:2:0 YUV buffer to a jpeg image, but
tjCompressFromYUV() fails, and the error string returned by tjGetErrorStr()
is "Bogus input colorspace".

What am I doing wrong?

Below is my code if it can help.

Thanks in advance,
Alessio

#define PADDING     2
tjhandle tjh;unsigned long buf_size;unsigned char *jpegBuf =
NULL;unsigned long jpegSize;int width = 352;int height = 288;int
quality = 70;unsigned char *ucp_frame;int j;FILE *fp = NULL;

ucp_frame = malloc(width * height * 3 / 2);if ( NULL == ucp_frame ) {
    printf("malloc error ucp_frame\n");
    return 0;}

fp = fopen("planar_352x288.raw", "rb");if( NULL == fp ) {
    printf("fopen error\n");
    return 0;}

j = fread( ucp_frame, 1, width * height * 3 / 2, fp);if( j != width *
height * 3 / 2 ) {
    printf("fread error\n");
    return 0;}
fclose(fp);

tjh = tjInitCompress();if( NULL == tjh ) {
    printf("tjInitCompress error '%s'\n",  tjGetErrorStr() );
    return 0;}

buf_size = tjBufSizeYUV2( width, PADDING, height, TJSAMP_420);
jpegBuf = tjAlloc(buf_size);
if( tjCompressFromYUV( tjh, ucp_frame, width, PADDING, height,
                       TJSAMP_420, &jpegBuf, &jpegSize, quality,
                       TJFLAG_NOREALLOC ) ) {
    printf("tjCompressFromYUV error '%s'\n",  tjGetErrorStr() );}

Re: [Libjpeg-turbo-users] TJCompress what is the best compression setting for JPEG

[DRC <dco...@us...>]

Quality and subsampling are the only parameters that can affect the size
of the JPEG image without adversely affecting performance.  Using
progressive Huffman entropy encoding or arithmetic entropy encoding (as
opposed to baseline Huffman entropy encoding, which is the default and
the only fully accelerated path in libjpeg-turbo) can further reduce the
size of the JPEG image, but the performance vs. size tradeoff is not
very good.  It varies based on the specific image you're compressing,
but in general, enabling progressive encoding will reduce performance by
about 8-10x while increasing the compression ratio by only about 10%.
Enabling arithmetic coding will reduce performance by about 2x while
increasing the compression ratio by about 20%.  That's a much better
tradeoff, but it's still a lot slower than baseline encoding, and the
images generated using arithmetic coding aren't as universal (for
instance, most popular web browsers and many image viewers don't support
arithmetic-coded JPEGs, although there is no technical reason why they
shouldn't-- arithmetic-coded JPEGs are part of the official standard.)

Arithmetic and progressive encoding aren't exposed in the TurboJPEG API,
but you can enable them by setting either the TJ_PROGRESSIVE or
TJ_ARITHMETIC environment variables to 1.

But if your goal is to encode the images with maximum performance, then
your only options are to adjust quality and subsampling.


On 3/21/16 11:59 PM, Ivan Ooi wrote:
> Hi all,
> 
>  Other than this 2 settings :                   
> 
> setJPEGQuality(70);
> etSubsamp(TJ.SAMP_420);
> 
> Any others which I can further reduce the JPEG size but keeping the
> existing dimension ?
> 
> Thanks

[Libjpeg-turbo-users] TJCompress what is the best compression setting for JPEG

[Ivan O. <oli...@gm...>]

Hi all,

 Other than this 2 settings :

setJPEGQuality(70);
etSubsamp(TJ.SAMP_420);

Any others which I can further reduce the JPEG size but keeping the
existing dimension ?

Thanks

Re: [Libjpeg-turbo-users] TJCompressor for more than 300 images

[Ivan O. <oli...@gm...>]

is ok... thanks for your feedback.hopefully this matters alerts others...



On Tue, Mar 15, 2016 at 3:06 AM, DRC <dco...@us...>
wrote:

> No clue.  Sorry.
>
>
> On 3/14/16 12:51 PM, Ivan Ooi wrote:
> > just tested your way. init TJCompressor 1 time. and reuse it.
> >
> > 1st time i call
> > tjc_byte = tjc.compress( ii_compress_flags );
> >
> > then call the following for rest :
> > tjc.compress( tjc_byte, ii_compress_flags );
> >
> > and every time i will call tjc.close();
> > but still no luck...
> >
> > still, 33 photos only and out of heap size...
> >
> >
> > On Tue, Mar 15, 2016 at 1:29 AM, DRC <dco...@us...
> > <mailto:dco...@us...>> wrote:
> >
> >     You're doing exactly what I would do.  Not sure why the garbage
> >     collector isn't working properly.  The next things I would try:
> >
> >     (1)  Allocate the TJCompressor instance statically and reuse it for
> >     every subsequent image.
> >
> >     (2)  If you know that the output image will never exceed a particular
> >     size, then allocate it statically with size TJ.bufSize(maxWidth,
> >     maxHeight, TJ.SAMP_420) and reuse the same output buffer for every
> image
> >     (compress(byte[] dstBuf, int flags).)  Even if the image size is
> >     variable, then you could allocate the buffer statically with the
> >     dimensions of the first image and re-allocate it only when a
> subsequent
> >     image exceeds those dimensions.
> >
> >
> >     On 3/14/16 12:14 PM, Ivan Ooi wrote:
> >     > Hi all,
> >     >
> >     >   I'm try to use TJCompressor to compress more than 300 images but
> it is
> >     > easily out of memory heap size.
> >     >
> >     >    Is there anyway to over come this issues ?
> >     >
> >     > Thanks
> >     > Ivan
> >     >
> >     > This is my test code :
> >     >
> >     >                TJCompressor tjc = new TJCompressor();
> >     >
> >     >
> tjc.setSourceImage(abi_image,0,0,abi_image.getWidth(),
> >     > abi_image.getHeight() );
> >     >
> >     >                tjc.setJPEGQuality(70);
> >     >                tjc.setSubsamp(TJ.SAMP_420);
> >     >
> >     >                byte lbyt_image2[] = tjc.compress(
> ii_compress_flags );
> >     >                tjc.close();
> >     >                tjc = null ;
> >     >                System.gc();
> >
> >
>  ------------------------------------------------------------------------------
> >     Transform Data into Opportunity.
> >     Accelerate data analysis in your applications with
> >     Intel Data Analytics Acceleration Library.
> >     Click to learn more.
> >     http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
> >     _______________________________________________
> >     Libjpeg-turbo-users mailing list
> >     Lib...@li...
> >     <mailto:Lib...@li...>
> >     https://lists.sourceforge.net/lists/listinfo/libjpeg-turbo-users
> >
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > Transform Data into Opportunity.
> > Accelerate data analysis in your applications with
> > Intel Data Analytics Acceleration Library.
> > Click to learn more.
> > http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
> >
> >
> >
> > _______________________________________________
> > Libjpeg-turbo-users mailing list
> > Lib...@li...
> > https://lists.sourceforge.net/lists/listinfo/libjpeg-turbo-users
> >
>
>
> ------------------------------------------------------------------------------
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
> _______________________________________________
> Libjpeg-turbo-users mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libjpeg-turbo-users
>