Lossy output with FFMPEG JPEG 2000

[dmkr]

Hi guys,

I'm trying to achieve a lossy JPEG 2000 output with FFMPEG, but no success so far.

Using this command line:

ffmpeg -i input.dpx -pix_fmt yuv420p -vcodec libopenjpeg output.jp2

As a result I get lossless output, which is a default setting for JPEG 2000. I tried -b:v and -q:v, but they both have no impact to the output.

Does anyone know a command that changes the quality/compress the output?

Any kind of help is really appreciated. Thank you!

[poisondeathray]

try -lowres 10 . I assume 0 is lossless

ffmpeg -fullhelp

jpeg2000 AVOptions:
-lowres <int> .D.V.... Lower the decoding resolution by a power of two (from 0 to 32) (default 0)

ffmpeg -codecs

DEVILS jpeg2000 JPEG 2000 (decoders: jpeg2000 libopenjpeg ) (encoders: jpeg2000 libopenjpeg )

Not sure if there is any difference is between -c:v libopenjpeg vs. -c:v jpeg2000

[dmkr]

Thank you for you answer!

Tried using -lowres to the output that gave me an error "This is not an encoding option". -Lowres can only be apllied to the input.

-c:v jpeg2000 is an experimental encoder by FFMPEG developers, it's advised not to use it at the current state. FFMPEG uses -c:v libopenjpeg by defauult.

[poisondeathray]

libopenjpeg AVOptions:
-format <int> E..V.... Codec Format (from 0 to 2) (default 2)
j2k E..V....
jp2 E..V....
-profile <int> E..V.... (from 0 to 4) (default 0)
jpeg2000 E..V....
cinema2k E..V....
cinema4k E..V....
-cinema_mode <int> E..V.... Digital Cinema (from 0 to 3) (default 0)
off E..V....
2k_24 E..V....
2k_48 E..V....
4k_24 E..V....
-prog_order <int> E..V.... Progression Order (from 0 to 4) (default 0)
lrcp E..V....
rlcp E..V....
rpcl E..V....
pcrl E..V....
cprl E..V....
-numresolution <int> E..V.... (from 1 to INT_MAX) (default 6)
-numlayers <int> E..V.... (from 1 to 10) (default 1)
-disto_alloc <int> E..V.... (from 0 to 1) (default 1)
-fixed_alloc <int> E..V.... (from 0 to 1) (default 0)
-fixed_quality <int> E..V.... (from 0 to 1) (default 0)

You can try one of the other switches, try changing from default value. The other ones probably won't do anything, try these

-disto_alloc <int> E..V.... (from 0 to 1) (default 1)
-fixed_alloc <int> E..V.... (from 0 to 1) (default 0)
-fixed_quality <int> E..V.... (from 0 to 1) (default 0)

[dmkr]

Nope, these don't change anything.

[poisondeathray]

What about -numlayers ?

The openjpeg documentation has -r for compression ratio which talks about "layers" (of course -r in ffmpeg is frame rate), where 1 is lossless
http://code.google.com/p/openjpeg/wiki/DocJ2KCodec

[poisondeathray]

I believe the switch is -compression_level

http://forum.doom9.org/showthread.php?t=166632

Higher values seems to produce smaller sized files, like a quantizer value

[El Heggunte]

^ Yes, -compression_level does the trick

As a side note, openjpeg compresses worse than proprietary solutions. From a 1136x640 photo, ffmpeg created a 987kB lossless file, whereas the jurassic LEAD J2K Photoshop plugin produced a 757kB lossless output.

[poisondeathray]

^ Yes, -compression_level does the trick

As a side note, openjpeg compresses worse than proprietary solutions. From a 1136x640 photo, ffmpeg created a 987kB lossless file, whereas the jurassic LEAD J2K Photoshop plugin produced a 757kB lossless output.

Did you use the same color subsampling with LEAD ? He's using 420

[El Heggunte]

^ Yes, -compression_level does the trick

As a side note, openjpeg compresses worse than proprietary solutions. From a 1136x640 photo, ffmpeg created a 987kB lossless file, whereas the jurassic LEAD J2K Photoshop plugin produced a 757kB lossless output.

Did you use the same color subsampling with LEAD ? He's using 420

Yes, 4:4:4 for both ffmpeg and PSP 7.04 (in other words, NO subsampling at all ^.^ ).

[dmkr]

Thanks a lot for your help! The -compression_level flag does indeed reduce the image quality / file size. The only thing that botheres me with it is that it's not a defined scale, the -compression_level range goes 0-9999999999999.

My intention is to compare HEVC vs. JPEG 2000 encoder. Especially with higher bit depths in combination with different chroma subsampling. And I kind of miss a common shared value, like dB value or a bitrate, that would allow me to compare the encoder efficiency. Such an option seems not to be working in FFMPEG.

If you know any other JPEG 2000 encoders worth trying out, let me know about it. I already tried OpenJPEG and JasPer but the input formats are pretty limited, which either don't support higher bit depths or are RGB.

[El Heggunte]

If you know any other JPEG 2000 encoders worth trying out, let me know about it.

MainConcept Reference. It will output to YUV color space if you feed it with YUV video, otherwise the output will be in RGB, or even in XYZ (Digital Cinema). Notice: the open-source decoders display YUV MJ2 in black and white , at least on my machines

[dmkr]

If you know any other JPEG 2000 encoders worth trying out, let me know about it.

MainConcept Reference. It will output to YUV color space if you feed it with YUV video, otherwise the output will be in RGB, or even in XYZ (Digital Cinema). Notice: the open-source decoders display YUV MJ2 in black and white , at least on my machines

Thanks for this hint. TotalCode Studio is a nice piece of software. But it seems like it only accepts 4:2:0 YUV files with 8 bit depth as input

[poisondeathray]

Thanks a lot for your help! The -compression_level flag does indeed reduce the image quality / file size. The only thing that botheres me with it is that it's not a defined scale, the -compression_level range goes 0-9999999999999.

My intention is to compare HEVC vs. JPEG 2000 encoder. Especially with higher bit depths in combination with different chroma subsampling. And I kind of miss a common shared value, like dB value or a bitrate, that would allow me to compare the encoder efficiency. Such an option seems not to be working in FFMPEG.

Instead of ffmpeg, why no use openjpeg directly ? opj_compress accepts 16bit TIFF , and has -q in dB , -r for compression ratio

[dmkr]

Thanks a lot for your help! The -compression_level flag does indeed reduce the image quality / file size. The only thing that botheres me with it is that it's not a defined scale, the -compression_level range goes 0-9999999999999.

My intention is to compare HEVC vs. JPEG 2000 encoder. Especially with higher bit depths in combination with different chroma subsampling. And I kind of miss a common shared value, like dB value or a bitrate, that would allow me to compare the encoder efficiency. Such an option seems not to be working in FFMPEG.

Instead of ffmpeg, why no use openjpeg directly ? opj_compress accepts 16bit TIFF , and has -q in dB , -r for compression ratio

It seems like opj_compress has no option to vary bit depth, therefore I'll have to use numerous inputs with different bit depth. Well, that shouldn't be a problem.

However, if I use a subsampling factor it streches the image size... Also it applies the same subsampling factor to all 3 components. Maybe I'm using a wrong command line. In case there is a possibility to use different subsampling factor for each component (seems that this function only works with raw images) then I couldn't find it...

[poisondeathray]

It seems like opj_compress has no option to vary bit depth, therefore I'll have to use numerous inputs with different bit depth. Well, that shouldn't be a problem.

However, if I use a subsampling factor it streches the image size... Also it applies the same subsampling factor to all 3 components. Maybe I'm using a wrong command line. In case there is a possibility to use different subsampling factor for each component (seems that this function only works with raw images) then I couldn't find it...

I don't know, I guess you're back to ffmpeg and fiddling with the -compression_level

You should be doing bit depth and chroma sampling conversions beforehand anyways (or at least in a more controlled manner), because some programs dither between bit depth conversion automatically, some use different algorithms, and others do not dither at all. Some use different chroma subsampling algorithms. That will adversely affect your testing since they are uncontrolled variables

Are you doing this for still image comparison , or actual video (sequences ? )

[dmkr]

I don't know, I guess you're back to ffmpeg and fiddling with the -compression_level

You should be doing bit depth and chroma sampling conversions beforehand anyways (or at least in a more controlled manner), because some programs dither between bit depth conversion automatically, some use different algorithms, and others do not dither at all. Some use different chroma subsampling algorithms. That will adversely affect your testing since they are uncontrolled variables

Are you doing this for still image comparison , or actual video (sequences ? )

I'm quite happy with the FFMPEG result, it covers all the functions I need. Just that there is no other compression option implemented for JPEG 2000 is kinda strange.

The files come from a raw video sequence, which were extracted to DPX frames. That's what I'm dealing with. If I could get a single properly compressed JPEG 2000 frame that would be enough for me.

[poisondeathray]

The files come from a raw video sequence, which were extracted to DPX frames. That's what I'm dealing with. If I could get a single properly compressed JPEG 2000 frame that would be enough for me.

Now by "raw video sequence" do you really mean camera raw ? Or some compressed raw variant like redcode? How did you do the debayering ?

So are you now using the dpx seqence as the new "source" to test jpeg2000 vs. HEVC? DPX isn't that ideal because there tends to be a lot of interpretation issues between different software (levels, black and white points, log vs. linear)

So you're doing single frame still comparisons ? No temporal compression? Because HEVC will wipe the floor with jpeg2000 for any video sequence

[El Heggunte]

Thanks for this hint. TotalCode Studio is a nice piece of software. But it seems like it only accepts 4:2:0 YUV files with 8 bit depth as input

I know nothing about TotalCode --- but as for MCR, I've always fed it with fake AVIs created through ffdshow's makeAVIS.

[dmkr]

Video was recorded with Sony PMW-F55 in raw mode. The output is a MXF file, which was edited with Sony Raw Viewer (setting tone curve, color space, export data etc..). DPX is surely not ideal, but it's the best option Sony Raw Viewer offers (UHD image size, 16 bit depth).

Since HEVC HM reference software only works with uncompressed YUV files, I converted DPX frames into YUV (color space conversion). The YUV sequence was used to generate HEVC Intra video sequence with high bitrates (100 - 500 Mbit/s). So, no frame prediction, every single frame gets same compression ratio.

I wouldn't mind having a M2J sequnce for JPEG 2000, but still frame (jp2) would be also fine. Of course HEVC is much better than JPEG 2000, but how much better that's thing I try to find out.

[dmkr]

I know nothing about TotalCode --- but as for MCR, I've always fed it with fake AVIs created through ffdshow's makeAVIS.

It seems that TotalCode is just a new name for MCR. Good software, but doesn't support all of the functions I need.