29.4.2012, 1:49:
Velké Bílovice
HEQ-5 bez pointace
Canon EOS 60D
Canon 200mm/f2.8 L II USM
1x ISO 1600, f/2.8, 120s
0x dark, 0x flat
Ano, jen jedna jedina expozice bez dark i flat frame. Astrofotografie vyžaduje střízlivého člověka…
As the maintainer, I was asked to summarize issues with famous Offline Application Cache, so here it is.
Current status of how application cache is implemented in Firefox isn’t perfect. From both the user’s point of view as well as developer’s point of view. Except web content, that didn’t adopt this technology very widely, there are new consumers: Boot2Gecko and Open Web Apps support. Time to return and improve.
The most important issues that may imply a spec update:
Most people (both users and developers) hate the prompt that pops up and needs to be accepted when a page or an app (I’ll use the word “app” in the following text) wants to cache it self. This is not that simple to remove because:
- If we accept automatically, we open potential for DoS attack on user’s storage. The limits for offline content are wider and there is a poor way of automatic eviction of offline cache from one’s disk if we want to behave by the spec.
- Accepting allows persistent cookies. In my opinion, more of a problem.
Until you visit the app’s main page again, the cache has no chance to get off of your disk. It can of course be deleted by Clear Recent History command (Shift-Ctrl-Del) and also somewhere deep in the Options dialog, but who does it? So the cache may easily just waste disk capacity.
The space on user’s disk dedicated to offline apps is large, so apps can pile. We’d like to lower the space limit down, mainly on mobile. It means to throw long time unused offline apps silently away sometimes.
Recently there had been introduced app “pinning”. “Pinned” apps are not removed automatically and have a separate (larger) disk space. That sounds opposite, right? But this opens space to turn common (unpinned) web apps to an intermediate layer. To explain:
- Layer 1 – Web content HTTP cache (this is not offline app cache): makes your browsing faster. Quickly flows, old content is silently threw away, replaced with more recent and current. The most recent news articles are cached here along with CSS of the page.
- Layer 2 – Offline application cache: intended to cache only the “code”, simpler said, persists “the machine”, not the data flowing through it. Design flaws prevent use of this level to improve caching to be more effective on usual web sites dayly used. I believe the “make this available when browser is offline” bit haven’t hit the target well. This level should just behave closer to how HTTP cache works – i.e. automatically.
- Layer 3 – Pinned applications cache: actually what the current spec for offline application cache is about, but even more persistent. It can, because it will have a full user’s consent – a prompt or some other obvious UX path such as an OWA installation. This will be used for critical applications that need to be available also offline.
To sum: change the default offline application cache behavior to be more like a “flow” then a “room for old boxes”.
DOM storage (window.localStorage) and IndexedDB content written by an offline app is not deleted along with cookies when history is deleted. The storage used by an app is understood as a storage for user’s critical data, like documents, email concepts, calendar entries, whatever, stored locally. That obviously cannot be deleted just by removing cookies.
This could however, when not accepted explicitly, be misused by a malicious site to store a very persistent cookies. Users delete their cookies to get rid of tracking or to log out, not to delete their work. If you want to delete any of these “very persistent” cookies, you have to delete all the app cached content and also your potentially critical data.
We may either remove support for such user data (I vote against!) or, do something of this:
- Split the ‘allow offline caching’ and ‘allow user’s documents’ privileges. Simply: when an app defines a manifest, cache it automatically, no prompt. When that app wants to use some data persistent storage to e.g. save your document concept, prompt to get user’s consent. This doesn’t allow tracking more then today, but I assume the prompt will appear in 90% of cases anyway. At least localStorage is widely used.
- Expose a new web content API that an app may use to ask for e.g. a new IndexedDB or localStorage instance to write and read critical data like documents that must not be deleted w/o user’s knowledge, or at least that simply as e.g. cookies. User may be prompted to let the app use this API. It may be similar to a selection of a file. Also we can bind to user’s identity managed by the browser. New open area to design.
Offline cache content of an app now updates only after you visit the app’s main page. Only then we check whether the manifest of the cache has changed on the server. If so, we download a new version. The whole page then has to refresh to use the newer version.
This behavior is by the spec. And has usability and also security implications since on the visit user may see and use the old content. It updates on next visit only or after an explicit refresh. So, you may always be one version late.
We want to change this to periodically check the manifest on the server. This will ensure that on next visit you won’t be bothered with reload and also will be using up to date content with all security issue fixed and so.
Středa 28.3.12. Původně jsem chtěl zkoušet můj nový kroužek pro afokální fotografii na planetách, neb dle předpovědi na meteoblue.com měl být seeing index 5 a 5. Na calsky.com ale byly tečky v meteogramu relativně velké, což mě mělo trknout. Seeing byl děsný. Podle meteoblue za to asi mohly jet streamy, předpověď byla myslím kolem 28, už v červených barvách. Přiště brát v potaz!
Takže jsem se uchýlil k širokoúhlým fotkám.
Krátce po západu slunce, srpek Měsíce a zářící Venuše s Jupiterem
To samé, v cca 22:00 už spolu s Orionem:
HEQ-5 bez pointace
Canon EOS 60D
Tokina 11-16 @ 11mm
5x ISO 1600, f/5.0, 60s
5x ISO 1600, f/5.0, 14s
1x ISO 1600, f/5.6, 1/2s
1x ISO 1600, f/5.6, 1/30s
Stack v Registax pro jednotlivé expozice, Photoshop: manuální HDR (spousta hraní)
Západ měsíce, to už se přihnali slibované mraky:
cca 0:41
HEQ-5 s lunárním pohybem
Canon EOS 60D
Canon EF 200mm/2.8L
ISO 200, f/3.2, 1x 1/8s + 1x 1s + 1x 5s
Photoshop: manuální HDR, saturace
Možná přibidou i další, ale zpracovaní Registaxem je docela katastrofa..
Byl páteční věčer 16.3.2012. Teplo. Jasno. Tak jsem vyrazil na jedno místo jižně od Prahy. A tady je výsledek:
Nejdříve chuťovka, širokoúhlý záběr zapadajícího Orionu a mléčné dráhy:
20:30 – 20:50
HEQ-5 s manuální pointací
Canon EOS 60D
Tokina 11-16 @ 11mm
1x ISO 1250, f/5.0, 26s
4x ISO 1600, f/4.0, 241s – 2x darkframe
Stack v Registax, Photoshop: 241s expozice: 32bit levels, 16bit HDR merge down (glow, detail decrease, saturation, gamma), manualní stack s 26s expozicí, levels, curves, jemně selectivní saturace
Všechny planety foceny Canon EOS 60D v primárním ohnisku, crop video 640 x 480/50fps na TAL-200K s 2x barlow na HEQ-5 (bez pointace), Registax 6 – asi 900 snímků a jemné doladění ve Photoshop.
Venuše (18:30, ISO 400, 1/1250)
Jupiter, dnes trochu nudnější (19:00, ISO 500, 1/160)
Mars (22:44, ISO 800, 1/200)
Saturn (23:07, ISO 3200, 1/80)
Kometa C/2009 P1 Garrad
0:16
HEQ-5 s manuální pointací
Canon EOS 60D
TAL-200K
1x ISO 2500, 180s
Photoshop: 32bit levels, 16bit HDR merge down (glow, detail decrease, saturation, gamma)
Manuální pointace je umění mě zatím vzdálené, takže hvězdy jsou stejně čárky. Ostatně celá tahle fotka je tak trochu pokus.
Mozilla puts a lot of effort to make Firefox faster and smoother. There is a lot of work made to find and optimize places of the code. However, I can see that sometimes developers are a bit guessing what to actually fix. I’m also part of this effort, so I decided to create a tool that would help with performance optimizations – a visualizer of all internal operations.
Profilers are nice but cannot always tell you well why UI of your app has been stuck for 2 seconds without an obvious reason.
In software so complex as Mozilla Platform and Firefox are a traditional profiler may not be able to help at all. Lot of events are being cross-posted between event queues and a lot of operations are asynchronous – i.e. w/o an immediate result. To find out what is actually slow is then hard.
My tool, on the other hand, can show you a pretty timeline with all events that have happened during Firefox run, what allows you to see where Firefox waits for a result too long … and also why.
All the work is tracked in Mozilla bug 729182.
Click the screen shot to open the visualization tool real-time example.
(The example log is a load of edition.cnn.com web site)
Oblíbené místo blízko Prahy, a obvyklé cíle pro srovnaní, byla strašná zima a foukal celkem vítr.
Jupiter.
Čas: 20.2.2012, cca 20:30
Optika: TAL-200K
Montáž: HEQ-5, ustavena hledáčkem
Aparát: Canon 60D v primárním ohnisku za 2x Barlow
Osvit: cca 3 minuty video crop 640 x 480/50, 1/60s, ISO 400
Úprava: Registax 6 (Limit cca 20% best frames), Photoshop (HiPass difference pro odstranění kruhů vzniklích při wavelet, Levels, Doostření)
Jádro M-42
Čas: 20.2.2012, cca 21:00
Optika: TAL-200K
Montáž: HEQ-5, ustavena hledáčkem
Aparát: Canon 60D v primárním ohnisku, ostření přes LiveView 10x zoom
Osvit: 4x30s, ISO 1600, +4x Darkframe, focený už doma za oknem 
Úprava: CameraRaw (Jen minimální doostření, cca 50% odstranění luminescenčního šumu), Registax 6, Photoshop (Curves, Levels, Sharpen)
Few days ago I wanted to buy the excellent Tokina 11-16/2.8 lens. I’ve discovered (with great help from guys both in Megapixel and Fotoškoda) it doesn’t correctly auto-focus at 11mm with my Canon EOS 30D (1.0.6) body.
At 11mm the lens produces a large front focus (even 15cm) on every shot taken. Since I’ve checked 8 (yes, by words: “eight”) pieces of this lens and all behave the same way, it seems to be a problem in the body it self. In general I assume, for any 30D, not just the one piece I own. I’ve tested the camera with other lenses such as Sigma 10-20/4-5.6, works perfectly. The camera is actually in a perfect shape. Also, one of the tested Tokinas apparently worked perfectly with e.g. Canon EOS 550D as I had a chance to check.
At 16mm, auto-focus with the Tokina works perfectly, so the problem (surprisingly) is only at the wide end.
After talking to AWH Canon service I have turned to Tokina dealer in CZ. After a phone call – they were quit surprised and really willing to accept and solve the issue – I’ve sent them some sample shots. I’ll see what the results will be. I really don’t want to buy a new camera just because I want this particular lens so much…
Here is the test image, single point focusing at the center (at the yellow Fotoškoda logo), 11mm, f/2.8, you can clearly see the large front focus:
I’ll post updates on this with Tokina dealer response.
Edit:
I’m going to buy a new body.
Tokina dealer let me test some 5 other pieces of this lens, and also some other types of lenses they sell. They all had the same problem. It makes me feel the body has a problem more then Tokina’s lenses.
The guy from Tokina, by the way – thanks for his time, told me that reports of issues like this are not that uncommon. Problem is that both sides always claim flaw is not on their side. Cameras and lenses are simply too complicated to work always perfectly…
However, it might be just problem of the revision of the Canon body I’ve got and not of all 30D’s around the world. I’ve found articles, actually reviews, of Canon 30D and Tokina 116 where all worked perfectly. According that Canon and Sigma lenses work well on the body, the issue really is just Canon+Tokina.
I decided to rather buy a new body. It’s hard, but I have to say I also have other reasons – for astrophotography currently available 60D seems better then 30D according opinions I’ve read. But you will see your self
Měsíc zdaleka není jen šedivý. Takhle vypadá, když trochu zvýrazníte barvy. Foceno ve spolupraci s Janem Přerovským.
Čas: 10.12.2011, cca 23:00, chvíli po uplňku
Optika: TAL-200K
Montáž: HEQ-5, ustavena hledáčkem
Aparát: Canon 5D Mark II v primárním ohnisku
Osvit: 15 x 1/128, ISO 100
Uprava: Registax 6, Photoshop 32-bit saturace, levels
Oblast Velké Mlhoviny v Orionu M42 a M43, Koňské Hlavy a NGC 2024. Trochu ohraná scenerie, ale jako test pro objektiv Canon EF 200mm f/2.8L II USM naprosto ideální.
Čas: 1:00 – 2:00, 29.11.2011
Aparát: Canon EOS 30D unmod
Optika: Canon EF 200mm
Montáž: HEQ-5, ustavena hledáčkem
Pointace: 0
Expozice: 5 x 60s/F3.2/ISO 1600 + 2 x 60s/F8.0/ISO 1600
Registax 6 (stack separatne pro F3.2 a F8.0)
Photoshop: Median Difference – 32 bit merge, HDR manual merge
Pravdou je, že fotogafile ve výsledku dělá dojem trochu jako cedník. Předpokládám, že je to chybějící flatfield a bias kompenzací. Všechny fotografie s vlastnim dark frame.
Plejády.
Expozice: 3 x 60s/F3.2/ISO 1600, zbytek stejný jako předešlá fotka.
Edit: nemůžu si pomoct, ale takle se mi zdá M42 daleko hezčí:
