Best file format for viewing images on web?

[Rechmbrs]

I'm new to the the forums but have 60 years of experience in photography. Started using my mother's Kodak Brownie.

I'm interested in having a conversation about which file format is best for Pixel peeping when the file is displayed on the web. My conclusion so far is PNG24 with JPG no compression next. It is too bad html etc will not display TIF 16 bits.

Like to hear your thoughts please.
RONC

[Manfred M]

Standard 8-bit jpeg using sRGB is the defacto standard for web images.

Most computer screens in use are sRGB with 8-bits per channel. Colour management is rather variable based on the browser used and the less well colour managed ones will "assume" sRGB so the wider colour spaces used in images will end up looking rather muddy.

[JBW]

I'm new to the the forums but have 60 years of experience in photography. Started using my mother's Kodak Brownie.

I'm interested in having a conversation about which file format is best for Pixel peeping when the file is displayed on the web. My conclusion so far is PNG24 with JPG no compression next. It is too bad html etc will not display TIF 16 bits.

Like to hear your thoughts please.
RONC

I tried various formats. Nobody could see any difference. They did however notice the increased time needed to open the file compared to JPEG.

[dje]

Hi Ron, welcome to CiC.

You mention pixel peeping so I am assuming you want to view the images at 100% magnification. The main thing with this is to retain the original pixel dimensions of the image when you post it on the web, ie don't downsize. A jpeg with a high quality setting and an embedded sRGB color profile should be fine. This will mean a fairly large file size of course and will mean slower load times on the web. Note also that some web applications may downsize the image automatically which is something to avoid if at all possible.

Dave

PS: I'm not sure that you can create a jpeg without compression. There is however a lossless compression option in the standard I believe.

[IzzieK]

Welcome to CiC....from St. Louis, Missouri. Hope you enjoy your stay here.

[JohnRostron]

I'm reading a lot about the WebP format. (I'm investigating html for mobile pages.) Has anyone any experience of WebP?

John

[george013]

I'm new to the the forums but have 60 years of experience in photography. Started using my mother's Kodak Brownie.

I'm interested in having a conversation about which file format is best for Pixel peeping when the file is displayed on the web. My conclusion so far is PNG24 with JPG no compression next. It is too bad html etc will not display TIF 16 bits.

Like to hear your thoughts please.
RONC

Do you've a monitor that's able to show 16 bits? And if so, what I doubt, than would you see a difference?


George

[DanK]

What's your workflow? That matters. For example, if you are shooting raw and pixel-peeping while the image is still in the raw conversion software, there is no reason to use any other file format. The software renders the raw image for you, and you can simply expand the image to pixel peep. If you have shot raw and are in a pixel editor like Photoshop, you can again pixel peep without saving the image. If you are shooting jpeg, the data loss has already occurred, so it won't matter: you can't regain it by saving in another format.

If you want to export or save the image to pixel peep on another monitor, then I agree with Manfred: you need to save it in the color space of the monitor, which is usually sRGB. Apart from that, I have a hunch that George is right: you may not be able to see any difference, assuming that you use jpeg with minimal compression. If you try it and find differently, post the results, as people would be interested.

[Manfred M]

+1 to George's comments.

When shooting in raw, most modern cameras give you 14-bit data that is converted to 16-bit for your computer to work on.

The bulk of the computer screens display 8-bit images and the high end AdobeRGB compliant ones are running 10-bit colour, so even best case, you can only see part of the total colour set that your camera captured.

I don't know what camera model you use, but most modern cameras tend to be in the 18+ MP range. Most computer displays are closer to 2MP range (1920 x 1080 or so), so the image has to be down-sized to display. Even the highest resolution screens are going to be in the 8MP range, (4k screens are 3840 x 2160 or so) and usually sRGB only, so the image is still going to be downsampled.

[Rechmbrs]

Hi guys,
I didn't abandon you but had a health problem. I'm going home in a few minutes and will respond to your posts. One of my doctors told me that the problem I'm having is like having your mother-in-law come to visit for a the weekend but she stays for two weeks. It never goes away.
Cheers,
RONC

[Rechmbrs]

Manfred,
Thanks for the response.
I agree with you and your concerns about color handling and monitors. I think we have color handling questions all through our work flows. We have other questions about every step from camera to the human eye viewing the image.
I hope we might be able to find ways to minimize the problems and hopefully we lay a methodology down to do that.
Follow on if you don't mind my preaching etc.
RONC

[Rechmbrs]

Brian,
Thanks for the response.
I've tried whatever methods of viewing images with great frustration. This part of the reason I initiated this thread. I'm hoping that your clear minds will help us to fine ways to minimize the frustration and increase our knowledge of what we are looking at. Personally the cost in time waiting to see something doesn't matter much if you see a benefit.
I think we see ways that will better our ways to see results.
RONC

[Rechmbrs]

Dave,
Thanks for the response.
To me pixel peeping is different at various stages within the work flow. Naturally on raw data I was to see what 14bits is giving me. But after all of the processing gyrations, 4 bits might be what to look at. I don't have an answer yet but hope we can fill in some of the holes.
I think Adobe JPG has an option to minimize the steps caused during the process use 10 as the parameter input. I prefer no compression!
If you have followed my responses above, I want us to talk through what is needed to view differences at the various stages.
RONC

[Rechmbrs]

Izzie,
Thanks for the welcome.
RONC

[Rechmbrs]

John,
Thanks for the response.
I've looked into WebP a bit and it seems to be another takeoff from JPG this time by Google. It is aimed at better compression with minimal damage to the data. Which probably means an easier way to view your images to get information from them. To compression should be nearly a dead issue unless you are well in the terabyte storage range. Not 1 or 2 tb but 100 or 500 tb.
Hang around.
RONC

[george013]

Dave,
Thanks for the response.
To me pixel peeping is different at various stages within the work flow. Naturally on raw data I was to see what 14bits is giving me. But after all of the processing gyrations, 4 bits might be what to look at. I don't have an answer yet but hope we can fill in some of the holes.
I think Adobe JPG has an option to minimize the steps caused during the process use 10 as the parameter input. I prefer no compression!
If you have followed my responses above, I want us to talk through what is needed to view differences at the various stages.
RONC

I'm pretty sure you can't tell the difference between a JPG, 12bit or 14bit so out off the camera. What you see on your screen is 8 bit. The main reason for using 12 or 14 bit RAW is for editing. Editing with a deeper bitdepth causes less artifacts.
Beside that you can't see a RAW-image. It has to be converted to a raster-image. That's the only mage that can be made visible with the used techniques. When you open a RAW image in a viewer you see either the embedded JPG or the result of a conversion from whatwever converter.

George

[Rechmbrs]

George,
Thanks for speaking out.
Keep in mind that the image is just a matrix of numbers. Therefore we can view the matrix in many ways not just as rasters. We can also prepare the matrix so that it fits various plotting schemes.
I hope to find what we need to understand the image both at different levels and at different steps in its history. You have any ideas? Everyone tells why we can't but I want to know why and can we dream away to understand it.

I don't smoke or drink strange stuff! I was born this way.

RONC

[Rechmbrs]

George,
See my response below please.
RONC

[Manfred M]

Manfred,
Thanks for the response.
I agree with you and your concerns about color handling and monitors. I think we have color handling questions all through our work flows. We have other questions about every step from camera to the human eye viewing the image.
I hope we might be able to find ways to minimize the problems and hopefully we lay a methodology down to do that.
Follow on if you don't mind my preaching etc.
RONC

I don't mind your preaching at all, but there is no single "right answer" to this question, but there are some methodologies that tend to have wider acceptance than others. The real issue to me is driven by the final use of the image.

Regardless, a colour managed workflow is generally regarded as a "best practice" to go from camera capture to final output.

If I target having a print output created on a high end colour photo printer, I will use a different workflow than I would if I am preparing an image for display on the internet, where I have no control of the device the image will be viewed on. For the print I have a process have capture to print control, when I do my own printing. When I post on the web, I have absolutely no control of the device where my image is viewed on, so I tend to produce output that both helps protect my intellectual property, can be viewed on as many different devices as possible and loads relatively quickly.

[Rechmbrs]

Dan,
Thanks for the response.
I keep the images as much the same as when recorded. I shoot a Pentax K 1 at 36+mp of 14 bits per color and often use Pixel Shift Resolution mode to fill in the Bayer pattern with real data. This is a lot of data but gives excellent results. The more data means more ways for things to go wrong. That is one reason why I am working on this thread. I'm hoping to find ways to verify the quality of the image data so I don't have to to go back and fix or kludge something to cover the problem.
Bring your ideas along.
RONC