Luminous Landscape Forum
Raw & Post Processing, Printing => Digital Image Processing => Topic started by: jule on September 23, 2008, 01:40:25 am
-
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 (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
-
Convert to sRGB and embed the profile.
-
sRGB - 72 dpi will do it.....
-
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
-
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
-
Modern browsers can read embedded profiles.
-
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
-
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
-
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
-
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
-
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]
-
Of course ppi does makes a difference when I set the image size to say 800 x 600 pixels @ 96 ppi.
-
Here's the same image, one at 72, the other at 96ppi.
(http://www.petercox.ie/thaw-72ppi.jpg)
(http://www.petercox.ie/thaw-96ppi.jpg)
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.
(http://www.petercox.ie/thaw-300ppi.jpg)
Peter
-
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
-
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.
-
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.]
-
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
-
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
-
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
-
"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 (http://www.northlight-images.co.uk/article_pages/web-browser-color-management.html)
-
"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 (http://www.northlight-images.co.uk/article_pages/web-browser-color-management.html)
[a href=\"index.php?act=findpost&pid=224076\"][{POST_SNAPBACK}][/a]
Thanks Alaska for the link, which I had come across before. It is good to see samples of images which have profiles embedded and not embedded, and their resultant display on my monitor. I obviously do not have colour management happening with my browser. I will download Firefox 3 and see what changes occur.
From what I can determine from the link above, there is no visual difference between the images with the Adobe 98 profile embedded and the one without. Similarly, there seems to not be a difference between the image with sRGB embedded and the one without. So the aim to embed a profile is obviously have browsers which can render the colours correctly of the image with the embedded profile. So... with browsers starting to adopt colour management, it is difficult when situations like this result. -
Update, June 21, 2008 : We've received a small but steady stream of reports, primarily from Mac users, that enabling colour management in Firefox 3 causes certain hues in pictures with embedded profiles to display differently than either Photoshop or Safari, and in some cases the difference has been described as dramatic and that Firefox seems to be the one rendering the affected colours incorrectly. We've not seen this problem, either in the release version of Firefox 3 nor in daily use of betas over the past several months, but it's becoming clear that some users' machines are affected and that it's negating the benefit of turning on colour management in the new Firefox.
.....so if embedding the profile is causing colour shifts with some users in this new development in colour management of the internet, the same question arises - should a profile be embeded? why or why not?
Julie
-
....management of the internet, the same question arises - should a profile be embeded? why or why not?.so if embedding the profile is causing colour shifts with some users in this new development in colour
Julie,
I don't know if there is a bug on Firefox color management.
But if the bug exists, I suppose it will be fixed.
Should a profile be embedded? Sure. It is beneficial for users which browser is color-managed.
Don't forget to upload sRGB images, as most of the monitors are sRGB-like.
Jacopo
-
Julie,
I don't know if there is a bug on Firefox color management.
But if the bug exists, I suppose it will be fixed.
Should a profile be embedded? Sure. It is beneficial for users which browser is color-managed.
Don't forget to upload sRGB images, as most of the monitors are sRGB-like.
Jacopo
[a href=\"index.php?act=findpost&pid=224229\"][{POST_SNAPBACK}][/a]
Thanks Jacopo and all those who contributed. Seems as if this is a time where colour management on the web is being addressed but still has a fair way to go.
Julie
-
I would appreciate some thoughts on the most appropriate way to prepare files for a web gallery
Prepare the files for the worst viewing conditions within your market. Embed the sRGB_IEC61966-2-1_withBPC.icc profile. Set files between 75-85 dpi and sharpen at 100% of viewing conditions. Be aware that Flash does not support ICC profiles (i.e., the Flash engine strips the profile from the image), and that certain php scripts do not support embedded ICC profiles. Test, test, test.
-
Prepare the files for the worst viewing conditions within your market. Embed the sRGB_IEC61966-2-1_withBPC.icc profile. Set files between 75-85 dpi and sharpen at 100% of viewing conditions. Be aware that Flash does not support ICC profiles (i.e., the Flash engine strips the profile from the image), and that certain php scripts do not support embedded ICC profiles. Test, test, test.
[a href=\"index.php?act=findpost&pid=225317\"][{POST_SNAPBACK}][/a]
Julie,
ignore the dpi (ppi is the correct term) advice. The PPI value embedded into the image file does'nt make any difference.
The image dimension (in pixels) must be compatible to screen resolution.
Jacopo
-
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?
Only two browsers will "see" the embedded profiles.
If you're concerned about speed for users and storage, the addition of the 4K used by the profile may be an issue. If you don't care that each image is that much larger (you're not uploading thousands of images), go ahead and embed, but it will make little difference to the vast majority of users because their browsers simply don't know they exist.
Of course, you have to currently convert to sRGB! There's no debate about that.
-
Be aware that Flash does not support ICC profiles (i.e., the Flash engine strips the profile from the image), and that certain php scripts do not support embedded ICC profiles. Test, test, test.
[a href=\"index.php?act=findpost&pid=225317\"][{POST_SNAPBACK}][/a]
Flash 10 does support this now.
-
The image dimension (in pixels) must be compatible to screen resolution.
And exactly what is that?
-
And exactly what is that?
[a href=\"index.php?act=findpost&pid=225518\"][{POST_SNAPBACK}][/a]
For example 800x600 pixel. Nothing to do with PPI.
Jacopo
-
For example 800x600 pixel. Nothing to do with PPI.
Yes, I agree. DPI is incorrect terminology when resizing an image in Photoshop -- PPI is correct. However, what I'm referring to is the pixel pitch (also known as dot pitch) of monitors (http://en.wikipedia.org/wiki/Dot_pitch). Back in the day, a pixel pitch of .3mm to .4mm was the norm. Today, monitors can have a much tighter pixel pitch. This resolution directly affects the image size. An image spec'd at 75 ppi will appear much smaller on a 1920×1200 monitor with a .27 ppi pitch, which corresponds to a native resolution of 94 ppi (if an image is to be best viewed that type of monitor, it should be spec'd at 94 ppi).
You said "The image dimension (in pixels) must be compatible to screen resolution". I'm saying there is no definitive global screen resolution, so an estimation must be made about the dot pitch of monitors your images will be viewed on.
-
Yes, I agree. DPI is incorrect terminology when resizing an image in Photoshop -- PPI is correct. However, what I'm referring to is the pixel pitch (also known as dot pitch) of monitors (http://en.wikipedia.org/wiki/Dot_pitch). Back in the day, a pixel pitch of .3mm to .4mm was the norm. Today, monitors can have a much tighter pixel pitch. This resolution directly affects the image size. An image spec'd at 75 ppi will appear much smaller on a 1920×1200 monitor with a .27 ppi pitch, which corresponds to a native resolution of 94 ppi (if an image is to be best viewed that type of monitor, it should be spec'd at 94 ppi).
You said "The image dimension (in pixels) must be compatible to screen resolution". I'm saying there is no definitive global screen resolution, so an estimation must be made about the dot pitch of monitors your images will be viewed on.
[a href=\"index.php?act=findpost&pid=225629\"][{POST_SNAPBACK}][/a]
The dot pitch value fix the size of a rendered pixel. I agree.
But this value is related to DPI value, not PPI value.
You cannot modify it changing the PPI value embedded in the image file.
If you are in doubt do the following simple test:
fix the PPI value to 1 and save the image =>IMG1
fix the PPI value to 1000 and save the image => IMG2
Do not resample, otherwise you are changing the image width and height.
The pixel-width(height) of IMG1 are equal to the pixel-width(height) of IMG2.
Now open IMG1 and IMG2 and check for difference.
For web publishing, it's more simple to think about screen resolution.
If you want to get audience from about all the surfers, you must remember that 800x600 is the resolution of the old 15' CRT.
Jacopo