ilyakurdyukov / jpeg-quantsmooth Goto Github PK

Interested in MP3 DCT Quantum Smooth based on madplay (https://www.underbit.com/products/mad/) or mpg123 (https://www.mpg123.de/).

I immediately warn the obvious answer: I know about filter banks. I don’t propose to mess with “filter banks” for dequantization, but I suggest using other information.

“Volume War” in combination with “filter banks” in any MP3 without additional regulation (REPLAY_GAIN) leads to clipping. It is this fact that I propose to use for dequantizing MP3.

I’m not sure that the result of dequantization can be saved in MP3 (even 320kbps), but the utilities I have specified allow to save the result in WAV.

PS: This time expected library + tool.

@ilyakurdyukov Based on #11 & #18 (comment), I'd like to suggest for the prebuilt released IV plugin

• exposing the available settings via the UI in a compact way
• building against libjpeg-turbo by default for the sake of performance. Loading via the current plugin takes ~2⅛× the time (in my tests), which is why imho Irfan has it disabled by default. IV is known as a high-speed viewer for the last 24½ years, so improving that loading time any amount would make more likely to be enabled (hopefully, eventually by default) & expose your amazing work more widely.

Hi @ilyakurdyukov .

The other day I came across jpeg with CMYK color space. jpegqs (at least from https://github.com/ImageProcessing-ElectronicPublications/libjpegqs) did a great job with it. But it turned out that only http://netpbm.sourceforge.net/ can work with such a file. Don't want to play with the coefficients for obtaining pseudo-lossless color space conversion?

Maybe?:

#if defined(__SSE_USE__)
#if defined(__SSE4_1__)
#define USE_SSE2
#define USE_SSE4
#include <smmintrin.h>
#elif defined(__SSE2__)
#define USE_SSE2
#include <emmintrin.h>

#define _mm_cvtepu8_epi16(a) _mm_unpacklo_epi8(a, _mm_setzero_si128())
// _mm_cmplt_epi16(a, _mm_setzero_si128()) or _mm_srai_epi16(a, 15)
#define _mm_cvtepi16_epi32(a) _mm_unpacklo_epi16(a, _mm_srai_epi16(a, 15))
#define _mm_abs_epi16(a) ({ \
	__m128i __tmp = _mm_srai_epi16(a, 15); \
	_mm_xor_si128(_mm_add_epi16(a, __tmp), __tmp); })
#endif
#endif

Pass __SSE_USE__ from the Makefile:

CFLAGS ?= -Wall -D__SSE_USE__ -O2 -march=native -fopenmp

And add to docs alternative:

make CFLAGS="-Wall -O2"

PS: Debian Wheezy. I feel better without SSE.

Hi there,

is there any chance you can make this build under macOS?
I was able to build it on my linux server just fine, but I would love to have this working on macOS too.

Anyway - thanks for this cool project!

Reproducable on Arch Linux, observed roughly since libjpeg-turbo 2.1.90 (pre-3.0):

make SIMD=select clean example LDFLAGS="-lm $(pkg-config --libs libjpeg)"
./example test.jpg test.bmp

Sample input (YCbCr 4:2:0) and output (converted to PNG):

It is the JPEGQS_UPSAMPLE_UV flag that decides whether output becomes garbage. YCbCr 4:4:4 is fine.

How about porting functions to libiio (https://github.com/mnhrdt/iio)?

sample file

id0_FPE_jpegqs+0x41c889.zip

command to reproduce

./jpegqs -o [sample file] /dev/null

crash detail

AddressSanitizerAddressSanitizerAddressSanitizerAddressSanitizer:DEADLYSIGNAL
:DEADLYSIGNAL
:DEADLYSIGNAL
:DEADLYSIGNAL
=================================================================
AddressSanitizer:DEADLYSIGNAL
==28436==ERROR: AddressSanitizer: FPE on unknown address 0x0000004f5d6c (pc 0x0000004f5d6c bp 0x7ffc2659eef0 sp 0x7ffc2659e2c0 T0)
AddressSanitizer:DEADLYSIGNAL
    #0 0x4f5d6c  (/home/bupt/Desktop/jpeg-quantsmooth/jpegqs+0x4f5d6c)
    #1 0x7fbb4a1b3452 in __kmp_invoke_microtask (/usr/lib/x86_64-linux-gnu/libomp.so.5+0x7c452)
    #2 0x7fbb4a16d1b6  (/usr/lib/x86_64-linux-gnu/libomp.so.5+0x361b6)
    #3 0x7fbb4a16e2b5 in __kmp_fork_call (/usr/lib/x86_64-linux-gnu/libomp.so.5+0x372b5)
    #4 0x7fbb4a1617be in __kmpc_fork_call (/usr/lib/x86_64-linux-gnu/libomp.so.5+0x2a7be)
    #5 0x4ea485  (/home/bupt/Desktop/jpeg-quantsmooth/jpegqs+0x4ea485)
    #6 0x7fbb49b4fc86 in __libc_start_main /build/glibc-CVJwZb/glibc-2.27/csu/../csu/libc-start.c:310
    #7 0x41c889 in _init (/home/bupt/Desktop/jpeg-quantsmooth/jpegqs+0x41c889)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: FPE (/home/bupt/Desktop/jpeg-quantsmooth/jpegqs+0x4f5d6c) 
==28436==ABORTING

@ilyakurdyukov I've used QuantSmooth via IrfanView & noticed that it isn't currently compatible with arithmetic coded jpgs. Are there plans to implement that?

I was wondering if the program can improve frames from low resolution video. I exported the frames to PNG (lossless) but since they are not accepted by the program I converted to JPEG Q=100 (still not a lossless step). I ran the program with max quality, -q 6, but there's no difference between frames.

So I'm guessing the program needs an "original" JPEG file and won't work with frames exported from video even though they have JPEG like compression artifacts.

Maybe?:

PNAME = jpegqs
...
all: $(PNAME)

clean:
	rm -rf $(PNAME)

$(PNAME): quantsmooth.h idct.h

$(PNAME): quantsmooth.c
	$(CC) $(CFLAGS) -s -o $@ $< $(LIBS)

And:

	const char *progname = argv[0], *fn;

A division by zero differs from #25 .

sample file
crashes.zip

reproduce

./jpegqs ./crash1 /dev/null

fix
Maybe add a check, I guess.

Hi @ilyakurdyukov .

"Мысли вслух, не более того".

Use default :

$ make
cc -Wall -O2  -march=native -Wextra -pedantic -fopenmp -DAPPNAME=jpegqs -o jpegqs quantsmooth.c -ljpeg  -Wl,--gc-sections -s -lm

$ ldd jpegqs 
        linux-vdso.so.1 (0x00007ffe5e16d000)
        libjpeg.so.62 => /usr/lib/x86_64-linux-gnu/libjpeg.so.62 (0x00007f7a394b7000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f7a39373000)
        libgomp.so.1 => /usr/lib/x86_64-linux-gnu/libgomp.so.1 (0x00007f7a39333000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f7a3916e000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f7a3958c000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f7a39168000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f7a39146000)

Use https://github.com/ilyakurdyukov/libminiomp :

$ make LIBMINIOMP=libminiomp.a
cc -DOVERFLOW_CHECKS=0 -O2 -Wall -Wextra -c -o miniomp.o miniomp.c -ffunction-sections -fdata-sections
ar -rsc libminiomp.a miniomp.o
cc -Wall -O2  -march=native -Wextra -pedantic -fopenmp -DAPPNAME=jpegqs -o jpegqs quantsmooth.c -ljpeg -L./  -Wl,--gc-sections -s -lm

$ ldd jpegqs 
        linux-vdso.so.1 (0x00007fffe84cb000)
        libjpeg.so.62 => /usr/lib/x86_64-linux-gnu/libjpeg.so.62 (0x00007ff9a5392000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007ff9a524e000)
        libgomp.so.1 => /usr/lib/x86_64-linux-gnu/libgomp.so.1 (0x00007ff9a520e000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ff9a5049000)
        /lib64/ld-linux-x86-64.so.2 (0x00007ff9a5467000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007ff9a5043000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007ff9a5021000)

This is wrong!

$ cc -Wall -O2  -march=native -Wextra -pedantic -fopenmp -DAPPNAME=jpegqs -o jpegqs quantsmooth.c libminiomp.a -ljpeg -L./  -Wl,--gc-sections -s -lm

$ ldd jpegqs
        linux-vdso.so.1 (0x00007ffd3b156000)
        libjpeg.so.62 => /usr/lib/x86_64-linux-gnu/libjpeg.so.62 (0x00007fdd879dc000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fdd87898000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fdd87876000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fdd876b1000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fdd87ab0000)

This is true! (added libminiomp.a)

Patch:

ifneq ($(LIBMINIOMP),)
LDFLAGS += $(LIBMINIOMP)
endif

Hi @ilyakurdyukov .

Libjpeg out DCT coefficient out of range. The file is not processed (output 0). The file is viewed and converted.

make SIMD=none all

cc -Wall -O2  -DNO_SIMD -c -o libjpegqs.o libjpegqs.c
In file included from libjpegqs.c:28:0:
/usr/include/jpeglib.h:1150:55: fatal error: jpegint.h: Нет такого файла или каталога
compilation terminated.
make: *** [libjpegqs.o] Ошибка 1

jpegint.h : libjpeg62-dev - YES, libjpeg8-dev - NO.

libjpeg8-dev : /usr/include/jpeglib.h (end file):

#ifdef JPEG_INTERNALS
#include "jpegint.h"		/* fetch private declarations */
#include "jerror.h"		/* fetch error codes too */
#endif

Hello Ilya Kurdyukov, Sorry to bother you.

I get some strange color issue on non-photo drawing content,
those issue will happen on -q 5~6(--quality).

In this non-photo picture case, green book middle area have some tiny red pixel,
-q 3~4 haven't happen this issue.

original-cut-png (jpeg q90 420)

qs-q6-png

JPEG Quant Smooth : Copyright (C) 2020 Ilya Kurdyukov : 2020-05-17
Build date: Jan 11 2021
https://github.com/ilyakurdyukov/jpeg-quantsmooth/releases/tag/1.20210110

jpegqs64 -q 6 -o -t 12 test.jpg test-qs.jpg
sample.zip

Maybe add alternative links?:

• https://github.com/victorvde/jpeg2png
• https://github.com/google/knusperli

Is it allowed to rename a utility from quantsmooth to jpegqs in a fork (https://github.com/ImageProcessing-ElectronicPublications/jpeg-quantsmooth)? For me, the original name is inconvenient.

Are you planning a graphical interface?

Maybe add a control parameter?

To:

add = coef1 - a0;
add -= roundf(a2);
add *= coefgain; // double coefgain >= 0.0

Just stumbled across this today, and it looks like a really neat program. However, I can't get the current Windows builds to produce any output file. The latest working version seems to be 2020-03-06 afaict. I'm on Windows 10 64bit, version 10.0.19041.264, if that matters. Here's the full console out put if that helps

jpegqs64.exe --verbose 1 -q 4 0008.jpg 0008_o.jpg


Compiled with libjpeg version 62
Version string: 6b  27-Mar-1998
Copyright (C) 1998, Thomas G. Lane

component[0] : table 0, samp 1x1
component[1] : table 1, samp 1x1
component[2] : table 1, samp 1x1
quant[0]:
0003 0003 0003 0004 0005 0007 000b 0011
0003 0003 0004 0005 0007 0008 000b 000f
0003 0004 0005 0006 0009 000c 0012 001b
0004 0005 0006 0008 000b 000f 0015 001f
0005 0007 0009 000b 000e 0013 001a 0026
0007 0008 000c 000f 0013 0019 0022 0030
000b 000b 0012 0015 001a 0022 002d 003e
0011 000f 001b 001f 0026 0030 003e 0054
quant[1]:
0003 0003 0003 0004 0005 0007 000b 0011
0003 0003 0004 0005 0007 0008 000b 000f
0003 0004 0005 0006 0009 000c 0012 001b
0004 0005 0006 0008 000b 000f 0015 001f
0005 0007 0009 000b 000e 0013 001a 0026
0007 0008 000c 000f 0013 0019 0022 0030
000b 000b 0012 0015 001a 0022 002d 003e
0011 000f 001b 001f 0026 0030 003e 0054