webmproject / sjpeg Goto Github PK

It would be nice, please.

Large coefficients can cause an overflow in Horizontal pass of Dct_NEON transformation.
Consider input coeffs = { 128, 128, 128, 128, 128, 128, 128, 128, ...}.
Vertical pass produces { 8192, 8192, 8192, 8192, 8192, 8192, 8192, 8192, ..} and 2 consecutive butterfly operations on the first row leads to an overflow of c0 = -32768.

I am using Linux Mint 18.1 with GCC 5.4.0-6 and CMake 3.10.0-rc1. I perform the following:
mkdir build
cd build
cmake ..
make -j

I get the following error message:
make[2]: Entering directory '/home/nlbutts/projects/sjpeg/build'
[ 6%] Building CXX object CMakeFiles/sjpeg.dir/src/bit_writer.cc.o
/usr/bin/c++ -I/home/nlbutts/projects/sjpeg/src -O3 -DNDEBUG -fPIC -o CMakeFiles/sjpeg.dir/src/bit_writer.cc.o -c /home/nlbutts/projects/sjpeg/src/bit_writer.cc
In file included from /home/nlbutts/projects/sjpeg/src/bit_writer.h:29:0,
from /home/nlbutts/projects/sjpeg/src/bit_writer.cc:19:
/home/nlbutts/projects/sjpeg/src/sjpeg.h:336:6: error: ‘shared_ptr’ in namespace ‘std’ does not name a template type
std::shared_ptr MakeByteSink(std::string* output);
^
/home/nlbutts/projects/sjpeg/src/sjpeg.h:339:6: error: ‘shared_ptr’ in namespace ‘std’ does not name a template type
std::shared_ptr MakeByteSink(std::vector* output);
^
/home/nlbutts/projects/sjpeg/src/sjpeg.h:340:17: error: ‘shared_ptr’ in namespace ‘std’ does not name a template type
template<> std::shared_ptr MakeByteSink(std::vector<uint8_t>* output);
^
In file included from /home/nlbutts/projects/sjpeg/src/bit_writer.cc:19:0:
/home/nlbutts/projects/sjpeg/src/bit_writer.h: In member function ‘virtual bool sjpeg::Sink::Commit(size_t, size_t, uint8_t**)’:
/home/nlbutts/projects/sjpeg/src/bit_writer.h:63:71: error: ‘nullptr’ was not declared in this scope
data = extra_size ? reinterpret_cast<uint8_t>(&(ptr_)[pos_]) : nullptr;
^
/home/nlbutts/projects/sjpeg/src/bit_writer.cc: In constructor ‘sjpeg::MemorySink::MemorySink(size_t)’:
/home/nlbutts/projects/sjpeg/src/bit_writer.cc:31:12: error: ‘nullptr’ was not declared in this scope
: buf_(nullptr), pos_(0), max_pos_(0) {
^
/home/nlbutts/projects/sjpeg/src/bit_writer.cc: In member function ‘virtual void sjpeg::MemorySink::Reset()’:
/home/nlbutts/projects/sjpeg/src/bit_writer.cc:41:10: error: ‘nullptr’ was not declared in this scope
buf_ = nullptr;
^
/home/nlbutts/projects/sjpeg/src/bit_writer.cc: In member function ‘void sjpeg::MemorySink::Release(uint8_t*, size_t*)’:
/home/nlbutts/projects/sjpeg/src/bit_writer.cc:49:10: error: ‘nullptr’ was not declared in this scope
buf_ = nullptr;
^
/home/nlbutts/projects/sjpeg/src/bit_writer.cc: In member function ‘virtual bool sjpeg::MemorySink::Commit(size_t, size_t, uint8_t**)’:
/home/nlbutts/projects/sjpeg/src/bit_writer.cc:65:20: error: ‘nullptr’ was not declared in this scope
if (new_buf == nullptr) return false;
^
/home/nlbutts/projects/sjpeg/src/bit_writer.cc: At global scope:
/home/nlbutts/projects/sjpeg/src/bit_writer.cc:79:6: error: ‘shared_ptr’ in namespace ‘std’ does not name a template type
std::shared_ptr MakeByteSink(std::string* const output) {
^
/home/nlbutts/projects/sjpeg/src/bit_writer.cc:85:6: error: ‘shared_ptr’ in namespace ‘std’ does not name a template type
std::shared_ptr MakeByteSink(std::vector<uint8_t>* const output) {
^
/home/nlbutts/projects/sjpeg/src/bit_writer.cc: In constructor ‘sjpeg::BitWriter::BitWriter(sjpeg::ByteSink*)’:
/home/nlbutts/projects/sjpeg/src/bit_writer.cc:92:64: error: ‘nullptr’ was not declared in this scope
BitWriter::BitWriter(ByteSink* const sink) : sink_(sink), buf_(nullptr) {
^
CMakeFiles/sjpeg.dir/build.make:62: recipe for target 'CMakeFiles/sjpeg.dir/src/bit_writer.cc.o' failed
make[2]: *** [CMakeFiles/sjpeg.dir/src/bit_writer.cc.o] Error 1
make[2]: Leaving directory '/home/nlbutts/projects/sjpeg/build'
CMakeFiles/Makefile2:67: recipe for target 'CMakeFiles/sjpeg.dir/all' failed
make[1]: *** [CMakeFiles/sjpeg.dir/all] Error 2
make[1]: Leaving directory '/home/nlbutts/projects/sjpeg/build'
Makefile:129: recipe for target 'all' failed
make: *** [all] Error 2

If I update the CMakelists.txt file and add -std=c++11, everything works fine.

Currently building vjpeg.exe fails when using MSVC (Visual Studio) targeting the Arm64 platform. vjpeg.cc experiences a linking error:

vjpeg.cc
LINK : fatal error LNK1181: cannot open input file 'opengl32.lib' [C:\projects\sjpeg\vjpeg.vcxproj]

The error probably occurs because opengl32.lib is x86 specific.

Example builds can be found on AppVeyor: Arm64 (fails) | x64 (passes).

I'm currently trying to build for Android. According to the Readme there should be a file android.cmake in the cmake directory, but that one seems to be missing.

8 bits are not enough to store many useful default quant tables (example: https://github.com/mozilla/mozjpeg/blob/master/rdswitch.c#L322-L333 by the way, this is apparently the table which is used by default in mozjpeg, they probably have good reasons for using it instead of the JPEG Annex K).

Even when using a table which is all ≤ 255, after the scaling with quality parameter the values can become bigger and I think it's not good to have to limit them. (both the standard cjpeg tool and the mozjpeg fork allow values larger than 255 in final quantization tables, it can be seen by inspecting jpeg files produced by them with djpeg -v -v example.jpg > /dev/null; as an extreme example, a file produced by cjpeg -q 1 has quantizer values as big as 6050)

If you agree with the idea of changing the quant tables type from uint8_t to uint16_t, I might try to develop a patch.

reported esser messages:

ld: error: undefined symbol: sjpeg::EncoderParam::ResetMetadata()
>>> referenced by utils.cc:514 (/home/leleliu008/.ndk-pkg/run/2308279/sjpeg/src/examples/utils.cc:514)
>>>               CMakeFiles/sjpeg-utils.dir/examples/utils.cc.o:(ReadJPEG(std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char> > const&, int*, int*, sjpeg::EncoderParam*))
>>> referenced by utils.cc:320 (/home/leleliu008/.ndk-pkg/run/2308279/sjpeg/src/examples/utils.cc:320)
>>>               CMakeFiles/sjpeg-utils.dir/examples/utils.cc.o:(ReadJPEG(std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char> > const&, int*, int*, sjpeg::EncoderParam*))
>>> referenced by utils.cc:745 (/home/leleliu008/.ndk-pkg/run/2308279/sjpeg/src/examples/utils.cc:745)
>>>               CMakeFiles/sjpeg-utils.dir/examples/utils.cc.o:(ReadPNG(std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char> > const&, int*, int*, sjpeg::EncoderParam*))
>>> referenced 3 more times
clang++: error: linker command failed with exit code 1 (use -v to see invocation)

workaroud:

sed -i '133c target_link_libraries(sjpeg-utils sjpeg)' CMakeLists.txt

sjpeg recommends sharp YUV for this image (https://user-images.githubusercontent.com/19407943/33548263-53136816-d8ef-11e7-8994-6a6cfded7912.png):

Riskiness: 60.1 (recommended yuv_mode: SharpYUV420)

But in fact only YUV444 gives transparent results for this image; any chroma subsampling adds very obvious changes to the image.

(opening this 'issue' as a vague reminder for an interesting TODO)

Similar to WebP API[1], it would useful to have an inner loop that dichotomizes toward
a given, user-specified, target for PSNR or file-size.

Compared to an external script that would dichotomize on -quality, there's some savings to be had by not re-doing histogram collection or sample import for instance. Also the gradient descent could alternate trellis & adaptive-quantization (right now, the trellis pass is somewhat sub-optimal because there's no update pass on the Huffman codes).

Agreed, PSNR is not the ultimate metric to aim for, but targeting PSNR>40dB is usually a good threshold for lot of practical purpose.

[1] https://developers.google.com/speed/webp/docs/api#advanced_encoding_api

jpegrescan can sometimes shrink the size further. There should be an option to have progressive-coded output.

Starting a branch 'prog' for that.

This has been a common transition for other projects.