Fiji: Save as Movie

[Knecht, David]

Is there any reason that the codec options in Save as/Movie are so limited?  It would be nice to be able to use H264 and other codecs for compressing movies.  Thanks-Dave

David Knecht, Ph.D.
Professor and Head of Core Microscopy Facility
Department of Molecular and Cell Biology
U-3125
91 N. Eagleville Rd.
University of Connecticut
Storrs, CT 06269
860-486-2200
860-486-4331 (fax)






--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Michael Schmid]

On Jan 22, 2014, at 19:14, Knecht, David wrote:

> Is there any reason that the codec options in Save as/Movie are so limited?  It would be nice to be able to use H264 and other codecs for compressing movies.  Thanks-Dave

Hi Dave,

there would be two problems saving movies as H264 in the core of ImageJ:
 - License issues - ImageJ is completely public domain. I am not aware of any H264 implementation in Java compatible with this.
 - Complexity and size - I think we should keep ImageJ nifty and lean (due to the small size, it starts very quickly); an H264 codec would bloat ImageJ a lot.

If someone wants to write a plugin (where these limitations would not apply), based on some java H264 library on the web, it would be welcome!

In the meanwhile, please use a converter like ffmpeg...

Michael

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[dscho]

Hi Michael,

On Thu, 23 Jan 2014, Michael Schmid wrote:

> On Jan 22, 2014, at 19:14, Knecht, David wrote:
>
> > Is there any reason that the codec options in Save as/Movie are so
> > limited?  It would be nice to be able to use H264 and other codecs for
> > compressing movie
>
> there would be two problems saving movies as H264 in the core of ImageJ:
>  - License issues - ImageJ is completely public domain. I am not aware
>  of any H264 implementation in Java compatible with this.

There is even more to it. While H.264 allows distribution of free video
without paying royalties, the same is distinctly *not* true for free
encoders/decoders:
http://en.wikipedia.org/wiki/H.264#Patent_licensing

That does imply that you would have to pay royalties if you distribute
software encoding H.264, you have to pay up, even if you release the code
into the public domain. (There are really complicated rules and exceptions
and agreements and waivers around H.264, so you *might* get away with
distributing an encoder implementing only a very limited set of features,
but you need to ask a lawyer, so even that is not free -- great job
security for people of the law!).

>  - Complexity and size - I think we should keep ImageJ nifty and lean
>  (due to the small size, it starts very quickly);

ImageJ does not start very quickly... it does have to do a lot in the
background, such as parsing all the plugins and generating the menu
structure. The size of ImageJ has little to do with the startup time,
therefore, but the number of plugins does.

Also, a plugin that implements encoding with 100 different codecs would
slow down the startup time exactly as much as a plugin implementing only
one codec.

Of course, the size would be affected if one were to make said complex
plugin part of the core ImageJ. That is why many functions needed by many,
but not needed by many more, are not part of core ImageJ.

Actually, there is another very good reason why high-complexity plugins
need to stay out of the core: already with the current set of core
plugins, development is impeded: the more complexity, the more bugs.

> an H264 codec would bloat ImageJ a lot.

I fully agree. H.264 is a very complicated standard, coming with quite a
lot of parameters and a number of "profiles" that already select sensible
combinations of parameters.

> If someone wants to write a plugin (where these limitations would not
> apply), based on some java H264 library on the web, it would be welcome!

I must caution that anybody who writes such a plugin might run into legal
trouble. Better check that out first, before spending a *lot* of time to
implement it!

Ciao,
Dscho

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Michael Schmid]

Hi Johannes,

yes, I agree, the H264 licensing issues are quite complicated and a pain.

Using the OpenH264 code might be a way out, as it is under the BSD license, and Cisco pays the H264 licensing costs. Unfortunately, OpenH264 is in C++, not Java, and platform-specific.

Probably one could access it from an ImageJ plugin with JNI, but that's nothing I am familiar with. If someone wants to do it, I would not discourage him or her.

The main caveat seems to be that one must not distribute OpenH264 with a plugin, every user would have to download it separately.

See http://www.openh264.org/faq.html

Michael
________________________________________________________________
On Jan 23, 2014, at 19:14, Johannes Schindelin wrote:

> Hi Michael,
>
> On Thu, 23 Jan 2014, Michael Schmid wrote:
>
>> On Jan 22, 2014, at 19:14, Knecht, David wrote:
>>
>>> Is there any reason that the codec options in Save as/Movie are so
>>> limited?  It would be nice to be able to use H264 and other codecs for
>>> compressing movie
>>
>> there would be two problems saving movies as H264 in the core of ImageJ:
>> - License issues - ImageJ is completely public domain. I am not aware
>> of any H264 implementation in Java compatible with this.
>
> There is even more to it. While H.264 allows distribution of free video
> without paying royalties, the same is distinctly *not* true for free
> encoders/decoders:
> http://en.wikipedia.org/wiki/H.264#Patent_licensing
>
> That does imply that you would have to pay royalties if you distribute
> software encoding H.264, you have to pay up, even if you release the code
> into the public domain. (There are really complicated rules and exceptions
> and agreements and waivers around H.264, so you *might* get away with
> distributing an encoder implementing only a very limited set of features,
> but you need to ask a lawyer, so even that is not free -- great job
> security for people of the law!).
>
>> - Complexity and size - I think we should keep ImageJ nifty and lean
>> (due to the small size, it starts very quickly);
>
> ImageJ does not start very quickly... it does have to do a lot in the
> background, such as parsing all the plugins and generating the menu
> structure. The size of ImageJ has little to do with the startup time,
> therefore, but the number of plugins does.
>
> Also, a plugin that implements encoding with 100 different codecs would
> slow down the startup time exactly as much as a plugin implementing only
> one codec.
>
> Of course, the size would be affected if one were to make said complex
> plugin part of the core ImageJ. That is why many functions needed by many,
> but not needed by many more, are not part of core ImageJ.
>
> Actually, there is another very good reason why high-complexity plugins
> need to stay out of the core: already with the current set of core
> plugins, development is impeded: the more complexity, the more bugs.
>
>> an H264 codec would bloat ImageJ a lot.
>
> I fully agree. H.264 is a very complicated standard, coming with quite a
> lot of parameters and a number of "profiles" that already select sensible
> combinations of parameters.
>
>> If someone wants to write a plugin (where these limitations would not
>> apply), based on some java H264 library on the web, it would be welcome!
>
> I must caution that anybody who writes such a plugin might run into legal
> trouble. Better check that out first, before spending a *lot* of time to
> implement it!
>
> Ciao,
> Dscho
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html