Recherche avancée

Sur d’autres sites (5158)

• FFMPEG Inverts colors when converting tiff pictures to png

  1er juin 2021, par Mounia Jaiti

  We need to convert thousands of tiff pictures to png. To accomplish that we are using FFMPEG. We've noticed recently that for very few of the converted files (in png), the colors are inverted : the input tiff file is all black and white (a technical drawing in black with a white background), and the output png file is white and black (the drawing becomes white and the background becomes black). Of course we don't want that, we need the colors to stay the same.

  


  Here is the command we are using :

  


  ffmpeg -y -v warning -i in_file.tif out_file.png


  


  We've tested the 'negate' parameter on those files, and the pictures are correctly converted. But we can't apply this parameter to all of the input tiff files.
Here is the command with the negate parameter :

  


  ffmpeg -y -v verbose -i input.tif -vf negate output.png


  


  The Code Java we're using :

  


              String ffmpegPath="/Users/user11/ffmpeg//ffmpeg";&#xA;            List<string> commandArgs = new ArrayList<string>();&#xA;            commandArgs.add(ffmpegPath);&#xA;            //overwrite output file if it exists&#xA;            commandArgs.add("-y");      &#xA;            commandArgs.add("-v");&#xA;            commandArgs.add("verbose");&#xA;            //set input file &#xA;            commandArgs.add("-i"); &#xA;            commandArgs.add(picture.getAbsolutePath());&#xA;            commandArgs.add(dest.getAbsolutePath());&#xA;            &#xA;            String cmd = "";&#xA;            for(String cmdArg : commandArgs) {&#xA;                cmd &#x2B;= cmdArg &#x2B; " ";&#xA;            }&#xA;&#xA;&#xA;</string></string>

  


  Logs for tif having the bug :

  


  
31, 2021 2:15:51 PM 
INFO: Executing : /Users/user11/ffmpeg/ffmpeg -y -v verbose -i /Users/user11/ffmpeg/input.tif /Users/user11/ffmpeg/output.png 
May 31, 2021 2:15:51 PM 
INFO: ReencodePicture output: ffmpeg version 4.4-tessus  https://evermeet.cx/ffmpeg/  Copyright (c) 2000-2021 the FFmpeg developers
May 31, 2021 2:15:51 PM 
INFO: ReencodePicture output:   built with Apple clang version 11.0.0 (clang-1100.0.33.17)
May 31, 2021 2:15:51 PM 
INFO: ReencodePicture output:   configuration: --cc=/usr/bin/clang --prefix=/opt/ffmpeg --extra-version=tessus --enable-avisynth --enable-fontconfig --enable-gpl --enable-libaom --enable-libass --enable-libbluray --enable-libdav1d --enable-libfreetype --enable-libgsm --enable-libmodplug --enable-libmp3lame --enable-libmysofa --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenh264 --enable-libopenjpeg --enable-libopus --enable-librubberband --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvmaf --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxavs --enable-libxvid --enable-libzimg --enable-libzmq --enable-libzvbi --enable-version3 --pkg-config-flags=--static --disable-ffplay
May 31, 2021 2:15:51 PM 
INFO: ReencodePicture output:   libavutil      56. 70.100 / 56. 70.100
May 31, 2021 2:15:51 PM 
INFO: ReencodePicture output:   libavcodec     58.134.100 / 58.134.100
May 31, 2021 2:15:51 PM 
INFO: ReencodePicture output:   libavformat    58. 76.100 / 58. 76.100
May 31, 2021 2:15:51 PM 
INFO: ReencodePicture output:   libavdevice    58. 13.100 / 58. 13.100
May 31, 2021 2:15:51 PM 
INFO: ReencodePicture output:   libavfilter     7.110.100 /  7.110.100
May 31, 2021 2:15:51 PM 
INFO: ReencodePicture output:   libswscale      5.  9.100 /  5.  9.100
May 31, 2021 2:15:51 PM 
INFO: ReencodePicture output:   libswresample   3.  9.100 /  3.  9.100
May 31, 2021 2:15:51 PM 
INFO: ReencodePicture output:   libpostproc    55.  9.100 / 55.  9.100
May 31, 2021 2:15:51 PM 
INFO: ReencodePicture output: [tiff_pipe @ 0x7fa7f6008200] parser not found for codec tiff, packets or times may be invalid.
May 31, 2021 2:15:51 PM 
INFO: ReencodePicture output:     Last message repeated 1 times
May 31, 2021 2:15:51 PM 
INFO: ReencodePicture output: Input #0, tiff_pipe, from '/Users/user11/ffmpeg/input.tif':
May 31, 2021 2:15:51 PM 
INFO: ReencodePicture output:   Duration: N/A, bitrate: N/A
May 31, 2021 2:15:51 PM 
INFO: ReencodePicture output:   Stream #0:0: Video: tiff, 1 reference frame, monob, 2008x2481 [SAR 1:1 DAR 2008:2481], 25 fps, 25 tbr, 25 tbn, 25 tbc
May 31, 2021 2:15:51 PM 
INFO: ReencodePicture output: Stream mapping:
May 31, 2021 2:15:51 PM 
INFO: ReencodePicture output:   Stream #0:0 -> #0:0 (tiff (native) -> png (native))
May 31, 2021 2:15:51 PM 
INFO: ReencodePicture output: Press [q] to stop, [?] for help
May 31, 2021 2:15:51 PM 
INFO: ReencodePicture output: [graph 0 input from stream 0:0 @ 0x7fa7f4c08300] w:2008 h:2481 pixfmt:monob tb:1/25 fr:25/1 sar:1/1
May 31, 2021 2:15:51 PM 
INFO: ReencodePicture output: Output #0, image2, to '/Users/user11/ffmpeg/output.png':
May 31, 2021 2:15:51 PM 
INFO: ReencodePicture output:   Metadata:
May 31, 2021 2:15:51 PM 
INFO: ReencodePicture output:     encoder         : Lavf58.76.100
May 31, 2021 2:15:51 PM 
INFO: ReencodePicture output:   Stream #0:0: Video: png, 1 reference frame, monob(progressive), 2008x2481 (0x0) [SAR 1:1 DAR 2008:2481], q=2-31, 200 kb/s, 25 fps, 25 tbn
May 31, 2021 2:15:51 PM 
INFO: ReencodePicture output:     Metadata:
May 31, 2021 2:15:51 PM 
INFO: ReencodePicture output:       encoder         : Lavc58.134.100 png
May 31, 2021 2:15:51 PM 
INFO: ReencodePicture output: frame=    1 fps=0.0 q=0.0 size=N/A time=00:00:00.00 bitrate=N/A speed=   0x    
May 31, 2021 2:15:51 PM 
INFO: ReencodePicture output: No more output streams to write to, finishing.
May 31, 2021 2:15:51 PM 
INFO: ReencodePicture output: [AVIOContext @ 0x7fa7f4c14180] Statistics: 0 seeks, 1 writeouts
May 31, 2021 2:15:51 PM 
INFO: ReencodePicture output: frame=    1 fps=0.0 q=-0.0 Lsize=N/A time=00:00:00.04 bitrate=N/A speed=1.31x    
May 31, 2021 2:15:51 PM 
INFO: ReencodePicture output: video:37kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown
May 31, 2021 2:15:51 PM 
INFO: ReencodePicture output: Input file #0 (/Users/user11/ffmpeg/input.tif):
May 31, 2021 2:15:51 PM 
INFO: ReencodePicture output:   Input stream #0:0 (video): 1 packets read (18100 bytes); 1 frames decoded; 
May 31, 2021 2:15:51 PM 
INFO: ReencodePicture output:   Total: 1 packets (18100 bytes) demuxed
May 31, 2021 2:15:51 PM 
INFO: ReencodePicture output: Output file #0 (/Users/user11/ffmpeg/output.png):
May 31, 2021 2:15:51 PM 
INFO: ReencodePicture output:   Output stream #0:0 (video): 1 frames encoded; 1 packets muxed (38013 bytes); 
May 31, 2021 2:15:51 PM 
INFO: ReencodePicture output:   Total: 1 packets (38013 bytes) muxed
May 31, 2021 2:15:51 PM 
INFO: ReencodePicture output: [AVIOContext @ 0x7fa7f4f041c0] Statistics: 18100 bytes read, 0 seeks
May 31, 2021 2:15:51 PM 
INFO: BinaryRepositoryHelper.convertPixTo ffmpeg Process returned : java.lang.UNIXProcess@27ddd392, ended with code 0, and returned in 160 ms, out=/Users/user11/ffmpeg/output.png exists=true







  


  So our questions are :

  


  

  1. Is there a way to identify the tiff files that will be converted to png with inverted colors ? So that we can know to which files the 'negate' parameter must be applied.

  


  2. Are there any other FFMPEG parameter that we can use.

  


  


  This issue has been driving us mad for the last couple of days. Any help would be highly appreciated.
Thanks.

  


  Example of Tif picture

  


  https://drive.google.com/file/d/1U1a91gTk1gaJb-XAPavNq6UhmjWXZjbM/view?usp=sharing

  


• Of ctors and dtors

  18 février 2011, par Multimedia Mike — Programming, Sega Dreamcast

  I haven’t given up on the Sega Dreamcast programming. I was able to compile a bunch of homebrew code for the DC many years ago and I can’t make it work anymore. Again, I was working with a purpose-built, open source RTOS named KallistiOS (or KOS). I can make the programs compile but not run. I had ELF files left over from years ago which still executed. But when I tried to build new ELF files, no luck— the programs crashed before even reaching my main() function.

  I found the problem : ELF files are comprised of a number of sections and 2 of these sections are named ’.ctors’ and ’.dtors’ which stand for constructors and destructors. The KOS RTOS performs a manual traversal of .ctors section during program initialization and this is where things go bad. The traversal code doesn’t seem to account for a .ctors section that only contains a single entry. I commented out the function that does the traversal and programs started to work, at least until it was time to exit the program and return control to the program loader. That’s when the counterpart .dtors section traversal code ran and demonstrated the same problem. I’ll exhibit the problematic code at the end of this post.

  So I’m finally tinkering with Sega Dreamcast programming once again and with a slightly better grasp of software engineering than the first time I did this.

  Portable and Compatible C ?
  If nothing else, this low-level embedded stuff exposes you to some serious toolchain arcana, the likes of which you will likely never see working strictly in the desktop arena.

  Still, this exercise makes me wonder why C code from a decade ago doesn’t compile reliably now. Part of it is because gcc has gotten stricter about the syntax it will accept. In the case of this specific crashing problem, I suspect it comes down to a difference in the way the linker generates the final ELF file. I’ve written a list of items I have had to modify in the KOS codebase in order to get it to compile on more recent gcc versions. I wonder if it would be worth publishing the specifics, or if anyone would ever find the information useful ? Oh, who am I kidding ? Of course I’ll write it up, perhaps publish a new version of the code, if only because that’s the best chance I have of finding my own work again some years down the road.

  Problematic C Code
  See if this code makes any sense to you. It somehow traverse a list of 32-bit function pointers (in different directions, depending on constructors or destructors), executing each in turn. However, it appears to fall over if the list of pointers consists of a single entry.
  

  PLAIN TEXT

  C :

  1. typedef void (*fptr)(void) ;
  2.  
  3. static fptr ctor_list[1] __attribute__((section(".ctors"))) = { (fptr) -1 } ;
  4. static fptr dtor_list[1] __attribute__((section(".dtors"))) = { (fptr) -1 } ;
  5.  
  6. /* Call this to execute all ctors */
  7. void arch_ctors() {
  8.     fptr *fpp ;
  9.  
  10.     /* Run up to the end of the list (defined by crtend) */
  11.     for (fpp=ctor_list + 1 ; *fpp != 0 ; ++fpp)
  12.          ;
  13.  
  14.     /* Now run the ctors backwards */
  15.     while (—fpp> ctor_list)
  16.         (**fpp)() ;
  17. }
  18.  
  19. /* Call this to execute all dtors */
  20. void arch_dtors() {
  21.     fptr *fpp ;
  22.  
  23.     /* Do the dtors forwards */
  24.     for (fpp=dtor_list + 1 ; *fpp != 0 ; ++fpp )
  25.         (**fpp)() ;
  26. }

• Decoding VP8 On A Sega Dreamcast

  20 février 2011, par Multimedia Mike — Sega Dreamcast, VP8

  I got Google’s libvpx VP8 codec library to compile and run on the Sega Dreamcast with its Hitachi/Renesas SH-4 200 MHz CPU. So give Google/On2 their due credit for writing portable software. I’m not sure how best to illustrate this so please accept this still photo depicting my testbench Dreamcast console driving video to my monitor :

  
  
  

  Why ? Because I wanted to try my hand at porting some existing software to this console and because I tend to be most comfortable working with assorted multimedia software components. This seemed like it would be a good exercise.

  You may have observed that the video is blue. Shortest, simplest answer : Pure laziness. Short, technical answer : Path of least resistance for getting through this exercise. Longer answer follows.

  Update : I did eventually realize that the Dreamcast can work with YUV textures. Read more in my followup post.

  Process and Pitfalls
  libvpx comes with a number of little utilities including decode_to_md5.c. The first order of business was porting over enough source files to make the VP8 decoder compile along with the MD5 testbench utility.

  Again, I used the KallistiOS (KOS) console RTOS (aside : I’m still working to get modern Linux kernels compiled for the Dreamcast). I started by configuring and compiling libvpx on a regular desktop Linux system. From there, I was able to modify a number of configuration options to make the build more amenable to the embedded RTOS.
  
  I had to create a few shim header files that mapped various functions related to threading and synchronization to their KOS equivalents. For example, KOS has a threading library cleverly named kthreads which is mostly compatible with the more common pthread library functions. KOS apparently also predates stdint.h, so I had to contrive a file with those basic types.

  So I got everything compiled and then uploaded the binary along with a small VP8 IVF test vector. Imagine my surprise when an MD5 sum came out of the serial console. Further, visualize my utter speechlessness when I noticed that the MD5 sum matched what my desktop platform produced. It worked !

  Almost. When I tried to decode all frames in a test vector, the program would invariably crash. The problem was that the file that manages motion compensation (reconinter.c) needs to define MUST_BE_ALIGNED which compiles byte-wise block copy functions. This is necessary for CPUs like the SH-4 which can’t load unaligned data. Apparently, even ARM CPUs these days can handle unaligned memory accesses which is why this isn’t a configure-time option.

  Showing The Work
  I completed the first testbench application which ran the MD5 test on all 17 official IVF test vectors. The SH-4/Dreamcast version aces the whole suite.

  However, this is a video game console, so I had better be able to show the decoded video. The Dreamcast is strictly RGB— forget about displaying YUV data directly. I could take the performance hit to convert YUV -> RGB. Or, I could just display the intensity information (Y plane) rendered on a random color scale (I chose blue) on an RGB565 texture (the DC’s graphics hardware can also do paletted textures but those need to be rearranged/twiddled/swizzled).

  Results
  So, can the Dreamcast decode VP8 video in realtime ? Sure ! Well, I really need to qualify. In the test depicted in the picture, it seems to be realtime (though I wasn’t enforcing proper frame timings, just decoding and displaying as quickly as possible). Obviously, I wasn’t bothering to properly convert YUV -> RGB. Plus, that Big Buck Bunny test vector clip is only 176x144. Obviously, no audio decoding either.

  So, realtime playback, with a little fine print.

  On the plus side, it’s trivial to get the Dreamcast video hardware to upscale that little blue image to fullscreen.

  I was able to tally the total milliseconds’ worth of wall clock time required to decode the 17 VP8 test vectors. As you can probably work out from this list, when I try to play a 320x240 video, things start to break down.

  1. Processed 29 176x144 frames in 987 milliseconds.
  2. Processed 49 176x144 frames in 1809 milliseconds.
  3. Processed 49 176x144 frames in 704 milliseconds.
  4. Processed 29 176x144 frames in 255 milliseconds.
  5. Processed 49 176x144 frames in 339 milliseconds.
  6. Processed 48 175x143 frames in 2446 milliseconds.
  7. Processed 29 176x144 frames in 432 milliseconds.
  8. Processed 2 1432x888 frames in 2060 milliseconds.
  9. Processed 49 176x144 frames in 1884 milliseconds.
  10. Processed 57 320x240 frames in 5792 milliseconds.
  11. Processed 29 176x144 frames in 989 milliseconds.
  12. Processed 29 176x144 frames in 740 milliseconds.
  13. Processed 29 176x144 frames in 839 milliseconds.
  14. Processed 49 175x143 frames in 2849 milliseconds.
  15. Processed 260 320x240 frames in 29719 milliseconds.
  16. Processed 29 176x144 frames in 962 milliseconds.
  17. Processed 29 176x144 frames in 933 milliseconds.