Could new .heic file replace .jpg in future?

[Scottelly]

I posted this in another forum, but I thought I would link to it here, since it seems to apply to this forum too:

Loading…

www.dpreview.com

I think the new HEIF (high efficiency image file) is a good idea, after learning a little about it. I mean with 10 bit color in images, fewer artifacts, and less data in the compressed images, it seems like a winner to me . . . in the long run - and both Nokia AND Apple seem to be behind it too. If they can get Microsoft or Google behind it, we might see it become more and more popular in the future.

What do YOU think?

 

[J A C S]

There are many formats supposedly better than JPEG. This is yet another one which will not see a wide use.

Having said that, I only skimmed through the technical info page and did not find an explanation about the encoding algorithm.

 

[Joofa]

I posted this in another forum, but I thought I would link to it here, since it seems to apply to this forum too:

https://www.dpreview.com/forums/thread/4169271#forum-post-59699757

I think the new HEIF (high efficiency image file) is a good idea, after learning a little about it. I mean with 10 bit color in images, fewer artifacts, and less data in the compressed images, it seems like a winner to me . . . in the long run - and both Nokia AND Apple seem to be behind it too. If they can get Microsoft or Google behind it, we might see it become more and more popular in the future.

What do YOU think?

As JACS pointed out in another response there are several formats already out there. As an example, there is this OpenEXR format by ILM - founded by George Lucas of Star Wars fame:

http://www.openexr.com/

I believe EXR format has support for floating points, and also 'whiter than white', over saturated colors.

BTW, JPG is technically an algorithm. The file format that JPEG uses is JFIF.

There is this

--
Dj Joofa
http://www.djjoofa.com

 

[Mark S Abeln]

How the heck to you pronounce "heic"? You gotta give things simple, memorable names.

The time has passed, I think, for a more efficient image encoder. Disk space is so cheap that numerous companies are giving it away with their cloud services, and internet bandwidth is constantly increasing at lower costs.

One advantage of JPEG is it's near universial support: we can rely on JPEG being supported in just about every image processing application, web browser, and any type of document-creation software.

Code libraries for handling JPEGs are mature, debugged, and widely available for every system so adding JPEG support to a new app is fairly trivial.

JPEG does just about everything needed, and where it is lacking, we have other mature formats to fall back on, such as TIFF.

Now all this becomes irrelevant if the technology is actually needed. I've heard reports that JPEGs can exhibit banding on high dynamic range monitors, but I haven't seen that myself. As these devices become more commonplace, then a new format may very well be desirable. During a transition period, web servers could very well down-convert a heic file to JPEG for devices that don't support it.

 

[Scottelly]

How the heck to you pronounce "heic"? You gotta give things simple, memorable names.

The time has passed, I think, for a more efficient image encoder. Disk space is so cheap that numerous companies are giving it away with their cloud services, and internet bandwidth is constantly increasing at lower costs.

One advantage of JPEG is it's near universial support: we can rely on JPEG being supported in just about every image processing application, web browser, and any type of document-creation software.

Code libraries for handling JPEGs are mature, debugged, and widely available for every system so adding JPEG support to a new app is fairly trivial.

JPEG does just about everything needed, and where it is lacking, we have other mature formats to fall back on, such as TIFF.

Now all this becomes irrelevant if the technology is actually needed. I've heard reports that JPEGs can exhibit banding on high dynamic range monitors, but I haven't seen that myself. As these devices become more commonplace, then a new format may very well be desirable. During a transition period, web servers could very well down-convert a heic file to JPEG for devices that don't support it.

 

[Scottelly]

I posted this in another forum, but I thought I would link to it here, since it seems to apply to this forum too:

https://www.dpreview.com/forums/thread/4169271#forum-post-59699757

I think the new HEIF (high efficiency image file) is a good idea, after learning a little about it. I mean with 10 bit color in images, fewer artifacts, and less data in the compressed images, it seems like a winner to me . . . in the long run - and both Nokia AND Apple seem to be behind it too. If they can get Microsoft or Google behind it, we might see it become more and more popular in the future.

What do YOU think?

As JACS pointed out in another response there are several formats already out there. As an example, there is this OpenEXR format by ILM - founded by George Lucas of Star Wars fame:

http://www.openexr.com/

I believe EXR format has support for floating points, and also 'whiter than white', over saturated colors.

BTW, JPG is technically an algorithm. The file format that JPEG uses is JFIF.

There is this

 

[hjulenissen]

I posted this in another forum, but I thought I would link to it here, since it seems to apply to this forum too:

https://www.dpreview.com/forums/thread/4169271#forum-post-59699757

I think the new HEIF (high efficiency image file) is a good idea, after learning a little about it. I mean with 10 bit color in images, fewer artifacts, and less data in the compressed images, it seems like a winner to me . . . in the long run - and both Nokia AND Apple seem to be behind it too. If they can get Microsoft or Google behind it, we might see it become more and more popular in the future.

What do YOU think?

 

[dosdan]

The "edit list" feature mentioned in the "HEIF File Playback Options" near the end of http://nokiatech.github.io/heif/technical.html#table-2 seems an interesting playback option. HEIF doesn't seem to be a full-fledged video format. But I'd like a video container format that had that capability. Take for example a video of a 90 min. soccer match. I could imagine an option to just play incidents, saves and goals from this, perhaps with slo-mo repeats (either via frame-repetition or variable frame-playback-rate) of certain portions. This EDL, or rather a Playback Decision List, would all be stored within the video container and a playback program would show extra options if it detected its presence.

Dan.

 

[BobORama]

Oh, well, if Nokia AND Apple are behind it.

Personally we should be forced, by law, to use MIFF for everything. If only because I love Image Magick that much.

-- Bob
http://bob-o-rama.smugmug.com -- Photos
http://www.vimeo.com/boborama/videos -- Videos
http://blog.trafficshaper.com -- Blog

 

[Enginel]

jpeg supported 12 bit since... forever. But most libraries don't even implement it, because almost nobody needs it.

 

[Tommi K1]

How the heck to you pronounce "heic"? You gotta give things simple, memorable names.

The time has passed, I think, for a more efficient image encoder. Disk space is so cheap that numerous companies are giving it away with their cloud services, and internet bandwidth is constantly increasing at lower costs.

Disk space might be cheap for photographers who shoot 20 frames a week.

Shoot a 32GB a day and you will be suffering on the go that where you are going to put all the files as you can't buy 1-4TB drives all the time in pairs.

I have faster than usual bandwidth on my mobile (12MiB/s down and 4MiB/s up) at home (25MiB/s up and 45MiB/s down) most of the time and even that is too slow to transfer data over network than just a few files.

Today if you want to manipulate data, it is SSD on external drives, a HDD RAID connections etc and still we are waiting a lot of times transferring data across locations and places.

Transferring 15TB worth of data to Japan example is still far faster just to put on the airplane with a person and then get it done. Safer as well.

Now, go to the typical mobile connections and other network problems etc and hell can break loose very very easily!

The question really is, how much can we improve a small data savings for the image quality? JPEG is already so good that even raw files are almost useless for common edit requirements. So improving again something very tiny pixels in expense of totally new file format etc is just not worth it.

Those who things that they have too much empty space and too wide network bandwidth can go and shoot uncompressed TIFF or BMP and be happy.

 

[TKinVA]

Betteridge's law of headlines is one name for an adage that states: "Any headline that ends in a question mark can be answered by the word no."

--

Art from the air

 

[BakserZ]

The "edit list" feature mentioned in the "HEIF File Playback Options" near the end of seems an interesting playback option. HEIF doesn't seem to be a full-fledged video format. But I'd like a video container format that had that capability. Take for example a video of a 90 min. soccer match. I could imagine an option to just play incidents, saves and goals from this, perhaps with slo-mo repeats (either via frame-repetition or variable frame-playback-rate) of certain portions. This EDL, or rather a Playback Decision List, would all be stored within the video container and a playback program would show extra options if it detected its presence.

https://www.iseepassword.com/convert-heic-to-jpg.html

Dan.

Using your method I successfully transferred photos from my mobile phone to my computer, The most important thing is that the sharpness of the image is not impaired ,

 

[MediaArchivist]

I'm still waiting for jpeg2000 to replace jpg.

 

[Sympa]

Plain-old-JPG is good enough for what it is. If we need better, there is uncompressed for images (storage and bandwidth being cheap these days).

Images are probably not worth optimizing for any further for most use cases - though some work is done by the big web companies (Facbook/Google).

 

[Entropy512]

Plain-old-JPG is good enough for what it is. If we need better, there is uncompressed for images (storage and bandwidth being cheap these days).

Images are probably not worth optimizing for any further for most use cases - though some work is done by the big web companies (Facbook/Google).

I think we're approaching the point at which plain-old 8-bit JPEG might no longer be good enough.

For years we've had the limitation of sRGB displays, with only a small handful of displays being capable of more and hence no need for a standardized format.

Now, high dynamic range wide-gamut displays are becoming common for TVs and there's finally a standard for HDR PC displays. We're coming to the point where we need an image format that supports them, and that image format really should have at least 10 bits/color. (10 bits/color with a gamma curve applied is probably enough.)

 

[hjulenissen]

Plain-old-JPG is good enough for what it is. If we need better, there is uncompressed for images (storage and bandwidth being cheap these days).

Images are probably not worth optimizing for any further for most use cases - though some work is done by the big web companies (Facbook/Google).

I think we're approaching the point at which plain-old 8-bit JPEG might no longer be good enough.

For years we've had the limitation of sRGB displays, with only a small handful of displays being capable of more and hence no need for a standardized format.

Now, high dynamic range wide-gamut displays are becoming common for TVs and there's finally a standard for HDR PC displays. We're coming to the point where we need an image format that supports them, and that image format really should have at least 10 bits/color. (10 bits/color with a gamma curve applied is probably enough.)

Jpeg supports 12 bits per primary and any color space/gamma as far as I can recall.

For capture, jpeg is just fine for convenience. For quality, I would go for raw.

For distribution, HEIF might make it easier to exploit the wave of HDR/bt2020 that the video distribution is going through.

-h

 

[Entropy512]

Plain-old-JPG is good enough for what it is. If we need better, there is uncompressed for images (storage and bandwidth being cheap these days).

Images are probably not worth optimizing for any further for most use cases - though some work is done by the big web companies (Facbook/Google).

I think we're approaching the point at which plain-old 8-bit JPEG might no longer be good enough.

For years we've had the limitation of sRGB displays, with only a small handful of displays being capable of more and hence no need for a standardized format.

Now, high dynamic range wide-gamut displays are becoming common for TVs and there's finally a standard for HDR PC displays. We're coming to the point where we need an image format that supports them, and that image format really should have at least 10 bits/color. (10 bits/color with a gamma curve applied is probably enough.)

Jpeg supports 12 bits per primary and any color space/gamma as far as I can recall.

For capture, jpeg is just fine for convenience. For quality, I would go for raw.

For distribution, HEIF might make it easier to exploit the wave of HDR/bt2020 that the video distribution is going through.

-h

At least all software I've seen won't do more than 8 bits for JPEG - if it supports more than 8 bits, it's not widely deployed or standardized.

It's one of those things where if something is optional in a standard, you may frequently see so many people leave it out that it may as well not exist.

The only JPEG I've seen that supported 12 bits was JPEG2000. If I choose "jpeg" output in darktable - 8 bits is the only option.

I think the only reason HEIF has a chance to succeed are two reasons:

1) As you say, taking advantage of the wave of HDR/Rec.2020/Rec.2100 being deployed, since it's basically a single intra frame of codecs that are already required.

2) Apple is pushing it which will greatly help its deployment.

 

[hjulenissen]

Plain-old-JPG is good enough for what it is. If we need better, there is uncompressed for images (storage and bandwidth being cheap these days).

Images are probably not worth optimizing for any further for most use cases - though some work is done by the big web companies (Facbook/Google).

I think we're approaching the point at which plain-old 8-bit JPEG might no longer be good enough.

For years we've had the limitation of sRGB displays, with only a small handful of displays being capable of more and hence no need for a standardized format.

Now, high dynamic range wide-gamut displays are becoming common for TVs and there's finally a standard for HDR PC displays. We're coming to the point where we need an image format that supports them, and that image format really should have at least 10 bits/color. (10 bits/color with a gamma curve applied is probably enough.)

Jpeg supports 12 bits per primary and any color space/gamma as far as I can recall.

For capture, jpeg is just fine for convenience. For quality, I would go for raw.

For distribution, HEIF might make it easier to exploit the wave of HDR/bt2020 that the video distribution is going through.

-h

At least all software I've seen won't do more than 8 bits for JPEG - if it supports more than 8 bits, it's not widely deployed or standardized.

It's one of those things where if something is optional in a standard, you may frequently see so many people leave it out that it may as well not exist.

Loading…

www.w3.org

ITU/CCITT Rec. T.81 1992:

«For DCT-based processes, two alternative sample precisions are specified: either 8 bits or 12 bits per sample. Applications which use samples with other precisions can use either 8-bit or 12-bit precision by shifting their source image samples appropriately. The baseline process uses only 8-bit precision. DCT-based implementations which handle 12-bit source image samples are likely to need greater computational resources than those which handle only 8-bit source images. Consequently in this Specification separate normative requirements are defined for 8-bit and 12-bit DCT-based processes.»

In practice, the sRGB 8-bit narrowing in done in the JFIF standard has been sufficient for most applications up until now.

The only JPEG I've seen that supported 12 bits was JPEG2000. If I choose "jpeg" output in darktable - 8 bits is the only option.

I think the only reason HEIF has a chance to succeed are two reasons:

1) As you say, taking advantage of the wave of HDR/Rec.2020/Rec.2100 being deployed, since it's basically a single intra frame of codecs that are already required.

2) Apple is pushing it which will greatly help its deployment.

 

[hjulenissen]

Loading…

www4.cs.fau.de

«We support both 8- and 12-bit data precision, but this is a compile-time choice rather than a run-time choice; hence it is difficult to use both precisions in a single application.»