Del porqué de la encuesta de tamaños de imagen y sentido común

Bien, en vista de que no hubo más comentarios, planteo de dónde salió mi duda.

La pregunta era:

Si les ponen la encomienda de reducir una imagen al 50% de su tamaño manteniendo la razón de aspecto, y la imagen mide originalmente 1 m x 1 m a 200 dpi, ¿cómo la entregan?

De los votos que estuvieron dentro de las opciones, hubo 2 votos por la opción «entregarla en 0.5 m x 0.5 m a 200 dpi», es decir, misma resolución, diferente tamaño por lado.

Sin embargo, una imagen de 0.5m x 0.5m cabe 4 veces en una imagen de 1m x 1m. Esto significa que estamos reduciendo al 25% la imagen original (y no al 50% como se pidió). Lo que en realidad está sucediendo es que ese «50%» es por cada uno de sus lados, y 50% x 50% = 25%.

Lo podemos comprobar con Gimp:

  1. Configuramos las preferencias para un tamaño máximo de memoria a 128 MB.
  2. Creamos la imagen de 1000 mm x 1000 mm a 200 dpi. GIMP nos reclama que estamos tratando de crear una imagen de 551 MB.
  3. Intentamos la opción I: 500 mm x 500 mm a 200 dpi. GIMP nos reclama que estamos tratando de crear una imagen de 137 MB MB, aproximadamente el 25% de la imagen original.
  4. Intentamos la opción E: 707.1 mm x 707.1 mm a 200 dpi. GIMP nos reclama que estamos tratando de crear una imagen de 275 MB MB, aproximadamente el 50% de la imagen original.
  5. Regresamos las preferencias de Gimp al valor original.

Sin embargo, aunque matemáticamente la respuesta sería la E, dado que el tamaño de una imagen es su superficie (su área), es algo que aparenta ser antinatural. Para sacar el 40% del tamaño de una imagen, multiplicamos cada lado por SQRT(40/100), lo cual no es agradable (o bien, multiplicar el dpi por SQRT[40/100]).

Entonces, considerando esto, la intención original de mi pregunta era sobre la costumbre entre la gente que a esto se dedica: si cuando se pedía una amplificación o una reducción de imagen, se acostumbra hablar de un porcentaje de la imagen calculado sobre su área o cada uno de sus lados.

Gracias a los que comentaron, y saludos.

Encuesta de tamaños de imagen y sentido común

Recurro a ustedes para preguntar su opinión sobre el siguiente dilema que se le presentó a alguien que conozco. Aunque yo tengo mi propia respuesta, yo pienso como ingeniero, no conozco las prácticas ni las costumbres ni los problemas diarios de los diseñadores. Por eso abogo a su sentido común para que me den su opinión.

Si les ponen la encomienda de reducir una imagen al 50% de su tamaño manteniendo la razón de aspecto, y la imagen mide originalmente 1 m x 1 m a 200 dpi, ¿cómo la entregan?

(Les agradecería que formularan su respuesta antes de leer los comentarios)

(En mi opinión, puede haber más de 1 respuesta, según el enfoque.)

Opción A: la entregan en 2 m x 2 m a 100 dpi.
Opción B: la entregan en 1 m x 1 m a 200 dpi.
Opción C: la entregan en 1 m x 1 m a 100 dpi.
Opción D: la entregan a 0.71 m x 0.71 m a 400 dpi.
Opción E: la entregan a 0.71 m x 0.71 m a 200 dpi.
Opción F: la entregan a 0.71 m x 0.71 m a 100 dpi.
Opción G: la entregan en 0.5 m x 0.5 m a 800 dpi.
Opción H: la entregan en 0.5 m x 0.5 m a 400 dpi.
Opción I: la entregan en 0.5 m x 0.5 m a 200 dpi.
Opción J: la entregan en 0.5 m x 0.5 m a 100 dpi.
Opción K: Ninguna de las anteriores (esta opción es nomás por joder).

Si existe alguna explicación para avalar su respuesta, lo agradecería todavía más.

Gracias de antemano.

(Como no tengo ningún plugin para hacer polls, voy a ir actualizando a mano los resultados en estas líneas.)

Anécdota del saludo después de desayunar burritos

Hoy por la mañana, después de «echarme» unos deliciosos burritos, me saluda por Messenger un compañero del DF al que le estaba ayudando a instalar un rebelde access point desde el día anterior:

él: Que pasó…

yo: Aquí nomás, digiriendo burritos.

él: Chaaaale, gracias…
él: … por lo que nos toca.

yo: Jaja, nooooo, hay un bato aquí que vende burritos.

él: Ah, ya.
él: Entendí «dirigiendo burritos».
él: Eso es lo malo de no leer bien.

Video favorito: Eroneia (avance)

Eroneia Trailer, TitleEroneia es lo que no imaginarás. Eroneia es la relación entre el pasado y el futuro. Eroneia es una experiencia de vida.

El proyecto de este cortometraje comenzó casi como una broma sobre una mesa con pizzas, sodas, nerviosismo y escepticismo, pero con el firme objetivo de hacer algo por nuestra amistad: convivir más y divertirnos. No importó que nunca hubiéramos actuado ni tocado una cámara profesional. El simple hecho de ver este avance cinematográfico me causa emoción. Misión cumplida. Ahora los extraño.

… y además, aprendí mucho. Por culpa de ustedes, ahora veo la televisión y sus errores de continuidad, de iluminación, etc., en lugar de apreciar el programa. ¡Culpables!

La premier de Eroneia será en octubre del 2008; será el cortometraje anfitrión en el Short Film Festival 2008, parte de Expociencias Nacional 2008 en Tehuacán, Puebla.

Es una película de Rod Zapién en asociación con Samuel Ramírez, producida por Primum Vivere Films.

Qué falló durante mi plática en el SFD2008

A todas las personas que estuvieron presentes en la plática «Invitación al Desarrollo del Software Libre»:

Quiero expresar mi agradecimiento por su presencia en mi plática; en general, en el evento SFD 2008 en Tijuana.

Recordarán que al terminar la presentación realicé en vivo un cambio al código de audiosum; específicamente, al componente audiodup. Con este cambio busqué mostrarles de manera práctica un ejemplo de cómo se desarrolla en el mundo del software libre mediante Git.

También recordarán que el experimento no funcionó del todo:

  1. descargamos el código desde repo.or.cz con git clone http://repo.or.cz/audiosum.git,
  2. compilamos audiosum y lo vimos funcionando con ./autogen.sh && ./configure && make,
  3. realizamos un cambio en audiodup,
  4. mostramos el parche resultante con git diff,
  5. revisamos el estado del repositorio local con git status,
  6. aplicamos el cambio en el repositorio local con git commit -a,
  7. observamos las diferencias entre el repositorio local y el repositorio público con git log origin..master,
  8. pero no pudimos publicar el cambio con git push.

El motivo fue muy sencillo: no tenía autorizada la laptop para enviar cambios al repositorio. En repo.or.cz se deben dar de alta las claves públicas de cada persona@computadora autorizada para enviar cambios. Tengo diferentes claves públicas en cada máquina, y sólo tenía dada de alta la PC del trabajo y la PC de la casa. Mi cuenta de la laptop no estaba autorizada para enviar cambios.

Finalmente el cambio fue aplicado con git push y pueden observar en el historial de cambios de audiosum el cambio «Added support for file pattern matching«. En el segundo enlace pueden ver que la fecha es del 13 de septiembre a las 17:56, hora local, es decir, que el commit fue realizado durante la conferencia.

Saludos.