Свежие комментарии

Багу все-таки стоило бы отрепортить, как мне кажется....

На гис-лабе посоветовали сначала по рядам обрезать юг-север а потом по столбцам запад-восток, вручную задавая границы. Работает, но оооочень заморочно, особенно столбцы выбирать в списке.
И, да, там поля ввода в градусах, по 20 минут задавать тоже так себе. Но работает. Идеально всё стыкуется.

> нафига она мне вся такая расжатая постоянно в памяти

Чтобы поскроллить ее и позумить быстро. Ну и память же надо куда-то девать, а то понакупили 64-битных систем...

Мне, кстати, сдается, что ты никогда до OpenGL-я не доходил. Я сам дошел где-то с год назад и до сих пор в изумлении, то что у меня в одной программе делает изрядно кода (скажем, ~1000 строк, потому что параллельно и все такое) - делает теперь (в дпугой программе) 20-строчный шейдер. Цена вопроса - чипсетные интелы с OpenGL 1.5, но таких уже крайне мало (и есть, в принципе, эмулятор на DX9)

Интуиция обманывает тебя.

Типичное время обработки (распаковки, преобразования, показа) "картинки фотоаппаратного размера, но не JPEG" - 2-4 секунды.
Что невероятно много, когда этих картинок - тысячи. А JPEG - не всех устраивает (и именно в эту группу я и целюсь своим софтом).

А смешнее всего то, что почти все "производители мелкой и средней руки" (но не Adobe) пользуются для этой "распаковки, преобразования" - одним и тем же кодом.

> Но за сжатие данных для передачи их в фронтенд для визуализации *внутри одного приложения* полагается ровно оно же.

Хранить легкосжимаемые данные в сжатом виде внутри программы - нормально.
Если у меня есть огромная картинка, и я никогда не показывать от неё юзеру больше маленького кусочка, нафига она мне вся такая расжатая постоянно в памяти?

> Вместе с тем, если ты считаешь, что пользователю не впадлу поаплоадить полгигабайта прежде чем начать работать - я это учту.

Нормальный домашний юзер с видеокамерой редко снимает ролики дольше трёх минут (собственно он редко снимает ролики дольше 40 секунд), и обычно он их хочет в итоге залить на Ютуб. Go figure.

"Вход на Ютуб с редактированием" - очень разумный сценарий приложения.

> Потому что сжать, чтобы тут же, через долю секунды, разжать - просто глупо.

Если через долю секунды - то не глупо, а пофигу.

Глупо если это медленно.

> Но на них эффективность еще важнее, чем на нормальном компьтере и идея кидаться внутри приложения жатыми PNG меня пугает.

Интуиция подсказывает мне, что в 21-м веке абсолютно любые операции, которые ты проделываешь с одиночной статической картинкой фотоаппаратного размера, выполняются за нулевое время на любом процессоре, включая телефонный.

Даже не ясно, репортить ли багу, и если репортить то -- как. Правовой статус что карт в примере что моей копии глобалмэппера сомнительный :)

Там, действительно, ерунда какая-то.

Потому что берешь лист, говоришь обрезать его до целых градусов - и режется криво.
А координаты показывает - прямо.

> Сбросьте с вашей камеры нежатый CinemaDNG, сконвертируйте его в mpeg

Это какие-то странные слова - CinemaDNG, mpeg... Загрузите .mts, получите .flv.

А ещё лучше - получите URL на ютубе.

> залейте на сайт за недельку

Ютубу это расскажи, про "за недельку". Сегодняшний миллиард новых ютубовских роликов начал аплоадится 4-го августа, бгг.

> Вопрос: а юзер этого безумия - кто?

Кто юзер онлайновых версий программ? Да все. Вот я например.

Ну вот я честно - не видел проблем ни с ggc (которые, правда, исходно электрические), ни с нормально отсканированным генштабом.

А что там с F47 - не знаю, надо смотреть что там за привязка (может она просто не в той системе координат, в которой карта?)

Слушай, а ты с GM вообще понимаешь как бороться? Я вот загрузил, скажем F-47 весь в 200k (двухкилометровка). Убираю рамки -- дыры в одну рамку шириной.
Но я запускаю Image Rectifier -- и смотрю, что восточные точки из листа, скажем, F-47-01 в точности попадают на рамку (западную) листа F-47-02. Т.е. привязка очень точная, точнее не сделать. И что теперь? Почему края плохо режутся?
И если пальцем на экране "прижать" край любого листа (начало рамки) и сказать Crop, то видно, что отрезает он гораздо дальше, чем рамка, залезая внутрь листа!

> Я все это прочитал и все равно не понимаю, что я выиграю

Ты выиграешь уплывание существенной части твоего продукта в очень высококачественную живую среду (HTML и CEF) из фиговатой и умирающей (Qt).

> обсуждать lossless PNG, имелся в виду, вероятно, нежатый, я не хочу

Имелся ввиду именно lossless. PNG сжимает внутри себя deflate-ом от zip-а. Непонятно, почему именно его ты не хочешь обсуждать, отличный формат для внутреннего обмена.

> Что потеряю - выше написано (в перечислении того, что я беру из Qt). Thread pool, Map/Reduce, общий одинаковый и работающий интерфейс к OpenGL, много всего.

Как-то ты это всё очень детально обсуждаешь, я бы даже сказал серьезно. Обычно когда человеку советуют выбросить нах глюкавый M$ Виндоуз и перейти на правильный кошерный Линукс ответ бывает короче и конкретнее.

Понятно что менять в живой программе базовую UI+ библиотеку на что-то совершенно другое как самый минимум очень лень.

Я все это прочитал и все равно не понимаю, что я выиграю (обсуждать lossless PNG, имелся в виду, вероятно, нежатый, я не хочу)?

Что потеряю - выше написано (в перечислении того, что я беру из Qt). Thread pool, Map/Reduce, общий одинаковый и работающий интерфейс к OpenGL, много всего.

> В смысле, "написан"?

В смысле написан.

> Как мне получить этот объект "внутри" яваскрипта?

Никаки. Связка между JS и C++ примерно на уровне SQL и C++. С++ объект внутри SQL не получают.

> Ну там скормить ему файл, подождать пока прожует, потом он выплюнет 400 мегабайт (например) RGB-битмепа

JS узнаёт у юзера имя файла и передает его C++. С++ жуёт. Когда прожевал - вызывает, например, OpenGL, если хочется экстрима.

> Сгенерировать JPEG и скормить его этому CEF-у? Херня же какая-то....

И так тоже можно. Только не JPEG конечно, а loseless PNG. Я бы именно так и сделал, и всё верчение-зуменье засунул в JS, типа такого:

http://demo.leadtools.com/HTML5/ViewerDemo.htm

> У меня приложение для быстрого жевания гигабайтов фоточек.

Ну и жуй себе, внутри C++. А потом отдавай простым UI-шны средствам для показа юзеру. Мы в 21-м веке, сейчас это визуалбейсиковая задачка - показать на экране двухмерную картинку сжатым размером ну пусть даже 60 мегабайт (на самом деле небось 16, да?). Делать надо через визуалбейсик, т.е. JS, canvas и WebGL как самый максимум. WebGL уже очевидно оверкилл для показа двухмерных картинок, но если надо извращений...