¿Qué factores causan o evitan la "pérdida generacional" cuando los archivos JPEG se vuelven a comprimir varias veces?

29

Durante años, he creído que recomprimir archivos JPEG varias veces degradaría gradualmente su calidad hasta que sean un desastre irreconocible, como lo hacen las fotocopias de fotocopias. Esto tiene sentido intuitivamente porque JPEG es un formato con pérdida. También hay otras preguntas y respuestas que afirman que esto es así:

Sin embargo, también he leído que volver a comprimir archivos JPEG con el mismo nivel de calidad no degradará la calidad de la imagen. Esto va en contra de la degradación gradual que se describe en otra parte.

¿Qué sucede técnicamente cuando se vuelve a comprimir un JPEG?  ¿Qué se está perdiendo y cómo? ¿La imagen realmente se transformará en el desorden nevado que solía aparecer en la televisión? ¿Qué pasa con esos videos que muestran imágenes que se desmoronan después de ser recomprimidas varias veces?

(Por favor, no simplemente agite a mano y apele al concepto general de pérdida).

(Esta pregunta, y las respuestas que ha atraído hasta ahora, se centran en los factores técnicos (configuraciones específicas y manipulaciones de imagen) que causan o evitan la degradación de la imagen cuando un archivo JPEG se vuelve a comprimir varias veces).

xiota
fuente
Relevante .
Mehrdad
2
@MonkeyZeus Se pierde una cantidad (pequeña) de datos de imagen por error de redondeo en la calidad 100. La recompresión con la misma configuración (como 80) no da como resultado una pérdida progresiva de datos. Ese es el "conocimiento común" que este Q&A pretende abordar.
xiota
1
@MonkeyZeus Los valores como "100" y "80" (o "10, 11, 12" en Photoshop) son arbitrarios: el 100% no tiene pérdidas.
mattdm

Respuestas:

32

Casi todas las pérdidas de calidad de imagen ocurren la primera vez que una imagen se comprime como JPEG. Independientemente de cuántas veces se vuelva a comprimir un JPEG con la misma configuración , las pérdidas generacionales se limitan al error de redondeo.

  • Los límites de MCU permanecen intactos (bloques de 8x8).

  • El submuestreo de croma está deshabilitado.

  • DQT constante (misma configuración de calidad).

Sin embargo, los errores de redondeo pueden ser grandes para cada iteración si no se cumplen los criterios anteriores, y es prudente mantener copias de seguridad de todos los archivos originales.


El algoritmo de compresión JPEG

  1. Convertir espacio de color. Si lo desea, disminuya la información de color (submuestreo de croma) (con pérdida) . Si no se disminuye la muestra, la pérdida de información es el resultado de un error de redondeo .

  2. Segmentación. Divida cada canal en bloques de 8x8 (MCU = Unidad de codificación mínima). (Sin pérdida)

    Nota: Si el submuestreo de croma está habilitado, las MCU pueden ser efectivamente 16x8, 8x16 o 16x16, en términos de la imagen original. Sin embargo, las MCU todavía son todos bloques 8x8.

  3. Transformación discreta de coseno (DCT) en cada MCU. La pérdida de información es el resultado de un error de redondeo .

  4. Cuantización  El valor en cada celda de la MCU se divide por un número especificado en una tabla de cuantificación (DQT). Los valores se redondean hacia abajo, muchos de los cuales se convertirán en cero. Esta es la porción primaria con pérdida del algoritmo.

  5. Escaneo en zigzag. Reorganice los valores en cada MCU en una secuencia de números siguiendo un patrón en zig-zag. Los ceros que ocurrieron durante la cuantización se agruparán. (Sin pérdida)

  6. DPCM = Modulación diferencial de código de pulso. Convierta las secuencias numéricas en una forma que sea más fácil de comprimir. (Sin pérdida)

  7. RLE = Ejecutar codificación de longitud. Los ceros consecutivos están comprimidos. (Sin pérdida)

  8. Entropía / Codificación Huffman. (Sin pérdida)

Recomprimir archivos JPEG

Tenga en cuenta que la disminución de muestreo de los canales de color y la cuantización son los únicos pasos intencionalmente con pérdida . Dejando de lado el error de redondeo por ahora, todos los demás pasos no tienen pérdidas. Una vez que se ha producido la cuantización, invertir y repetir el paso da resultados idénticos. En otras palabras, la recuantificación (con el mismo DQT) no tiene pérdidas .

En principio, es posible crear un algoritmo de remuestreo que no tenga pérdidas después de la primera pasada. Sin embargo, con la implementación en ImageMagick, los colores pueden cambiar drásticamente antes de alcanzar el estado estable, como se ve en la imagen de esta.

En condiciones óptimas, volver a comprimir un JPEG con la misma configuración de calidad daría como resultado exactamente el mismo JPEG. En otras palabras, volver a comprimir archivos JPEG es potencialmente sin pérdidas . En la práctica, la recompresión de archivos JPEG no es sin pérdidas, sino que está sujeta a errores de redondeo y está limitada por ellos. Aunque los errores de redondeo a menudo eventualmente convergen a cero , de modo que se recrea exactamente la misma imagen, el submuestreo de croma puede provocar cambios de color significativos.

Demostración (misma configuración de calidad)

Escribí el siguiente bashscript, que usa ImageMagick para recomprimir repetidamente un archivo JPEG con una configuración de calidad dada:

#!/usr/bin/env bash
n=10001; q1=90
convert original.png -sampling-factor 4:4:4 -quality ${q1} ${n}.jpg

while true ; do
   q2=${q1}            # for variants, such as adding randomness
   convert ${n}.jpg -quality ${q2} $((n+1)).jpg
   #\rm $((n-5)).jpg   # uncomment to avoid running out of space
   n=$((n+1))

   echo -n "$q2  "
   md5sum ${n}.jpg
done

Después de dejar que se ejecute durante unos cientos de iteraciones, ejecuté md5sumlos resultados:

d9c0d55ee5c8b5408f7e50f8ebc1010e  original.jpg

880db8f146db87d293def674c6845007  10316.jpg
880db8f146db87d293def674c6845007  10317.jpg
880db8f146db87d293def674c6845007  10318.jpg
880db8f146db87d293def674c6845007  10319.jpg
880db8f146db87d293def674c6845007  10320.jpg

Podemos ver que, de hecho, el error de redondeo ha convergido a cero, y se reproduce exactamente la misma imagen, una y otra vez .

Lo he repetido varias veces con diferentes imágenes y configuraciones de calidad. Por lo general, se alcanza el estado estable y se reproduce exactamente la misma imagen una y otra vez.

¿Qué pasa con los resultados de @ mattdm ?

He intentado replicar los resultados de mattdm usando Imagemagick en Ubuntu 18.04. El original era una conversión en bruto a TIFF en Rawtherapee, pero parece que ya no está disponible. En su lugar, tomé la versión ampliada y la reduje a su tamaño original (256x256). Luego repetidamente recomprimí a 75 hasta que logré la convergencia. Aquí está el resultado (original, 1, n, diferencia):

intento de replicar mattdm

Mis resultados son diferentes. Sin el verdadero original, la razón de la diferencia es imposible de determinar.

¿Qué pasa con el montaje de @ ths ?

Comprimí la imagen desde la esquina superior izquierda del montaje hasta la convergencia en 90. Este es el resultado (original, 1, n, diferencia):

intento de replicar este montaje

Después de habilitar el submuestreo de croma, los colores cambian cuando se alcanza el estado estable.

ths-cambio de color

Cambiar entre una pequeña cantidad de configuraciones

Al modificar la variable q2, la configuración de calidad puede limitarse a un conjunto de valores distribuidos uniformemente.

q2=$(( (RANDOM % 3)*5  + 70 ))

Para un pequeño número de opciones de configuración, el equilibrio puede eventualmente alcanzarse , lo que se ve cuando los valores de md5 comienzan a repetirse. Parece que cuanto más grande es el conjunto, más se demora y peor es la imagen, antes de que se pueda alcanzar el equilibrio.

Lo que parece suceder en el equilibrio es que el coeficiente DCT antes de la cuantización debe ser divisible en todos (o la mayoría) de los valores cuánticos. Por ejemplo, si se cambia entre dos DQT donde el coeficiente DCT se divide alternativamente por 3 y 5, se alcanzará el equilibrio cuando el coeficiente DCT sea divisible por 15. Esto explica por qué la caída en la calidad es mucho mayor que la diferencia entre las configuraciones originales.

Cambiar entre una mayor cantidad de configuraciones

Eeyore no está contento cuando q2se cambia así:

q2=$(( (RANDOM % 9)  + 90 ))

Para hacer un video, use ffmpeg:

rename 's@1@@' 1*.jpg
ffmpeg -r 30 -i %04d.jpg -c:v libx264 -crf 1 -vf fps=25 -pix_fmt yuv420p output.mp4

Ver las primeras 9999 iteraciones es casi como ver hervir el agua. Es posible que desee duplicar la velocidad de reproducción. Aquí está Eeyore después de 11999 iteraciones:

11999 iteraciones, DQT aleatorio

¿Qué pasa si los límites de MCU cambian?

Si se producen cambios un número limitado de veces, es probable que la recompresión repetida alcance el estado estable. Si se producen cambios en cada iteración, la imagen probablemente se degradará de manera similar a cuando cambia DQT.

  • Esto es lo que sucede en los videos que rotan una imagen con dimensiones que no son divisibles por 8.

¿Qué pasa con la edición?

El efecto de volver a comprimir después de la edición depende de la edición particular realizada. Por ejemplo, guardar con la misma configuración de calidad después de reducir los artefactos JPEG reintroduciría los mismos artefactos. Sin embargo, la aplicación de un cambio localizado, como un pincel de curación, no afectaría las áreas que no fueron tocadas.

La mayor caída en la calidad de la imagen ocurre la primera vez que el archivo se comprime en una configuración de calidad dada. Posteriormente, volver a comprimir con la misma configuración no debería introducir ningún cambio mayor que el error de redondeo. Por lo tanto, esperaría que los ciclos de edición-resave en una configuración de calidad dada se vean como cualquier otra imagen guardada con la misma configuración de calidad (siempre que los límites de MCU permanezcan intactos y el submuestreo de croma esté desactivado ).

¿Qué hay de esos videos?

  • ¿Implementación JPEG defectuosa? ( Volver a guardar 500 veces con Photoshop al 10/12. )

  • Cambiar la configuración de calidad. (La mayoría de los videos)

  • Interrumpiendo los límites de MCU. (Recortar o rotar )

  • ¿Otras maniobras que reducen la calidad de la imagen o interfieren con el algoritmo JPEG?

¿Puedo sobrescribir mis originales con archivos JPEG comprimidos?

Es prudente mantener copias de seguridad de todos los archivos originales, pero si accidentalmente sobrescribe uno, es probable que el daño sea limitado. También estaría bien trabajar en JPEG con submuestreo de croma deshabilitado.

JPEG no se puede usar para imágenes que usan más de 8 bits por color.

xiota
fuente
55
Sin embargo, la imagen es bastante diferente con los bucles load- edit -save. en este caso, la cuantificación repetida causará degradación.
THS
2
Acabo de hacer una prueba con el mismo guión que en la respuesta. Aquí hay un montaje de cada vigésima imagen hasta tp 100: i.stack.imgur.com/xtob6.jpg que es significativo.
THS
2
ah Encontré el problema con mi imagen. Si tiene activado el submuestreo de croma, esto conduce a una degradación progresiva.
THS
2
Encontrado eso también. Por lo tanto, habilitar el submuestreo de croma altera significativamente el color de la imagen antes de alcanzar el estado estable.
xiota
2
Las cargas y los guardados repetidos utilizando exactamente los mismos parámetros probablemente no introducirían una pérdida de calidad ilimitada, ya que la mayoría de los archivos de entrada podrían cargarse y volverse a guardar sin introducir un error de redondeo adicional, y los archivos que se verían afectados por errores de redondeo probablemente se transformarían en archivos que no lo harían. Por otro lado, los ciclos repetidos de carga / guardado que alternan entre parámetros de compresión que son similares pero no idénticos pueden dar lugar a errores de redondeo en cada ciclo.
supercat
20

La pérdida de recompresión es real, especialmente cuando se trabaja con niveles más altos de compresión JPEG.

En teoría, si vuelve a guardar archivos JPEG con los mismos parámetros exactos y ha alineado su recorte a bloques de 8 × 8, la degradación debería ser mínima. Sin embargo, si está utilizando un alto nivel de compresión, verá una mayor pérdida, ya que los artefactos introducidos por la compresión inicial son cambios permanentes en la imagen y también se volverán a comprimir, causando más artefactos.

Si vuelve a guardar con un bajo nivel de compresión (alta calidad, como "100" en Gimp u 11 o 12 en Photoshop), será difícil notar cualquier artefacto agregado recientemente. No hará que la imagen de cualquier mejor , pero no significativamente peor. Sin embargo, será introducir cambios a través de toda la imagen.

Como prueba rápida, usé ImageMagick para recomprimir una imagen JPEG una y otra vez al 75%. Los ejemplos a continuación se cargan como archivos PNG para evitar una nueva compresión adicional, y se duplicaron en tamaño cuando convertí a PNG para que el efecto sea más obvio. (Los originales utilizados en la prueba no se duplicaron). Resulta que después de ocho remuestreos, el efecto convergió en un resultado perfectamente estable, donde la recompresión nuevamente da como resultado un archivo idéntico bit por bit.

Aquí está el original sin comprimir:

original, sin compresión jpeg

Aquí está el resultado de ir a 75% JPEG:

primer jpeg

Y aquí está eso guardado:

segundo pase

¡Ese solo segundo guardado causa una gran cantidad de degradación adicional!

Y aquí está la imagen convergente final (octavo pase):

JPEG convergente

Nuevamente, los colores definitivamente están aún más apagados, incluidos algunos patrones de colores falsos, y los artefactos en bloque saltan más. El algoritmo converge, pero a una versión significativamente degradada. Entonces, no hagas eso.

Pero aquí está lo mismo con un nivel de calidad del 99%, después de 9 pases (el punto en el que converge para que otros pases sean idénticos):

99% 9 veces

Aquí, la diferencia apenas se registra. (Lo digo literalmente; compárelos píxel por píxel con la versión no comprimida y la desviación es un ruido aleatorio muy leve). Entonces, ¿qué pasa si vuelvo a esa primera imagen del 75% y luego la vuelvo a guardar al 99%? Bueno, esto (después de solo una vez):

75% una vez y luego 99% una vez

Ahorrar a alta calidad definitivamente es visiblemente mejor que volver a guardar con los mismos parámetros, algo para mi sorpresa. Pero, hay una nueva degradación obvia alrededor del recorte rosado y los ojos. Con la versión reciclada de la misma configuración, los artefactos JPEG se exageran con cada recompresión. Con la baja resolución y la baja calidad que he elegido, eso resulta ser peor que volver a comprimir todo de manera diferente.

En esos videos: encontré este como uno de los principales éxitos de Google. Tenga en cuenta que dice en la descripción:

Esto es lo que sucede si vuelve a codificar una imagen JPEG muchas veces, en configuraciones aleatorias de alta calidad (85 o superior).

Énfasis agregado : esto explica por qué no hay convergencia, porque en lugar de guardar con la misma configuración, o guardar con una calidad súper alta, se usan configuraciones aleatorias cada vez .

El segundo video que encontré dice:

Se copió una imagen JPEG y se hizo girar una revolución completa para cada imagen. [...] (596 acciones "rotar en sentido horario")

Entonces, nuevamente, se hizo algo para mantener los errores acumulados.

En cualquier caso, para la edición práctica de fotos , vale la pena mencionar que ahorrar un 75% una vez es mucho peor que ahorrar un 99% un millón de veces . En mi caso de ejemplo, los artefactos al 75% son tan obvios que la degradación adicional es como arrojar agua al océano. Si guarda a un nivel lo suficientemente alto como para que estos artefactos no sean realmente visibles, guardar de nuevo con la configuración original es una buena estrategia. Por supuesto, si puede seguir trabajando siempre con originales sin comprimir, es mejor que lo haga.

Si por alguna razón tiene que (o prefiere) trabajar con JPEG, configure su cámara para guardar con la mayor calidad posible , incluso si no nota la diferencia en los archivos iniciales. Ver ¿Vale la pena usar la configuración de calidad Premium JPEG de Pentax? para más información sobre eso, no necesariamente realmente Pentax específico.

mattdm
fuente
(1) Estás ahorrando al 75%. En esa configuración, se espera una pérdida de calidad de imagen. (2) Esa imagen fue seleccionada y alterada para exagerar los artefactos de compresión JPEG. (3) La imagen converge después de 8 rondas de recompresión, después de lo cual no habrá más reducción en la calidad de la imagen. (4) Un video de esa imagen que muestra la "pérdida de generación" no tendría mucho que pasar después del primer 1/4 de segundo.
xiota
55
(1) Sí (2) "Seleccionado" como una foto típica donde uno podría preocuparse por este tipo de cosas. "Alterado" solo para acercar. Tenga en cuenta que esto es solo para mostrar aquí: no dupliqué el tamaño de la imagen con la que estaba trabajando. (3) Sí, pero en la práctica para la edición, son las primeras rondas las que te pueden interesar. (4) Eso es cierto, pero no implica que converger al peor de los casos y permanecer allí sea útil de ninguna manera.
mattdm
Para replicar, tome la primera imagen y cambie el tamaño a 256 × 256 sin remuestreo o interpolación.
mattdm
No puedo ver mucha diferencia entre las imágenes que muestra. Pero si tomo la diferencia de una imagen recompresada individualmente y una imagen recomprimida mutuamente y la amplifico para que sea visible, obtengo este resultado (mucho más convincente): i.stack.imgur.com/57uaY.png (vea mi eliminado responda exactamente lo que se hizo) Es más convincente porque las personas no tienen que seguir mirando la imagen para detectar pequeñas diferencias.
Szabolcs
Las diferencias son bastante pequeñas. Si tiene una pantalla LCD grande, la diferente "gamma" que resulta de ángulos de visión ligeramente diferentes puede hacer que los artefactos parezcan más prominentes.
xiota
5

La recompresión tiene un efecto medible en la calidad de la imagen y ese efecto es mucho más pronunciado al cambiar las tasas de compresión.

Como una comprobación rápida aquí, algunos valores SSIM para operaciones realizadas en una imagen de prueba que contiene una combinación de características de línea y características continuas. Seleccioné JPG95 porque eso es lo que me enseñaron a usar en Ad-photo school y JPG83 porque eso es común entre los proveedores de contenido digital.

  • Guardar imagen Tiff como JPG95 - .9989
  • Guardar imagen Tiff como JPG83 - .9929
  • Vuelva a guardar la imagen JPG95 como JPG95 10 veces - .9998
  • Vuelva a guardar la imagen JPG83 como JPG83 10 veces - .9993
  • Vuelva a guardar JPG95 como JPG83 y luego vuelva a guardar como JPG95 - .9929
  • Vuelva a guardar JPG95 como JPG83 luego JP83 a JP92 luego JPG92 a JPG86 - .9914

Por lo tanto, la cantidad de similitud estructural que se pierde al volver a guardar en la misma compresión 10 veces es 1/10 de la pérdida que se ahorra en la calidad de tiff. Sin embargo, la pérdida de calidad al cambiar la compresión JPG, incluso una vez, es la misma que la calidad perdida al guardar esa imagen de Tiff a JPG.

Ejecutaré esta prueba de algunas maneras más y la actualizaré.

Metodología : En ImageJ:

  1. Convierta Tiff RGB a escala de grises de 8 bits
  2. Guarde JPG95 y JPG83 de Tiff Original
  3. Llevar a cabo más operaciones de revelado como se especifica
  4. Cargue imágenes de comparación y use el complemento de índice SSIM

NOTA: muchas personas que miran los valores SSIM por primera vez los leen como porcentajes y suponen que la diferencia es pequeña. Esto no es necesariamente cierto. Los valores de SSIM deben compararse entre sí en lugar de considerarse como una variación de 1.

PhotoScientist
fuente
@xiota, estoy usando un complemento SSIM para ImageJ. Es una de las pocas implementaciones de SSIM que permite el ajuste de los parámetros (configuré el ancho del filtro en 8 para que sea más probable que detecte cambios dentro de los bloques JPEG de 16px). Prefiero SSIM porque es más sensible a las diferencias de energía. redistribución. Una imagen de diferencia puede ser engañosa si las diferencias se cancelan o si las diferencias se concentran en un área pequeña.
PhotoScientist
Y a su segunda pregunta, eso dice que la diferencia de JPG95 a JPG83 a JPG95 es la misma que pasar de Tiff a JPG83. Si quieres Tiff-JPG95-JPG83-JPG95, eso es .9923
PhotoScientist
Se agregó una prueba con cuatro compresiones diferentes. La pérdida es aún mayor, pero está claro que la "convergencia" observada en varias generaciones de la misma compresión también está presente al intentar múltiples compresiones diferentes. Todavía me gustaría probar esto en un flujo de trabajo centrado en la aplicación, pero eso requiere un poco más de trabajo preliminar.
PhotoScientist
Otro problema es que no existe un mapeo estándar de la configuración de "calidad" a los umbrales de SSIM, ni hay ninguna forma de determinar qué configuración de calidad sería necesaria para evitar una pérdida significativa de información. Si uno carga un JPEG y lo guarda en una configuración lo suficientemente alta, se puede evitar una pérdida de calidad adicional, pero es probable que el archivo se agrande. Si uno no sabe qué configuración se usó cuando se produjo un archivo, puede ser difícil determinar qué configuración usar al volver a guardarlo.
supercat
4

Nada como algo de experimentación. El siguiente script bash (escrito en Linux, podría funcionar en OSX si tiene ImageMagick ):

  • comenzando con una primera imagen (nombrada step000.jpg)
  • toma un archivo JPEG, agrega un punto blanco (para demostrar que esta es una imagen nueva) y lo guarda como (PNG sin pérdidas)
  • toma el PNG y lo vuelve a comprimir como JPEG (por lo que nunca comprimimos JPEG a JPEG, y no podemos suponer que el software solo copia bloques codificados)
  • crea una imagen que muestra los diferentes píxeles entre los dos archivos JPEG
  • enjuague y repita, utilizando el JPG de salida del paso anterior

El resultado es que:

  1. no hay mucha pérdida en altas cualidades JPG
  2. Los errores de redondeo finalmente se resuelven, después de un corto número de generaciones, las cosas ya no se degradan.

Por supuesto, todo esto supone que el JPEG es guardado por el mismo software con los mismos parámetros cada vez.

#! /bin/bash
# Runs successive JPEG saves on an image to evaluate JPEG losses

# convert & compare command from imagemagick
# if you use a recent version of IM, set these variables to:
# compare="magick compare"
# convert="magick convert"
convert=convert
compare=compare

dotradius=2
defaultsteps=10
defaultquality=90 # default quality for "convert"

function usage {
        echo "Usage: $0 [quality [steps]]"
        echo ""
        echo "Where:"
        echo "       - 'quality' is the quality factor of the JPEG compression "
        echo "          (1-100, 100 is best, default is $defaultquality)"
        echo "       - 'steps' is the number of successive steps to perform"
        echo "         (default is $defaultsteps)"
        echo ""
        echo "Produces:"
        echo "   - successive saves of a JPEG image to test JPEG-induced losses."
        echo "   - compare images with the original file and the 1st JPEG save."
        echo ""
        echo "Starts from a 'step000.jpg' file in the current directory."
        exit 1
}

[[ -n "$3" ]] && { usage ; exit 1 ; }
steps=${1:-$defaultsteps}
quality=${2:-$defaultquality}    
dotcolor="white" # change this if the top of the image is too clear

echo "Running with $steps steps with quality $quality"

for step in $(seq $steps)
do 
    echo "Step $step of $steps"
    src=$(printf step%03d $(( $step - 1 )) ) 
    dst=$(printf step%03d $(( $step )) )
    dif=$(printf diff%03d $(( $step )) )
    # dot coordinates
    let cxc="2 * $dotradius * $step"
    let cxr="$cxc + $dotradius"
    let cyc="$dotradius * 2"
    let cyr="$dotsradius * 2"

    $convert $src.jpg -fill white -draw "circle $cxc,$cyc,$cxr,$cyr" $dst.png
    $convert $dst.png -quality $quality $dst.jpg
    rm $dst.png
    $compare $src.jpg $dst.jpg $dif.jpg
done

Por el momento no mostraré los resultados, prefiero dejar que experimentes con tus propias imágenes. Con suficientes comentarios, agregaré una muestra.

xenoide
fuente
1
Tenía curiosidad sobre la cosa del software diferente. Intenté guardar 7x de 7 software diferentes. La diferencia era bastante grande, así que la desglosé para ver si cada aplicación tenía la misma pérdida. 1 de las aplicaciones fue responsable de toda la variación. Una vez que quité el arenque rojo, 6x salvados de 6x programas fueron lo mismo que 6x salvados de ImageJ
PhotoScientist
Es probable que haya algún software mal codificado. También es posible que al mezclar los algoritmos de varias aplicaciones también se eviten los errores de redondeo.
xenoid
@xiota, era un pequeño programa extraño llamado FLEMinimizer. Ni siquiera recuerdo por qué lo tuve en primer lugar. Los otros fueron ImageJ, Matlab, Photoshop, FastStone Image Viewer, Ifranview y CameraRaw. Casi no hubo variación en ningún paso entre esos seis.
PhotoScientist