Leica I don't like lossy image compression...

Brian

Product of the Fifties
I worked with Digital sensors when they were new, almost 35 years ago now. Data compression schemes were subroutines that you wrote and called before storing the data to tape or disk. There was no JPEG.

Lossless compression - run length encoding, meaning counting how many pixels in a row were the same, storing a repeat factor and value- worked for Graphics, not imagery.

Imagery- you have enough resolution, the data does not change "too fast", you store a running difference frame on a row-by-row basis. SO- you have 14-bit data that normally requires two-bytes to store. For all the Red, Green, Blue pixels- store the first full-pixel value for each color of the row, Red-Green for a Bayer filter in one row, Green-Blue for the next- Subtract the second value from it and store the difference in 1-byte. Use values -127:+127, and use -128 (FF'x) as an "escape" to store a new 16-bit value. For most images, you get close to a 2:1 compression.

Leica did not use that for compressed DNG on the M9 and M8. Compressed DNG stores the "Square-Root" of the value. It stores J= SQRT( I* 4), then restores it using I= (J** 2)/ 4.

I hate it. It is "Chaotic", meaning loss of precision due to computer round-off error. Great for making interesting Graphics, just ask Dr. Mandelbrot.

It loses data. It is responsible for the very poor High-ISO performance of the M8.

This is what an M8 looks like at ISO5000 when using M8RAW2DNG to get uncompressed DNG files.

16414555015_2679b76fdf_b.jpg
autocurves_ISO5000eqv
by fiftyonepointsix, on Flickr

If M8 ISO5000 files had looked like this in 2006, no one would have complained.

Better than what you are used to.

I had to "Visualize" what the compression routine discards.

First image is the original M9 image at base ISO, 160.

by fiftyonepointsix, on Flickr

This is the Information that is Thrown Away by DNG8.

by fiftyonepointsix, on Flickr

"The Daughter is in the details"

Lots of high-frequency information, noise and signal.

A second one, less highlights- ISO160.

16788351425_f8349d795a_b.jpg
L1000441
by fiftyonepointsix, on Flickr

16788351455_1a0ff11684_b.jpg
L441DFSC
by fiftyonepointsix, on Flickr
 
Last edited:
So- I dug out some of my old FORTRAN-77 code written 25+ years ago, "looked around in the .DNG files" in HEX, "intuitively obvious to the most casual of observers" how the data was stored. Kind of fun to create 36MByte DNG image files using a 17 year old DOS Laptop running FORTRAN-77 under PharLap extenders. A 333MHz Pentium-II running DOS is about as fast as a Cray-2.

The coolest thing about the 17-year old Micron Trek 2: the original batteries still hold a full charge. It's going to outlast this octal-core I7 that I'm using as a terminal. I wonder how fast it will run a DOSBOX emulator.
 
Last edited by a moderator:
I did some additional tests- converted an uncompressed DNG to a DNG-8, the "suspicion" that it created sharp edges at the boundaries of the compressed levels used to store the image. The 16384 levels of the uncompressed image get divided into 256 values. At the upper end, 127 different values all get lumped together. It did- acts like sharpening when you don't suspect it. At these "contour boundaries", noise is amplified as the naturally occurring noise can cause the compressed image to shift between two values. Once in the compressed step, noise gets lost in the level.

To put some numbers on it, the "bin size" gives the size of the step increase.

16169382553_ff85f52713_b.jpg
dataloss_vs_pixelvalue
by fiftyonepointsix, on Flickr

So at an edge- a noise count of "4" (as an example) can get magnified up to 127 if it occurs on that edge.
 
Last edited by a moderator:
:bravo-009: Brian! I actually understand this--which scares me. :) The question is, didn't the folks at Leica understand it? While they didn't have the wealth of digital experience that Japan, Inc. has with this stuff, I can't believe they didn't know their basic math.

We'll probably never know for sure. But I suspect that they *had* to get the M8 out in the marketplace by a certain date, and they *had* to be able to write files at a certain minimum speed to avoid being laughed out of said marketplace. And they were bound to the hardware they had chosen, which was already slow by Japanese standards. When faced with the 20 MB RAWs taking too long to write, somebody came up with a quick expedient in the form of the square root compression. They probably implemented it with something simple and fast like a lookup table or a greater than/less than sieve. On the M8's hardware, this was probably appreciably faster than the better method you outline in your first remarks. But like all shortcuts, it had its price. So we ended up with a camera that was great for the Kodachrome crowd, but not so good for the available darkness hounds.

What irks me is that the code for the "good" RAW files has been tucked away in the Service Mode "Easter Egg" all along. I wish they had done what they did with the M9--defaulted to the compressed DNGs, but given us the option for uncompressed. With the disclaimer, "for absolute best quality, particularly in marginal light, use uncompressed, even though it is slower." Somebody in Marketing probably nixed it. I would have forgiven them and been thankful for the option.

Anyway, the secret's out now. So far, I think it's well worth using. I have told my friends on the LUG about it. A couple of people found it interesting. One says that while my pictures at (effective) 1250 look good, the slow write times are a deal-breaker for him. He uses a Fuji XT-1 when things get dark. That reaction is probably why Leica hid the uncompressed option from us in the first place.

--Peter
 
Last edited by a moderator:
Thankyou- I wish they had put the uncompressed DNG in. The RAW mode available in "service mode" also has to compute and store the Fine JPEG, and in dim light- stores the background measurement. So it can store up to 50MBytes for a 10Mpixel image.

With the DSP available in the M8, all they had to do was call me and I would have had the running difference algorithm coded up for them... It's only 10MPixels with an Integer* 2 Subtract! I love writing assembly language code, have done a lot of RISC assembly language. I could beat the GNU C/C++ compiler by a factor of 5.
 
I'm a mathematical moron, so I don't understand the math. I do understand the stated purpose of raw files, though, and lossy raw just makes no sense. Anyone else throwing away data in their raw files??
 
Nikon's "Compressed" NEF files and Sony Alpha throw away data, but not as much as Leica DNG. The Nikon compressed NEF claim to be "visually lossless", but if you want it all: use uncompressed NEF. Sony uses a "Strange", "Adaptive?" algorithm that can cause some strange artifacts. They do NOT give the option of using uncompressed. All that tells me- the guy that came up with the algorithm is very impressed by it. Maybe if someone discovers a Button Dance for the A7 I will change my mind on it. Until then, Nikon Df and Leica all the way.

I loaded DOSBOX 0.74 on Win7. If it runs Phar Lap in "regular protected mode" I'll be able to run my software. If it allows me to run in supervisory mode, - I'll be impressed. I like DOS as it lets me essentially take over the hardware.

Well I tried to make Windoze Useful. DOSBOX only allows 16MBytes of protected memory. Phar Lap DOS gives me all of protected mode memory for my code. The overhead is ~200K of memory to run. So loading up a 36MByte DNG under DOS is easy, and I don't even have to pull in the virtual memory manager.
 
Last edited by a moderator:
Brian, if you run DOSBox "as administrator" you should have Grand Poohbah permissions. DOSbox was designed to run games, so it's pretty permissive. I believe it works with XMS memory. There is some virtualization re. COM ports and the disk. How far you'll get with bare-metal ports and interrupts, I don't know.
 
THANKYOU! I will give that a try.

My Software running under Phar Lap "goes low", as in I do my own Keyboard FIFO handling, rewrite the protected mode interrupt table, and reset the Counter-Timer registers of the CPU. If they do a full-blown hardware emulation, it'd work. Otherwise you get an illegal instruction kind of error. One of my projects basically turns a PC104 computer running DOS/Phar Lap DOS into a very-smart logic analyzer.

I found the "MEM" parameter in the configuration file, was set to 16. Looks like the Max is 64MBytes.

I have one Celeron 2.4GHz computer with 1.2GBytes running DOS. Phar Lap Dos can use it all, but with Win98 I have to cut the max memory to ~768MBytes in one of the .ini files. They did not leave enough room in the Page-Table-Entry list, or something like that. With the Phar Lap DOS, you can do your own File to Page-Table mapping. I used to do a lot of computer generated animated models using that technique, 25 years ago... It would speed up reading in DNG files.

Well, the code loaded up, asked for the filename, .... very, very, very slow compared with a Pentium-II...

I wrote my first image processing code for a Z80a.

I think my code is trying to get rid of Windows. Just had to pull up task manager.

But it did not burst into flames.
 
Last edited by a moderator:
I have no idea what's going on in this thread, but I like it. Keep up the good work!

Actually, that's not true. I understand enough just enough to be impressed and nod politely.
 
This is with the M8, using the "Button Dance" and M8RAW2DNG.

16805046712_e742af5cd5_o.jpg
Join to see EXIF info for this image (if available)
L1015636

And what the DNG8 throws away,

16806127595_5d97b44858_o.jpg
Join to see EXIF info for this image (if available)
L15636DF

For anyone with an M9- don't use compessed DNG.

If you have an M8, try out M8RAW2DNG. I have a tutorial for using it, if anyone needs it.
 
I don't like lousy compression either.:cool:

But seriously, love this post and ones like it where someone is thinking about things on more than a superficial level. Nice Brian!!!
 
The thread has given me pause over whether to start converting my .org files from my Olympus E-M5 to DNG. For the moment, I'm inclined not to.

A real digital negative standard would have to have everyone on board and would have to be totally lossless, compressed or otherwise.
 
The DNG format includes uncompressed, lossless-compressed, and lossy compressed. The M8 did not offer uncompressed, it only offered lossy-compressed.

With M8RAW2DNG- uncompressed DNG is now available for the M8.

When converting to DNG- make sure you select uncompressed format. Disk space is cheap. Even if the file format is truly "Lossless", and data error in the file will cause a "chain reaction of corruption that will destroy the image". With an uncompressed file, an error will cause a smaller part of the image to drop out.
 
Back
Top