search

ilia3101 / MLV-App

All in one MLV processing app.
https://mlv.app/
GNU General Public License v3.0
283 stars 29 forks source link

Fix bugs in liblj92 implementation. #151

Closed FaresMehanna closed 5 years ago

FaresMehanna commented 5 years ago

Fixes Introduced:

MLV Tests: Input: 2x MLV file with 10bit lossless compression with sizes 138 MB - 2.51 GB. Implementation without "Adjust Bits" Outputs: lossless dng files with total size of 204 MB - 3.1 GB. Implementation with "Adjust Bits" Outputs: lossless dng files file with total size of 62.2 MB - 1.47 GB. Difference ratio: 0.305 - 0.474.

Test file used to test the implementation: here Note, the test file works with the old API of liblj92, the one without the "int components". ` int lj92_open(lj92 lj, uint8_t data, int datalen, int width,int height, int bitdepth); Not this one int lj92_open(lj92 lj, uint8_t data, int datalen, int width,int height, int bitdepth, int components); `

bouncyball-git commented 5 years ago

This patch indeed gives better compression for real life MLVs.

Small example:

Uncompressed MLV             : 170,758,752 bytes
Compressed with original code: 109,123,729 bytes
Compressed with patched code : 108,619,437 bytes

This should not break anything (modifies only encoder).

@FaresMehanna: Thank you for this PR. I guess you are familiar with lj92 encoding/decoding quite a bit. Do you have any Idea about decoder, could it be optimized for even better speed?

masc4ii commented 5 years ago

@bouncyball-git & @ilia3101 : would you like to pull? I would like to commit something different too, but don't want to irritate github again... 😄

FaresMehanna commented 5 years ago

@bouncyball-git Thank you for the feedback. I'm more interested in the encoding part since I'm implementing it in the FPGA for axiom cameras. I read the decoding part and it is quite good, there are few parts that can be optimized if you don't use linearization but it won't make big difference. If you are more interested in the time taken in decoding rather than the throughput, it is possible to preprocess MLV file and split each frame to number of parts, and those parts can be decoded in parallel. If -even little- optimizations in decoding part is needed I can remove some unnecessary code, add some caching and try to do more optimization in "nextdiff" function.

masc4ii commented 5 years ago

This should not break anything (modifies only encoder).

So I'll pull now. @FaresMehanna : thank you for this PR!

bouncyball-git commented 5 years ago

@FaresMehanna

If you are more interested in the time taken in decoding rather than the throughput, it is possible to preprocess MLV file and split each frame to number of parts, and those parts can be decoded in parallel.

You mean decode each component separately?

If -even little- optimizations in decoding part is needed I can remove some unnecessary code, add some caching and try to do more optimization in "nextdiff" function.

Would be very nice, thanks :)

ilia3101 commented 5 years ago

@FaresMehanna

I'm more interested in the encoding part since I'm implementing it in the FPGA for axiom cameras.

Very impressive!

And cool to have someone from Axiom project here. is Axiom going to use MLV format? So Axiom cameras will be compatible with MLV App? 😍😍😍

FaresMehanna commented 5 years ago

Very sorry for my late reply!

@bouncyball-git

You mean decode each component separately?

It depends on what you mean by "component", in LJ92, if the frame is encoded in one scan even with multiple components they will not be separated components, they will be interleaved and a sequential decoding method will be used.

To make it parallel, one way is to create multiple scans and decode each one separately, but I don't know if this method is supported in DNG or not. another way which is supported in DNG is to reset the encoding operation after some pixels, by that you can detect the marks in advance, and start several decoders to decode each part separately, if some background process can recompress the files with different LJ92 parameters, it may be faster to decode in the future.

If -even little- optimizations in decoding part is needed I can remove some unnecessary code, add some caching and try to do more optimization in "nextdiff" function.

Would be very nice, thanks :)

I have looked online and there is a good library in dng sdk to encode/decode LJ92 images, I have yet to test and benchmark it to check how good/bad it is in comparison to the implemented one. I will keep you updated.

FaresMehanna commented 5 years ago

@ilia3101

And cool to have someone from Axiom project here.

I think I am the newest member in Axiom project 😄. I was influenced by your work on canon cameras. If hacking cameras got us that far, what if we build one?

is Axiom going to use MLV format? So Axiom cameras will be compatible with MLV App? 😍😍😍

I believe yes! last year Supragya did a research and concluded that MLV will be good. here is the research. We will know for sure once any of (USB3.0/emmc/SATA) modules get ready.

bouncyball-git commented 5 years ago

@FaresMehanna: Understood. Thanks for reply.

ilia3101 commented 5 years ago

@ilia3101

And cool to have someone from Axiom project here.

I think I am the newest member in Axiom project :smile:. I was influenced by your work on canon cameras. If hacking cameras got us that far, what if we build one?

Completely agree about building a camera. Also can anyone 'join' the Axiom project? (Opencine looks interesting :wink: )

is Axiom going to use MLV format? So Axiom cameras will be compatible with MLV App? :heart_eyes::heart_eyes::heart_eyes:

I believe yes! last year Supragya did a research and concluded that MLV will be good. here is the research. We will know for sure once any of (USB3.0/emmc/SATA) modules get ready.

This is very good to hear! And thanks for the link.