Any plans to support .heic files in Fedora?

[Dusty Mabe]

Seems like Apple converted their phones over to using a new file format
to store pictures. I was copying some pictures from a phone and noticed
my linux box couldn't read them and they had an interesting extension .heic.

Looks like there is a new image format in town and we need the libheif and
libde265 libraries in order to read it according to the gimp plugin [1]. The
plugin docs say it should be included by default now in gimp but the gimp on
my f29 system says it can't read the file. This is probably because we don't
have the underlying libraries in Fedora.

Anybody been down this road? Is it as simple as getting the libraries in or
is there much more pain involved that I haven't discovered yet?

Thanks,
Dusty

[1] https://github.com/strukturag/heif-gimp-plugin

[Samuel Sieb]

On 11/26/18 8:58 PM, Dusty Mabe wrote:
>  Looks like there is a new image format in town and we need the
> libheif and
>  libde265 libraries in order to read it according to the gimp plugin [1]. The
>  plugin docs say it should be included by default now in gimp but the gimp on
>  my f29 system says it can't read the file. This is probably because we don't
>  have the underlying libraries in Fedora. 
They would have to be provided through rpmfusion.  I thought I saw a 
comment a while back that getting the libraries in was being worked on, 
but I could be mistaken.

[Richard W.M. Jones]

On Mon, Nov 26, 2018 at 09:08:17PM -0800, Samuel Sieb wrote:
>  On 11/26/18 8:58 PM, Dusty Mabe wrote:
>  >Looks like there is a new image format in town and we need the libheif and
>  >libde265 libraries in order to read it according to the gimp plugin [1]. The
>  >plugin docs say it should be included by default now in gimp but the gimp on
>  >my f29 system says it can't read the file. This is probably because we don't
>  >have the underlying libraries in Fedora.
>  
>  They would have to be provided through rpmfusion.  I thought I saw a
>  comment a while back that getting the libraries in was being worked
>  on, but I could be mistaken. 
Is there a license/patent problem?  Debian has libheif in the regular
channels, but I guess as it uses a video codec it may have a patent
problem.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/

[Tom Hughes]

On 27/11/2018 11:02, Richard W.M. Jones wrote:
>  On Mon, Nov 26, 2018 at 09:08:17PM -0800, Samuel Sieb wrote:
> > On 11/26/18 8:58 PM, Dusty Mabe wrote:
> >> Looks like there is a new image format in town and we need the libheif and
> >> libde265 libraries in order to read it according to the gimp plugin [1]. The
> >> plugin docs say it should be included by default now in gimp but the gimp on
> >> my f29 system says it can't read the file. This is probably because we
> don't
> >> have the underlying libraries in Fedora.
> >
> > They would have to be provided through rpmfusion.  I thought I saw a
> > comment a while back that getting the libraries in was being worked
> > on, but I could be mistaken.
>  
>  Is there a license/patent problem?  Debian has libheif in the regular
>  channels, but I guess as it uses a video codec it may have a patent
>  problem. 
The problem will probably be libde265 (which implements HEVC) rather
than libheif (which implements a container file format).

Tom

-- 
Tom Hughes (tom(a)compton.nu)
http://compton.nu/

[Leigh Scott]

Reviewers welcome.

https://bugzilla.rpmfusion.org/show_bug.cgi?id=5089
https://bugzilla.rpmfusion.org/show_bug.cgi?id=5090

[Dusty Mabe]

On 11/30/18 5:20 AM, Leigh Scott wrote:
>  Reviewers welcome.
>  
>  https://bugzilla.rpmfusion.org/show_bug.cgi?id=5089
>  https://bugzilla.rpmfusion.org/show_bug.cgi?id=5090 
Thanks Leigh. I see those have already made progress in code review. +1000

Is there a definitive reason why those are necessary to go in RPM fusion? Was 
Tom Hughes right?

Dusty

[Samuel Sieb]

On 12/3/18 1:42 PM, Dusty Mabe wrote:
>  On 11/30/18 5:20 AM, Leigh Scott wrote:
> > https://bugzilla.rpmfusion.org/show_bug.cgi?id=5089
> > https://bugzilla.rpmfusion.org/show_bug.cgi?id=5090
>  
>  Thanks Leigh. I see those have already made progress in code review. +1000
>  
>  Is there a definitive reason why those are necessary to go in RPM fusion? Was
>  Tom Hughes right? 
libheif depends on libde265 which can't be in the Fedora repo, so it 
can't be in the Fedora repo either.

[Leigh Scott]

>  On 11/30/18 5:20 AM, Leigh Scott wrote:
>  
>  Thanks Leigh. I see those have already made progress in code review. +1000
>  
>  Is there a definitive reason why those are necessary to go in RPM fusion? Was 
>  Tom Hughes right?
>  
>  Dusty 
This sums up the situation

http://gnome-apps.13852.n7.nabble.com/High-Efficiency-Image-File-Format-H...

[Andrew Lutomirski]

On Mon, Dec 3, 2018 at 3:56 PM Leigh Scott <leigh123linux(a)gmail.com&gt; wrote:

>  > On 11/30/18 5:20 AM, Leigh Scott wrote:
>  >
>  > Thanks Leigh. I see those have already made progress in code review.
>  +1000
>  >
>  > Is there a definitive reason why those are necessary to go in RPM
>  fusion? Was
>  > Tom Hughes right?
>  >
>  > Dusty
>
>  This sums up the situation
>
>
>
> http://gnome-apps.13852.n7.nabble.com/High-Efficiency-Image-File-Format-H...

IANAL, and I know basically nothing about codec patents, but it might be
worth noting that there are a whole bunch of video coding techniques that
are presumably completely unnecessary for decoding video *stills*, i.e.
I-frames.  Things like motion compensation are irrelevant if there's no
motion.

So it's at least slightly plausible that any patents in question wouldn't
apply to a heavily stripped down decoder that only implemented the parts of
the spec needed to decode HEIF.

[Dusty Mabe]

On 12/3/18 6:53 PM, Leigh Scott wrote:
> > On 11/30/18 5:20 AM, Leigh Scott wrote:
> >
> > Thanks Leigh. I see those have already made progress in code review. +1000
> >
> > Is there a definitive reason why those are necessary to go in RPM fusion? Was 
> > Tom Hughes right?
> >
> > Dusty
>  
>  This sums up the situation
>  
>
> http://gnome-apps.13852.n7.nabble.com/High-Efficiency-Image-File-Format-H...
Thanks! That helps a lot!

Dusty

[Leigh Scott]

>  On 11/30/18 5:20 AM, Leigh Scott wrote:
>  
>  Thanks Leigh. I see those have already made progress in code review. +1000 
The packages should be in the repo by the weekend.

https://koji.rpmfusion.org/koji/packageinfo?packageID=581
https://koji.rpmfusion.org/koji/packageinfo?packageID=582