Luminous Landscape Forum
Raw & Post Processing, Printing => Digital Image Processing => Topic started by: dreed on February 22, 2015, 05:05:11 am
-
With digital cameras capable of capturing 14 stops of DR, it seems a shame that the most portable image format used on the web is only 8bit - there's a lot of colour information being thrown away.
On top of that, screen manufacturers are increasingly producing wider gamut screens and with 4K content being drafted as 10bit, we can expect a larger number of screens will be developed to portray rec 2020 (or at least a wider gamut.)
JPEG is going to come up short pretty soon.
Is it time to start pushing vendors for a newer format such as BPG?
http://bellard.org/bpg/
-
JPEG supports 8-bits or 12-bits, although 12-bit is rarely used. However the newer JPEG 2000 supports any bit depth.
I've not read enough to know of relative technical advantages of BPG and JPEG 2000, but at present BPG has a few barriers to its adoption, including:
- It's not a formal standard approved by an international standards body, or (AFAIK) any heavyweight player. This matters as companies using a standard like to see someone reliable and stable "owning" and maintaining it.
- I believe there are patent issues. It uses some HEVC technology which is believed to be covered by various patents. It is likely that use of BPG may require patent licences, which are not free for HEVC and so probably wouldn't be free for BPC.
At the moment, I would have thought that JPEG 2000 is more likely as a replacement for jpeg, if and when that happens.
(HEVC is the next generation video coding, successor to H.264, also referred to as H.265.)
-
Why? whats wrong with Tiff if you want better quality. I don't see the point of making something thats worked well for ages obsolete. Remember the vast majority of people these day are looking at the net on small tablets, even a jpeg is plenty good enough for that.
-
With digital cameras capable of capturing 14 stops of DR, it seems a shame that the most portable image format used on the web is only 8bit - there's a lot of colour information being thrown away.
Hi,
That's not really what is happening. The 14-bit data is in linear gamma space. The 8-bit data is after a conversion to 1/gamma space. We need 14-bit linear gamma data to create 8-bits gamma pre-compensated data, e.g. 13-bit L* input would only get us 255 out of 256 levels (see here (http://www.brucelindbloom.com/LevelsCalculator.html)).
On top of that, screen manufacturers are increasingly producing wider gamut screens and with 4K content being drafted as 10bit, we can expect a larger number of screens will be developed to portray rec 2020 (or at least a wider gamut.)
Displays have totally different capabilities (exaggerated contrast emitting light) than printed output (practical maximum of 7 stops of dynamic range reflected light). Therefore, tonemapping will always be required for an optimal viewing experience, just as we do today (often helped by color profiles).
JPEG is going to come up short pretty soon.
Is it time to start pushing vendors for a newer format such as BPG?
http://bellard.org/bpg/
It certainly is something that makes sense, but it needs industry wide support for it to become something of importance.
Cheers,
Bart
-
...
I've not read enough to know of relative technical advantages of BPG and JPEG 2000, but at present BPG has a few barriers to its adoption, including:
...
- I believe there are patent issues. It uses some HEVC technology which is believed to be covered by various patents. It is likely that use of BPG may require patent licences, which are not free for HEVC and so probably wouldn't be free for BPC.
...
HEVC is also the compression algorithm for 4K video, so if your camera is using a chip to do 4K/HEVC then any license fees would presumably be also taken care of?
-
HEVC is also the compression algorithm for 4K video, so if your camera is using a chip to do 4K/HEVC then any license fees would presumably be also taken care of?
Not necessarily.
What happens generally is that for standards like MPEG or HEVC (which is technically MPEG-H Part 2 aka H.265) you get a patent pool. That is, there's an agreement by patent owners to put their patents into a "pool". If you want to use the standard, you take a licence to the pool, which gives you a licence to use all the patents (there might be many tens or even hundreds) in exchange for paying a royalty, and the royalties are shared among the companies with patents in the pool. In this case, a pool has been set up by MPEG-LA, who run most of the video patent pools.
However, when you take a licence to a patent pool, generally you get a field of use licence. That means a licence to use all the patents in the pool, but only for the purpose of using that standard.
In other words, if you wanted to use the same patents for another purpuse such as BPG, you might need a separate licence.
-
Why? whats wrong with Tiff if you want better quality. I don't see the point of making something thats worked well for ages obsolete. Remember the vast majority of people these day are looking at the net on small tablets, even a jpeg is plenty good enough for that.
There's no need to make JPEG obsolete. Rather it should be incorporated into a broader format spec that includes higher bit options. I haven't read up on JPEG 2000…maybe that's exactly what it does.
-Dave-
-
What about PNG? It has lossless compression and, if memory serves, supports 8 and 16 bits per channel for both grayscale and color. It supports an alpha channel and transparency - not useful for photos but for other types of images.
-
the most portable image format used on the web is only 8bit
JPEG will remain 'fit for purpose' until you get display systems capable of more than an 8bit display(print or screen).
-
RAW files are sensor-oriented.
JPEG files are display-oriented.
The two cannot easily be compared in terms of bits etc. If the in-camera processing suits your requirements, then I believe that JPEG is usually sufficient. If the in-camera processing does not suit your requirements, then why are you using JPEG in the first place?
It is possible to capture 16 bits worth of HDR photography, apply tonemapping and store the result as 8-bit JPEG with great (depending on your taste) results.
-h
-
Why? whats wrong with Tiff if you want better quality. I don't see the point of making something thats worked well for ages obsolete. Remember the vast majority of people these day are looking at the net on small tablets, even a jpeg is plenty good enough for that.
TIFF compression is terrible when compared to more modern algorithms.
-
JPEG will remain 'fit for purpose' until you get display systems capable of more than an 8bit display(print or screen).
And that's the whole point of this thread - with 4K comes a colour spec that utilises 10 bit colour and thus we're likely to see 10bit displays in the not too distant future.
-
And that's the whole point of this thread - with 4K comes a colour spec that utilises 10 bit colour and thus we're likely to see 10bit displays in the not too distant future.
While the spec seems promising, it remains to be seen how and if manufacturers choose to implement it. As always, one might expect the early adopters get to use bug-ridden and half-finished products. One might think that the added bits and adressable brightness range will be used for doing "generally bright" vs "generally dark" scenes initially (exploiting the adaptive iris/backlight commonly found in display technology) - something that seems to have little direct use in still-imagery.
I don't get your motivation as linear 12-14 bits can be had today from cameras by simply switching to "raw" files, and calibrated quality monitors can offer 10 bits (with some caveats and software/OS compability issues). Why should I care about the quality on the files that are least likely to provide quality (pre-baked camera files, today encoded as JPEG)?
-h
-
...
I don't get your motivation as linear 12-14 bits can be had today from cameras by simply switching to "raw" files, and calibrated quality monitors can offer 10 bits (with some caveats and software/OS compability issues). Why should I care about the quality on the files that are least likely to provide quality (pre-baked camera files, today encoded as JPEG)?
...
Whilst it is fine for you to have nice output on your calibrated monitor, what use are the extra bits when nobody else can benefit from them? When more people have displays with greater than 8 bit display capability (is will end up being the case) then it becomes a question of how do other people see what you see (or something close to that) and JPEG isn't the answer but JPEG2000 might.
-
Whilst it is fine for you to have nice output on your calibrated monitor, what use are the extra bits when nobody else can benefit from them? When more people have displays with greater than 8 bit display capability (is will end up being the case) then it becomes a question of how do other people see what you see (or something close to that) and JPEG isn't the answer but JPEG2000 might.
I am sorry, I thought that you were talking about in-camera file formats.
Yes, for (web) distribution, formats targeting higher DR might be nice. It seems to me, though, that UHD with rec.2020 will be primarily used for video playback (updated Bluray formats, Netflix etc). While "the web" seems to be largely moving to cellphones, where such quality increases might be expected to be way off.
Having a file format that produce manageable file sizes and larger DR without visible banding seems to be the least problem. Making website owners, browser/OS/display manufacturers conscious about calibrated and/or standard ways to do colors and image brightness seems to be a much larger problem?
-h
-
I am sorry, I thought that you were talking about in-camera file formats.
Yes, for (web) distribution, formats targeting higher DR might be nice. It seems to me, though, that UHD with rec.2020 will be primarily used for video playback (updated Bluray formats, Netflix etc). While "the web" seems to be largely moving to cellphones, where such quality increases might be expected to be way off.
Having a file format that produce manageable file sizes and larger DR without visible banding seems to be the least problem. Making website owners, browser/OS/display manufacturers conscious about calibrated and/or standard ways to do colors and image brightness seems to be a much larger problem?
I quite agree that a better still image encoding format is only part of the problem.
But 4K monitors will not be used only for video playback, and I doubt the web will become phone-only. Clearly phones and tablets are becoming much more important, but tablets have screen capabilities rivalling or exceeding many PCs these days (e.g. Galaxy Tab S is 2560 x 1600 and wider gamut than sRGB). The idea that people will want wide-gamut for movies but not for still images seems unlikely to me.
-
There have been multiple proposals to replace JPEG, including PNG and two that have been officially adopted as alternative standards by the standards group JPEG, but yet are widely ignored: JPEG 2000 and JPEG XR (http://en.wikipedia.org/wiki/JPEG_XR) proposed recently by Microsoft. None has made a dent in the dominant position of JPEG as a final display format, and indeed as the in-camera recording format for the vast majority of photography, and I doubt that BPG has the slightest chance. The best hope for progress is a backward compatible upgrade, like the most recent update of the existing JPEG standard to JPEG 9.1 (http://www.popphoto.com/news/2014/01/jpeg-standard-91-will-bring-12-bit-color-lossless-compression), which adds options for 12-bit encoding and lossless compression.
My reasons?:
1) The DR argument is mostly irrelevant even before that 12-bit upgrade of JPEG: as already mentioned, the 14-bit of some cameras and the 10 bits of coming displays is a linear scale, whereas JPEG is 8-bits on a gamma-corrected scale that assigns proportionately more levels in the shadows, so that it can hold more dynamic range than a 10-bit linear display, or even a 12-bit one.
2) Saving space is the other big argument for alternatives to traditional JPEG (better IQ at a given compressed file size or smaller files for a give IQ) but storage is becoming cheaper, smaller, and more abundant far faster than the resolution/DR needs of image files are growing, so the size argument is becoming less and less relevant.
3) JPEG is massively entrenched, so a backward compatible upgrade is the only approach with much hope of success. (Even JPEG 2000 and JPEG XR are not backward compatible.)
-
The two cannot easily be compared in terms of bits etc. If the in-camera processing suits your requirements, then I believe that JPEG is usually sufficient. If the in-camera processing does not suit your requirements, then why are you using JPEG in the first place?
Well said, totally agree. JPEG for it's intended usage is fine.
-
Not seeing any issues visual issues with JPEG an NEC PA272. Even one saved in ProPhoto RGB!
In what way is 10 bits for encoding data going to produce a visually superior image in terms of what we can actually see? 8 bits encoding (which defines 'colors values') produces colors we can't see either. In sRGB, it isn’t possible to see a difference between 2/255/240 and 1/255/240 as they have the same Lab values (90/-54/-8). Those two sets of values define 1 color.
-
1) The DR argument is mostly irrelevant even before that 12-bit upgrade of JPEG: as already mentioned, the 14-bit of some cameras and the 10 bits of coming displays is a linear scale, whereas JPEG is 8-bits on a gamma-corrected scale that assigns proportionately more levels in the shadows, so that it can hold more dynamic range than a 10-bit linear display, or even a 12-bit one.
10-bit: yes, 12-bit: no. As I understand it, 2.2 gamma encoded data in 8-bit jpeg can manage about 11-bits of DR.
2) Saving space is the other big argument for alternatives to traditional JPEG (better IQ at a given compressed file size or smaller files for a give IQ) but storage is becoming cheaper, smaller, and more abundant far faster than the resolution/DR needs of image files are growing, so the size argument is becoming less and less relevant.
Agreed, I don't think that's an issue.
3) JPEG is massively entrenched, so a backward compatible upgrade is the only approach with much hope of success. (Even JPEG 2000 and JPEG XR are not backward compatible.)
JPEG 9.1 is backwards compatible (9.1 decoders can read earlier spec jpegs) but not forward compatible (earlier decoders can't read 12-bit jpegs). In theory it would have been possible to make it forward compatible by including the 8-bit data as now, and new tags for the additional 4 bits, which earlier decoders would have ignored. That would be rather limiting though, and I don't think it's possible with the standard.
Arguably backward compatibility without forward compatibility might be of limited benefit. I mean: even without backward compatibility you can always write a decoder that decodes two or more standards. In the case of jpeg and jpeg 2000, for example, quite a lot of code would be common anyway.
-
In the case of jpeg and jpeg 2000, for example, quite a lot of code would be common anyway.
I have some practical knowledge of JPEG and some superficial knowledge of JPEG2k. This leads me to believe that the common code between the two would be very little. Perhaps some setup/teardown, scaling/colorspace conversion could be shared, but the core codecs seems to be totally different?
-h
-
Not seeing any issues visual issues with JPEG an NEC PA272. Even one saved in ProPhoto RGB!
Some photographers (myself included) use their monitor as a softproofing device. If you limit your monitor to 100:1 or 200:1 of CR, then >8bits may be irrelevant.
But what if your display (and content and viewing conditions) allowed for 1000:1 or 10000:1 CR (possibly doing some tricks like dynamic backlighting). At some point, gradations would be a)visible in hand-picked corner cases, b)visible in a large number of cases. My only reference is Poynton and 9 bits for 50:1 television quality, and the developer of a well-known open-source color calibration package saying something to the effect of "10 bits aint worth it".
-h
-
JPEG 9.1 is backwards compatible (9.1 decoders can read earlier spec jpegs) but not forward compatible (earlier decoders can't read 12-bit jpegs).
Agreed that JPEG 9.1 might not have the best possible compatibility with older JPEG; indeed I think it quite likely that the current JPEG will persist for a very long time, due to being an incumbent that is "good enough" for almost all users. One further point: oversampling and then down-sampling on display (like 24MP JPEG displayed on even 4K displays) also improves perceived DR over the "per pixel DR", so that is one way that even the current 8-bit JPEG can keep up with viewing needs, short of 100% pixel-peeping.
My point was only about the relative prospects of adoption for the various proposed replacement for current JPEG; the combination of some compatibility (including the potential for a phase-in of hardware support in newer devises) and the support of the the main standards body give JPEG 9.1 a lot more chance than the others.