Nem Nintendo szoftver első futtatása a 4.3-as Wii-n

Ez a cikk a sokkal későbbi kistestvére annak, amelyben ugyanezt a 4.2-es szoftverhez magyaráztam el. Mivel nekem is szükségem lett rá, most összeszedtem hogy lehet a legfrissebb, 4.3-as rendszerverziójú Wiiken ugyanazt megcsinálni.
Jó eséllyel ennél újabb verziót már nem ad majd ki a Nintendo, a garanciád úgyis lejárt a gépre, úgyhogy hajrá! :)
Nézd meg, hogy milyen verziójó a Wii rendszerszoftvere: válaszd ki a főképernyőn a Wii Opciók kerek gombját balra lent:

Aztán a beállításokat, a jobboldali nagy gomb:

És itt a jobb felső sarokbán látható a Ver(ziószám):

Ha itt nem 4.3-at látsz, akkor használd inkább az előző leírást! Ha 4.3-assal van dolgod, akkor még egy dologra lesz szükség: menj egy menüvel jobban és válaszd ki az Internet opciót:

...aztán a Console Informationt:

Itt jegyezd le (vagy fotózd le :) a MAC címet:

A következő lépéseket a számítógépeden kell elvégezni, nem a Wiivel. Szükséged lesz hozzá egy üres, 4GB-nál kisebb FAT16-ra vagy FAT32-re formázott SD kártyára is: kattints rá jobb gombbal és nézd meg a tulajdonságait:

 Ha itt FAT32-t vagy FAT16-ot látsz, az jó, ha exFAT-ot, vagy NTFS-t, akkor újra kell formázni.
A következő lépésként meg kell nyitnod ezt a weboldalt: http://please.hackmii.com/
Itt:

1. válaszd ki, hogy Európai (4.3E), USA (4.3U) stb. verziójú-e a Wii (amilyet a Wii beállításokban láttál);
2. és írd be a feljegyzett vagy lefotózótt MAC címet!
3. Maradhat bekapcsolva a "Bundle the HackMii installer..." is. 
4. Írd be a számodra mutatott számot a reCAPTCHA-tól balra.
5. Nyomd meg a "Cut the red wire" gombot;
6.  és mentsd el a Letterbomb.zip fájlt, amit letöltésre kapsz.

Ennek tartalmát tömörítsd ki az üres SD kártyára, valahogy így kell kinéznie az eredménynek:

Azután távolítsd el az SD kártyát a számítógépből (biztonságosan), aztán helyezd be a Wiibe.
Azt vártam én is, hogy megjelenik, hogyúj üzeneted érkezett:

De akkor is, ha nincs a jobb alsó levélen üzenet jelzés, akkor is nyisd meg. Ha itt sincs semmi, akkor lapozz balra, hátha egy korábbi napon van (lehet, hogy velem ez az időzóna különbségek miatt volt), amíg ezt nem látod:

Erre kattintva jön maga a gyári szoftver feltörése, ezt kell látnod egy rövid ideig:

És aztán ezzel a képernyővel már révbe is értél:

Csak meg kell várnod, amíg az alján megjelenik, hogy nyomd meg az (1)-et a folytatáshoz. Ha megjelent, nyomd is meg!Erre kell jönnie ennek a képernyőnek:

 Itt az első lehetőséget kell kiválasztani, és rányomni, ahogy fent látszik. Arra jön ez a képernyő:

Itt is csak Continue-t kell nyomni. Ezután már csak az előző menüből az exit, és el is indul a frissen feltelepített HomeBrew csatorna:

Nem kell megilyedni, akkor lesznek majd benne alkalmazások, ha felmásolod őket az SD kártyára, de innen már gyerekjáték az SD kártyával tetszőleges új programot másolni a Wiire!
Ezen a képernyőn egyébként a Home-mal és az (1) gyel is fel lehet hozni menüket. Ez jön fel a Home-ra:

 Ez pedig az (1)-re:

Stop Microsoft CRM making your life miserable!

I have been annoyed beyond words by how bad is the Dynamics CRM 2015 Client built by Microsoft for their own Outlook application. I went through quite a bit of research, fiddling, trial and error, and these things seemed to help a bit.

Funny bit is that the CRM web interface seems to work faster now in Firefox and Chrome than in IE and Outlook. :) (Outlook also mostly loads CRM pages into Outlook windows.)

Hope they will help you too!

N.b.: yes, I am writing this after installing the latest 1.1 Update for Microsoft Dynamics CRM 2015 for Outlook and problems still presisting: https://support.microsoft.com/en-us/kb/3072333.

Script errors

If messages like this stop you regularly annoy the hell out of you:

..and render pages like "Edit Opportunity" unusable:

1. Exit all programs;
2. empty your %TEMP% folder;
3.  flush your DNS cache and Internet Explorer cache as described here: http://www.dynamicscrmpros.com/clearing-microsoft-dynamics-crm-common-script-error/

Getting around the problem

If you are till getting the script errors, but do not want to resort to using browsers, you can also set Ribbon: View / reading pane to Right, then you can see almost all Opportunity data on the right without opeing the item and triggering all the script errors.
You can also add notes and other stuff without opening it: Ribbon:Add / Note etc.

Obviously it would be best if MS just fixed this, but I got tired waiting for that in the past few years using the Alpha quality software they put into GA... :(

Annoying Tracking windows blocking you

If your hands are tied for tens of seconds almost every minute by these windows (which will happily block applications other than Outlook as well):

1) Go to Windows search bar, type CRM, and select Diagnostics (same CRM icon though).

2) Make sure the following are checked under Synchronization Troubleshooting

Then go to the Advanced Troubleshooting and Delete temps  then Enable crm outlook addons

Finally Restart outlook a and sync a few times.

Even less tracking

Open an email, that is tracked by CRM, then select Options form the bottom CRM pane:

This dialog should open:

And disallow your software to send email and check your inbox (first two checkboxes).

Additional sources I used

•  Send error reports automatically to annoy Microsoft, not the users: http://www.powerobjects.com/2015/02/24/disable-script-error-notifications-dynamics-crm-2015/

• How to get rid of blocking tracking windows: How tohttps://community.dynamics.com/crm/f/117/t/151320

Process iperf output for high latency high bandwidth broadband

Well after my last post I got the time to analyze, why WinSCP and the SFTP protocol in general cannot get a single TCP connection up to the maximum available bandwidth but usually max out at around 400Kbytes/sec, while 4-8 transfer do use up all the remote uplink (~10Mbit/sec cable uplink = ~1.25Mbytes/sec or ~1220 Kilobytes/sec).
I created (copy&paste) a long script to test several send buffer sizes and TCP windows. Iperf gives you output like this:
------------------------------------------------------------
Client connecting to 222.165.17.7, TCP port 443
TCP window size:  512 KByte (WARNING: requested  256 KByte)
------------------------------------------------------------
[  3] local 192.168.121.2 port 36327 connected with 222.165.17.7 port 443
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  6.06 MBytes   621 KBytes/sec
[  3] 10.0-20.0 sec  8.19 MBytes   838 KBytes/sec
[  3] 20.0-30.0 sec  8.31 MBytes   851 KBytes/sec
[  3] 30.0-40.0 sec  8.38 MBytes   858 KBytes/sec
[  3] 40.0-50.0 sec  8.12 MBytes   832 KBytes/sec
[  3] 50.0-60.0 sec  8.00 MBytes   819 KBytes/sec
[  3] 60.0-70.0 sec  7.62 MBytes   781 KBytes/sec
[  3] 70.0-80.0 sec  8.31 MBytes   851 KBytes/sec
[  3] 80.0-90.0 sec  8.12 MBytes   832 KBytes/sec
[  3] 90.0-100.0 sec  8.12 MBytes   832 KBytes/sec
[  3] 100.0-110.0 sec  8.19 MBytes   838 KBytes/sec
[  3] 110.0-120.0 sec  8.00 MBytes   819 KBytes/sec
[  3]  0.0-120.2 sec  95.5 MBytes   814 KBytes/sec
[  3] MSS size 1248 bytes (MTU 1288 bytes, unknown interface)

 I applied this script to the output of iperf to create a CSV only using bash scripting:
echo -ne "\xEF\xBB\xBF"
echo "Send buffer;MTU;MSS;TCP window;Speed"

while read TOPROCESS
do
    case "$TOPROCESS" in
        *buffer* )
            TOPROCESS="${TOPROCESS/K send buffer*/}"
            SENDBUFFER="${TOPROCESS/* /}"
            ;;
        TCP* )
            TOPROCESS="${TOPROCESS/ [KM]Byte (WARNING*/}"
            TOPROCESS="${TOPROCESS/TCP window size: /}"
            TOPROCESS="${TOPROCESS/ /}"
            case "$TOPROCESS" in
                1.00 )
                    WINSIZE="1024" ;;
                1.12 )
                    WINSIZE="1152" ;;
                1.25 )
                    WINSIZE="1280" ;;
                * )
                    WINSIZE="$TOPROCESS"
            esac ;;
        *MSS* )
            MSS=${TOPROCESS/* size /}
            MSS=${MSS/ bytes \(*}
            MTU=${TOPROCESS/*MTU /}
            MTU=${MTU/ bytes,*}
            ;;
        *Bytes/sec )
            SPEED=${TOPROCESS/ [KM]Bytes\/sec*/}
            SPEED=${SPEED/ Bytes\/sec*/}
            SPEED=${SPEED/*Bytes/}
            SPEED=${SPEED##* }
            case "$SPEED" in
                1.*    )
                    SPEED=${SPEED#1\.}
                    SPEED=${SPEED#0}
                    SPEED=$((SPEED*1024))
                    SPEED=${SPEED%??}
                    SPEED=$((SPEED+1024))
                ;;
                0.00 )
                    SPEED="0"
                ;;
            esac
            echo "$SENDBUFFER;$MTU;$MSS;$WINSIZE;$SPEED"
            ;;
        *0.0-10.0*Bytes/sec | Client\ connecting* | *connected\ with* | --------------* | *Interval*Transfer*Bandwidth* )
            # echo "Dropping connection ramp-up measurement"
            # echo "Dropping connecting/connected lines"
            # echo "Dropping separator lines"
            # echo "Dropping header lines"
            ;;
        * )
            echo "$TOPROCESS"
    esac
done < bandwidth-measurements.txt

This outputs a standard UTF-8 CSV for Excel, but the MSS and MTU readings are unfortunately always from the previous measurement. I did not bother fixing this, since it was the same for me along the whole measurement. :)

The result did highlight a few things:

• Probably there have been some intermittent errors here and there
• the send buffer size does not seem to change a lot, there are good results with 64 and 512 as well
• TCP windows below 768kbyte/s are useless, however I did not try windows large enough to see the speed decline
• probably I should rerun the tests with less buffer sizes and 768-5k window sizes
• or just allow the sending linux box to scale it's TCP window very high :)

Change Drive Letter and Paths greyed out? (Windows 7)

If you use Backblaze cloud backup it can be utterly frustrating that disconnecting and reconnecting USB drives can change their drive letters, and Backblaze has no method of cleverly "following"them.

Even more frustrating, that they do not provide a knowledge base article how to fix it (change it back).

But the worst thing happens, when for some reason you cannot do it right clicking your computer, then "Manage" then "Disk Management", then right clicking the Volume (not the disk!) with the improper drive letter: for one out of my three USB HDDs that option is greyed out!

Let's cut to the chase: i found the solution on this forum:
1. Open a command prompt.
2. Type in diskpart.
3. Type list disk to see a list of disks.
4. Type select disk #  (where # is the disk you want).
5. Type list volume to see partitions.
6. Type select volume #  (where # is the volume you want).
7. Type assign letter=x  (where x is the drive letter).

Using a command line and diskpart just worked for me! YMMW!

Five times faster TCP speed on high latency high bandwith connections

All right, it took me quite some time to figure this out so I will just give you some background to see if you are in the same situation, then the solution.

My home connection in Singapore is a 100/10 Mbit/sec cable line, speedtest.net measures an average 10ms ping, 103.8Mbit/s (12 682 KiB/s) download and 5.9 Mbit/s (714 KiB/s) upload speed, which is kind of a decent connection (there is 500Mbps fiber available to those who really need it. :)

Ther server and network I would like to access is in Hungary, on a 120/20 Mbps cable, so obviously that 20Mbit/sec uplink should be limiting my download speeds at around 2441 KiB/s=20*1000*1000/1024/8.

I did test the intercontinental connection speed with speedtest.net:

•  Magyar Telecom, Vodafone and Telenor servers
• SG daytime and SG late evening HU daytime as well

The daunting average numbers (average of 3 or 5 for each server-daytime combination): 411ms ping (RTT), 1114 KiB/s download, 168 KiB/s upload. Also there is a huge variance even in the short term, and a large drop when both time zones are in daytime.

I have set up OpenVPN but could not get anything more than 175 KiB/s (neither using SMB nor pure FTP transfer).

Next tried SCP and SFTP without VPN: the best I could get was a much favorable 700 KiB/s. (Not CPU bound, even the far side Linux on and Atom CPU was only used 10%) That however is a protocol most movie players will not stream over. :)

Then I figure I will need to go rouge (I mean raw) and have set up iperf (and the necessary port forwarding on both sides). On the first run with default parameters I got back to results around 175 KiB/s!

After tuning TOS, increasing send buffer and TCP window size I was able to get it up to nearly 512 KiB/s.Clearly, something was still limiting it.
Windows accepted any window size I threw at it, but Linux maxed out at 320KiB for some reason. ("Should be enough for everyone!" some Linux believers might scream.)

But in fact calculating the Bandwidth Delay Product (see iperf page) for the six intercontinental per server averages I get, e.g. to Vodafone server in the evening 1235 KiB/s * 0.516sec (RTT) = 637 KiB of data can be in flight!

Then I just had to look up these network tuning parameters:
net.core.netdev_max_backlog = 5000
net.core.wmem_max = 12582912
net.core.rmem_max = 12582912
net.ipv4.tcp_rmem = 10240 87380 12582912
net.ipv4.tcp_wmem = 10240 87380 12582912
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_sack = 1
Which you should put into /etc/sysctl.conf, then run 'sudo sysctl -p', and set TCP window size to 640KB (that should be enough for everyone!), voila:
[  3] 10.0-20.0 sec  9.75 MBytes   998 KBytes/sec
[  3] 20.0-30.0 sec  9.75 MBytes   998 KBytes/sec
[  3] 30.0-40.0 sec  9.62 MBytes   986 KBytes/sec
[  3] 40.0-50.0 sec  9.44 MBytes   966 KBytes/sec
[  3] 50.0-60.0 sec  9.88 MBytes  1011 KBytes/sec
[  3] 60.0-70.0 sec  9.56 MBytes   979 KBytes/sec
[  3] 70.0-80.0 sec  9.38 MBytes   960 KBytes/sec
[  3] 80.0-90.0 sec  9.38 MBytes   960 KBytes/sec

I admit I did not do a lot of further testing and tuning, since I got pretty close to the average value that was achievable according to the intercontinental speedtest measurements. :)

ToDo: 8 and 16 parallel TCP streams can rob more bandwidth and perform at a total of 1.2-1.3 MiB/s, so there is some more space for tuning.
But that may also just be fooling the rate limiting algorithms for a bit longer in the several routers between the endpoints, also streaming a single movie over multiple TCP streams is not feasible, so I think I am pretty much done for now. :)

EDIT: Another article about Windows 7 TCP tuning suggests:
netsh int tcp set global congestionprovider=ctcp
For better broadband utilization. :)

Quick buyers' guide to the ultimate bicycle lock

I was repeatedly told my bike lock (3kg armored cable lock from ABUS) is crap, should have a better one for my bike. I started reading up on the subject, here is a concise summary of my findings. See reference articles at the bottom. Just read the first 2 sections if you do not have time!

Principles

1.  If you leave your bike in a place without traffic and people the thief  can try to break your lock forever - and no lock can withstand that.
2. If you choose a crowded place to lock your bike lock only has to take longer to hack than the one on the next similar bike - they will pick the easier to break.
3. You should spend at least 10% of the value of your bike on your lock.

In my case my Kona bike costs somewhere north of USD1000, so I am supposed to look for a $100+ lock (the current one cost around $30).

The winner

Without further ado: buy hardened steel squared or hexagonal link chains with hardened steel integrated locks or padlocks: these swing away from the angle grinder, slip out of the bolt cutters, resist longer than any other kind except for the best U-locks, with which however it is pretty hard to find any object to lock to where I live (Budapest, Hungary).
Read reviews before making a choice on the specific models: chain locks can also have weak points ("He found a weak link in the HipLok L1 Lite, snipping the shackle with bolt cutters in 29 seconds.").

Caveat emptor: these are heavy(!!!) and rattling pieces, you will have to wear them or put them e.g. into a backpack, cannot really fix it on the bike while riding.

Good examples

1. ABUS Granit CityChain X-Plus - 1.9kg (85cm) - 3.7kg (170cm)
2. OnGuard 8020 Mastiff ("hardened-steel links withstood a hacksaw and bolt cutters. After nearly three minutes of use, the battery in Ruzal's angle grinder died before he could cut the shackle") - 7kg
3. OXFORD NEMESIS MOTORCYCLE ULTRA STRONG CHAIN and PADLOCK 1.5M - 9kg
4. Blackburn ATTICA CHAIN AND PAD LOCK - 6kg

Or by anything with a Gold Sold Secure rating, or anything with four or five stars here.

Major manufacturers: Kryptonite, OnGuard, Abus, Blackburn, Masterlock, Knog, and Avenir.

Second best

U-locks (or D-locks) are the second best choices, hardest to cut through, however if large, a car jack can easily inserted into it. The smaller it is (against jacks) the harder it is to find a sufficiently narrow but strong object at the right height to lock your bike to. :(
If you by this, choose one that is locked on both ends of the U part:

1. ABUS Granit X-Plus
2. ONGUARD Brute
3. Kryptonite New York Lock
4. Kryptonite New York Fahgettaboudit U-Lock
5. Kryptonite Evolution Series 4 

Most of them are up to 2kg.

Or by anything with a Gold Sold Secure rating, or anything with four or five stars here.

Not recommended

1. Masterlock Force 3 - long term problems reported (ref. no. 11)
2. TiGr - - easy target for bolt cutters and angle grinders (ref. no. 11)

Tools

This is what we are defending against:

1. Battery powered angle grinders: the most hardcore tool, quite fast, not quiet, but cuts through any metal with time:
   
2. Hacksaw: basically the hand powered version of the above, slower and quieter:
   
3. Jack: mainly used against U locks, quite fast and quiet:
   
4.  Bolt cutter: a cutting tool designed to yield a cutting force up to 100 times stronger than the force on the handle. Quick, quiet but clumsy:
   
   
5. Wire cutter: basically small, pocketable version of the above, whichever lock cannot withstand this is a lost cause:
   
   

Standards

From reference no. 6:
"Sold Secure is an independent organisation administered by the Master Locksmiths Association. Locks submitted receive one of three ratings: Gold, Silver or Bronze. These reflect the length of time a lock will hold out against escalating levels of attack. Bronze is a minute with basic tools; Silver is three, with a wider array of tools; Gold is five minutes with a more sophisticated array of tools. 

The largest manufacturers also submit to the German and Dutch ART1 to 5+ standards. These are a very tough standard and worth looking out for. Gold or high ART-rated locks can be more expensive but they may help you get a discount on your insurance if you use one."

References

1. Bike locking 101 in Hungarian - not fully agreed, but do not buy that they don't recommend
2. German test TV show, obviously biased towards / sponsored by ABUS
3. A quick comparison (only care about what is best recommended)
4. A New York based mechanic shows you how easy it is: cable lock cut with wire cutters - unbiased
5. Suggests u-lock for portability, however still chain is best for security and flexibility
6. An in-depth guide
7. Nice tips in there: GPS tracker and to use an additional cable for the wheel not hold by the chain
8. Some more chain locks
9. Shows that the fashionable Hip Lock chain lock is actually only Silver rated, still at the top of the league
10. How to lock it? with either a chain or a U lock
11. Another detailed write up

NTFS compression vs. 7zip

I was migrating 7 years of accumulated "My Documents" (word, PDF, scanned, totally mixed) of my wife to her new SSD, where capacity is still much more scarce.
I took time to decide: shall I compress all unused and old data with 7zip* to save space, but make it a lot more complicated to access them**, or shall I just let NTFS in Windows 7 do the job, leaving them accessible as single files?

I am posting the results, because they differ significantly from what I have expected: that would have been a slightly less efficient compression from NTFS.

Instead, this is what I got (for a subset of "My Documents" M-Z, 67 folders, 1 142 files).

Windows 7 NTFS compression (bytes):
Total size: 1 060 762 801, Compressed: 971 467 130, Gain: 8.4%
7zip Ultra compression (bytes):
Total size: 1 060 762 801, Compressed: 489 906 124, Gain: 53.8%

This means, that NTFS compression was basically useless on her "My Documents" contents, and that is not because the contents were incompressible: 7zip freed up more than six times more than NTFS, giving back more than half of the valuable SSD capacity!

Have had a quick Google: it seems there is no way to beef up NTFS compression levels the way Linux can be tweaked.

Comments Welcome!

*: 7z format, Ultra compression level, which obviously does combine multiple files for better compression, since I was unable to obtain single file statistics.

**: The other disadvantage being that a single archive is most probably a lot more fragile, a bit of damage could potentially make a lot of files inaccessible. Fortunately I have a backup of all the files, so this is not a concern. :)

Big JPEG Compression and Statistic experiment

A short while ago I had to think about how to make images smaller, without loosing (any more) information. For PNGs it is easy: I am a long time user of IrfanView, which includes the PNGOUT plugin to optimize compression of the image information.
Unfortunately two color images (used frequently in document scanning, because they use 1 bit per pixel, 1bpp) are usually stored in TIFF, Group 4 compressed images and in the past I have found these to be smaller than the same image saved in 1bpp PNG from IrfanView using PNGOUT. I have found no tools to poke around with this compression, also, IrfanView tends to save larger TIFF G4 images, than what come out of scanning.

This made me tudn my attention to Grayscale (8bpp) images,  which are often saves in JPEG, even though that is a lossy compression (meaning the decompressed image will not be equivalent to what came out of the scanner, just will look like that).
It is very easy to make a JPEG smaller by lowering its quality during compression, but it will just increase the difference from the original image thus decrease the similarity to that. We want to keep as much information of the original image as we can, so I was only looking into improving the compression while keeping the encoded information intact.

This made me do a large scale experiment on all my fifty two thousand JPEG images: I compressed them with all the different methods I could find, and recorded the results. In a series of posts I will review these result, because I have found several interesting angles to them:

1. How to check the integrity of all your photos in an automated way: easily done with a following these instructions! Basically, on linux install jpeginfo, then, in the designated folder perform: (let me know if you need windows instructions!)
   
   

   find -iname "*.jpg" -print0 | xargs -0 jpeginfo -c | grep -e WARNING -e ERROR
   

2. How much space can you save by re-compressing your photos, _without_ losing a single pixel of information (nor the EXIF data)?
3. Is it really worth all the extra hassle to create ultra-progressive JPEGs?
4. What is an arithmetic compressed JPEG, how much size it gains and which applications can read it?
5. Which cameras / camera makes have the best and the worst JPEG compression engines?
6. How have the megapixels evolved along the years?
7. How do re-compression gains change compared to image size (megapixels)?
8. How to automate all these, and which problems need to be solved for this (e.g. how to create progressive, arithmetic coded JPEGs)? actual scripts and binaries where needed!
9. Shall I look at my 30GB+ MJPEG movies as well? :)

For starters, let's see what cameras have produced my 51719 JPEGs: (yes, several images were taken with mobile phones)

Apple	562
BlackBerry	135
Canon	5928
Casio	214
Fuji	17552
HP	112
Kodak	234
Minolta	244
Motorola	2
Nikon	9783
Nokia	1430
Olympus	13813
Panasonic	698
Pentax	5
Samsung	236
Sony	276
#N/A	495

And a sneak peak into the total possible filesize / storage gains, and for you to have a quick answer:

1. Originals: 135.6GB
2. Re-compressing only the Huffman coding: 130.21GB, 3.78% total gain
3. Re-compressing the Huffman coding, and storing a progressive JPEG: 123.67GB, 8.79% total gain, 4,82% gain over just Huffman optimization!
4. Re-compressing the Huffman coding, and optimizing progressive JPEG storage (a.k.a. ultra-progressive JPEG):122.53GB, 9.64% total gain, only 0.85% gain over progressive JPEG
5. Re-compressing using arithmetic compression instead of Huffman: 116.88GB, 13.81% total gain, 4.17% gain over the best possible Huffman compression!
6. Re-compressing using arithmetic compression and storing a progressive JPEG: 114.72GB, 15.4% total gain, 1,59% gain over non-progressive arithmetic JPEG
7. Re-compressing using arithmetic compression and and optimizing progressive JPEG storage (a.k.a. ultra-progressive arithmetic JPEG): 113.94GB, 15.97% total gain, only 0.58% gain over progressive arithmetic JPEG

Breakdown for each camera brand in the next post!

Questions welcome, as always! :)