Recherche avancée

Sur d’autres sites (7538)

• About image opacity

  23 octobre 2013, par Mikko Koppanen — Imagick

  There is a common misconception that Imagick::setImageOpacity() would work to reduce the opacity of the image. However, as the name says the method actually sets the opacity throughout the image and thus affects also transparent areas.

  To demonstrate let’s first look at this image of a red circle on a transparent background :

  

  Now, let’s apply setImageOpacity on the image :

  php

  < view plain text >

  1. < ?php
  2. $im = new Imagick (’red-circle.png’) ;
  3. $im->setImageOpacity (0.5) ;
  4. $im->writeImage (’red-circle-setopacity.png’) ;
  5.  ?>

  

  As we can see from the resulting image the transparent background is affected as well.

  In order to actually reduce the opacity of the opaque parts Imagick::evaluateImage can be used instead :

  php

  < view plain text >

  1. < ?php
  2. $im = new Imagick (’red-circle.png’) ;
  3.  
  4. /* Divide the alpha channel value by 2 */
  5. $im->evaluateImage(Imagick: :EVALUATE_DIVIDE, 2, Imagick: :CHANNEL_ALPHA) ;
  6. $im->writeImage (’red-circle-divide.png’) ;
  7.  ?>

  And here are the results :

  

  As the background is already fully transparent so the divide operation causes no changes to it.

  Similar example is available in the PHP manual http://php.net/imagick.evaluateimage and I added a note to setImageOpacity page as well (at the time of writing it has not synced to documentation mirrors yet).

• Can I use a text file's content to create a filtered list for ffmpeg ?

  20 octobre 2022, par Angel Lopez Jr

  I am attempting to make a CMD script that will

  &#xA;

  &#xA;
  1. Create a text file that lists file names followed by video codec (using ffprobe)

  &#xA;

  2. Create a new text from the list so that any file with x265 codec is removed from the list (and formated as&#xA;file "*filepath*"

  &#xA;

  3. Run ffmpeg on the edited list to transcode remaining files to x265.

  &#xA;

  &#xA;

  I have a script that does #1

  &#xA;

  for /R %%f IN (*.mkv,*.avi,*.mp4,*.m2ts,*.mts,*.rm,*.m4v) do echo "%%f" >>Probe.txt & ffprobe -v error -hide_banner -of default=noprint_wrappers=0 -print_format flat  -select_streams v:0 -show_entries stream=codec_name "%%f" >>Probe.txt & echo.  >>Probe.txt


  &#xA;

  which outputs

  &#xA;

  &#xA;

  "filepath"
  &#xA;streams.stream.0.codec_name="codec"

  &#xA;

  "filepath"
  &#xA;streams.stream.0.codec_name="codec"

  &#xA;

  &#xA;

  and I have a script that will do #3

  &#xA;

  for /R %%f IN (*.mkv,*.avi,*.mp4,*.m2ts,*.mts,*.rm,*.m4v) do ffmpeg -hide_banner -hwaccel_output_format qsv -i "%%f" -c:v libx265 -c:a ac3 -x265-params crf=25 "%%f.mkv"


  &#xA;

  I am not sure if #2 is even possible though.

  &#xA;

  End result of task 2 should be that in probe.txt, any line that has a&#xA;streams.stream.0.codec_name value of anything besides hevc will have the line immediately above it written to a new txt file with the word file in front.

  &#xA;

  final goal is getting all three tasks to run under one batch file (each task running sequentially)

  &#xA;

  Is there any help on what I am missing to be able to unify these and get #2 to happen

  &#xA;

• lavu/pixdesc : handle xv30be in av_[read|write]_image_line

  4 décembre 2022, par Philip Langdale

  lavu/pixdesc : handle xv30be in av_read_image_line
  xv30be is an obnoxious format that I shouldn't have included in the
  
  first place. xv30 packs 3 10bit channels into 32bits and while our
  
  byte-oriented logic can handle Little Endian correctly, it cannot
  
  handle Big Endian. To avoid that, I marked xv30be as a bitstream
  
  format, but while that didn't produce FATE errors, it turns out that
  
  the existing read/write code silently produces incorrect results, which
  
  can be revealed via ubsan.
  In all likelyhood, the correct fix here is to remove the format. As
  
  this format is only used by Intel vaapi, it's only going to show up
  
  in LE form, so we could just drop the BE version. But I don't want to
  
  deal with creating a hole in the pixfmt list and all the weirdness that
  
  comes from that. Instead, I decided to write the correct read/write
  
  code for it.
  And that code isn't too bad, as long as it's specialised for this
  
  format, as the channels are all bit-aligned inside a 32bit word.
  

  • [DH] libavutil/pixdesc.c