2

Does a JPEG image converted back to bitmap image when displayed on the screen? Does it occupy more memory than the actual file-size when it is being displayed?

Does JPEG images, if added to the web-page, consume the amount of memory of their bitmap equivalent when displayed by the browser?

VVK
  • 131
  • 6
  • 2
    I'm struggling to see how this curiousity might relate to photography. How would it matter either way? – mattdm Jul 03 '14 at 10:17
  • 5
    This question appears to be off-topic because it is about digital images in general and not photography. – ElendilTheTall Jul 03 '14 at 13:01
  • 1
    This is a programming question really... and, if you're not coding up some new whiz bang browser, you shouldn't be concerned with this. Stick to the general principles of good web design concerning your images, and you will be fine. Let the browser makers worry about memory usage of rendered web pages - that is pretty far out of your control. In general, the answer is yes they do, but the image is converted for display on the particular machine where it happens, and you can't prepare an image for that, because the client can do anything it wants. – Jasmine Jul 03 '14 at 17:04

2 Answers2

7

Yes. How else could it be displayed? The screen needs to show the actual pixels, not an abstracted mathematical representation of them.

Perhaps more crucially, a JPEG needs to be converted to a bitmap to be edited, which is why re-saving an image in JPEG can cause artifacts and loss of detail even if you don't change anything.

Community
  • 1
mattdm
  • 143,140
  • 52
  • 417
  • 741
  • Not entirely correct. It depends on the nature of the program and the editing action if JPEG needs to be converted to a bitmap. See my answer for details. – John Thomas Jul 03 '14 at 10:55
  • 2
    @JohnThomas There is no program which can display a JPEG without decoding it to a bitmap. It's correct that there are editing actions which work on the metadata and not on the image itself, but those are special cases. – mattdm Jul 03 '14 at 14:32
  • I didn't say that exists a program which displays a JPEG without decoding it to a bitmap. I said that there are programs which edit JPEGs in such a way - for ex. crop, rotate in 90 degrees (which are quite common edits on the image itself :) ) and metadata manipulation. For algorithm see at http://is.gd/1Yw8aw - for an extensive discussion see here: http://newsgroup.xnview.com/viewtopic.php?t=24984 – John Thomas Jul 03 '14 at 16:22
  • @JohnThomas I'm not trying to argue, just clarifying that your "not entirely correct" statement doesn't apply to the main point of the question or the answer. – mattdm Jul 03 '14 at 17:20
  • Also a jpeg would have to be converted from the Y'CbCr colour system that it uses natively into RGB for display and the result of that transform has to be stored somewhere in memory. That doesn't have to be main memory it could be decoded and stored on the graphics card for example. – James Snell Jul 03 '14 at 18:56
5

The actual screen representation of a jpeg file (or any other graphic file) is different from the one which lies in the file.

Because JPEG is a lossy compression, the JPEG cannot be converted BACK to the original bitmap (the one which was saved by camera and/or another program). It is converted to one (or more) new bitmap(s) which can be (and is) dependent on the program and/or operating system and/or output device (screen, printer etc.) internals.

Again, because is a lossy compression, the expanded bitmap(s) is quite bigger than the actual JPEG file. Also, as I keep mentioning there can be more bitmaps for caching, undo etc. That's why there are optimizations in place, including keeping the actual image in a compressed format (usually losseless, of course) and preparing (converting, uncompressing, painting etc.) for the screen only the part (a crop) of the image which is actually shown.

However the memory consumption isn't of a concern nowadays for the regular user, the usual bottleneck being storage read/write time and, of course, the time spent within the processing algorithms.

Related to the internal conversions between JPEG and internal bitmap(s), is important to know which are the editing actions which require this load->conversion->save process and which are the editing actions which can be done directly in/on JPEG file. This is because of the lossy nature of JPEG compression which at each conversion degrades the quality of the image.

There are programs which do all the editing actions in a destructive load > conversion > save cycle. (eg. Photoshop, Corel PhotoPaint etc.).

There are other programs which do some actions directly on JPEG file like Loseless rotate in 90 degree increments, metadata/catalog management (XMP, IPTC, Rating, Coloring etc.). All the other advanced editing actions are done via a normal load > conversion > save cycle. Usually these are the organizers, multimedia managers/viewers - personally I use XnView MP but I know that also FastStone Viewer or others has such functions.

Also, there are other programs which support a reduced set of editing actions which - regardless of the file type - apply these actions in a non-destructive manner. In fact these programs (eg. Lightroom, AfterShotPro etc.) save only the script (history) of the actions which apply each time when (a part of) the image is rendered on the screen. It needs CPU power (sometimes a lot) but one can accept this for obvious reasons. For these programs, in order to actually 'see' your edited JPG in another program you need to 'export'/'burn'/'render' it to another/same file. IOW to apply the edits to the image.

John Thomas
  • 4,495
  • 1
  • 18
  • 30