Recherche avancée

Médias (1)

Mot : - Tags -/musée

Autres articles (56)

  • Participer à sa traduction

    10 avril 2011

    Vous pouvez nous aider à améliorer les locutions utilisées dans le logiciel ou à traduire celui-ci dans n’importe qu’elle nouvelle langue permettant sa diffusion à de nouvelles communautés linguistiques.
    Pour ce faire, on utilise l’interface de traduction de SPIP où l’ensemble des modules de langue de MediaSPIP sont à disposition. ll vous suffit de vous inscrire sur la liste de discussion des traducteurs pour demander plus d’informations.
    Actuellement MediaSPIP n’est disponible qu’en français et (...)

  • Publier sur MédiaSpip

    13 juin 2013

    Puis-je poster des contenus à partir d’une tablette Ipad ?
    Oui, si votre Médiaspip installé est à la version 0.2 ou supérieure. Contacter au besoin l’administrateur de votre MédiaSpip pour le savoir

  • Support de tous types de médias

    10 avril 2011

    Contrairement à beaucoup de logiciels et autres plate-formes modernes de partage de documents, MediaSPIP a l’ambition de gérer un maximum de formats de documents différents qu’ils soient de type : images (png, gif, jpg, bmp et autres...) ; audio (MP3, Ogg, Wav et autres...) ; vidéo (Avi, MP4, Ogv, mpg, mov, wmv et autres...) ; contenu textuel, code ou autres (open office, microsoft office (tableur, présentation), web (html, css), LaTeX, Google Earth) (...)

Sur d’autres sites (8380)

  • Different filesizes for images generated using octave and python

    22 février 2017, par Lakshay Garg

    I am using python (scikit-image) and octave to generate 200 images as follows

    Python3

    import numpy as np
    
from skimage.io import imsave
    

    
images = [255*np.ones((100,100), dtype=np.uint8),  # white
    
             np.zeros((100,100), dtype=np.uint8)]  # black
    

    
for i in range(200): # save alternating black and white images
    
    imsave('%04d.png'%(i+1), images[i%2])

    Octave

    pkg load image;
    

    
im1 = 255*ones(100,100); # white
    
im2 = zeros(100,100);    # black
    
for i=1:200
    
    name = sprintf('%04d.png', i);
    
    if mod(i,2) == 0
    
        imwrite(im1, name);
    
    else
    
        imwrite(im2, name);
    
    end
    
end

    Next, I use ffmpeg to generate two videos (alternating white and black frames) from these two sets of images using the following command

    ffmpeg -r 10 -loglevel quiet \
    
       -i ./%04d.png -c:v libx264 \
    
       -preset ultrafast -crf 0 ./out.mkv

    1. Sizes of image files generated by both these codes are different.

      • Octave white : 192 bytes, black : 98 bytes
      • Python white : 120 bytes, black : 90 bytes

    2. Sizes of video files generated from these octave and python images are significantly different from each other.

      • Octave filesize : 60 kilobytes
      • Python filesize : 116 kilobytes

    Why do we have this apparently very strange behavior ?

    EDIT

    Since it was suggested that the behavior might be dues to octave and python using different bit-depths to store the images, I changes the octave code to use 8 bit numbers

    im1 = uint8(255*ones(100,100)); # white
    
im2 = uint8(zeros(100,100));    # black

    and now the image file sizes are nearly the same

    • Octave white : 118 bytes, black : 90 bytes
    • Python white : 120 bytes, black : 90 bytes

    but the problem is still the same for video files, octave : 60K, python : 116K

  • Anomalie #4700 : Erreur sur l’édition des rubriques racine

    22 mars 2021, par nicod _

    Ben c’est normal non ? une rubrique secteur a comme id_secteur elle même, mais id_parent et profondeur à 0

  • avcodec/jpeg2000 : Simplify exp2fi for numbers used here

    17 février 2024, par Andreas Rheinhardt
    avcodec/jpeg2000 : Simplify exp2fi for numbers used here

    The call to ff_exp2fi() here always uses arguments in the normal
    
range, so that the branches in ff_exp2fi() are unnecessary.
    
This is so because JPEG2000 itself only supports up to
    
128 bits per component per pixel (we only support far less) ;
    
furthermore, expn is always 0..31 for the decoder and also
    
sane for the encoder, so that the difference between these
    
two values is always in the normal range of -126..128.
    

    Reviewed-by : Tomas Härdin <git@haerdin.se>
    
Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
    • [DH] libavcodec/jpeg2000.c

Navigation