Help talk:JPEG

Progressive JPEGs

I've been using progressive JPEGs since I started editing Wikipedia and other Wikimedia projects, and I have had no problems with them. They are almost always smaller files--that's why they are used

Furthermore, looking at the bug in question, the prohibition was created by a single programmer rather than via consensus. A single user has no right to create policy. People do a lot of things on Wikimedia that use more memory. As long as it works, there's no reason to change.

The most this page should say is that, if a JPEG fails, you can try reuploading as a baseline JPEG.

Trlkly (talk) 13:59, 10 January 2014 (UTC)

1) Wikimedia Commons is not running short on disk space; other factors may be more important.

2) Very large progressive JPEGs will not display thumbnail or resized versions.

3) Since progressive JPEGs require more memory to process, uploading JPEGs in non-progressive format, where feasible and reasonably convenient, is a kind of courtesy to the site.

4) In short, all other things being more or less equal, non-progressive JPEG format is preferred here... AnonMoos (talk) 17:00, 10 January 2014 (UTC)

jpegtran -optimize

I suggest adding, as a suggested good practice, lossless optimization of jpegs using the -optimize flag in jpegtran. This will produce a baseline jpeg losslessly optimized by optimizing the Huffman tables. Doing this can make the jpeg smaller in size (in the worst case scenario the image will stay at same size) while keeping it saved as a baseline image.

Of course to make sure that all EXIF data is preserved the full command should include the -copy all flag as well. SuperTank17 (talk) 13:35, 16 March 2014 (UTC)

Running "jpegtran -optimize" can clean up certain internally-problematic JPEG files and/or squeeze some bytes, but I don't think it's something that most people will be doing on most of their files to be uploaded... AnonMoos (talk) 03:38, 18 March 2014 (UTC)

That's why I think it should added as a suggested good practice especially since we're already telling people not to use progressive JPEGs. It is helpful to the uploaders as running a batch script that optimizes all jpegs in a folder using the -optimize flag takes a few seconds even if you have hundreds of jpegs in that folder while it can save much more time during the upload if the uploaders are uploading a large number of pictures at once (especially if they have a slow connection, I can still remember how slowly my pictures were uploading back when I had 0.25 megabit upload speed). It is also helpful to the people downloading the full size versions of the pictures in question and a website like Wikimedia Commons can't assume that everyone using it has a fast connection. - SuperTank17 (talk) 21:08, 18 March 2014 (UTC)

Running "jpegtran -optimize -copy all" on JPEG files before they're uploaded is one of those things which it would be good if people did, but which it's not necessarily reasonable to expect people to do routinely (especially since people may be uploading from a variety of platforms). Any filesize savings would be good, but usually they would not be too dramatic -- and transforming a progressive JPEG into non-progressive can sometimes result in a filesize increase... -- AnonMoos (talk) 05:19, 19 March 2014 (UTC)

I know that transforming a progressive JPEG into a baseline JPEG can result in the increase in file size (In fact it has been proven that most JPEGs are smaller when saved as progressive JPEGs rather than as baseline JPEGs) but this help page explicitly forbids uploading of progressive JPEGs because they cause problems with thumbnail creation. Doing this will create the best possible baseline JPEG.

Let me repeat: I am not saying that this is something everyone would have to do. I am just saying it might be worthwhile to tell people about the possibility of using jpegtran's -optimize flag so that they know they have this option if they want to get their file size down without compromising on quality. - SuperTank17 (talk) 10:45, 19 March 2014 (UTC)

Suspicious 2× file size increase

Need a JPEG expertise. Here was a 104 KiB file which bloated to 212 KiB after… mirror reflection. I suspect an ordinary incompetence, but am not a lossy compression expert and also due to my history of not-very-productive interaction with the uploader, it would be nice if somebody else will handle this.

Happy New Year! Incnis Mrsi (talk) 18:58, 30 December 2017 (UTC)

I did not edit any of the images. Details can be found in the OTRS-ticket listed on the image page. As one can see, the first upload has lettering in mirror script. The later upload is the correct version. Regards, Elly (talk) 21:15, 30 December 2017 (UTC)

“[D]id not edit any of the images”… should we infer that, on receiving an incorrectly oriented image, an OTRS member wrote “give me a correct one, please!” to the right holder? And in less than three minutes they replied: “OK, get another file” – in such a story I hardly believe. Or did they send(publish) two images at once, one 104 KiB mirrored while another oriented correctly but 212 KiB? Also dubious iMHO. Incnis Mrsi (talk) 22:27, 30 December 2017 (UTC)

Much more time passed on the OTRS emails then you can see at the upload moments. I do not understand what makes you think this is dubious. Please clarify. Regards, Elly (talk) 16:17, 31 December 2017 (UTC)

Image file size

Hi, in my observations a PNG is on the order of 10 times the size of the JPEG of the same image. I'd expect this to be significant for anyone hoping to see the image via a slow connection. My specific concern: should PNG and JPEG both be uploaded? If only PNG is uploaded, what happens to J. Doe at the end of a slow connection? Thanks, ... PeterEasthope (talk) 14:49, 23 August 2021 (UTC)