Для работы проектов iXBT.com нужны файлы cookie и сервисы аналитики.
Продолжая посещать сайты проектов вы соглашаетесь с нашей
Политикой в отношении файлов cookie
И далее сам цвет ещё компенсировать на Color.minValue
Это безотносительно самого исходного кода. Просто там делаются точно такие же допущения, что оно в 256 влезет. С фига ли — понятно плохо.
Логика мышления точно такая же, как у написавших это.
Я вижу в указанном куске кода тип int, где вы там у int максимальное значение в 255 нашли, и где гарантия, что из Color.xxx не прилетит например 4095 для 12 бит?
-
По-хорошему там не [256] должно быть, а что-то наподобие [({specificImageObject}.Color.maxValue +1) * 3]. Но тот же _условный_ Color.maxValue не обязательно 255. А ещё int знаковый, т.е. мы можем поиметь дело с знаковыми значениями цвета, поэтому надо ещё усложнять. Что-то типа [({specificImageObject}.Color.maxValue — {specificImageObject}.Color.minValue + 1) * 3]
Неужели ни одной картинки с белым цветом не попадалось? :)
-
У меня подозрение, что при тамошнем преобразовании в «грейскейл» байтовые значения тупо делят на 4 (сдвиг на 2), поэтому и тёмный, и поэтому после сложения прекрасно влезает в байт, а когда влетает 12-битный источник — диапазон получается совершенно иной. Но это чисто с потолка подозрение, вчитываться мне честно говоря лень.
Код не бред, а типовая ошибка. Cудя по всему положились на API grayscale.getPixel/Color.xxx и не сделали клэмпинг по диапазону, а в этих самых getPixel/Color.xxx на выходе вышло что-то неожиданное.
-
«Если бы программисты строили дома, первый залетевший дятел разрушил бы цивилизацию» — древнющая фраза и поныне оправдывает своё существование. Уточним: не все программисты, некоторые.
Ахах мама дорогая, я валяюсь.
-
int[] histogram = new int[256];
int pixel = grayscale.getPixel(col, row);
int y = Color.red(pixel) + Color.green(pixel) + Color.blue(pixel);
histogram[y]...
-
Кодятлы, других слов нет. Там не 12-bit JPEG случайно?
Именно. «Незачем» — ключевое слово. В совке немецкие технологии имплементировать-то смогли, а понять, зачем они, кроме надувания щёк и военщины (единственного, чем совок и жил) — нет. Соответственно и на развитие забили.
Не, мимо.
Ждём исключения из фразы слов «красивых коробочек у».
Это безотносительно самого исходного кода. Просто там делаются точно такие же допущения, что оно в 256 влезет. С фига ли — понятно плохо.
Я вижу в указанном куске кода тип int, где вы там у int максимальное значение в 255 нашли, и где гарантия, что из Color.xxx не прилетит например 4095 для 12 бит?
-
По-хорошему там не [256] должно быть, а что-то наподобие [({specificImageObject}.Color.maxValue +1) * 3]. Но тот же _условный_ Color.maxValue не обязательно 255. А ещё int знаковый, т.е. мы можем поиметь дело с знаковыми значениями цвета, поэтому надо ещё усложнять. Что-то типа [({specificImageObject}.Color.maxValue — {specificImageObject}.Color.minValue + 1) * 3]
-
У меня подозрение, что при тамошнем преобразовании в «грейскейл» байтовые значения тупо делят на 4 (сдвиг на 2), поэтому и тёмный, и поэтому после сложения прекрасно влезает в байт, а когда влетает 12-битный источник — диапазон получается совершенно иной. Но это чисто с потолка подозрение, вчитываться мне честно говоря лень.
-
«Если бы программисты строили дома, первый залетевший дятел разрушил бы цивилизацию» — древнющая фраза и поныне оправдывает своё существование. Уточним: не все программисты, некоторые.
-
int[] histogram = new int[256];
int pixel = grayscale.getPixel(col, row);
int y = Color.red(pixel) + Color.green(pixel) + Color.blue(pixel);
histogram[y]...
-
Кодятлы, других слов нет. Там не 12-bit JPEG случайно?
Отсюда и.
Дальше можно не изучать, смысла нет.