Recherche avancée

Sur d’autres sites (9895)

• Lossless compression of a sequence of similar grayscale images

  25 octobre 2020, par damien200

  I would like to have the best compression ratio of a sequence of similar grayscale images. I note that I need an absolute lossless solution (meaning I should be able to check it with an hash algorithm).

  


  What I tried

  


  I had the idea to convert my images into a video because there is a chronology between images. The encoding algorithm would compress using the fact that not all the scene change between 2 pictures. So I tried using ffmpeg but I had several problems due to sRGB -> YUV colorspace compression. I didn't understand all the thing but it's seems like a nightmare.

  


  Example of code used :

  


  ffmpeg -i %04d.png -c:v libx265 -crf 0 video.mp4 #To convert into video
ffmpeg -i video.mp4 %04d.png #To recover images



  


  My second idea was to do it by hand with imagemagik. So I took the first image as reference and create a new image that is the difference between image1 and image2. Then I tried to add the difference image with the image 1 (trying to recover image 2) but it didn't work. Noticing the size of the recreated picture, it's clear that the image is not the same. I think there was an unwanted compression during the process.

  


  Example of code used :

  


  composite -compose difference 0001.png 0002.png diff.png #To create the diff image
composite -compose difference 0001.png diff.png recover.png #To recover image 2


  


  Do you have any idea about my problem ?
And why I don't manage to do the perfect recover with iamgemagik ?

  


  Thanks ;)

  


  Here are 20 samples images : https://cloud.damien.gdn/d/f1a7954a557441989432/

  


• Merge commit ’15a29c39d9ef15b0783c04b3228e1c55f6701ee3’

  26 mars 2014, par Michael Niedermayer

  Merge commit ’15a29c39d9ef15b0783c04b3228e1c55f6701ee3’
  * commit ’15a29c39d9ef15b0783c04b3228e1c55f6701ee3’ :
  
    truehd : add hand-scheduled ARM asm version of mlp_filter_channel.
  Conflicts :
  
  	libavcodec/arm/Makefile
  
  	libavcodec/arm/mlpdsp_init_arm.c
  See : 87b128d5ef6aeb01cc8bba167c929c74cbf2e7c7
  
  Merged-by : Michael Niedermayer <michaelni@gmx.at>
  

  • [DH] libavcodec/arm/Makefile
  • [DH] libavcodec/arm/mlpdsp_armv5te.S
  • [DH] libavcodec/arm/mlpdsp_init_arm.c

• split video (avi/h264) on keyframe

  30 novembre 2012, par m.sr

  Hallo.

  I have a big video file. ffmpeg, tcprobe and other tool say, it is an h264-stream in an AVI-container.

  Now i'd like to cut out small chunks form the video.

  1. Problem : The index of the video seam corrupted/destroyed. I kind of fixed this via mplayer -forceidx -saveidx <indexfile> <bigvideofile></bigvideofile></indexfile>. The Problem here is, that I'm now stuck with mplayer/mencoder which can use this index file via -loadidx <indexfile></indexfile>. I have tried correcting the index like described in man aviindex (mplayer -frames 0 -saveidx mpidx broken.avi ; aviindex -i mpidx -o tcindex ; avimerge -x tcindex -i broken.avi -o fixed.avi), but this didn't fix my video - meaning that most tools i've tested couldn't search in the video file.

  2. Problem : I cut out parts of the video via following command : mencoder -loadidx in.idx -ss 8578 -endpos 20 -oac faac -ovc x264 -sws 9 -lavfopts format=mp4 -x264encopts <lotsofopts> -of lavf -vf scale=800:-10,harddup in.avi -o out.mp4</lotsofopts>. Now here the problem is, that some videos are corrupted at the beginning. I think this is because the fact, that i do not necessarily cut at keyframe.

  Questions :

  1. What is the best way to fix the index of an avi "inline" so that every tool can again work as expected with it ?

  2. How can i split at the keyframes ? Is there an mencoder-option for this ?

  3. Are Keyframes coming in a frequency ? How to find out this frequency ? (So with a bit of math it should be possible to calculate the next keyframe and cut there)

  4. Is ther perhaps some completely other way to split this movie ? Doing it by hand is no option, i've to cut out 1000+ chunks ...

  Thanks a lot !