информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Все любят медSpanning Tree Protocol: недокументированное применение
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Microsoft обещает радикально усилить... 
 Ядро Linux избавляется от российских... 
 20 лет Ubuntu 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / hacking
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Гы, интересная постановка эксперимента :) Пока я учился в аспиратуре, подрабатывал в рекламном агентстве завпроизводством и результаты экономии 05.12.07 17:50  Число просмотров: 4443
Автор: Fighter <Vladimir> Статус: Elderman
<"чистая" ссылка>
дискового пространства с помощью джипега знаю не понаслышке . Использование битмэпа только затянет получение результата, видимого невооруженным глазом. Шоб увидеть все быстрее открывай, изменяй и сохраняй только джипеги.
<hacking>
JPG-подляна. 05.10.07 14:10  
Автор: Zef <Alloo Zef> Статус: Elderman
<"чистая" ссылка>
Смотрю картинку бровсером (ИЕ и Мозиллой) - все нормально. Сохраняю, а он синий! Кто знает, как и чем это сделано и почему бровсер все кажет нормально. (В кэше ИЕ файл то же - синий!)
Продолжение банкета: 26.11.07 13:38  
Автор: Zef <Alloo Zef> Статус: Elderman
<"чистая" ссылка>
Открываю синий файл Фотошопом - все намана!!! Сохраняю - после этого ACDSee видит цвета нормально!
Может какая-нибудь особенность формата "JPEG 2000" 26.11.07 23:24  
Автор: Neznaika <Alex> Статус: Member
<"чистая" ссылка>
А когда сохраняем - получаем обычный JPEG.
Меня другое интересует: 27.11.07 05:17  
Автор: Zef <Alloo Zef> Статус: Elderman
<"чистая" ссылка>
Насколко я понимаю, сохранение Фотошопом ЧПЕГа с малейшими измнениями (хоть точку в углу) должно приводить к потере качества, поскольку картинка проходит повторное сжатие после декомпрессии, поскольку сама открытая Фотошопом копия уже отличается от оригинала. Или нет? Тогда - как? Поблочно? Только тот кусок, который был изменен пережимается, а остальные пишутся неизменными?

Понимаю, что вопрос пустой: если кто то и может в этом разобраться, так только я сам - по крайней мере, я знаю, как хачить Фотошоп MSVCшным дебагером, влезши в него через плагин (таким способом можно пролезть в интересующее место).

То же самое относительно синих картинок: явно, там используется какое-то поле, зарезервированное в старых форматах на будущее (типа палитры). Можно сравнить синий файл и сохраненный.

Но - лень! Тем паче, что проблема-то с помощю Фотошопа, вроде, решена.
1. Поблочно, квадратами, которые вытягиавются в строку по... 27.11.07 10:57  
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 27.11.07 10:59  Количество правок: 2
<"чистая" ссылка>
> Насколко я понимаю, сохранение Фотошопом ЧПЕГа с малейшими
> измнениями (хоть точку в углу) должно приводить к потере
> качества, поскольку картинка проходит повторное сжатие
> после декомпрессии, поскольку сама открытая Фотошопом копия
> уже отличается от оригинала. Или нет? Тогда - как?
> Поблочно? Только тот кусок, который был изменен
> пережимается, а остальные пишутся неизменными?

1. Поблочно, квадратами, которые вытягиавются в строку по неглавной диагонали. Пример:
JPG(1,1)JPG(1,2)JPG(1,3)
JPG(2,1)JPG(2,2)JPG(2,3)
JPG(3,1)JPG(3,2)JPG(3,3)
вытянутся в JPG(1,1)JPG(2,1)JPG(1,2)JPG(3,1)JPG(2,2)JPG(1,3)JPG(3,2)JPG(2,3)JPG(3,3)
Только квадрат в JPG с бОльшей стороной.
Далее эта цепочка пикселов подвергается гармоническому преобразованию, называющееся, если не ошибаюсь, "Дискретное синусно-косинускное преобразование". В зависимости от коэффициента сжатия (потерь) сохраняются только нужное количество первых параметров гармоник.
Стало быть при многочисленном сжатии/восстановлении с одними и теми же параметрами качество картинки не изменится, а изменения в одном блоке не влияют на другие.
Качество изменится. И еще как. Причем не в лучшуюю сторону. 02.12.07 12:13  
Автор: Fighter <Vladimir> Статус: Elderman
<"чистая" ссылка>
Естественно у всех возникает вопрос "почему"? 03.12.07 11:26  
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
<"чистая" ссылка>
Я пытался производить множество раз аналогичное преобразование. Значение не изменилось.
Y = arcsin( X / 1000 )
X = sin( Y ) * 1000
Взял число 256.
Y = arcsin ( 256 / 1000 ) = 14.832848 градусов
X = sin( 14.832848 ) * 1000 = 256.0000013360
После целочисленного округления получил все те же 256.
Надо думать, что если эту операцию бесконечно повторять, то значение X не изменится.
Все это правильно, но есть одно "но". Маленькое, но очень... 04.12.07 13:13  
Автор: Fighter <Vladimir> Статус: Elderman
<"чистая" ссылка>
> Я пытался производить множество раз аналогичное
> преобразование. Значение не изменилось.
> Y = arcsin( X / 1000 )
> X = sin( Y ) * 1000
> Взял число 256.
> Y = arcsin ( 256 / 1000 ) = 14.832848 градусов
> X = sin( 14.832848 ) * 1000 = 256.0000013360
> После целочисленного округления получил все те же 256.
> Надо думать, что если эту операцию бесконечно повторять, то
> значение X не изменится.
Все это правильно, но есть одно "но". Маленькое, но очень противное. Файлы никто не открывает в редакторе только для просмотра. С ними обычно что-то делают. Отсюда и преобразование при сохранении не тех же самых данных, а уже других. Плюс неизбежные ошибки округления. Что и дает нам в сумме ухудшение изображения при каждном новом сохранении. Именно поэтому в издательско-дизайнерском деле используют громоздкий TIFF, а не компактный JPEG. Можешь проверить это экспериментально :)
Так все-таки меняется только блок, 05.12.07 06:02  
Автор: Zef <Alloo Zef> Статус: Elderman
<"чистая" ссылка>
который изменили, или они все взаимосвязаны и повторной свертке подвергается вся картинка?
Чесслово пока нет времени эксперимент поставить, который... 05.12.07 11:06  
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 05.12.07 11:09  Количество правок: 1
<"чистая" ссылка>
> который изменили, или они все взаимосвязаны и повторной
> свертке подвергается вся картинка?

Чесслово пока нет времени эксперимент поставить, который хочу для собственного убеждения.
Берем какую-нибудь ВМР картинку, открываем графредактором, сохраняем в ЖПГ с качеством ~90%, открываем этот ЖПГ, сохраняем в ВМР с другим именем, открываем последний ВМР, сохраняем в ЖПГ с новым именем и тем же качеством, открываем последний ЖПГ и сохраняем его в ВМР с новым именем. Сравниваем последний и предпоследний ВМР (с первым сравнивать глупо, хотя можно, даже прикольно) командой >fc /b bmp0.bmp bmp1.bmp, смотрим сколько байтиков разница и где. Делаем выводы. Затем открываем последний ВМР, изменяем одну точку, сохраняем в ЖПГ с тем же качеством, но с новым именем, открываем последний ЖПГ, сохраняем в ВМР с тем же именем, сраниваем этот новый ВМР с предыдущим командой >fc /b bmp1.bmp bmp2.bmp, делаем выводы: если количество различающихся байт увеличилось на 1-3, то вообще все прекрасно, если не больше десятка при качестве ЖПГ свыше 95%, то хорошо, если два-три десятка при качестве свыше 90%, тоже хорошо, если в пределах 128 байт при любом другом качестве то приемлемо, но в любом случае изменение пиксела не повлияло на другие, находящиеся за пределами квадрата 8х8.
Результаты в студию.
Гы, интересная постановка эксперимента :) Пока я учился в аспиратуре, подрабатывал в рекламном агентстве завпроизводством и результаты экономии 05.12.07 17:50  
Автор: Fighter <Vladimir> Статус: Elderman
<"чистая" ссылка>
дискового пространства с помощью джипега знаю не понаслышке . Использование битмэпа только затянет получение результата, видимого невооруженным глазом. Шоб увидеть все быстрее открывай, изменяй и сохраняй только джипеги.
Изменение одной из компонент на несколько единиц... 05.12.07 18:56  
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 05.12.07 18:56  Количество правок: 1
<"чистая" ссылка>
> . Использование битмэпа только затянет получение
> результата, видимого невооруженным глазом. Шоб увидеть все
> быстрее открывай, изменяй и сохраняй только джипеги.

Изменение одной из компонент на несколько единиц (приблизительно до 4) я глазом не увижу даже если это будут два рядомрасположеных больших объекта, поэтому и предложил битмап (можно тиф непожатый) чтоб быстро определить сколько и какие точки изменились.
В предположении того, что верно утверждение "Изменение даже одной точки изображения может повлиять на множество остальных точек", попробуйте взять фотку (джипеговскую), открыть графредактором, изменить одну точку, сохранить, потом посмотреть просмотровщиком эти картинки и сказать приблизительно сколько точек изменилось вместе с этой точкой.
Честно говоря, подробностей работы джипеговского алгоритма я... 05.12.07 20:26  
Автор: Fighter <Vladimir> Статус: Elderman
<"чистая" ссылка>
> > . Использование битмэпа только затянет получение
> > результата, видимого невооруженным глазом. Шоб увидеть
> все
> > быстрее открывай, изменяй и сохраняй только джипеги.
>
> Изменение одной из компонент на несколько единиц
> (приблизительно до 4) я глазом не увижу даже если это будут
> два рядомрасположеных больших объекта, поэтому и предложил
> битмап (можно тиф непожатый) чтоб быстро определить сколько
> и какие точки изменились.
> В предположении того, что верно утверждение "Изменение даже
> одной точки изображения может повлиять на множество
> остальных точек", попробуйте взять фотку (джипеговскую),
> открыть графредактором, изменить одну точку, сохранить,
> потом посмотреть просмотровщиком эти картинки и сказать
> приблизительно сколько точек изменилось вместе с этой
> точкой.
Честно говоря, подробностей работы джипеговского алгоритма я уже просто не помню (доменные области, области квантования(?) и ДКП - только самые общие понятия), т.к. он очень старый - >10 лет. Но при редактировании изображений одну точку никто не меняет. Более того, изменениее одной (1-й) точки может привести как к нулевому результату, так и к появлению интересных эффектов (ореолы). Это зависит от того где находиться точка и насколько она контрастна по отношению к окружающим точкам.
Насколько я помню - вся картинка. 05.12.07 09:44  
Автор: Fighter <Vladimir> Статус: Elderman
<"чистая" ссылка>
Thank's! Все бы так отвечали и не надо было бы мануалы лопатить! 02.12.07 12:03  
Автор: Zef <Alloo Zef> Статус: Elderman
<"чистая" ссылка>
Для того Инет и существует, чтобы обмениватся готовыми осмысленными выводами и собственными изобретениями, а не посылать "к первоисточникам".
то что прописано в src картинки в хтмле - синее. А настоящая... 05.10.07 17:26  
Автор: ZloyShaman <ZloyShaman> Статус: Elderman
<"чистая" ссылка>
то что прописано в src картинки в хтмле - синее. А настоящая картинка грузится потом Javascriptом.
Скрип и активпукс запрещены. 06.10.07 15:28  
Автор: Zef <Alloo Zef> Статус: Elderman
<"чистая" ссылка>
Эффект однаковый и вразых бровсерах
при показе с помощью стилей можно накладывать всякие фильтры 05.10.07 16:41  
Автор: dl <Dmitry Leonov>
Отредактировано 05.10.07 16:42  Количество правок: 1
<"чистая" ссылка>
Как на картинки, так и на любые куски текста. Самое простое для описанного - воткнуть style="filter:invert" и получить негативное изображение, можно воткнуть chroma для исключения некого цвета, которым изначально загажена картинка.
Вот это ближе к теме. 06.10.07 15:32  
Автор: Zef <Alloo Zef> Статус: Elderman
<"чистая" ссылка>
Но у меня такое ощущение, что это именно ЧПЕГ. Потому, что это на фотосайте и защащенные и не защищенные вперемешку. Или у фотосайта такая фича есть? Он же не позволяет ХТМЫЛ странички редактировать.
хорошо бы на страницу взглянуть 06.10.07 15:39  
Автор: dl <Dmitry Leonov>
<"чистая" ссылка>
А так это будут только догадки.
1  |  2 >>  »  




Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2024 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach