Jump to content
Sign in to follow this  
the warrior

The reality of the 8-bit Leica

Recommended Posts

Advertisement (gone after registration)

Ok, I confirm that indeed.

At first I tried your tool in Mac OS, but it didn't provided a log even in verbose, unless it wasin console? I dont know. Anyway, then I jumped in the win version and yes, the tables are constant. Nice tool btw...

 

Now, correect me if I am wrong, but only Leica can mke them dynamic right? That is, this needs to be done before on the fly, just before the compression is taken, if we want to preserve fidelity of the shot. Is that correct?

 

In the Mac version of CornerFix, you have to enable the log window - <Apple L> or Window->Show Log Window to be able to see any logging output. In the Windows version, the logging output is always displayed in the Log pane of the main window.

 

And correct, only Leica could make the table dynamic - it would require firmware changes. It very unlikely that would do that though:

 

a) Many raw developers - notably Aperture and Capture One, are notorious for not actually reading the "what format is this data in" fields embedded in the DNG, but just assume what the format is based on the camera type. The Adobe products (Lightroom, Photoshop, CR, etc) do read this data properly, but many other raw developers would break if Leica changed tables.

 

Making the table dynamic would be a pretty computationally intensive task - you'd have to analyse each image. If the extra computing power was available, there are easier ways to get more tonal range - e.g., level compress to 10 or 11 bits, then do a losless Hufman compression. That would get you files about the same size, but a lot more tonal data than any 8-bit level compression, dynamic or not. That, BTW, is about what Nikon do for their compressed NEFs. Although Nikon use a more sophisticated compression curve than the square law one Lieca use.

 

Sandy

Share this post


Link to post
Share on other sites
Hallo Hans!

 

The picture you see on the LCD at first is simply the 320x240 pixel thumbnail, which is also included in each DNG file. After some seconds (depending on how fast the SD card is) the DNG is converted and show instead on the LCD. This picture is scaleable.

Isaac,

 

I checked what you said, and replaced the thumbnail in a picture with another thumbnail.

When looking now on the LCD, first I get the replaced thumbnail, and then 2 seconds later the correct real picture,

So what you said is right, with one comment, the thumbnail is not 320*240, but 555*370 pixels, and the full display is 555*414 pixels

 

So Scott's idea that a sqrt helps in displaying the picture faster on the LCD is not the reason why to compress the full picture with a sqrt.

Maybe the thumbnail is compressed with a sqrt

We are back to where we started.

 

Hans

Hans

Share this post


Link to post
Share on other sites

Hallo Hans!

So what you said is right, with one comment, the thumbnail is not 320*240, but 555*370 pixels, and the full display is 555*414 pixels

Maybe the display is 555*414 pixels but the thumbnail is 320*240:

 

Processing M8_20080722_0233.DNG

Byte order : I, Version : 2A

IFD1 : 0000:0008, Entries : 40

1 FE NewSubfileTyp uLong 1 v 0000:0001 1

2 100 Imagewidth uLong 1 v 0000:0140 320

3 101 Imagelength uLong 1 v 0000:00F0 240

4 102 BitsPerSample uShort 3 * 0000:03F4 8 8 8

5 103 Compression uShort 1 v 0000:0001 1

6 106 PhotometricInt. uShort 1 v 0000:0002 2

7 10F Make ASCIIZ 16 * 0000:03FC Leica Camera AG

8 110 Model ASCIIZ 18 * 0000:0424 M8 Digital Camera

 

The thumbnail is stored uncompressed in 3*8 bit sRGB colorspace. When displayed, it is (obviously very fast) scaled (expanded) to the physical pixelrange of the LCD.

 

The thumbnail has also the 4:3 aspect with a black bar on top and on bottom to retain the 3:2 aspect of the sensor.

 

If lens detection (and UV/IR filter) is off, the square root compression is done by a single look up from one table.

If lens detection and UV/IR filter is on, the square root compression is done by a double look up, one in dependance from image center (to correct vignetting and IR falloff) and the other one from the real square root look up table (maybe it is the other way, I do not remember well).

The appropriate vignetting look up table is selected through the lens index table.

All this details were published here more than a year ago...

Share this post


Link to post
Share on other sites
Hallo Hans!

 

Maybe the display is 555*414 pixels but the thumbnail is 320*240:

 

Processing M8_20080722_0233.DNG

Byte order : I, Version : 2A

IFD1 : 0000:0008, Entries : 40

1 FE NewSubfileTyp uLong 1 v 0000:0001 1

2 100 Imagewidth uLong 1 v 0000:0140 320

3 101 Imagelength uLong 1 v 0000:00F0 240

4 102 BitsPerSample uShort 3 * 0000:03F4 8 8 8

5 103 Compression uShort 1 v 0000:0001 1

6 106 PhotometricInt. uShort 1 v 0000:0002 2

7 10F Make ASCIIZ 16 * 0000:03FC Leica Camera AG

8 110 Model ASCIIZ 18 * 0000:0424 M8 Digital Camera

 

The thumbnail is stored uncompressed in 3*8 bit sRGB colorspace. When displayed, it is (obviously very fast) scaled (expanded) to the physical pixelrange of the LCD.

 

The thumbnail has also the 4:3 aspect with a black bar on top and on bottom to retain the 3:2 aspect of the sensor.

 

If lens detection (and UV/IR filter) is off, the square root compression is done by a single look up from one table.

If lens detection and UV/IR filter is on, the square root compression is done by a double look up, one in dependance from image center (to correct vignetting and IR falloff) and the other one from the real square root look up table (maybe it is the other way, I do not remember well).

The appropriate vignetting look up table is selected through the lens index table.

All this details were published here more than a year ago...

 

Isaac,

very interesting info that you have sent, where did you find this ?

 

But despite all, the thumbnail on the SD card memory lies between 4020H and 3629FH, which is 205.440 bytes long.

The whole LCD display is 230.000 pixels in a ratio of 5.1*3.8 mm, or approx 555*414 pixels.

A picture ratio of 3:2, gives me then 555*370 pixels, or 205.350 pixels which corresponds fairly good with the previous 205.440 found in memory.

 

When displaying a thumbnail on the LCD display, it has indeed the ratio of 3:2 ( 5.1*3.4mm), with above the image some additional info's about picture nr. etc.

 

The thumbnail you are referring to is probably a different thumbnail that is generated after the first conversion into another raw format by LR, Photoshop or whatever program .

Notice that the raw picture after this first conversion bears little resemblance with the original raw picture.

The most obvious is that the original size of 10 Mb has been reduced to 5.63 Mb.

Also in comparing the original raw image with the processed raw image, there is hardly anything similar to be found in the information before the actual picture.

 

Hans

 

I

Share this post


Link to post
Share on other sites

Hallo Hans!

very interesting info that you have sent, where did you find this ?

Where? On my screen, of course :-)

I have a "TIF reader", which can open all mysteries of any TIF (like) file.

 

Well, let's go deeper inside...

9 111 Stripoffsets uLong 4 * 0000:0A18 00000f60 00010e60 00020d60 00030c60

10 112 Orientation uShort 1 v 0000:0001 1

11 115 SamplesPerPixel uShort 1 v 0000:0003 3

12 116 RowsPerStrip uLong 1 v 0000:0044 68

13 117 StripByteCount uLong 4 * 0000:0A28 65280 65280 65280 34560

 

Thumbnail is stored in four "stripes", the values added give 230400 bytes. Now divide by 3 (red, green and blue) gives 76800. Now divide by 320 (ImageWidth) gives 240, the correct ImageLength.

 

So where are your doubts???

But despite all, the thumbnail on the SD card memory lies between 4020H and 3629FH, which is 205.440 bytes long.

Who bothers, where it is on the SD card?

The whole LCD display is 230.000 pixels in a ratio of 5.1*3.8 mm, or approx 555*414 pixels.

A picture ratio of 3:2, gives me then 555*370 pixels, or 205.350 pixels which corresponds fairly good with the previous 205.440 found in memory.

I think your mistake is here. The display has exactly 230400 pixel. 76800 are red, 76800 are green and 76800 are blue. That's it. So the thumbnail does need to be expanded (scaled) it is a 1:1 image of the display.

The thumbnail you are referring to is probably a different thumbnail that is generated after the first conversion into another raw format by LR, Photoshop or whatever program .

The thumbnail I have used in our case is an original one from the M8 (I neither own LR nor Photoshop).

Notice that the raw picture after this first conversion bears little resemblance with the original raw picture.

The most obvious is that the original size of 10 Mb has been reduced to 5.63 Mb.

So YOU do not have an original DNG from M8.

The shrink of file size is due to a lossless Huffman compression which is legal for a DNG file.

Also in comparing the original raw image with the processed raw image, there is hardly anything similar to be found in the information before the actual picture.

A raw image is a raw image is a raw image....

There does not exist anything like a "processed" raw image (other than devignetted from M8 internal).

Share this post


Link to post
Share on other sites

The thumbnail is indeed 320x240. Below is the first part of an M8 file in human readable form (From CornerFix, but Adobe's DNG validation tool will give you exactly the same info).

 

The Thumbnail is the "Preview Image"

 

Sandy

 

______________________________________________

 

 

Uses little-endian byte order

Magic number = 42

 

IFD 0: Offset = 8, Entries = 40

 

NewSubFileType: Preview Image

ImageWidth: 320

ImageLength: 240

BitsPerSample: 8 8 8

Compression: Uncompressed

PhotometricInterpretation: RGB

Make: "Leica Camera AG"

Model: "M8 Digital Camera"

StripOffsets: Offset = 3936 69216 134496 199776

Orientation: 1 - 0th row is top, 0th column is left

SamplesPerPixel: 3

RowsPerStrip: 68

StripByteCounts: Count = 65280 65280 65280 34560

XResolution: 72.00

YResolution: 72.00

PlanarConfiguration: 1

ResolutionUnit: Inch

Software: "1.104"

Artist: ""

SubIFDs: IFD = 494

Copyright: ""

ExifIFD: 764

SelfTimerMode: Off

DateTimeOriginal: 2007:05:07 21:30:50

FocalPlaneXResolution: 3729.0000

FocalPlaneYResolution: 3764.0000

FocalPlaneResolutionUnit: Inch

TIFF/EPStandardID: 0.0.0.1

DNGVersion: 1.0.0.0

UniqueCameraModel: "M8 Digital Camera"

Share this post


Link to post
Share on other sites

Advertisement (gone after registration)

In the Mac version of CornerFix, you have to enable the log window - <Apple L> or Window->Show Log Window to be able to see any logging output. In the Windows version, the logging output is always displayed in the Log pane of the main window.

 

And correct, only Leica could make the table dynamic - it would require firmware changes. It very unlikely that would do that though:

 

a) Many raw developers - notably Aperture and Capture One, are notorious for not actually reading the "what format is this data in" fields embedded in the DNG, but just assume what the format is based on the camera type. The Adobe products (Lightroom, Photoshop, CR, etc) do read this data properly, but many other raw developers would break if Leica changed tables.

 

Making the table dynamic would be a pretty computationally intensive task - you'd have to analyse each image. If the extra computing power was available, there are easier ways to get more tonal range - e.g., level compress to 10 or 11 bits, then do a losless Hufman compression. That would get you files about the same size, but a lot more tonal data than any 8-bit level compression, dynamic or not. That, BTW, is about what Nikon do for their compressed NEFs. Although Nikon use a more sophisticated compression curve than the square law one Lieca use.

 

Sandy

 

1. I didn't saw any option for any log command, but I used the console and everything was there.

 

2. Even though, this is more or less an open standard and any decent programmer should process the file properly, I dont understand how is it possible for someone to interprete this wrong? You either use the actual file as an index that point to that table, or you don't. In any case if you don't you get everythng wrong

 

3. yes I suspect you should analyze the photo and focus at the density of data, but lets just wait what Hans findings are with jaaps files. I would bet that Leica is right about the pictures, but let's see

Share this post


Link to post
Share on other sites

2. Even though, this is more or less an open standard and any decent programmer should process the file properly, I dont understand how is it possible for someone to interprete this wrong? You either use the actual file as an index that point to that table, or you don't. In any case if you don't you get everythng wrong

 

I doubt that its getting it wrong - the issue is that the DNG standard allows a LOT of different options as to how to encode an image; everything from floating point formats to complex row and column indexed black levels. Most writers of raw developers simply decided that it was easier to write several camera specific decoders each for that camera's flavour of DNG file (e.g., one for the M8, one for the DMR, etc) than to write a single general purpose DNG decoder that covers every possible variant.

 

Sandy

Share this post


Link to post
Share on other sites
Hallo Hans!

 

Where? On my screen, of course :-)

I have a "TIF reader", which can open all mysteries of any TIF (like) file.

 

Well, let's go deeper inside...

9 111 Stripoffsets uLong 4 * 0000:0A18 00000f60 00010e60 00020d60 00030c60

10 112 Orientation uShort 1 v 0000:0001 1

11 115 SamplesPerPixel uShort 1 v 0000:0003 3

12 116 RowsPerStrip uLong 1 v 0000:0044 68

13 117 StripByteCount uLong 4 * 0000:0A28 65280 65280 65280 34560

 

Thumbnail is stored in four "stripes", the values added give 230400 bytes. Now divide by 3 (red, green and blue) gives 76800. Now divide by 320 (ImageWidth) gives 240, the correct ImageLength.

 

So where are your doubts???

 

Who bothers, where it is on the SD card?

 

I think your mistake is here. The display has exactly 230400 pixel. 76800 are red, 76800 are green and 76800 are blue. That's it. So the thumbnail does need to be expanded (scaled) it is a 1:1 image of the display.

 

The thumbnail I have used in our case is an original one from the M8 (I neither own LR nor Photoshop).

So YOU do not have an original DNG from M8.

The shrink of file size is due to a lossless Huffman compression which is legal for a DNG file.

 

A raw image is a raw image is a raw image....

There does not exist anything like a "processed" raw image (other than devignetted from M8 internal).

Hallo Isaac,

 

Of course I have original M8 DNG's, as I also have an M8. What gave you that Idea?

I imported Raw 10Mb pictures in LR while compressing them, that’s why my LR Raw file was so much smaller.

 

I have switched compression of now for a better way to compare. The LR raw file is almost full of readable text for the first part, that is not in the M8 File, at least not in that format.

The two files have now exactly the same full raw picture, so what you said is true, there is only one raw format.

 

But the Thumbnail from the M8 raw file is not in the LR raw file.

To check this, I tricked an M8 file, where I changed the thumbnail for a thumbnail from another picture. After having imported the file in LR, I opened the LR raw file with windows viewer, and I got a small (jpeg?) thumbnail of roughly 250*170 pixels, but with the correct Image and not the switched thumbnail !!

This proves that LR is not even looking at the thumbnail in the original M8 file, but generates one itself from the main raw picture.

 

Your info on the M8’s LCD was helpful, in as far as the size is really 320*240, but this has to be multiplied by 3 for RGB.

A 3:2 ratio thumbnail needs only 320*214 full pixels, and multiplied by 3 gives 205 440 bytes.

 

The Thumbnail info as written on the M8's SD card is exactly this 205.440 bytes long, and not the 230.400 bytes like your TIFF reader says..

I have checked this with several different pictures, all with the same results.

Again, this area is from 4020h to 3629Fh in the picture file as stored on the SD card's.

I cannot explain why TIFF readers are giving different information, but it is wrong and can be checked quite easily with a hex editor.

 

Hans

Share this post


Link to post
Share on other sites
This proves that LR is not even looking at the thumbnail in the original M8 file, but generates one itself from the main raw picture

 

This isn't too surprising given that the embedded thumbnail is so small.

 

One of the problems with Microsoft Expression Media is that it only uses the embedded thumbnail, and therefore it's impossible to get a full screen preview. The only way to get one is to run the M8 files through the DNG converter and select the option for a full sized preview to be embeded in the converted file.

Share this post


Link to post
Share on other sites

Hallo Hans!

Your info on the M8’s LCD was helpful, in as far as the size is really 320*240, but this has to be multiplied by 3 for RGB.
correct..
A 3:2 ratio thumbnail needs only 320*214 full pixels, and multiplied by 3 gives 205 440 bytes.

Yes, but this is only the visible part excluding the black bars above and below the image of 320x240 pixel. These two black bars are "added" to copy the image to the LCD...

The Thumbnail info as written on the M8's SD card is exactly this 205.440 bytes long, and not the 230.400 bytes like your TIFF reader says..
Sorry to correct you again, but to what you refer here is not the whole image, it is only the part without the two black bars, which are part of the whole thumbnail!
I have checked this with several different pictures, all with the same results.
Of course, because these two black bars are added to all thumbnails.
Again, this area is from 4020h to 3629Fh in the picture file as stored on the SD card's.

Also again :-) the image starts in the file at 0f60h (start of first stripe) and ends at 3935fh. At 39360h the full raw file starts.

Your fault is obviusly, that you do not include the two black bars, which are an integral part of the thumbnail.

The reason why these two black bars are added is simple the fact, that the LCD has 4:3 aspect and the sensor has 3:2 aspect. To make the copy faster, the thumbnail image has also a 4:3 aspect but only the visual image inside is a 3.2 subset of the whole thumbnail image.

I cannot explain why TIFF readers are giving different information, but it is wrong and can be checked quite easily with a hex editor.
No explanation neccessary, the TIFF reader is correct (and the strip offsets and length proof this), but you are ignoring the two black bars which are also part of the thumbnail image. These two black bars you can see in your hex-reader also, they have the pixel values of 0 (zero).

Last try: the two black bars you can see on the LCD are also stored in the thumbnail image.

Share this post


Link to post
Share on other sites
Hallo Hans!

correct..

 

Yes, but this is only the visible part excluding the black bars above and below the image of 320x240 pixel. These two black bars are "added" to copy the image to the LCD...

Sorry to correct you again, but to what you refer here is not the whole image, it is only the part without the two black bars, which are part of the whole thumbnail!

Of course, because these two black bars are added to all thumbnails.

 

Also again :-) the image starts in the file at 0f60h (start of first stripe) and ends at 3935fh. At 39360h the full raw file starts.

Your fault is obviusly, that you do not include the two black bars, which are an integral part of the thumbnail.

The reason why these two black bars are added is simple the fact, that the LCD has 4:3 aspect and the sensor has 3:2 aspect. To make the copy faster, the thumbnail image has also a 4:3 aspect but only the visual image inside is a 3.2 subset of the whole thumbnail image.

No explanation neccessary, the TIFF reader is correct (and the strip offsets and length proof this), but you are ignoring the two black bars which are also part of the thumbnail image. These two black bars you can see in your hex-reader also, they have the pixel values of 0 (zero).

Last try: the two black bars you can see on the LCD are also stored in the thumbnail image.

Hi

 

Hi Harald,

 

Taking the black area before and after the Thumbnail and adding this to the Thumbnail, then yes, you have your 230.400 bytes.

If this is what your Tiff reader does, fine, problem solved, although we know this is not the way the thumbnail is displayed.

There is no black area on the LCD display below theThumbnail, at least not on mine.

 

As it seems that we now both know what we are meaning, we can safely close this thumbnail discussion. Thank you for your input.

 

Hans

Share this post


Link to post
Share on other sites

Hallo Hans!

If this is what your Tiff reader does, fine, problem solved, although we know this is not the way the thumbnail is displayed.

There is no black area on the LCD display below theThumbnail, at least not on mine.

For the stored thumbnail image, the bar below and above are valid. On the LCD itself, the picture is "scrolled down" by the height of the bar below and therefore the black bar on top is the background for further image data.

As it seems that we now both know what we are meaning, we can safely close this thumbnail discussion.

ACK :-)

Share this post


Link to post
Share on other sites

This thread motivated me to investigate if the M8 compression was indeed according to a SQRT, and if a different compression would give a better result.

Well, I found the conversion table. It is there between 6B5h and 8B4h, and expands the 8 bits to 14 bits according to a SQRT.

 

Now I will try to process, meaning compressing and decompressing, the 16 bit picture that Jaap has send me from his DMR, according to a SQRT and according to a LOG.

Hope to have finalized this by the end of this week.

 

Hans

Share this post


Link to post
Share on other sites
Now I will try to process, meaning compressing and decompressing, the 16 bit picture that Jaap has send me from his DMR, according to a SQRT and according to a LOG.

 

Hans,

 

Well, should be interesting - but I think it will be very difficult to see any visible difference. Some old-timers on the forum will recall that I compared a DMR image processed using M8 compression to the original image, without being able to see any difference. As someone pointed out at the time, the only image I had available was fairly low contrast, so you might see something different. But you can't tell the difference between the original and the compressed image, then telling the difference between variations of 8-bit compression seems to be likely to be difficult. The original thread is here: http://www.l-camera-forum.com/leica-forum/leica-m8-forum/33768-8-bit-versus-14-bit-dngs.html

 

Sandy

Share this post


Link to post
Share on other sites
Hans,

 

Well, should be interesting - but I think it will be very difficult to see any visible difference. Some old-timers on the forum will recall that I compared a DMR image processed using M8 compression to the original image, without being able to see any difference. As someone pointed out at the time, the only image I had available was fairly low contrast, so you might see something different. But you can't tell the difference between the original and the compressed image, then telling the difference between variations of 8-bit compression seems to be likely to be difficult. The original thread is here: http://www.l-camera-forum.com/leica-forum/leica-m8-forum/33768-8-bit-versus-14-bit-dngs.html

 

Sandy

Hi sandy,

 

Interesting to see what you did. I was not aware of this attempt.

I have invested so much time in preparation, that the last step will be quite easy.

So, no matter what the result might be, I'll bring it to an end.

 

Hans

Share this post


Link to post
Share on other sites
One can, I suggest, [--] state: Precisely which data has been lost has been decided in advance by the camera manufacturer. [--]

For most pictures Leica’s choice works very well and Leica M8 files have exceptionally good shadow detail. Therein lays the problem. The highlight detail is not exceptionally good. It is better than average and in most situations more than adequate but rather too often in my experience it fails to deliver what one would really like. I spend too much time working on highlights in CS3 and very little time working on shadows.

[--] .

Just returning to the qualitative argument:

Peter, I agree, the highlights, such as the areas of a face, head, that are reflecting light (greasy surfaces), are nastiest in portraits. A little bit of local overexposure makes them unhandable. Even though my sitters don't recognize it still it is better than the canikon images. I try to use the 'highlights' slider in Capture One, but that does not (on my monitor) resolve things at all times. Therefore, I tend to accept your remark.

alberti

Share this post


Link to post
Share on other sites
Just returning to the qualitative argument:........ Therefore, I tend to accept your remark.

alberti

 

Alberti,

 

Thanks for bring this back to the original argument which in summary is "Do the 8 bit M8 DNG files do justice to Leica lenses?"

 

My view is that for whatever reason they do not quite match up to the task and this is most evident when dealing with highlights. Just as you say the slightest overexposure and things get very difficult. This seems not to be helped by the fact that the sensor is actually about 1/3 EV faster than the stated speed. After trying everything else I've taken to using my trusty old Gossen Profisix Incident Light meter and this really does help but it should not be necessary. Even if you nail the exposure the pre-printing management of the highlights is not nearly so easy or straight forward as dealing with the shadows.

 

Peter

Share this post


Link to post
Share on other sites

I analyzed the SQRT decompression table a bit in more detail, because I thouht to see some strange things.

 

In the table below, you first see the entry X , from 0 to 255. Second column shows the calculated 14 bit value Int(X*X/4)+0,5). Third column shows the value from the Leica DNG file.

Row 35 is just there as a separator.

 

 

The red figures are the ones that differ from the calculation, but they are all exactly 256 or 100h too low in value, look as an example at column L !

Since the red ones are spread quite randomly over the look up table, I was expecting another table which should be added to this one, to get the right figure.

So far I have not found this correction table although these figures have to be corrected somewhere.

I went back to my first pictures from march '07, when the M8 software was a number of releases behind the current one, but this decompression table has always been the same.

 

Hans

Share this post


Link to post
Share on other sites
Since the red ones are spread quite randomly over the look up table, I was expecting another table which should be added to this one, to get the right figure.

 

Hans,

 

Sorry, but there's only one table; the DNG format has no provision for anything more than a single table. Suggest you look to whatever code you're using to read the table for the problem.

 

Sandy

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue., Read more about our Privacy Policy