Recherche avancée

Médias (91)

Autres articles (97)

  • Demande de création d’un canal

    12 mars 2010, par

    En fonction de la configuration de la plateforme, l’utilisateur peu avoir à sa disposition deux méthodes différentes de demande de création de canal. La première est au moment de son inscription, la seconde, après son inscription en remplissant un formulaire de demande.
    Les deux manières demandent les mêmes choses fonctionnent à peu près de la même manière, le futur utilisateur doit remplir une série de champ de formulaire permettant tout d’abord aux administrateurs d’avoir des informations quant à (...)

  • Gestion de la ferme

    2 mars 2010, par

    La ferme est gérée dans son ensemble par des "super admins".
    Certains réglages peuvent être fais afin de réguler les besoins des différents canaux.
    Dans un premier temps il utilise le plugin "Gestion de mutualisation"

  • MediaSPIP Core : La Configuration

    9 novembre 2010, par

    MediaSPIP Core fournit par défaut trois pages différentes de configuration (ces pages utilisent le plugin de configuration CFG pour fonctionner) : une page spécifique à la configuration générale du squelettes ; une page spécifique à la configuration de la page d’accueil du site ; une page spécifique à la configuration des secteurs ;
    Il fournit également une page supplémentaire qui n’apparait que lorsque certains plugins sont activés permettant de contrôler l’affichage et les fonctionnalités spécifiques (...)

Sur d’autres sites (5287)

  • avcodec/codec_internal : add cap for ICC profile support

    28 juin 2022, par Niklas Haas
    avcodec/codec_internal : add cap for ICC profile support

    Codecs that can read/write ICC profiles deserve a special capability so
    
the common logic in encode.c/decode.c can decide whether or not there
    
needs to be any special handling for ICC profiles. The motivation here
    
is to be able to use it to decide whether or not an ICC profile needs to
    
be generated in the encode path, but it might as well get added to
    
decoders as well for purely informative reasons.
    

    It's not entirely clear to me whether the "thp" and "smvjpeg" variants
    
of "mjpeg" should have this capability set or not, given that the code
    
technically supports it but I somehow doubt these files may contain
    
them. In either case, this cap is purely informative for decoders so it
    
doesn't matter too much either way.
    

    It's also not entirely clear whether the "amv" encoder should signal ICC
    
profile support, but again erring on the side of caution, we probably
    
*shouldn't* be generating (and encoding !) ICC profiles for this type of
    
media file.
    

    Signed-off-by : Niklas Haas <git@haasn.dev>
    • [DH] libavcodec/codec_internal.h
    • [DH] libavcodec/libjxldec.c
    • [DH] libavcodec/libjxlenc.c
    • [DH] libavcodec/mjpegdec.c
    • [DH] libavcodec/mjpegenc.c
    • [DH] libavcodec/pngdec.c
    • [DH] libavcodec/pngenc.c
    • [DH] libavcodec/tiff.c
    • [DH] libavcodec/webp.c

  • fate/png : add test for ICC profile parsing

    28 juillet 2022, par Niklas Haas
    fate/png : add test for ICC profile parsing

    This tests the new "-flags2 icc_profiles" option by making sure the
    
embedded ICC profile gets correctly detected as sRGB.
    

    Signed-off-by : Niklas Haas <git@haasn.dev>
    • [DH] tests/fate/image.mak
    • [DH] tests/ref/fate/png-icc-parse

  • lavfi : add ICC profile support via lcms2

    9 avril 2022, par Niklas Haas
    lavfi : add ICC profile support via lcms2

    This introduces an optional dependency on lcms2 into FFmpeg. lcms2 is a
    
widely used library for ICC profile handling, which apart from being
    
used in almost all major image processing programs and video players,
    
has also been deployed in browsers. As such, it's both widely available
    
and well-tested.
    

    Add a few helpers to cover our major use cases. This commit merely
    
introduces the helpers (and configure check), even though nothing uses
    
them yet.
    

    It's worth pointing out that the reason the cmsToneCurves for each
    
AVCOL_TRC are cached inside the context, is because constructing a
    
cmsToneCurve requires evaluating the curve at 4096 (by default) grid
    
points and constructing a LUT. So, we ideally only want to do this once
    
per curve. This matters for e.g. ff_icc_profile_detect_transfer, which
    
essentially compares a profile against all of these generated LUTs.
    
Re-generating the LUTs for every iteration would be unnecessarily
    
wasteful.
    

    The same consideration does not apply to e.g. cmsCreate*Profile, which
    
is a very lightweight operation just involving struct allocation and
    
setting a few pointers.
    

    The cutoff value of 0.01 was determined by experimentation. The lowest
    
"false positive" delta I saw in practice was 0.13, and the largest
    
"false negative" delta was 0.0008. So a value of 0.01 sits comfortaby
    
almost exactly in the middle.
    

    Signed-off-by : Niklas Haas <git@haasn.dev>
    • [DH] configure
    • [DH] libavfilter/fflcms2.c
    • [DH] libavfilter/fflcms2.h

Navigation