Расстояние между городами задается по прямой или по реальному расстоянию дороги соединяющей пункты, например с Google Maps?
И если дорога из пунута А в пункт B лежит через пункт С и пункты A и B не связаны с собой отдельной дорогой, как алгоритму это задать?
Это не используется везде где только можно по той причине, что core2duo будет вам считать киношку размером в 30 гиг — очень и очень долго. Но когда наступит эра квантовых компов — минуты, если не секунды.
На том и остановимся. Извините, но мне нужно заниматься исследованиями, даже несмотря на то, что на Ваш взгляд они бессмысленны.
… но, шмель об этом не знает и продолжает летать.
На счет винта это была шутка юмора) Уважаемый, Вы когда нибудь пользовались функцией синуса? Сколько раз Вы подумали, что сжали информацию о синусоиде? На промежутке от 0 до pi на бесконечность мы можем получить таки длинный сигнал. Допустим тот же терабайт синусоиды. Но когда Вам нужно сгенерировать синусоиду той же длины Вы не скачиваете мой файл размером в терабайт. Вы просто задаете функции синус(х) вектор х. Я могу ошибаться, но процессом сжатия в таком случае было бы сжатие терабайтного файла до какого-то размера. Например, нашли бы один период синусоиды, а за ним написали бы число повторений.
но, не на моем винте) Источник информации должен быть источником информации. Генератор шума будет генерировать шум вопрос только в том, есть ли у Вас такой же генератор шума.
Ок. Я понял. Объясню так. Вы мне рассказали стих. Длинный такой. Если его записать в текстовый файл то он займет терабайт. Но я не хочу хранить у себя этот терабайт. Я попрошу Вас рассказать мне его снова. И получу ту же информацию из источника. Я не уверен что это можно отнести к сжатию информации.
На счет «последовательности из 256 нулей последовательностью „256 0“ я с Вами абсолютно согласен это процесс сжатия.
Мой метод не подразумевает процесса сжатия как такового. Скорее больше похоже на адресацию. Вы же не называете процессом сжатия кривой которую Вы описали с помощью регрессивного полиномиального анализа? Вы представили линию или точки как формулу. Я полагаю, что это находится в разных плоскостях с понятием сжатия. Это скорее трансформация. Прочем утверждать ничего не буду.
а кто Вам сказал, что я собираюсь сжимать данные? Конечно, если их сжимать по самому хитрому алгоритму то его эффективность будет экспоненциально падать с уменьшением размера файла. Но об этом и речи не идет.
Отнюдь, я не собираюсь ничего опровергать или хлопать по плечу классиков. У меня свой подход. Без нарушения причинно-следственных связей, законов и разрыва континуума.
Вы меня нисколько не расстроили, ведь я уверен в том, что это реально и цифра в 65536 файлов ничего не значит для метода который я разрабатываю. Конечно будет не пару байт но и, скорее всего не 30 мегабайт.
Поймите, я не изобраетал raw сьемку в телефоне, не продаю софт который может улучшить фото. Я всего лишь поковырялся в настройках и обнаружил тот факт, что МТК может в RAW причем качество фото (по моим многочисленным тестам) превосходят качество в жпег. А тот факт, что об этом почти нигде не написано, или не написано вовсе, я решил исправить. Я не собираюсь никого убеждать или что-то в этом роде. Хочешь снимай так, не нравится — проходи мимо.
Сейчас каждый день я меняю прошивки на своем телефоне и тестирую камеры и фото в RAW. Везде (даже на стоке) жпег снимки проигрывают по качеству.
На счет HDR — выход конечно, но имеет свои преимущества и недостатки. ИМХО. Предпочитаю сам обрабатывать фото, а не доверять встроенному ПО которое сделает это за меня по шаблону. Так же согласен что, способ требует немного больше времени, но мне, как человеку думающему перед щелчком затвора достается на обработку не так уж и много фото, а тот факт что с этих фото можно вытянуть намного больше чем обычно — будоражит воображение.
Странно, вот у человека который оставил второй комментарий получаются отличные фотографии в raw на Nexus 5. Так, что цитирую: «Гораздо лучше получается, чем автообработкой. И друзья обращают внимание. Сначала они думают, что это фото сделано на хороший фотик.»
Может у Вас «ничего приличного не вышло» по субъективным причинам.
У меня, так же фото сделанные в рав формате на телефоне (Phoenix 2) лучше чем в жпег. (Про что свидетельствую приложенные фото в посте.) Констатирую лишь то, что возрастают возможности обработки. Вчера тестил этот способ на достаточно посредственной камере THL 4000, и даже там фото в рав смотрятся куда лучше чем в жпег при эквивалентной обработке.
По поводу «получить на выходе «красивую» равку». Тут имеется ввиду, что в некоторых телефонах (кастомных прошивках) рав непосредственно с инженерного меню телефона «синит», «желтит» или совсем получается цветовой каламбур. Именно по этому нужно подбирать значение cfa_colors в файле raw2nef.ini. Тогда на выходе мы получим DNG с естественными цветами, а для меня естественность это красота. ИМХО.
Может имеет смысл сравнивать рав полученный с помощью инженерного мерю и с помощью обычной камеры на вашем аппарате, чтобы судить о целесообразности? Фото которые я выложил показывают, что в рав ДД расширился значительно по сравнению с жпег.
И если дорога из пунута А в пункт B лежит через пункт С и пункты A и B не связаны с собой отдельной дорогой, как алгоритму это задать?
… но, шмель об этом не знает и продолжает летать.
На счет «последовательности из 256 нулей последовательностью „256 0“ я с Вами абсолютно согласен это процесс сжатия.
Сейчас каждый день я меняю прошивки на своем телефоне и тестирую камеры и фото в RAW. Везде (даже на стоке) жпег снимки проигрывают по качеству.
На счет HDR — выход конечно, но имеет свои преимущества и недостатки. ИМХО. Предпочитаю сам обрабатывать фото, а не доверять встроенному ПО которое сделает это за меня по шаблону. Так же согласен что, способ требует немного больше времени, но мне, как человеку думающему перед щелчком затвора достается на обработку не так уж и много фото, а тот факт что с этих фото можно вытянуть намного больше чем обычно — будоражит воображение.
Может у Вас «ничего приличного не вышло» по субъективным причинам.
У меня, так же фото сделанные в рав формате на телефоне (Phoenix 2) лучше чем в жпег. (Про что свидетельствую приложенные фото в посте.) Констатирую лишь то, что возрастают возможности обработки. Вчера тестил этот способ на достаточно посредственной камере THL 4000, и даже там фото в рав смотрятся куда лучше чем в жпег при эквивалентной обработке.
По поводу «получить на выходе «красивую» равку». Тут имеется ввиду, что в некоторых телефонах (кастомных прошивках) рав непосредственно с инженерного меню телефона «синит», «желтит» или совсем получается цветовой каламбур. Именно по этому нужно подбирать значение cfa_colors в файле raw2nef.ini. Тогда на выходе мы получим DNG с естественными цветами, а для меня естественность это красота. ИМХО.