[FFmpeg-soc] Support for JPEG 2000 image files
Michael Niedermayer
michaelni at gmx.at
Sun Dec 13 20:58:59 CET 2009
On Sun, Dec 13, 2009 at 05:09:47PM +0100, Peter B. wrote:
> Thanks for the tip!
>
> I must admit that I haven't focused on JPEG-LS, because according to
> information about it I've found on the web, it seemed that JPEG-LS is
> less known/supported/used than JPEG 2000.
well ffmpeg supports jpeg-ls encoding & decoding, the code for that is
just ~1000 lines:
89 397 2977 jpegls.c
377 1397 11414 jpeglsdec.c
395 1534 12249 jpeglsenc.c
41 193 1266 jpeglsdec.h
111 396 3014 jpegls.h
1013 3917 30920 total
compare that to our unfinished jpeg2000 implementation:
384 1498 9557 dwt.c
389 1558 14122 j2k.c
1075 3923 36767 j2kdec.c
1045 3862 36837 j2kenc.c
108 445 2975 mqc.c
93 343 2396 mqcdec.c
119 381 2738 mqcenc.c
63 297 2038 dwt.h
234 901 7335 j2k.h
75 287 1902 mqc.h
3585 13495 116667 total
or libopenjpeg through which ffmpeg supports jpeg2000 currently
187 695 4491 bio.c
125 608 3956 bio.h
190 729 4872 cio.c
86 478 3106 cio.h
40 63 682 CMakeLists.txt
661 3146 19332 dwt.c
113 681 4514 dwt.h
121 547 3827 event.c
58 367 2455 event.h
64 366 2384 fix.h
87 378 3038 image.c
48 288 1854 image.h
119 605 3554 int.h
2630 9970 77828 j2k.c
525 2548 17030 j2k.h
76 421 2730 j2k_lib.c
75 389 2632 j2k_lib.h
700 2398 18777 jp2.c
176 800 5752 jp2.h
155 701 4659 jpt.c
75 390 2701 jpt.h
132 700 3859 mct.c
98 571 3860 mct.h
542 1757 13951 mqc.c
197 903 5952 mqc.h
307 905 8443 openjpeg.c
751 3311 24093 openjpeg.h
102 380 2957 opj_includes.h
1078 3585 32188 pi.c
152 837 5503 pi.h
87 372 2653 raw.c
100 538 3514 raw.h
1210 4372 30369 t1.c
295 1246 7667 t1_generate_luts.c
147 680 5198 t1.h
402 6209 27167 t1_luts.h
721 2724 19951 t2.c
102 586 3901 t2.h
1409 6049 51062 tcd.c
270 1293 8793 tcd.h
213 740 5180 tgt.c
114 608 4012 tgt.h
14740 64934 460447 total
>
> Theoretically it seems a valuable alternative to JPEG 2000 by offering
> faster processing and better compression [1] in many cases, but there
> are some issues that I'd have to evaluate about JPEG-LS:
>
> - lack of applications/tools that support it (e.g. ImageMagick can't do
> JPEG-LS [2])
As you can see above jpeg-ls is quite a bit simpler thus also simpler to
add. And we have a jpegls implementation while we dont have a finished
jpeg2000 one not counting the use of external libs like libopenjpeg.
imagemagick surely could use ours ...
> - partial data retrieval for thumbnail previews (possible with JPEG-LS?)
you can decompress the whole frame and scale it down, you can also store
that image in the video file in some user data or in a seperate file
for faster access.
You can even store the whole video as lossless jpeg-ls + in a seperate file
some lossy codec like mjpeg, h263 or mpeg4 or h264 (maybe at a lower
resolution). The options are many
Also as you mentioned support, how many jpeg2000 implementations support
retrieving lower resolution content? ive not checked but i would suspect
that not all support this.
ffmpeg supports btw, decoding most DCT based codecs in lower resolution.
>
> For a long-term archive it is important to use open standards that are
> as widespread as possible. I was even surprised that given the age of
> JPEG 2000 it's still not supported as seamlessly as I'd expected. :(
j2k is complex, we had 2 students during SOC fail getting the code in
useable shape.
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
it is not once nor twice but times without number that the same ideas make
their appearance in the world. -- Aristotle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-soc/attachments/20091213/86339c30/attachment.pgp>
More information about the FFmpeg-soc
mailing list