Prepare gallery for web - Colour space

[jule]

I would appreciate some thoughts on the most appropriate way to prepare files for a web gallery, to appear in the best possible way for the most viewers, considering the variables of different browsers and monitors. Technology is changing rapidly and I am interested in what is the current approach.    

Firstly -I have been researching a lot, but am becoming a little confused by a couple of terms ie; embedding and tagging. I thought I understood it but the following sentence confused me. "If an image has no profile, but is tagged as sRGB with the EXIF:ColorSpace tag, use sRGB. "  " http://regex.info/blog/photo-tech/color-spaces-page7  "  ..... I'm not sure how it can not have a profile if it is tagged?   I thought tagging meant associating a source profile with the document. Is it meaning that it has only been assigned a profile and not had one embedded?

Secondly - with the increasing numbers of colour managed browsers and operating systems, should I embed with Adobe 1998 for those monitors which can view these colours to their monitor profile as the destination profile....and those which can't, default to viewing as sRGB according to their browser/monitor conversion....?

...or convert to Adobe 1998 and save - without embedding the profile..?

....or should I convert to sRGB and save - without embedding the profile? ...

...or should I convert to sRGB and save - embedding the profile?

Advice and comments appreciated.
Thank you.  Julie

[The View]

Convert to sRGB and embed the profile.

[Alaska]

sRGB - 72 dpi will do it.....

[jule]

Thank you The View and Alaska for your responses.

Anyone else able to help me with my first question?

I would also be grateful if some explanation and thoughts could be given as to why you would or would not embed the sRGB profile.

Just found in my Real World Colour Management by Andrew Rodney....p 302 " So our simple recommendation is to convert all your colour to sRGB, and then save without embedding a profile, before uploading it. "  

...so Andrew Rodney suggests WITHOUT embedding with sRGB.

I'm still confused and would like to understand.  Digitaldog, I would love a brief outline of why you would, or would not, embed the sRGB profile for web display?

Thanks kindly
Julie

[mbalensiefer]

Just a note: Imbedded profiles seem to provide an annoying problem when moving them from one folder (or disk) to another.

 Whenever my pictures are missing their profiles, my OS (Vista) asks me if I want to move the files without a profile being attached. I wonder why a file "needs" this.

Michael

[The View]

Modern browsers can read embedded profiles.

[Henry Goh]

Julie,

I convert to sRGB and the profile is embedded.  What I used to do was to have resolution at 72 ppi but these days with so many people using LCD panels instead of  CRTs, I now use 96 ppi.

Hope this helps.

Henry

[jbrembat]

I convert to sRGB and the profile is embedded. What I used to do was to have resolution at 72 ppi but these days with so many people using LCD panels instead of CRTs, I now use 96 ppi.

The PPI value is embedded in the file. But, changes..... nothing.

Jacopo

[pcox]

I convert to sRGB and embed the profile in my gallery images. It adds a little to the size of the file, but I figure it doesn't hurt anything and might fix problems for some people.

The question is a good one though - since everyone is browsing in sRGB, does it really matter if we embed the profile?

As to PPI and web display - PPI has no effect whatsoever except in printing. When you're looking at an image on the web you're looking at the actual pixels - equivalent to 100% in Photoshop. PPI is only looked at when printing an image - it dictates how close together the pixels will appear on the page, affecting the size of the print.

It's a very commonly misunderstood term - if I had a dollar for every time someone asked me to send them a file 'at 300ppi' without specifying the intended print size, I'd be a rich man. Without the print size, the resolution means nothing.

Cheers,
Peter

[jbrembat]

PPI is only looked at when printing an image

If you mean PPI=image width(height) / print width(height)

image width(height) in pixel units
print width(height) in inch units

  then, you are right.

If you mean the value embedded into the image file, you are wrong.

Jacopo

[pcox]

Jacopo -
Would you care to elaborate on this?

Peter

If you mean PPI=image width(height) / print width(height)

image width(height) in pixel units
print width(height) in inch units

  then, you are right.

If you mean the value embedded into the image file, you are wrong.

Jacopo
[a href=\"index.php?act=findpost&pid=223897\"][{POST_SNAPBACK}][/a]

[Henry Goh]

Of course ppi does makes a difference when I set the image size to say 800 x 600 pixels @ 96 ppi.

[pcox]

Here's the same image, one at 72, the other at 96ppi.





Both are 800x267 pixels. Can you see a difference? I sure can't.

.. and for fun, here's the same one at 300ppi, same pixel dimensions.




Peter

[jbrembat]

Jacopo -
Would you care to elaborate on this?

Peter
[a href=\"index.php?act=findpost&pid=223906\"][{POST_SNAPBACK}][/a]

PPI does'nt make any sense until the image is rendered on a device (monitor, printer).

So, the information embedded in the image file is a nonsense.

An image has not a physical size. The image dimensions are in pixels not in inches or meters.

But, after rendering (on monitor or on printer), the image acquires a physical size, as is fixed the device size.

Again, no renderending operation check for the PPI value embedded.

As I said  PPI value is computed as  (image width)/(size width).
The result of the division is the pixel density (Pixels Per Inch).

Jacopo

[teddillard]

PPI does'nt make any sense until the image is rendered on a device (monitor, printer).

So, the information embedded in the image file is a nonsense.

An image has not a physical size. The image dimensions are in pixels not in inches or meters.

But, after rendering (on monitor or on printer), the image acquires a physical size, as is fixed the device size.

Again, no renderending operation check for the PPI value embedded.

As I said  PPI value is computed as  (image width)/(size width).
The result of the division is the pixel density (Pixels Per Inch).

Jacopo
[a href=\"index.php?act=findpost&pid=223969\"][{POST_SNAPBACK}][/a]

Exactly right...  think of it like this, the "resolution" (ppi) is the resolution of the document.  The "document" on the web is actually the display.  The display resolution is what determines the pixels-per-inch, so you give it a number of pixels, say 96, and it will display at one inch.  Right?

How the thing gets displayed on the monitor is just dertemined by the number of pixels, not the pixels per inch.

[pcox]

Jacopo -
You are saying that the image assumes a physical size on a monitor, which is not true. It is only in output to physical media (not a screen) that the image assumes a particular size.

But, after rendering (on monitor or on printer), the image acquires a physical size, as is fixed the device size

PPI has no effect for web browsing or any other sort of computer display, which was the original point, which was demonstrated by my collection of three images a couple of posts ago - all at different PPIs, but all display exactly the same way on the screen. It is the pixel dimensions alone that determine their size on this medium.

The reason PPI isn't taken into account for screen display is that on a monitor, the PPI is fixed - and every monitor is different. A 26" monitor with a resolution of 1920x1200 will display everything at 73.84PPI (1920/26). A 24" monitor with the same resolution will be 80PPI. You can't cram the monitor pixels closer together, or push them further apart.

On paper, the effective resolution is much higher because we don't have a predefined pixel size. The printer has a maximum DPI (not the same as PPI) that it can produce, and using more or less of that capability you can spread the image over more or less of the page by spreading the pixels of the digital image further apart, or pressing them closer together. This is probably grossly oversimplified, but you get the idea.

Peter

[edit: After re-reading Jacopo's posts, I think part of the problem here might be a language barrier - and we may both be saying the same thing. If so - my apologies.]

[jbrembat]

You are saying that the image assumes a physical size on a monitor, which is not true. It is only in output to physical media (not a screen) that the image assumes a particular size.

Why do you think that a monitor is not a physical media?
Can you measure it? Of course.
Can you measure the image size? Of course.

It is the pixel dimensions alone that determine their size on this medium.

As I said pixel is adimensional until you render it as one or many dots.

The reason PPI isn't taken into account for screen display is that on a monitor, the PPI is fixed - and every monitor is different. A 26" monitor with a resolution of 1920x1200 will display everything at 73.84PPI (1920/26). A 24" monitor with the same resolution will be 80PPI. You can't cram the monitor pixels closer together, or push them further apart.

24" or 26" are the measure of the diagonal.
But it's true that the dots (DPI) are rendered at a fix PPI value (DPI=PPI).
If the screen resolution is 1920, then you can display a 1920 width image.

But the rendering application fix the image size, and it can go up or down from 1920 (resampling), before passing the image to the graphic card.

A printer can work at different output resolutions (DPI)  (not many, generally 2).
As you set the printer quality, the driver sets the corresponding DPI and PPI value.

So, after setting the printer preferences, there is no difference between printer and monitor.The DPI value is fixed, the PPI value is fixed.

The ultimate rendering application for printer is the driver. The driver satisfies the request for a print size, so resampling is performed if the PPI value is different from the expected one.

On paper, the effective resolution is much higher because we don't have a predefined pixel size.

The DPI value can be equal to the PPI value. This is true for contone printers.
For inkjet printers,there is a difference. Ink colors are limited, so a dithering is applied to try to get a visual appearence similar to the original color. This explains why the DPI value is  bigger than the PPI value.

After re-reading Jacopo's posts, I think part of the problem here might be a language barrier - and we may both be saying the same thing. If so - my apologies

May be.

Jacopo

[pcox]

Jacopo, you're saying the same thing as me here in every respect except for one thing - you still seem to claim that saving an image at different PPI values (in the Photoshop 'Image Size' dialog, for example) will result in a different appearance on screen.

Is that the case? Are you saying that saving an image that is 800 pixels wide at different PPI values will affect screen display? If not, then we're in violent agreement and can go our merry ways.

Peter

[jbrembat]

Jacopo, you're saying the same thing as me here in every respect except for one thing - you still seem to claim that saving an image at different PPI values (in the Photoshop 'Image Size' dialog, for example) will result in a different appearance on screen.

Is that the case? Are you saying that saving an image that is 800 pixels wide at different PPI values will affect screen display? If not, then we're in violent agreement and can go our merry ways.

Peter
[a href=\"index.php?act=findpost&pid=224025\"][{POST_SNAPBACK}][/a]

Peter, the only way to change the pixel density is: resampling (adding or subtracting pixels)
In other words: modifying the width/height of the image.

I think we agree.

Jacopo

[Alaska]

"June 2008 PC users now have the availability of Safari (from Apple) or Firefox 3, both of which support colour management. Unfortunately Firefox 3 currently needs colour management enabling..."

http://www.northlight-images.co.uk/article...management.html