User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.116 Safari/537.36

Steps to reproduce:

Use Firefox's built-in screenshot function on a long page of text.

Actual results:

Firefox saves the screenshot as a huge JPG instead of a smaller PNG.

Expected results:

Firefox should ALWAYS save screenshots as PNG by default (and optionally also provide an option to save as JPG in the Save As dialog).

There is absolutely no reason for Firefox to save screenshots as JPG instead of PNG. It seems to use a bit of "dumb" decision code to decide whether it saves it as a JPG or PNG; apparently it saves as PNG by default but will switch to JPG if the resulting file is larger than a certain size (2MB? 🤔)

This is bad for numerous reasons:

1) JPG is lossy. That should be enough reason alone.

1b) People can convert from PNG to JPG but NOT the other way around.

2) JPG is NOT always smaller than PNG. If you save a big of text in JPG, it'll end up much bigger than a PNG. If you save a large page with a lot of text, the resulting JPG will end up much bigger than if it were a PNG.

3) JPGs have a lot of horrible artifacting, which is why all of those screenshots that noobs keep posting of text look horrible and waste space.

4) Using the console command :screenshot is impractical to force a save as a PNG, not just because it's hidden and inconvenient, but also because it doesn't put the page title in the filename like the normal screenshot function does.

5) You don't know how people are going to use the file, so making destructive actions like saving in a lossy format based on assumptions is terrible.

6) People will rarely post screenshots as is, they'll usually edit them, crop them, etc. and save them in whatever format they want (if they want a JPG, they'll save as JPG; they don't need you to do it for them). You shouldn't ruin things for millions of users to accommodate a small handful of users who don't know what they're doing.

6b) Editing (even cropping) JPGs could easily end up resulting in a BIGGER file than the original whereas editing PNGs would make them smaller.

7) Saving a screenshot as JPG that ends up larger than it would have as a PNG defeats the whole point that bit of "logic" in the code.

8) There's no practical reason or benefit from saving it as JPG even if it did result in a smaller file. There's no savings on bandwidth since it's a local function and not download the screenshot, and the difference in size from even a smaller JPG to PNG is negligible in most cases, especially with ever-growing SD cards. I can't imagine anyone saying that they'd rather have JPGs over PNGs to save an extra 300KB, especially since taking screenshots isn't exactly a frequent action, so it's not like people are going to have thousands of them so that 300KB adds up (and even then, it should be the USER'S CHOICE to convert it to JPG, let alone the aforementioned fact that a *lot* of screenshots can end up bigger as JPGs since webpages tend to be large swaths of plain text).

Like I said, if for some reason you MUST allow users to save directly to JPG instead of just converting it in a program or something like everybody does, then just provide that as an option in the Save As dialog, but ALWAYS default to PNG.

(Oh great, the post got formatted in a bad way such that most of the text isn't visible, and there's no option to edit it. Wonderful. 😒)

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

The severity field is not set for this bug.
:ianbicking, could you have a look please?

For more information, please visit auto_nag documentation.

Two more points:

9. Firefox saves JPGs files as 80%-quality files, so it's not even giving the best JPGs possible, resulting in even more artifacting and even bigger screenshot files of text.

10. The algorithms that Firefox uses aren't very efficient, so when it compare the sizes, it gets specious results. For example, I can take a screenshot with Firefox' built-in function as a PNG (either the normal way or the PITA way via the console) and then open it in Irfanview and re-save it with maximum compression (PNG is always lossless) and the new file will be at least 10% smaller. (This furthers a previous point about you not knowing what users will do with files, therefor not being in a position to make choices "in their interests".)

11. Even if we wanted to go to the trouble of using the :screenshot command to always save as PNG, that function only puts the date in the filename, not the page title, so its even more inconvenient an more work to take a screenshot for no good reason. 😕

Just save screenshots as PNG. Always.

I tried to take a screenshot of a long page, and as usual, Firefox insisted on saving it as a JPG with no option to save as PNG. The page was mostly white space, so it would have been much smaller as a PNG, but because Firefox saved it as a JPG, it ended up at 6MB. Since JPG is lossy and creates artifacting (especially at the 80% quality that Firefox saves them as, again with no option to select settings ¬_¬), saving it as a PNG didn't reduce its size and in fact, doubled it. 🤦

I opened the Developer Tools and clicked the screenshot button to force it save as a PNG, but it only saved half of the page. I switched to the console and used the ":screenshot --fullpage" command, but again, it only saved half of the page. In other words, the normal screenshot function is the only way to actually capture a full page sometimes, and its insistence on saving as JPG is terrible.

Forcing screenshots to be saved as JPGs if it's over 2MB is absurd and unrealistic. If the PNG is 2MB, the JPG is probably even bigger, especially since most screenshots (of WEB PAGES!) are going to have large amounts of solid color which means PNG should be used, not JPG.

Here's the screenshot I took (imgur actually shrank it to 5MB 😕). https://i.imgur.com/MK45k2s.jpg Feel free to waste some of your bandwidth to view it. You could have wasted only ~2-3MB if you had let me save it as a PNG. 😒

There is a size threshold above which the code decides to use a JPEG rather than PNG. This threshold is defined at https://searchfox.org/mozilla-central/source/browser/extensions/screenshots/build/buildSettings.js#10, and the logic is at https://searchfox.org/mozilla-central/source/browser/extensions/screenshots/background/main.js#201

I'm looking for the history on this decision. I'm personally inclined to agree - for most web pages, PNG is a better choice and the pngToJpegCutoff limit and logic seems like an added complexity that isn't adding much value to the feature in its current form.

It would be good to understand why the saved jpeg is actually larger than the png, when the whole point of this logic is to end up with a smaller file (for better or worse).

Listen, when on sale 20-terabyte hard drives it makes no sense to bother with a few megabytes lost in a dozen screenshots. But the fact that on some sites there is a font size so small that screenshots saved in JPEG are not recognized by the OCR application and the Windows document indexing system - this is a problem. Not to mention the fact that JPEG is, in principle, not intended to save images with sharp contrasting edges of objects. Almost all web pages are like that.

I tried understanding this code before, but had some problems figuring out which function is actually responsible for taking the screenshot.
From what I can tell Bug 1664444 is going to make substantially changes to this code, so we should see if this still a problem afterwards.

So I guess good news first, since Bug 1664444 we seems to default to PNG.
Testing on https://toronto.ctvnews.ca/ontario-unveils-plan-to-reopen-schools-in-september-here-s-what-you-need-to-know-1.5044038 there are two bad side effects from that change:

• Taking a full-screen screenshot takes a very long time. For me it feels like 5 seconds! Previously this was maybe 2s.
• The generated PNG is 9.3 MB vs the previous 3.3 MB JPEG file

(In reply to Tom Schuster [:evilpie] from comment #10)

• The generated PNG is 9.3 MB vs the previous 3.3 MB JPEG file

I saved the "[url=https://store.steampowered.com/search/]Steam Search[/url]" page using the built-in browser function. The result is a JPEG picture with a height of 32767 pixels and a weight of 6.27 MB. That is, with an image width of 1902 pixels, about 201 bytes per line. (I'll explain below why this is needed here.) Lots of graphical artifacts. The storage time is a couple of seconds.

Also, I saved the same page as PNG using the PicPick application. The file size is 3.79 MB, its height is 17724 pc (apparently, the limitation of the program) (225 bytes per line). Re-saved it to JPEG with maximum quality. The resulting file is 5.37 MB (318 bytes per line). There are few artifacts, but they are still there.

Conclusions:
[olist][]at least 85.0b2 x64, saving is still in JPEG;
[]the compression ratio when using the built-in browser function is about 63% (201/318);
[]JPEG is generally not suitable for saving web pages due to quality;
[]even large screenshots are saved very quickly;
[]large web pages in PNG take up less space than they are in JPEG format;
[*]the difference in file sizes of 40% (318/225) is considered insignificant.[/olist]

• Quality: 12 (Maximum), Format Options: Baseline Optimized

Bug 1683194 is a follow-up to Bug 1664444, I'm not sure if that will have an impact on the performance regressions pointed out in comment 10, but lets keep an eye on it.

I think the best outcome for this bug will be to remove the JPEG output and cut-over entirely. JPEG just isn't well suited to most web pages, and if we need to dial back the compression completely to get readable text, then ISTM the better trade-off is to always use PNG. I've looked for the original reasoning behind this feature and I think it was motivated at least partly by storage costs when mozilla provided hosting for these images. Now that all images will be saved to the user's drive, I think it is better to always capture in a non-lossy format and let the user compress them if they want to. Without some research, I don't know if that will mean large/tall screenshots will become slower due to the characteristics of the respective compression algorithms - possibly? As a first pass though, eliminating data loss seems a higher priority, as long as the end result falls within acceptable margins in terms of day-to-day usability and responsiveness.

let the user compress them if they want to

The screenshot as taken by Firefox is rarely going to be the final result, the user will usually crop or otherwise modify the image, so having to work with a JPG just further destroys quality. (I cringe every time I see screenshots of text with JPG artifacts on social-media. 🤦)

day-to-day usability and responsiveness

It's not like people are going to take giant screenshots of whole pages numerous times per day, every day, so the performance is irrelevant. That's like saying that nobody should go to the DMV because it takes a long time. Sure, but it's a once in a while thing that you need to do, so you just suck it up and wait for it happen. 🤷

Besides the fact that the 2.38MB threshold is laughably small by today's standards, the salient fact is that most webpage screenshots that are large enough to trigger it will end up as even larger in JPG than they would in PNG due to all of the solid blocks that don't compress well in JPG.

It doesn't really matter to me either way because I've modified the relevant files on my installation to always save as PNG and also remove the (equally poorly conceived) 10000x10000 limitation, but I'm certain other people have been affected and would prefer that Firefox did the right thing.

Bug 1600269 will hopefully be able to take care of some of the performance issues we see with full page screenshots on the graphics side

We have a pngToJpegCuttoff constant that we use to determine which format to save it in. I actually thought we had removed this already, but at least some of this functionality remains. We should remove that constant and the logic that depends on it.

https://hg.mozilla.org/mozilla-central/rev/d6514bb1e2e2