|
Notes |
|
|
(0005859)
|
|
zed
|
|
06-03-2012 14:26
|
|
|
vdemidov, с какого перепугу я вдруг стал ответственным за этот тикет? |
|
|
|
|
|
Ну ты ж разбирался с библиотекой экспорта в джепег. Можно его там сделать? Если нельзя или не хочешь, то просто закрой с won't fix. Я делать точно не буду. |
|
|
|
|
|
Я exif читал "руками", по оригинальной спецификации делал, писать тем кодом нельзя. Так что я тут тоже не помогу ничем. |
|
|
|
|
>Я делать точно не буду.
В постпроцессинге жпега весь сабж приравнивается к одной строчке, "вшивающей" привязку в экзиф юзая, например, EXIFtool (сорцы доступны).
http://en.wikipedia.org/wiki/ExifTool
Лично мне - некритично, у меня именно так и именно им и вшивается. Для проекта - было бы полезно в общем и целом, я так считаю. Сторонней фриварной тулзой или своими силами - некритично. |
|
|
|
(0005863)
|
|
zed
|
06-03-2012 14:56
(edited on: 06-03-2012 15:02) |
|
>Если нельзя
Честно говоря, я слабо представляю себе ситуацию, когда бы в jpeg нельзя было записать exif. Писать можно хоть руками, хоть либами (http://libexif.sourceforge.net/) хоть чем угодно ещё.
Та либа, которая сводит жпеги в файл, про exif ничего не знает, как и положено unix-way утилитам: "Делай что-то одно, но делай это хорошо" (c). Такой же философии придерживается и libexif.
|
|
|
|
|
|
PS: готов предоставить примеры пар "непривязанных"+"привязанных" жпегов, если этим кто-то будет вообще заниматься. Впрочем, любая привязка любого жпега на любые координаты делается, например, через тот же GeoSetter (http://www.geosetter.de/en/), внезапно юзающий все тот же ExifTool.... |
|
|
|
(0005865)
|
|
Parasite
|
06-03-2012 15:03
(edited on: 06-03-2012 15:04) |
|
PPS: недавно под Android появилось весьма годное приложение, юзающее GeoRef - распиаренное кучей изданий (через кои его нарыл и я лично), и уже собравшее кучу хитов.
http://sitis.mobi/geoview
Имхо, если планируется хоть какая-то экспансия проекта - то на тикет стоило бы обратить пристальное внимание.
|
|
|
|
(0005868)
|
|
vasketsov
|
06-03-2012 15:44
(edited on: 06-03-2012 15:45) |
|
>Та либа, которая сводит жпеги в файл, про exif ничего не знает, как и положено unix-way утилитам
Когда я пытался читать exif, я дошёл до той либы что читает jpeg-и. Точнее до реализации, используемой в сасе. Так вот если б там была хотя бы одна виртуальная функция, которой бы передавалось открытое изображение, чтобы почитать оттуда из каталогов внутри картинки - проблема с exif решилась бы "в одну строчку". Однако вклиниться в процесс чтения без переписывания либы (ну или что равносильно написанию своей либы) ну никак не получилось. Есть стойкое подозрение, что с сохранением будут те же яйца, только в профиль (если мы говорим за то как нагадить в exif при сохранении jpeg-ов из саса, а не о сферических лошадях на геостационарной орбите). Так что конкретно это - пример корявой с трудом рассширяемой реализации, а не unix-way.
А вообще конечно пункт не надо закрывать. Кому надо будет - тот сделает.
|
|
|
|
(0005870)
|
|
zed
|
|
06-03-2012 16:26
|
|
>Когда я пытался читать exif, я дошёл до той либы что читает jpeg-и.
Так то 2 совершенно разные задачи: читать/писать exif (мета-информация), и читать/писать jpeg (растр). И задачи эти решаются отдельно, двумя разными инструментами.
>Так вот если б там была хотя бы одна виртуальная функция
Не надо вилкой есть суп, для этого есть ложка.
>Так что конкретно это - пример корявой с трудом рассширяемой реализации, а не unix-way.
Неправда. Exif же можно писать не только в jpeg между прочим. Есть ещё tiff как минимум. И что, в каждой либе, формат растра которой поддерживает exif, пихать собственные костыли по чтению/записи? Вот это точно получится бедлам. Ну или что-то похожее на компоненты delphi "всё в одном", типа вампира, что работает чуть ли не с любым растром, но вываливается с out of memory при попытке свести большой файл.
>Кому надо будет - тот сделает.
1. Юзаем libjpeg и сводим растр на винт (done)
2. Юзаем libexif и дополняем раст любой вспомогательной информацией (some one ToDo) |
|
|
|
|
>2 совершенно разные задачи
Нифига подобного. Оттого что растр лежит не во всех "каталогах" картинки, суть от этого не меняется, сперва надо этот растр _найти_, а это НИЧЕМ не отличается от поиска EXIF. То бишь задачи по ходу чтения решаются _абсолютно_ идентичные - найти начало данных с нужным тэгом внутри картинки.
>в каждой либе, формат растра которой поддерживает exif, пихать собственные костыли по чтению/записи?
Нет, достаточно "завиртуалить" поиск тэгов каталога $FFD8, $FFFE, $FFE1 и т.п. и других аналогичных (в зависимости от формата) на уже открытом файле. Возможность этого совершенно очевидна самим существованием метаинформации типа exif. Читать exif - означает найти его положение в файле. Естественно "отщёлкивать" от него $457869660000 и возвращать Strings не надо. Зато представь себе необходимость читать Exif из тайлов в кэше - каково будет дважды искать-открывать-закрывать картинки?
> 1. Юзаем libjpeg и сводим растр на винт (done)
> 2. Юзаем libexif и дополняем раст любой вспомогательной информацией
Я ни за что не поверю, что unix-way подразумевает невозможность записи на носители, для которых либо невозможно чтение (лента), либо невозможна модификация уже существующих файлов (типа спецнастройки ftp). В этом и суть кривости имеющегося решения (по крайней мере с моей точки зрения). |
|
|
|
(0005872)
|
|
zed
|
|
06-03-2012 18:28
|
|
>Читать exif - означает найти его положение в файле.
А ну в таком случае и эта либа возможно сможет работать с exif:
"Some applications may need to insert or extract special data in the JPEG
datastream. The JPEG standard provides marker types "COM" (comment) and
"APP0" through "APP15" (application) to hold application-specific data."
т.е. там есть методы для записей своих "маркеров" в хедер жпега. Если exif пишется/читается в один из таких маркеров, то в общем-то и проблем быть не должно.
PS я лично под выражением читать exif понимаю распарсить его до состояния поле-значение, а не просто получить некий набор байт с пометкой "exif". |
|
|
|
(0005874)
|
|
zed
|
06-03-2012 21:08
(edited on: 06-03-2012 21:18) |
|
Да, походу так и есть: в тэг под маркером M_APP0 (0xE0) пишется стандартный 'JFIF', а в следующий тэг M_APP1 (0xE1), при желании, кладётся exif. Так что никаких проблем и в libjpeg соблюдён самый что ни на есть unix-way :)
|
|
|
|
(0005875)
|
|
vasketsov
|
06-03-2012 21:26
(edited on: 06-03-2012 21:28) |
|
>APP1
Я в курсе. Я про то что нельзя при чтении JPEG за один проход получить ВСЁ. По крайней мере _используемая_реализация_ это не позволяет. Чтобы было всё идеально - надо было про написании TJpegFileFormat.LoadData "ударить палец о палец" и вытащить наружу нечто похожее на procedure LoadMetaData. Этого захочено не было. Почему - ну наверное предполагалось что в частности я при чтении exif из тайлов GE (там правда не exif, а $FFFE) должен их сначала на хард скинуть ))). Ну естественно мне после такого фэйспалма проще было руками по спецификации разобрать. Тем более что в подавляющем большинстве случаев надо искать совершенно конкретный известный тэг, ведь мы ж не о редакторе произвольных exif-ов трём )).
>там есть методы для записей своих "маркеров" в хедер жпега
Ну тогда с записью проблем быть не должно.
|
|
|
|
(0005881)
|
|
zed
|
|
07-03-2012 04:41
|
|
>Я про то что нельзя при чтении JPEG за один проход получить ВСЁ.
Можно. Есть все необходимые методы как для чтения, так и для записи тегов.
>там правда не exif, а $FFFE
Это тэг M_COM = 0xfe - "комментарий" (COM). Ту да же, кстати, и САС пишет свои "копирайты" при сведении снимков.
>Ну естественно мне после такого фэйспалма проще было руками по спецификации разобрать.
Вот это действительно фэйспалм. RTFM:
- jpeg_save_markers: Control saving of COM and APPn markers into marker_list
- jpeg_set_marker_processor: Install a special processing method for COM or APPn markers |
|
|
|
|
|
Вопрос был не в либе, а в _используемой_реализации_ (TJpegFileFormat.LoadData). Безусловно можно было написать свой аналог TJpegFileFormat. Для разбора полутора указателей и буферов. |
|
|
|
(0005889)
|
|
zed
|
07-03-2012 05:29
(edited on: 07-03-2012 05:30) |
|
Кароч. не понимаю, что тебе не нравится, ну да ладно, а то мы слегка отклонились от тикета. Главное, что записать exif в жпег можно без проблем и твоё высказывание в третьем посте "писать тем кодом нельзя" ошибочно.
|
|
|
|
|
>твоё высказывание во втором посте "писать тем кодом нельзя"
Это было моё сообщение про мой ручной код моего чтения конкретных полей из COM\APP1 вообще без этой либы )))))) |
|
|
|
|
|
А почему бы не включить готовый ExifTool в сборку САСа? Благо что с помощью него всё делается мягко и не нарушая сна, функционала по экзифу там выше крыши (можно пихать например САСовский стринг + дату сведения\создания и прочие полезности), а папку /bin в САСе (куда можно и нужно класть всё подобное по теме) нам вроде Кришна нигде не запрещал... |
|
|
|
(0006031)
|
|
zed
|
|
13-03-2012 10:10
|
|
>готов предоставить примеры пар "непривязанных"+"привязанных" жпегов
Ну давай, раз готов. |
|
|
|
|
>Ну давай, раз готов.
Я сделаю даже немножко лучше: просто оставлю тут ссылку на удобнейшую фриварную тулзу для винды, коя умеет (пере)привязывать любой жпег в любую точку карты, просто утыкивая мышой в одну из карт (там их несколько, гугл - в наличии).
http://www.geosetter.de/en/
Прожка прекрасно юзабельна и сама по себе, в отрыве от фичреквеста. Авось кому пригодится.
PS: и она тоже юзает ExifTool... :)
PPS: смысловой аналог для Андроида - тут (http://sitis.mobi/geocam_pro/android), пикчу берет с камеры а привязку - с акселерометров\компаса\ГПСа. Нажал СПУСК - получил уже прекрасно привязанную фотку вплоть до углов обзора\наклонов. Тоже преудобнейшая вещь. Имеется клиент\просмотрщик сделанных фоток и под винду тоже. |
|
|
|
(0006042)
|
|
zed
|
|
13-03-2012 13:44
|
|
>Я сделаю даже немножко лучше
т.е. от тебя примеров не будет? |
|
|
|
|
>т.е. от тебя примеров не будет?
Могу, если так нужно. А смысл? Тулза привязывает любой жпег куда скажешь - вот и пара.
Я к тому, что экспериментировать уже можно _бесконечно_ и _моментально_, а не в пределах присланной мной пары. Но могу и прислать - не вопрос. |
|
|
|
(0006046)
|
|
zed
|
|
13-03-2012 14:11
|
|
|
Пришли один оригинальный тайл и кучку его реинкарнаций, привязанных к разным точкам. |
|
|
|
(0006100)
|
|
zed
|
|
14-03-2012 13:51
|
|
|
Не надо примеров. Разобрался. |
|
|
|
|
>Пришли один оригинальный тайл и кучку его реинкарнаций
Хорошо. Будет.
>Не надо примеров. Разобрался.
Хорошо. Не будет.
PS: и токи я склоняю к включению ExifTool в кучку к сасу, чтобы своего велосипеда не изобретать. Сугубо опционально - "если в папке /bin/ найден exiftool.exe - то фича доступна, если нет - то как обычно"
Благо что в эту же папку потом, позднее, можно напихать много чего из\для соседних хотелок. |
|
|
|
(0006240)
|
|
gpsMax
|
|
22-03-2012 08:13
|
|
|
А хотелка 72 - это сильно другое? |
|
|
|
(0006241)
|
|
Tolik
|
|
22-03-2012 08:24
|
|
|
Ну, настолько сильно, насколько jpeg отличается от tiff. |
|