uma coisa que dava jeito era poder ter no ecrã principal atalhos para aplicações. más notícias. para a maioria, não é possível. a samsung implementa uma api bondi, mas esta permite o acesso a escassas aplicações. claro que a samsung tem acesso a todas, com widgets até para aceder à aplicação da loja, que nem sequer consta na documentação. para as aplicações que interessa não deixam aceder…

além de aceder ao telemóvel, também seria interessante o acesso directo à web. é muito fácil criar pequenos atalhos no ecrã, estilo bookmarks. tive a ideia de ir mais longe, procurando poupar espaço comparativamente a essa solução. um pequeno widget do estilo da google, que vem no telemóvel, mas com botões configuráveis, e potencialmente ilimitados. surge o All Terrain Search:

a ideia é simples. uma caixa de texto e botões. se existir texto nessa caixa, o botão faz uma pesquisa no site. se a caixa estiver em branco, o botão redirecciona para a homepage. 4 botões não são lá grande coisa, portanto um scroll permite ver mais 4, e mais 4, e mais 4, tantos quanto inserir.

a ideia foi estruturar o código de maneira a que fosse simples adicionar novos motores. numa pasta individual colocam-se os ícones dos motores. qualquer que seja o tamanho da imagem, será sempre apresentada a 84×84 pixels. é recomendável redimensionar antes, uma vez que o rendering do browser estraga um pouco a qualidade das imagens.

as imagens são depois usadas num ficheiro javascript, onde o utilizador deve mexer para configurar a seu gosto. a lista de motores não passa de um array de variáveis com 3 propriedades: a homepage, a string para pesquisa e a localização da imagem. se o tamanho do array exceder o número de motores visíveis de uma vez, as restantes serão acedidas por scoll.

não queria usar um botão adicional e desperdiçar espaço, queria que um drag vertical no widget mudasse a lista de motores. o drag horizontal também seria interessante, mas esse será sempre apanhado primeiro pelo home screen, para mudar entre ecrãs. o scroll foi a maior perda de tempo. a samsung tem uma má implementação dos eventos touch no seu browser. a única coisa que me permitiu gerir com eficiência foi o evento onmousewheel, lançado aquando de arrastamentos do dedo. não funcionando como num computador, no entanto, o Event associado não tem a propriedade wheelDelta, que normalmente devolve a extensão/direcção do scroll. não consigo sequer saber se o scroll é para baixo ou para cima, só sei que houve scroll. ainda para mais, um arrastamento contínuo lança diversos eventos, o que provoca scrolls a mais, acidentais.

para solucionar os dois problemas, o scroll não faz bem scroll, mas faz cycle entre as páginas de motores. para evitar o lançamento consecutivo de vários scroll, quando capturo um primeiro deixo de ouvir o evento para só ouvir um quinto de segundo mais tarde:

scroll = function(e) { /* more like cycle through */
	page = (page + 1) % Math.ceil(engines.length / visibleEngines);

	/* disable scroll for a fifth of a sec */
	document.onmousewheel = null;
	setTimeout('document.onmousewheel = scroll', 200);

	changePage(page);
}

ao longo do episódio de south park emitido em 25 de março de 2009, stan tenta devolver uma misturadora que o pai comprou com um plano de pagamentos. como a loja não trata da dívida gerada com o plano, stan tem que se dirigir junto da companhia financeira responsável para obter a devolução.

acontece que o economista não pode devolver o dinheiro. o que ele faz é simplesmente convencer pessoas sem dinheiro a comprar uma misturadora, empacota as dívidas numa grande, e são os investidores em wall street que tratam delas.

uma vez em wall street, stan descobre que ainda não pode recuperar o seu dinheiro pois os investidores separaram o grande pacote em valores que pudessem vender aos bancos. no entanto os bancos também não podem fazer a devolução pois, uma vez que muita gente foi aos bancos à procura do retorno das misturadoras, o governo teve de comprar os valores aos bancos, para que não falissem.

então stan dirige-se ao departamento do tesouro. ali explica a situação, e dizem-lhe de imediato que não há problema, apenas precisam de consultar as tabelas para ver o valor que que lhe devem devolver. de regresso de uma sala, ensanguentados, os funcionários anunciam o valor de investimento no total de 90 trilhões de dólares (biliões, no nosso sistema).

entretanto surge uma emergência com uma companhia de serguros prestes a falir, e os funcionários têm de ir lá dentro verificar os gráficos para ver o que fazer. stan entra e espreita: solta-se uma galinha decapitada, onde cair é a jogada mais prudente:

metáfora: galinhas
realidade: polvos

humm… doesn’t seem that different, to me!

desta vez custou um pouco mais começar, pois foi preciso ler um pouco sobre controlos e containers. no fundo não há muita diferença relativamente a outros toolkits gráficos. comparando com gtk, que foi o último que usei, para o bada também tenho duas hipóteses: posso programar e colocar os controlos todos no sítio com código, ou posso desenhar no ide e depois, no código, pedir para que sejam colocados no sítio e obter o handle. nada de especial.

o problema que há com este modo de programação do bada, para mim, é que as callbacks para os módulos geradores de eventos não são passadas explicitamente. o que é passado é uma classe que implemente (herde, em c++) uma interface IModuleEventListener. além disto não podemos definir argumentos para passar a essas funções. resultado: torna-se complicado gerir a partilha de recursos a serem utilizados na rotina de atendimento. o que é que eu fiz? o módulo principal herda tudo… felizmente não há colisões, mas neste caso não vi que fizesse sentido criar módulos diferentes. uma vez que vou tratar de eventos wifi, e da interface, bem como os genéricos das aplicações, isto é a classe criada:

class WifiSmith :
	public Osp::App::Application,
	public Osp::System::IScreenEventListener,
	public Osp::Ui::IActionEventListener,
	public Osp::Net::Wifi::IWifiManagerEventListener,
	public Osp::Ui::IItemEventListener
{

em vez de dar uma caixa de texto e um botão “do the magic” achei que seria mais interessante (e até mais simples) limitar-me a pegar no wi-fi, obter uma lista das redes disponíveis e listá-las. isto foi muito fácil de fazer. ao construir o manifest.xml no site, tive de adicionar privilégio WIFI. isto permite fazer todas as operações com o módulo wi-fi, excepto Connect(). para ligar é necessário permissões WIFI_MANAGER. infelizemente, só parceiros da samsung podem pertencer a este grupo, pois é necessário um nível de acesso SYSTEM. uma parvoíce, a meu ver. qualquer que seja a parte da api, não vejo motivo para que alguém que pague (ou receba?) tenha acesso e os outros não. no entanto esta limitação apenas impede publicação na loja; o grupo pode ser adicionado manualmente no ficheiro xml, mas a aplicação será certamente rejeitada na loja:

<Privileges>
	<Privilege>
		<Name>WIFI</Name>
	</Privilege>
	<Privilege>
		<Name>WIFI_MANAGER</Name>
	</Privilege>
</Privileges>

para compilar com permissões especiais é preciso, com frequência, adicionar uma biblioteca para linkagem, neste caso FNet. verdade para o simulador, para o telemóvel parece-me estar tudo na mesma biblioteca, FOsp.

a interface da aplicação é muito simples. dois botões em baixo, um “refresh” e outro “back”. gosto das aplicações que têm botão de saída no ecrã, não gosto de usar o físico. no editor visual: as duas SOFTKEY activas e uma List que ocupa todo o ecrã. a List permite scroll se os elementos excederem o espaço reservado. a SlidableList serve para listas grandes, e alocação dinâmica dos elementos que interessam ver num dado momento apenas. no início desenho esta estrutura, associo as callbacks, e inicializo as variáveis necessárias:

bool
WifiSmith::OnAppInitializing(AppRegistry& appRegistry)
{
	// draw the form
	MainForm *pMainForm = new MainForm();
	pMainForm->Construct(L"IDF_FORM1");
	Frame *pFrame = GetAppFrame()->GetFrame();
	pFrame->AddControl(*pMainForm);
	pFrame->SetCurrentForm(*pMainForm);
	pMainForm->SetSoftkeyActionId(SOFTKEY_1, SOFTKEY_1);
	pMainForm->AddSoftkeyActionListener(SOFTKEY_1, *this); // register back button event
	pMainForm->SetSoftkeyActionId(SOFTKEY_0, SOFTKEY_0);
	pMainForm->AddSoftkeyActionListener(SOFTKEY_0, *this); // register refresh button event
	pMainForm->RequestRedraw();

	// set the wifimanager
	pWifiManager.Construct(*this);

	// get the essid list control
	pEssidListControl = (List*)pMainForm->GetControl("IDC_LIST1");
	pEssidListControl->AddItemEventListener(*this);

	return true;
}

que no fim liberto:

bool
WifiSmith::OnAppTerminating(AppRegistry& appRegistry, bool forcedTermination)
{
	// decided to use dynamic allocation for the WifiManager and the list of WifiBssInfo (networks)
	delete pEssidListControl;

	return true;
}

sair da aplicação faz-se chamando o método Application::Terminate(). este método parece só estar acessível no módulo principal. tentei mesmo Application::GetInstance()->Terminate() noutros módulos, mas nem assim consegui compilar. azelhice minha, talvez. a cada refresh limpa-se e volta-se a preencher a lista de redes disponíveis:

void
WifiSmith::OnWifiActivated(result r)
{
	pWifiManager.Scan();
}

 // SOFTKEYs
void
WifiSmith::OnActionPerformed(const Osp::Ui::Control &source, int actionId)
{
	// SOFTKEY_0 is just the actionId I associated with it on line 42, it's not really the key.
	if(actionId == SOFTKEY_0) // refresh
	{
		RefreshList();
	}
	else
	{
		Application::Terminate();
	}
}

void
WifiSmith::RefreshList()
{
	// clear the essid list
	pEssidListControl->RemoveAllItems();
	pEssidListControl->RequestRedraw();

	// turn on wifi, if off
	if(!pWifiManager.IsActivated())
	{
		MessageBox vMessageBox;
		vMessageBox.Construct("Action required!", "WiFi needs to be ON for scanning! Turn on?", MSGBOX_STYLE_YESNO, 0);
		int modalResult;
		vMessageBox.ShowAndWait(modalResult);

		if(modalResult == MSGBOX_RESULT_YES)
		{
			pWifiManager.Activate();
		}
		else
		{
			Application::Terminate();
		}
	}
	else
	{
		// get the available networks
		OnWifiActivated(E_SUCCESS);
	}
}

quando o wi-fi está desligado é na função refresh que pergunto ao utilizador se pretende activar, com uma MessageBox. se não o fizer, a aplicação termina. faria sentido chamar a RefreshList() na inicialização. no entanto há um problema de concorrência. enquanto a aplicação está a arrancar é mostrada uma “imagem splash”. por algum motivo a aplicação bloqueia nesse splash se tentar abrir uma MessageBox algures na função OnAppInitializing(). provavelmente funcionaria na função OnForeground(), mas nesse caso tinha de controlar o estado da aplicação com uma nova variável, pois a função OnForeground() é chamada sempre que se volta ao foreground, e não apenas da primeira vez. continuo a achar que o problema é do sistema operativo, algo diferente devia acontecer.

findo o Scan(), preenche-se novamente a lista:

void
WifiSmith::OnWifiScanCompletedN(const Osp::Base::Collection::IList *pWifiBssInfoList, result r)
{
	pNetworkList.RemoveAll();
	pNetworkList.AddItems(*pWifiBssInfoList);

	for(int r = 0; r < pNetworkList.GetCount(); r++)
	{
		WifiBssInfo *currentBssInfo = (WifiBssInfo*)pNetworkList.GetAt(r);
		pEssidListControl->AddItem(&currentBssInfo->GetSsid(), null, null, null, r);
	}
	pEssidListControl->RequestRedraw(true);
}

para quem não viu até aqui, é fácil perceber que não há muito tratamento de erros. esta função, por exemplo, indica com a variável r se o Scan() teve ou não sucesso. no entanto pouca diferença faz para o código que escrevi. mais, por motivos de eficiência, o mecanismo de controlo de excepções do c++ foi completamente ignorado pela samsung, não existem excepções no bada. o compilador até me avisou que, na linha 111, estou a passar um endereço de uma variável temporária. como nunca me deu problemas, não senti necessidade de copiar os nomes para uma lista.

depois de listadas as redes, é possível ver a listagem no telemóvel. clicando em qualquer rede, tenta-se ligar:

void
WifiSmith::OnItemStateChanged(const Osp::Ui::Control &source, int index, int itemId, Osp::Ui::ItemStatus status)
{
	WifiBssInfo *pWifiBssInfo = (WifiBssInfo*)pNetworkList.GetAt(itemId);
	const WifiSecurityInfo *pWifiSecurityInfo = pWifiBssInfo->GetSecurityInfo();

	// if open and no encryption, go right ahead!
	if(pWifiSecurityInfo->GetAuthenticationType() == WIFI_AUTHENTICATION_OPEN
			&& pWifiSecurityInfo->GetEncryptionType() == WIFI_ENCRYPTION_NONE)
	{
		pWifiManager.Connect(*pWifiBssInfo);
	}
}

lembre-se que, na linha 111, dei um itemId a cada elemento da List igual ao índice dessa rede na lista de redes. no fim da tentativa de ligação à rede, posso informar o utilizador:

void
WifiSmith::OnWifiConnected(const Osp::Base::String &ssid, result r)
{
	MessageBox vMessageBox;
	int modalResult;

	if(r == E_SUCCESS)
	{
		vMessageBox.Construct("Connected:", ssid, MSGBOX_STYLE_OK, 0);
	}
	else
	{
		vMessageBox.Construct("Unable to connect:", ssid, MSGBOX_STYLE_OK, 0);
	}

	vMessageBox.ShowAndWait(modalResult);
}

por vários motivos, neste código só me ligo a redes abertas. o primeiro é o facto de ainda não ter tratado disso. o segundo é que, quando fui a testar o caso dos routers thomson, por exemplo, acabei por descobrir que a resolução das chaves é um tanto ou quanto probabilística, e nem sequer funcionou para alguns casos que testei. o terceiro motivo é o facto de subscrever um aditivo internet, como faz todo o sentido, com este telemóvel, e até porque não frequento sítios atulhados de redes vulneráveis.

no entanto acrescentar esta funcionalidade, para mim, faz-se do seguinte modo: começa-se por criar uma classe que recebe um WifiBssInfo e, com essa informação (provavelmente só ssi e bssid), identifica o tipo de router com que está a lidar e devolve, de acordo, a chave a utilizar. pode ainda disponibilizar um método booleano do tipo CanSolve() o que permitirá, no tempo da listagem, mostrar apenas as redes com que é possível lidar. por último, uma vez que alguns algoritmos devolvem mais que uma chave, a função OnWifiConnected() deve implementar uma máquina de estados que permita tentar a chave seguinte para a mesma rede, caso a ligação tenha falhado, e até que não existam mais chaves. nada mais!

algumas capturas:

(uau, this sucks! é preciso mesmo clicar nas imagens, parece que os thumbnails do wordpress cortam a imagem…)

o primeiro passo foi obter o ide/sdk. nada a assinalar, trata-se do eclipse. o problema é que as tralhas da samsung exigem windows, e logo aqui desmoralizo fortemente. felizmente não estou sozinho, há mais quem gostasse de desenvolver para bada em linux, vamos confiar nos rumores que tendem a nosso favor! é um pouco estranho ter de esperar, uma vez que o próprio bada é baseado em linux, e o eclipse é até dos poucos ambientes decentes para este sistema operativo.

ligeiramente relutante, lá avancei à descoberta da documentação. o primeiro projecto seria colmatar a falha da loja: não existe uma lanterna. melhor, existe, mas usa o ecrã para iluminar, com um led tão bom do outro lado, junto à câmara.

depressa relembro como não sou grande fã de programação por eventos. o que vale é que c++ permite herança múltipla, e então é mais fácil atulhar a classe principal de métodos para atender eventos desde a bateria ao flash. a minha ideia de aplicação seria que o próprio programa fosse o botão de flash. isto é, ligar o flash seria tão simples como ligar o programa, que saía de imediato. desligar seria iniciar novamente a aplicação. um toggle!

neste caso de utilização não precisava de mais do que criar um objecto de acesso à câmara, que me dá controlo sobre o flash. se o IsFlashOn(), SetFlash(false), senão SetFlash(true). o IsFlashOn() funciona, o problema é que o SetFlash(true) liga o flash, mas não inicia a iluminação, per se. a iluminação é feita apenas ao utilizar a câmara, provavelmente desde que se inicia a focagem até à captura. talvez por este motivo não tenha aparecido a aplicação na loja…

além desta característica do sistema, tive outro problema. se não libertar a câmara quando a aplicação terminar, azar, tenho de reiniciar o telemóvel! nas funções que o ide cria automaticamente têm o cuidado de dizer na rotina OnAppTerminating(), em comentário, que se deve libertar a memória e os recursos. pergunto-me se o sistema operativo limpa a memória não libertada pelo programador???, caso contrário seria muito problemático deixar qualquer pessoa programar para o bada!

sobre este aspecto, parece que demora muito tempo até que uma aplicação seja admitida na loja. talvez seja esse o motivo para ainda não haver muitas aplicações (sinceramente não estou a ver lugar para muitas mais úteis…). por um lado é bom saber que as aplicações à disposição foram vistas e revistas, por outro deve ser altamente desmotivante para o programador…

podia considerar-me preguiçoso por não despender esse tempo com mais frequência? os amigos com quem hoje estou diariamente ficarão um dia esses contactos esporádicos. não são amizades maiores ou menores, melhores ou piores, mas têm papéis diferentes. relações desiguais que marcam fases da vida. os cheiros, olhares, sorrisos, vozes, que me permitem reviver o passado e ansiar o futuro.

eu acho que a viagem no tempo é um tema de conversa muito interessante, mas não suporto que se fale dela em termos científicos, muito menos em tom de leis. a primeira:

não se pode voltar atrás no tempo, as fórmulas não o permitem. é um mecanismo que a natureza tem de se proteger!

parece razoável: como é que se lidava com alterações no passado que criassem paradoxos no presente? boa pergunta, mas não ter resposta prova a impossibilidade? há milhares de anos era “impossível dar a volta ao mundo”, pois “o mundo era plano”. hoje é impossível voltar atrás no tempo, mas porquê?

se voltasses atrás no tempo e morresses, o que é que acontecia agora, que estás a falar comigo?

não sei, mas isto não prova que não é possível, só prova ignorância. eu não sei explicar o que acontece no meu cérebro que me permita escrever, no entanto escrevo. mas sei que o cérebro tem um papel no processo, já é qualquer coisa. para defender a resolução deste paradoxo gosto da física quântica, que afirma a existência de ramificações de universos num grande multiverso. isto é, se eu voltar atrás no tempo e morrer, estou a criar uma bifurcação. numa delas estou aqui, a escrever. noutra não estou, e outras coisas totalmente diferentes acontecem.

viajar para o futuro é possível, e está provado. os sistemas de gps precisam de ajustes devido ao facto de estarem afastados da terra. segundo einstein, o tempo passa mais devagar perto de objectos de grande massa.

bem, duas brincadeiras. claro que é possível viajar no tempo para o futuro. estou a fazê-lo neste preciso momento. não me sinto parado no tempo. corpos de grande massa: sim, se estiver ao pé de uma menina gorda o tempo parece passar mais devagar do que se estiver ao pé de uma menina elegante. =) relatividade de einstein. sabia umas coisas, o homem!

para provar estas teorias, usam-se relógios atómicos. uns na terra, uns no espaço, outros ali pela atmosfera às voltas para um lado e para o outro. no fim juntam-se e todos mostram durações diferentes. o que eu sei sobre os relógios atómicos é que são muito precisos, regulares. o que eu sei também é que um relógio não sustenta a noção de tempo. isto é, porque é que se diz que o tempo contrai e dilata e não se diz que o relógio alterou o seu período? se calhar as diferentes condições de velocidade e de massa condicionam o funcionamento dos relógios, e não o tempo em si.

se circundares a terra à velocidade da luz durante 40 anos, quando aterrares passaram 10’000 anos na terra, ou coisa que o valha.

até pode ser, mas o facto de eu ter envelhecido apenas 40 anos não implica que o tempo tenha mudado. explica apenas que eu envelheci a uma taxa de 40 anos por 10’000. o que mudou, a meu ver, foi a minha percepção do tempo, e a velocidade dos meus mecanismos biológicos. se é essa a noção de tempo, então claro que é fácil viajar, mesmo para trás: qualquer envelhecimento reversível.

não tenho para mim que envelhecer mais rápido ou mais devagar em relação a outros seja viagem no tempo. viagem no tempo consiste em saltar entre momentos diferentes de um tempo a 3 dimensões, se é que existem! há tanta coisa escrita que nem me atrevo a citar (nem a ler!). acredito em viagens no tempo, claro, e que o homem conseguiria controlar, mas acho que a extinção chegará antes desse dia. sem a discussão e as teorias científicas não era possível avançar, mas deixo isso para os tolos. por enquanto, e com tantas incertezas, o tema ao café não passa de filosofia.

autonomous driving robots frequently use cameras for object and road detection. after detecting such elements in an image it must be able to locate them in the real world, or else the image serves no purpose. that’s the ipm: a means of associating points in an image to points in the car coordinate system. to do obtain it, one only has to understand the transformations that occur when points are projected in an image and undo all those steps, for each point of the image, thus obtaining the real coordinates of each pixel.

a little geometry:

the first transformation to consider is the one relative to the mechanics of the camera, the way it was constructed. correction of these values comprehends the calibration of the focal distance and the alignment of the lens relative to the projective plane, the image sensor. this requires finding 4 unknowns, that are used in this way:

the left part contains the corrected points and the right part the original point coordinates in the real world, multiplied by a matrix. this matrix describes a change in scale as well as a translation. this operation gives us an image that is equivalent to the one obtained if we were using a pinhole camera.

the camera is now perfect, but the lens is still uncorrected. usually lenses produce radial distortion in the projection. this distortion is quite intense if using fisheye lenses. that’s actually the case in the considered robot. due to mechanical constraints, the camera is quite close to the road, and using a normal lens would yield a fairly small field of view. on top of that, some might consider that in practice it is hard to have the lens perfectly parallel to the image sensor, which is a requirement for an undistorted projection. these two problems are solved with 5 new parameters, as corrected by the first few terms of a taylor expansion around the center of the lens [bradski, kaehler]:

after these two transformations we say that the camera is calibrated for the intrinsic parameters. at this point, if we know the position of the camera relative to the floor, elementary geometry allows us to solve the position of each point. usually, though, it’s hard to mount a camera with a specific angle to the floor, at a fixed height. to find these parameters we need to solve for the perspective transformation. this transformation basically will allow us to obtain a bird’s eye view of whatever the camera is capturing. this transform is given by the following operation [bevilacqua, gherardi, carozza]:

on the left we have the corrected image point, on the right the matrix that describes its rotations and translations, and the uncorrected image point. these rotations and translations are the unknowns, called the extrinsic parameters. once we have a bird’s eye view of the scene we can infer distances between points. we just need to locate one point, so we’ll be able to define a fixed coordinate for all points.

a little code:

when you don’t know these parameters, because cameras don’t have a datasheet stating the angle between the lens and the sensor, or how much the lens distorts the image, you can obtain them capturing know objects with identifiable points. chessboards are a good example. fortunately i had to do very little with this math introduction to calibrate the image, because opencv solved most of these problems with just a few function calls. anyway, i didn’t know that until i studied image projection, and it eventually came handy to know the inner works.

so, opencv provides me: a way of detecting chessboard corners, those referred easily identifiable points; given a series of chessboards, the intrinsic parameters; given four image points and their corrected projection, the extrinsic parameters.

detecting chessboard corners is a call away from cvFindChessboardCorners(). this accepts an image and returns a list of points. this list of points can be used, along with the image that produced them, to call cvFindCornerSubPix(), and get subpixel accuracy on those same points.

given a series of captures of different images from chessboards, which will produce a series of lists of points, opencv provides cvCalibrateCamera2(), that calculates the rotations and translations of the chessboard between captures, thus fixing all 9 intrinsic parameters. it should be noted that, for better results, at least 10 chessboard captures should be done. using cvUndistort2() one is able to see the result of correcting an image for the intrinsic parameters. this is easily evaluated for fisheye lenses, since after the calibration no visible distortion should be noticed. straight lines should remain straight [devernay, faugeras]. cvUndistortPoints() corrects a sparse set of points instead of a whole image.

once calibrated for the intrinsic parameters, we can find all 8 extrinsic parameters (the matrix is normalized so that ) using 4 collinear points (their ideal and distorted positions). one can do this laying a chessboard on the road and detecting the outermost corners. we know that these form a rectangle, so we can fix 4 coordinates that form a rectangle where those corners should be projected. opencv allows us to do this using cvGetPerspectiveTransform(). the result can be observed with a call to cvWarpPerspective(), which yields the referred bird’s eye view (or the result of any other calculated perspective transform). cvPerspectiveTransform() corrects a sparse set of points instead of a whole image.

so, since we now have a bird’s eye view, we only need to locate two points in the image and indicate their real coordinates. this will allow us to both find the relation between distances in pixels and distances in the real world and also fix the location of all the points.

conclusion:

this is pretty much an overview what i’ve been doing, and is greatly based on “learning opencv: computer vision with the opencv library“, from o’reilly media. further steps include making use of this map to abstract algorithms such as “lane detection”, “car positioning”, to work at a car coordinate level, instead of image coordinates. this will not only make it easier for the programmer to produce algorithms but will also facilitate porting solutions to other architectures, and different camera mounts.

the project code is not public per se, but i’m free to disclose any requested parts.

sobre as t-shirts, a ideia surgiu-me ao acordar, claro, talvez porque durante o sono estive a arrumar os acontecimentos dos últimos dias em aveiro, onde foi depositada muita atenção nas minhas cores.

sobre o telemóvel, tenho uma história mais longa. há já algum tempo que procurava um telemóvel que me permitisse uma maior e melhor sincronização de calendários, contactos, e-mail e redes sociais como bónus. apesar de ter surgido muito antes, esta ideia tornou-se mais forte com o aparecimento de um android acessível no mercado português, o htc magic. acontece que, picuinhas como sou, não o comprei. o que se passava na altura, e ainda agora, é que todos os telemóveis da htc tinham um compromisso: ou era o ecrã, ou a memória, ou o processador, esquecendo o preço. enfim… não gosto de compromissos! graças ao empurrão na pesquisa dei para olhar para outros mercados, como o alguns symbian da nokia, e mesmo o iphone. quanto aos symbian, apesar da instalação no mercado, dei-os como mortos, lentos, e mesmo com bugs. quanto aos iphone é fácil esquecer a paixão, pois o preço nunca se justifica.

a febre passou até que um dia, por engano, tropecei no samsung wave. engraçado o preço ter sido a primeira coisa a reparar, 340€ na vodafone. até seria caro, dependendo do que tinha dentro. mas até fui ver o que tinha dentro. não descobri senão um ecrã maravilhoso, um processador potente, e uma autonomia razoável. vi logo que seria um bom negócio, e já lá vai mais de um mês e muitas reviews. depois de muita espera na vodafone acabei por comprar na expansys, que fez um excelente serviço aos melhores preços.

o maior medo era o bada, o novo sistema operativo da samsung. olhando para os vídeos a interface notava-se muito fluida, e com todas as funcionalidades básicas. o defeito é a escassez de aplicações. dei por mim a ser desencorajado por colegas com android, e perguntei quantas aplicações já tinham descarregado, ao que me responderam centenas. perguntei se eram úteis, e disseram que sim, liam códigos de barras no supermercado. perguntei quantas vezes fizeram isso: uma. é verdade, uma. o telemóvel para mim, apesar de necessitar de funcionalidades avançadas, não necessita de acasalar com outros, nem exprimir o quanto sou pobre. precisa de fazer o que disse inicialmente: sincronizar e comunicar.

acontece que este telemóvel faz isso na perfeição. há já muito tempo, na perspectiva de comprar um telemóvel novo, ou ser assaltado e perder o cartão, comecei a organizar os contactos no google contacts, com fotos, datas de nascimento, a história toda. uma das primeiras coisas que fiz com o novo wave foi sincronizar a conta do google et voilá, os contactos estavam no meu telemóvel, foto e tudo, o que não acontece em muitos clientes activesync. configurei a conta do facebook e seleccionei uma série de contactos para importar. a maioria deles ficou associado com os do google, mas outros tive de associar manualmente. a associação automática é feita, parece-me, por campos de contacto comuns entre as pessoas, como o e-mail ou o número de telefone. para as pessoas que não têm estas informações no facebook é impossível adivinhar, e associar pelo nome seria até indesejável. infelizmente o telefone faz uma certa distinção entre os contactos das contas de sincronização, o cartão sim e o telefone, não sendo possível a cópia entre o primeiro e os dois últimos e vice versa.

tive há dias a oportunidade de mexer num motorola droid. achei extremamente esquisito que o android não forneça um mecanismo para terminar aplicações. por um lado faz sentido, só as termina quando for preciso (mas ao menos deixa o utilizador escolher?), por outro não faz sentido nenhum, pois as aplicações ficam em segundo plano a consumir recursos… oops, não! não ficam! ficam em memória, mas não lhe é concedido processamento! quer dizer, eu carrego uma página web mas entretanto gostava de verificar uma mensagem que recebi, quando volto à aplicação é que a página continua a carregar! isto não acontece com o wave. o wave tem verdadeiro multitasking, neste exemplo a página continua a carregar e, quando volto ao browser, tenho tudo arrumadinho para consulta. infelizmente, e na única situação que me apercebi de lentidão, um evento em segundo plano que encrava ligeiramente a fluidez são os avisos de nova mensagem, novo e-mail, etc. talvez um problema do escalonador, talvez uma necessidade enorme de processador.

sobre a câmara, o resultado não está propriamente à vista, mas estou satisfeito. é fácil encontrar exemplos de vídeos e fotos na net, mas sempre tendo em conta que são “apontar e disparar”, nada cuidado. apesar de tirar boas fotos e óptimo vídeo, acredito que a fotografia é muito mais do que perfeição de imagens. apesar de uns milhares de euros fornecerem um potencial enorme em termos comerciais, a fotografia amadora é mais acerca de captar momentos, e exprimir sensações, que está muito além de resoluções, sensibilidades, tempos de exposição… mesmo assim existem algumas possibilidades de manipulação destes parâmetros, nomeadamente a exposição, alguns efeitos de pós processamento, etc.

quanto à autonomia, claro que não é telemóvel para durar uma semana, mas isso também depende do uso que se lhe dá. isto é, durante a noite, em rede 2G e sem outras conectividades ligadas, a bateria desce cerca de 5%. feitas as contas, se o deixar assim, dura 6 dias, o que vai além de muitos telemóveis sem motivo para consumir mais. esta bateria aguenta seguramente dois dias cada um com duas horas de mensagens de texto, 10 minutos de conversação, meia hora de wi-fi, 15 minutos de need for speed: shift. talvez mais.

no final de contas não me arrependo do investimento. ao fim de tanto tempo foi o único telemóvel que me captou a atenção em termos de qualidade/características/preço e, até agora, ficou à altura. também não foi só a mim que captou a atenção. este telemóvel ainda não chegou a todos os mercados e já esgotou em muitas lojas. é fácil também encontrar pela internet muitos fóruns e conversas dedicadas ao telemóvel e ao sistema operativo; a actividade no gsmarena não deixa dúvidas; e o objectivo da samsung em duplicar a quota no próximo ano parece-me já ter estado muito mais longe.

os autores, e o autor, fazem um óptimo trabalho a projectar os seus sentimentos mais profundos e a sua personalidade. do modo como o fazem, no entanto, facilmente se esquece o mal que traz aos que mais ama, e que acabam sempre do lado dele. o modo como o fazem transparece o seu perfeito descontrolo pelas suas acções, o que justifica o seu ódio e nos provoca também a solidariedade com a personagem. karen é uma mártir. apesar de não serem casados, amam-se incontrolavelmente. apesar de não o fazer por mal, a dificuldade de hank em definir um objectivo na vida traz sofrimento intermitente sobre karen, o que resulta numa impossibilidade de ficarem juntos por períodos longos. ambos inteligentes, com potencial, mantêm becca em comum, que é a verdadeira fonte de sabedoria na família, apesar de uma adolescência assolada pela incompatibilidade dos pais.

é verdadeiramente uma família de merda, mas o modo como é mostrado faz qualquer um desejar pertencer à história, trocar as nossos simples dias pelos seus momentos complicados, pois cada episódio mostra sofrimento duro, mas esconde o verdadeiro sentido da vida, amor.

entretanto continua pendente o primeiro mergulho deste verão, uma queda livre para um banho de emoções.