Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Progressive JPEG files by default? #142

Closed
wwinniww opened this issue Mar 28, 2023 · 12 comments
Closed

Progressive JPEG files by default? #142

wwinniww opened this issue Mar 28, 2023 · 12 comments

Comments

@wwinniww
Copy link

I use the windows 64 bit compile of jpegoptim 1.5.3

I noticed that every optimized jpeg file is progressive, but I don't specify --all-progressive as command line parameter.
Shouldn't be the default operation unless specified otherwise to keep sequential JPEG instead of converting every JPEG file into progressive JPEG?

@tjko
Copy link
Owner

tjko commented Mar 28, 2023

I couldn't replicate this. Are you perhaps using mozjpeg, and not libjpeg? (I was testing with jpegoptim compiled against latest libjpeg).

@wwinniww
Copy link
Author

Thanks for you reply.
I use the pre-compiled program you provide here. I didn't compile jpegoptim for myself.
I did not install MozJpeg anywhere on my PC, at least not intentionally.

I just use the pre-compiled jpegoptim program 1.5.3 x64 for Windows, which I downloaded from this website. Nothing else.

So my conclusion is that the pre-compliled version of Jpegoptim converts normal Jpeg files to progressive Jpeg files.

@tjko
Copy link
Owner

tjko commented Mar 29, 2023

Looks like it must be mozjpeg library doing this. It seems to default to progressive (presumably because that typically produces slightly smaller files than non-progressive mode), so its not 100% compatible with libjpeg....

Have to see if there is way to make it behave like libjpeg in this regard.

@wwinniww
Copy link
Author

Thanks.
Nice to have feature might be to display both normal and progressive jpeg file sizes when --no-action parameter is specified.

@tjko
Copy link
Owner

tjko commented Mar 30, 2023

I think this should now be fixed. If you want to test the fix, you can find binaries here: https://github.com/tjko/jpegoptim/actions/runs/4559486709

@wwinniww
Copy link
Author

Thanks.
I did test the windows test compile you provided. I can't that the compile for Apple Mac, and I don't have access to a PC with Linux OS atm.

The behaviour for normal Jpeg files is correct now,
for progressive jpeg files there is a little side effect,
in default mode the optization is less effective compared to when progressive mode is specified.
My verdict is
default mode use libjpeg, whereas in progressive mode mozjpeg is used for optimization.

So for best optimization of progressive jpeg files the switch --all-progressive is needed according to my tests.

@tjko
Copy link
Owner

tjko commented Apr 1, 2023

Maybe better (less intrusive) is to implement new option like --preserve-mode that could be used if someone wants to prevent JPEG changing from normal to progressive during optimization. Since most users likely just want smallest possible file (by default) and progressive vs non-progressive JPEG is not a factor at all... (?)

@wwinniww
Copy link
Author

wwinniww commented Apr 1, 2023

Hello.
The only drawback when it comes to this is:
Progressive JPEG images takes noticeably longer to decode compared to normal JPEG.
I don't know if every JPEG decoder out there is able to decode progressive JPEG.

I think that a --preserve-mode switch is a good idea.

An other minor thing, maybe the help option of the program should not display unavailable option,
in the case jpegoptim is compiled without support of arithmetic coding,
why should help show that option?

Thanks.

@starleafs
Copy link

starleafs commented Apr 17, 2023

I noticed that progressive jpegs not showing correctly on mac/ios
jpegoptim version 1.5.3 windows

When I covert images using standard method (jpegoptim.exe --max=90), I received images display wired colour lines opening with mac/ios, but images display correctly on PC.
After reading this post, i use non-progressive method (jpegoptim.exe --max=90 --all-normal), I received images display correctly both on PC/Mac

is it a bug?
I've attched screenshot and sample images below
IMG_0841-progressive(screenshot from mac)
IMG_0841-progressive(screenshot from PC)

@tjko
Copy link
Owner

tjko commented Oct 30, 2023

I noticed that progressive jpegs not showing correctly on mac/ios jpegoptim version 1.5.3 windows

When I covert images using standard method (jpegoptim.exe --max=90), I received images display wired colour lines opening with mac/ios, but images display correctly on PC. After reading this post, i use non-progressive method (jpegoptim.exe --max=90 --all-normal), I received images display correctly both on PC/Mac

is it a bug? I've attched screenshot and sample images below

@starleafs, can you provide the actual image file(s)? So I could test, if I can reproduce the issue you're seeing.

@wwinniww
Copy link
Author

wwinniww commented Oct 30, 2023 via email

@starleafs
Copy link

I noticed that progressive jpegs not showing correctly on mac/ios jpegoptim version 1.5.3 windows
When I covert images using standard method (jpegoptim.exe --max=90), I received images display wired colour lines opening with mac/ios, but images display correctly on PC. After reading this post, i use non-progressive method (jpegoptim.exe --max=90 --all-normal), I received images display correctly both on PC/Mac
is it a bug? I've attched screenshot and sample images below

@starleafs, can you provide the actual image file(s)? So I could test, if I can reproduce the issue you're seeing.

Hello, I tested again with jpegoptim version 1.5.5 and I think this bug was fixed on version v1.5.4 (Fix mozjpeg not preserving JPEG mode (progressive vs normal) by @tjko in #143

thanks.

@tjko tjko closed this as completed Nov 2, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants