Episode 047: Saving for the Web, CYMK or CMYK on a new server

Download the Video!
Download the companion file!

Just to get you over the gap in the flow of videos here is the last one before the server dies. And it’s the first one on the new server – this posting was not in the backup because the provider killed the server one day early. All your comments are lost too. 🙁

It covers CYMK modes for printing in a video of Andrew A. Gill. He tells us the why and how and what can be done with GIMP and what not.The discussion with more links is here.

I show you how to install and use the “Save for Web” plugin.

Hope to see you again soon! 2 weeks from now on!

9 thoughts on “Episode 047: Saving for the Web, CYMK or CMYK on a new server

  1. Hallo Rolf,

    you asked in this show. I will give a hint on what the ‘progressive’ option in some storage dialogs means.

    Typical images are stored sequentially, so, if you download them on a slow line to your webbrowser, you can watch the image rolling down, filling its place. If the image is stored in ‘progressive’ mode, it will fill the whole area really fast but is very unsharp in the first download phase. The more data come in to your webbrowser the sharper the image becomes.

    There are different technical methods to do this. In GIF this is done by storing each 8. horizontal line of the image in a sequence until there is no more 8. line. Then filling up the space between the lines by storing/sending every line in the middle of the free space between the allready received ones, until each line is stored/received.

    Using more complex methods for this, as in JPEG, you don’t need to store the pictue line by line as in GIF. So, in JPEG, the image is stored as a very unsharp one, constiting of a very small amount of data. After this (in the same file), the differences between the former step and the next step (with higher resolution) is stored in the file. So, if you watch the image arriving, you will see the whole thing after a very short time but really unsharp, becoming sharper as more data will be received. It’s up to the algorithm how many sequential parts of the image will be generated until the final resolution will be arrived.

    Especially with large images in high resolutions in large image collections, this storage methode is allways welcome for saving of time and bandwidth if you provide images for the web.


    PS: The ‘baseline’ question is not nearly as easy to answer as the ‘progressive’ question. But here is a document about it: http://www.dakx.com/theory/jpegbaseline.html

  2. I happen to still have my comment which was deemed lost 🙂

    BTW, the part on the progressive option is far better explained by Manfred.

    ****Posting before the server went down****

    JPEG compression is in fact a difficult mathematical exercise. As far as I understand, they mean the following:
    – Progressive, the easiest and very understandable one. If checked the image will be saved in such a way that a coarse image can be shown before all image data have been decompressed. As more and more data are decompressed, one sees more and more accurately the final image. This is typically used for large images on a web site in order to give people with a slow internet connection a pre-visualisation of what’s to come.
    – Smoothing, understandable. Probably everyone has noticed the blocky artefacts when compressing too much. It is possible to counteract it to a certain degree by smoothing. Because one applies in fact a slight blur, one is walking a thin line to achieve a compression as a high as possible without degrading the image too much by a strong blur.
    – Optimize, not understandable. It is related to determining optimal values for certain encoding parameters. It requires to examine the image two times but gives a better compression without extra loss. I do not think one has ever to uncheck this option.
    – Baseline, not understandable. JPEG allows several compression techniques. Baseline is the de facto standard, if I am not mistaken. Anyway, now that it is mentioned, the general opinion is that JPEG is always lossy. This is not true. Lossless JPEG exists! To be honest, I have not ever seen such an image, though.

    I hope it helps, Serge

  3. Hi there!

    It’s good to have meetthegimp back to life!

    Good show. Hopefully the 2.6 release and the GEGL stuff will begin to start to solve the cmyk issue

  4. Hi Rolf,
    Great videos, please keep them coming.
    I’d be very grateful if you could along with mp3, also post your tutorials as ogg files.

    Open source is the way forward.


  5. Pingback: MTG: Обзоры выпусков за весь 2008 год! « Блог фотолюбителя :)

Anything to add from your side of the computer?

This site uses Akismet to reduce spam. Learn how your comment data is processed.