Hi all I'm a noob to ATS but I have something for you.

I am also questioning the resolution of the entire SELENE imaging technique, as they say their true imaging resolution is around that 256 B/W bit color field. A Photoshop regular image is 16.2 million color steps, 256 is a gif color depth resolution, and astronomically smaller than 16.2 million color steps, even at black and white.

Besides, we will never get a full resolution image from internet compression anyway!

reply to post by Illustronic


That's a photo from the Terrain Camera, one of Kaguya/Selene's cameras.

Originally posted by Illustronic
I am also questioning the resolution of the entire SELENE imaging technique, as they say their true imaging resolution is around that 256 B/W bit color field. A Photoshop regular image is 16.2 million color steps, 256 is a gif color depth resolution, and astronomically smaller than 16.2 million color steps, even at black and white.

Black and white are just two colours, meaning 2 bit colour depth.

Greyscale with 256 shades of grey is the same detail as a 16 million (or, more precisely, 16777216) colours, because each colour channel (Red, Green and Blue) uses 8 bits (256 shades).

Besides, we will never get a full resolution image from internet compression anyway!

There's no such thing as "internet compression", and GIF and PNG formats are lossless, so their compression doesn't degrade the image. JPEG2000 also has that possibility, but as it also uses a lossy compression method, we can never know what type of compression is used just by looking at the image type.

And this is how that image looks like in the original Kaguya/Selene image,

[atsimg]http://files.abovetopsecret.com/images/member/302ca87fa3f6.png[/atsimg]
Do you see why I don't like Google as an image source?

PS: The above image was converted from an original 16 bits (65536 shades) greyscale image, not 8 bits.

reply to post by ArMaP

GIF and PNG formats are lossless, so their compression doesn't degrade the image.

PNG is a near lossless format, however a GIF is very much so a lossy format worse than a JPEG, because it only can achieve 256 colors, or grayscale color breaks. How a 'so called' uncompresses JPEG becomes lossy is that it will average near values to one digital signal, instead of describing every pixel, like a TIFF, EPS, PSD, and so on, even a PDF will not lose data, PS is supposed to maintain all of the image data, and many other file formats but a JPEG at its best is a lossy file format, so if you see an image on the internet is doesn't have the same amount of data as the original raw file.
Joint Photographic Experts Group.

Originally posted by Illustronic
PNG is a near lossless format,

No, PNG is lossless, as you can see here.

however a GIF is very much so a lossy format worse than a JPEG, because it only can achieve 256 colors, or grayscale color breaks.

No, GIF uses a lossless compression method, but it's limitation to 256 colours doesn't apply when looking at a 256 shades of grey image.

Colour depth is not the same thing as lossy compression. When you change a colour image into a 256 colours GIF you lose colour information, but the pixels remain the same. When you save that image as a JPEG, even with more colours (JPEG sometimes creates more colours to make us think the image looks better than it really is), the compression may create those famous 16x16 squares that make people think that all JPEG images show signs of being "photoshopped".

How a 'so called' uncompresses JPEG becomes lossy is that it will average near values to one digital signal, instead of describing every pixel, like a TIFF, EPS, PSD, and so on, even a PDF will not lose data,

PDFs use JPEG compression in their images, vector information (like letters and simple lines and shapes) are converted to PostScript, which is a based on formulas to recreate those shapes.

Tell me, is 256 out of 16.2 million color breaks a bit of a loss? Exponentially! PNG doesn't support 16.2 million colors.

No I'm not confusing PNG with GIF, Gif is limited to 256, PNG has more but not 16.2 million.

reply to post by ArMaP


When you lose color depth YES your pixels will not remain the same. Haven't you seen those pixel specks around contrast on poor JPEGs? Its because the compression was cranked up, at best a JPEG averages 16.2 million colors down, and will group average out like fields and only hold data of one value for all of those like fields, that's how it compresses. It doesn't repeat the vector information for multiple like fields, it sends one single data code for them all.

Don't confuse color depth with pixel resolution, they are two different things.

reply to post by Illustronic


Yes, it's a loss, but that doesn't happen in greyscale images like the ones from Clementine because they already work with 8 bits (256 shades of grey). So, while there's no loss of data with a greyscale GIF or PNG, JPEG always has that problem.

Original images from recent missions like Kaguya are 16 bits greyscale images, and only TIFF and PNG (besides other uncommon formats) can use that bit depth.

I see that there are some confusions about image formats.

Black and white uses only one bit, and it can only show two colours.

8 bit images can show 256 colours. Greyscale images (images without any colour information) are usually 8 bit images.

24 bit images can show up to 16,777,216 (not 16.2 millions), because they are made from 3 channels (red, green and blue) and each of those channels uses 8 bits. That's why we can make colour images from the greyscale images from the Mars rovers, for example, if we have three images from the three channels for red, green and blue wavelengths.
Some image formats add a fourth channel for the transparency, making it a 32 bit image.

Instead of 8 bits, some formats have the possibility of using 16 bits, making it possible to have up 65,536 levels of grey in a greyscale image or for each channel in a colour image, so colour images can have up to 281,474,976 million colours (and, in some cases a 65,536 levels transparency channel).

As for the compression, the highest compression levels are the result of lossy compression, in which data is permanently lost, the best known case being JPEG. Lossless formats cannot get such high compression levels, but they do not suffer from any data loss and can be saved as many times as we want them (if we use only lossless formats) without degrading the image further with each saving.

GIF is a 8 bits image format with lossless compression, so while limited to 256 colours, it doesn't suffer from data loss. As most images taken by the satellites and probes sent to space are greyscale photos, taken through a clear filter (making it look like a real gryescale photo) or through different filters for different wavelengths, using GIF images to show those photos does not result in loss of data, because the original format was only a 8 bit format.

PNG is a 1, 2, 4, 8, 16, 24, 32, 48, and 64 format, so it can go from just black and white (1 bit) to 281,474,976 million colours, with lossless compression, so it doesn't suffer from loss of data like JPEG and it can show even more colours than JPEG, which is limited to a maximum of 24 bits.

The image I posted above was converted from the original image in a modified PDS (Planetary Data System) format, and in this case they (Jaxa, the Japanese space agency) uses 16 bits, monochromatic (greyscale) images. The program(s) I used to read the PDS image and create the PNG image I posted was ISIS, and it makes an excellent work at converting from 16 to 8 bit images. Photoshop can open those images, but it's not as good as interpreting the information as the custom built ISIS suite.

I hope I haven't made things more confusing with this "explanation".

Originally posted by ArMaP
And this is how that image looks like in the original Kaguya/Selene image,

[atsimg]http://files.abovetopsecret.com/images/member/302ca87fa3f6.png[/atsimg]
Do you see why I don't like Google as an image source?

Yes, exactly.
We regularly see this kind of confusion, see this one for example recently taken for (another...) face on Mars:

From Google:



In Hi-resolution:

Originally posted by ArMaP
GIF is a 8 bits image format with lossless compression, so while limited to 256 colours, it doesn't suffer from data loss.

Here's the problem as I see it.

Wikipedia is using the term "lossless" where it violates their own definition of "lossless". So of course if they define a term, and then use the same term in a manner other than which it's defined, that will result in confusion. Also there is some historical precedence as a contributing factor to the confusion.

Let's look at the definition Wikipedia uses for Lossless data compression:

Lossless data compression is a class of data compression algorithms that allows the exact original data to be reconstructed from the compressed data.

That's pretty much the defintion I'd use. PNG can definitely be such a format, if a version of png is used that has an adequate number of bits, to allow the original image to be reconstructed. In my graphics application, when I convert an image to png format, I have a number of options, one of which will be lossless, and the other options will NOT be lossless, because I would be unable to reconstruct the original image from the compressions made with too few bits. Data is lost.

So first, PNG isn't always lossless. It can be, if the right options are selected when making the png compression, but if the wrong options are selected, you may not be able to reconstruct the exact original data.

The claim that GIF is a lossless compression format seems to violate the definition of lossless. I don't see how you can possibly reconstruct the EXACT original data from a GIF compression except in the narrow exception that the original image contains 256 colors or less. Perhaps they mean to say "nearly lossless" but that's not what they say, so I think Wikipedia is wrong, they don't meet their own definition. And there are even worse examples on Wikipedia of misuse of the term lossless.

They claim JPEG is a lossy format (no argument there) and then claim that JPEG2000 is a lossless format. Then they go on to describe the "artifacts" created with JPEG_2000, which are different from the artifacts created with JPEG:

the JPEG 2000 standard provides both lossless and lossy compression in a single compression architecture. Lossless compression is provided by the use of a reversible integer wavelet transform in JPEG 2000....in comparison with JPEG, is in terms of visual artifacts: JPEG 2000 produces ringing artifacts, manifested as blur and rings near edges in the image, while JPEG produces ringing artifacts and 'blocking' artifacts, due to its 8×8 blocks.

OK most of us here know very well the JPEG blocking artifacts, but if the image has ringing artifacts instead is it really lossless? I'm not as familiar with JPEG2000 but maybe it's like PNG in that it's only lossless if certain options are selected. It's obviously not always lossless, neither is PNG.

I think almost every site I've seen claims that GIF is a lossless format. I believe this claim is only true based on the very limiting condition that the original image doesn't contain more than 256 different colors. If the original image contains 257 colors or more, it's not possible to re-create the exact original image from the GIF compression and therefore contrary to the claims on 99% of the internet, it's NOT really lossless, if lossless is defined (as I think it should be ) as being able to re-create the original image from the compressed image. This site explains the problem, yet they STILL call it lossless when obviously they're explaining why it's NOT lossless:
www.devsource.com...

One limitation of GIF in certain circumstances is that it is limited to 256 simultaneous colors. The 256 colors, though, are selected from a palette of millions of colors; but GIF files can only use 256 of those colors at a time. For most Web applications, there's a commonly accepted palette known as the browser-safe palette that many GIF images now use. If you use this browser-safe palette, your GIF images are almost guaranteed to have the best reproduction on systems all over the world. However, if you use some custom palette that is not easy to match on all systems, your image may not look the same and may suffer when it is displayed on another system.

So, if the original image has 1000 colors, and GIF compression reduces that to 256 colors, you can't recreate the exact original image with 1000 colors from that, right? Therefore if lossless means being able to recreate the original image, then GIF isn't lossless when the original image contains 257 colors or more. Therefore practically the entire internet is wrong by calling it lossless.

I think I can explain this, it probably has historical roots. GIF was a compuserve format back in the early days of the internet, when virtually nobody had more than 256 colors, heck the original IBM PC was monochrome, then 16 colors was a big deal, then 256 colors was an even bigger deal. So back then no image had more than 256 colors because nobody had the hardware to handle more than 256 colors, it didn't exist. So GIF was correctly described as a lossless format, because, at the time, it WAS. But somehow, as PC tech advanced and images could then have more than 256 colors, somehwere along the line GIF lost the ability to recreate the original image, but I suppose it was still referred to as lossless on a historical basis since once it really was lossless, even though it's not anymore, unless the original image has 256 colors or less.

Originally posted by ArMaP
That's a photo from the Terrain Camera, one of Kaguya/Selene's cameras.

Thanks for backing me up on that, I didn't confirm it but I was pretty sure it was, just not 100% sure.

And this is how that image looks like in the original Kaguya/Selene image,

[atsimg]http://files.abovetopsecret.com/images/member/302ca87fa3f6.png[/atsimg]

As I said on page 1, I didn't think it was a collapsed lava tube but rather a series of impact craters, and in that image it looks even more like a series of impact craters.

Remember Shoemaker-Levy 9, a loose conglomerate of objects that broke apart before they impacted Jupiter and made a string of impacts? My guess would be that series of impact craters may have been created in a somewhat similar fashion. Perhaps 4-5 objects barely sticking to each other from the force of gravity made one pass near the Earth which separated them from each other just a little bit, and then on a subsequent orbit they impacted in sequence in slightly displaced positions which more or less formed a line. But that's just a guess.

Originally posted by Arbitrageur
In my graphics application, when I convert an image to png format, I have a number of options, one of which will be lossless, and the other options will NOT be lossless, because I would be unable to reconstruct the original image from the compressions made with too few bits. Data is lost.

What application is that?
I have never seen a lossless PNG image, although I have seen a compression level control.

PNG is not supposed to have a lossy compression scheme.

The claim that GIF is a lossless compression format seems to violate the definition of lossless.

No, because "lossless" is applied to the compression method and not a hypothetical conversion from another format.

You have an example of a lossless GIF image where there wasn't any data loss on the image to the left, my avatar. When I made it it had already less than 256 colours, so there was no data loss.

If we convert a 24 bit colour image into a 8 bit GIF, we are (probably) going to lose data, but not in the compression, we are losing it on the bit depth conversion, and that conversion is not part of the compression method.

It's the same thing as saying that a Word document loses formatting when pasted to Notepad and saved as txt. It's not the saving to txt that did the data loss, it was the pasting on Notepad.

They claim JPEG is a lossy format (no argument there) and then claim that JPEG2000 is a lossless format. Then they go on to describe the "artifacts" created with JPEG_2000, which are different from the artifacts created with JPEG:

JPEG 2000 has two different compression methods, a lossless and a lossy, and that only helps to the confusion.

These are some image file formats that have lossless compression methods:
GIF
PNG
BMP
JPEG 2000
TIFF

These are some image file formats that have lossy compression methods:
JPEG
JPEG 2000
TIFF

Originally posted by ArMaP

Originally posted by Arbitrageur
In my graphics application, when I convert an image to png format, I have a number of options, one of which will be lossless, and the other options will NOT be lossless, because I would be unable to reconstruct the original image from the compressions made with too few bits. Data is lost.

What application is that?

I have never seen a lossless PNG image, although I have seen a compression level control.

PNG is not supposed to have a lossy compression scheme.

I'm using Wikipedia's definition of lossless. If you can re-create the original image from the compressed image, it's lossless. If you can't, it's not. If you don't use enough bits when you compress the image, you can't reconstruct the original. Here's a screenshot (from firehand Ember) of the menu I get when I convert to PNG, I have 4 options for the number of bits for color depth.
[atsimg]http://files.abovetopsecret.com/images/member/ba562ad2037b.png[/atsimg]
Pick a number that's too low, and you can't re-create the original image from the compressed image.

If we convert a 24 bit colour image into a 8 bit GIF, we are (probably) going to lose data, but not in the compression, we are losing it on the bit depth conversion, and that conversion is not part of the compression method.

It's the same thing as saying that a Word document loses formatting when pasted to Notepad and saved as txt. It's not the saving to txt that did the data loss, it was the pasting on Notepad.

Microsoft makes no claim that you can restore everything in the original word document if you save it as a text document. But Wikipedia does state that you can recreate the original image from a compressed image if the compression is lossless. So no, it's not the same.

I'm not making that definition up, I'm using their own definition.

Bits and color depth are two different things, increasing the bits don't increase the gamut of the color field. Bits are simply the binary code for computer processing.

A bit is short for “binary digit.” It is basically how a computer stores and makes references to data, memory, etc. A bit can have a value of 1 or 0, that’s it. So binary code is streams of 1’s and 0’s, such as this random sequence 100100100111. These bits are also how your processor does calculations. By using 32 bits your processor can represent numbers from 0 to 4,294,967,295 while a 64-bit machine can represent numbers from 0 to 18,446,744,073,709,551,615. Obviously this means your computer can do math with larger numbers, and be more efficient with smaller numbers.

Bits do not create larger color gamut, the color gamut is limited to the wavelengths of light you can see. Without going into the chroma levels of colors, red being the largest, then yellow, and blue being the smallest you can't use simple math to determine the amount of color levels.

I said 16.2 from memory (it is 16.7-something) from when Photoshop (then using a smaller gamut of color–rgb IEC1966 before the CS versions came out), used to tell you the amount of color you can save at, 64, 256, thousands, millions, or 16.7 million colors. CS came out with a larger gamut color profile which I use, Adobe 1998 rgb and I can't find documentation on the number of colors in the gamut.

Let me put it this way, you save something in Adobe 1998 rgb you have millions of colors described by trillions of bits, now you convert the same image to CMYK and you just added bits to the information by having 4 channels, but you just lost tons of information in the gamut.

CMYK has a 0-100 color saturation scale.
RGB has a 0-255 scale of color saturation. In CMYK you added bits of data describing less than 40% of the rgb color chroma saturation levels.

Anything above 16 bit color is not a workable profile, it is just a conversion and a data transfer mechanism. You don't add to the color gamut by working in 16 bit rgb, the only way you can use the full gamut is by increasing the pixel count.

Originally posted by Arbitrageur
I'm using Wikipedia's definition of lossless. If you can re-create the original image from the compressed image, it's lossless. If you can't, it's not. If you don't use enough bits when you compress the image, you can't reconstruct the original.

And that and different things. Compression is one thing, number of colours is another. You can have a file format with compression and 256 colours and a file format without compression and 256 colours.

Here's a screenshot (from firehand Ember) of the menu I get when I convert to PNG, I have 4 options for the number of bits for color depth.
[atsimg]http://files.abovetopsecret.com/images/member/ba562ad2037b.png[/atsimg]
Pick a number that's too low, and you can't re-create the original image from the compressed image.

No, you can't recreate the original from the image saved with less colours, regardless of compression.

Microsoft makes no claim that you can restore everything in the original word document if you save it as a text document.

That's not what I was saying, I said "copying formatted text from Word into Notepad", not saving a Word document as text. If you write a sentence in Word and mark some words as bold, if you copy that text to Notepad you will lose the formatting, regardless of having the final text file saved to disk or in a zip file.

I'm not making that definition up, I'm using their own definition.

No, you using one definition for different things.

See it this way: You make a new, 256 colours image in an image processing program, and fill that image with all possible 256 colours.

Now, if you reduce the number of colours to 64, you are going to lose some, even before saving the image, so you have lost data without using any compression.

That's great ArMaP, losing color IS compression.

This is much more evident in video file formats, that more clearly state the color profile you have a choice to use. Another kind of compression, (that JPEG uses, is elimination of data redundancy. I tried to explain that earlier, when two pixels have the same color value, JPEG will only store that data once, and then stores where its coordinates are, thus compressing the file size. Video gets even more amazing than that, but based on the same principle, which is image averaging, data loss.

Haven't you ever opened up a JPEG file from, well lets say the Navy News Service photo galleries, and the image when opened is like 30M, but it has the pixelation of an image half its size? You also get sometimes that edge glow stuff Arbitrageur explained, that is the kind of digital artifact created by a lossy compression. It had the pixel count to be clearer, but it isn't. Even is smooth solid fields of color spotty pixels of a different color show up from the JPEG image averaging system. It tries to reproduce a color field by the average of a larger space of color, so it creates spots of different colors so the field averages out to the original by proxy.

OK, here's a clear easy to read explanation of the difference between the 1966 rgb and 1998 rgb color profile from Adobe, in short they both have the same number of colors, but they are different colors.

I'm not quite sure when this guy wrote this article (I don' t believe it holds true today), but it will put into a nutshell what color profiles do. Here's an excerpt so you know what he's talking about, related to what I was talking about.

sRGB is the older of the two and is the Microsoft Windows default. The ‘s’ stands for ‘standard’. sRGB is almost always shorthand for the ANSI designation of: sRGB IEC61966-2.1. sRGB is basically the set of colors that can be seen on the average computer color monitor or color TV.

aRGB was established by the Adobe software company with the ‘a’ standing for ‘Adobe’. aRGB is variously referred to as Adobe RGB, aRGB, Adobe RGB (1998) and SMPTE-240M just to keep everyone as confused as possible. Not all colors in aRGB can be represented on even the top of the line color computer monitors.

Adobe color profiles then and now

Today many plotter printers have as many as 8 color drums, that do saturate more than old CMYK printers that it seems he is making some reference to. Printing an image is very dependent on the printer you are using, and I always start with 1998 rgb, and lastly convert if the printer needs a CMYK compression. Like I said, some good digital plotters don't need 1998 rgb compression, in fact they do the best with the biggest color profile.

This one is funny;

Adobe RGB represents a wider range of possible colors using the same amount of information as sRGB by making the colors more spaced out. Since sRGB has a narrower range of colors than Adobe RGB, it cannot display certain highly saturated colors that could still be useful in certain applications, such as professional-grade printing. Thus, photographers and graphic artists that need this extra color range for specific purposes would choose Adobe RGB over sRGB.

Pros
Wider range of colors than sRGB
Better for professional prints
Can always obtain benefits of sRGB later down the road

Cons
Will be displayed incorrectly by most browsers
Complicates workflow

So my 'old school' of referring to the old and new rgb profiles as 1966 and 1998 must be confusing, when I should say sRGB, and aRGB, but are the 'disadvantages' stated (above) outweighing the advantages? Would I be interested in what 'most' people see? Would it complicate MY workspace? Not. It sounds like simple Microsoft stroking and everything Apple/Adobe bashing. Maybe one day Microsoft will catch up with QuickTime, but I doubt it.

Originally posted by Illustronic
That's great ArMaP, losing color IS compression.

No, although the result may be the same when we compare lossy compression schemes with colour loss (loss of data), they are not the same thing. You can have lossless compression but you cannot have lossless colour reduction.

When you reduce the number of colours in one image you are obviously reducing the resulting file size, but that's not compression, it's the same as writing in "txtspk". You get the general meaning by reducing the information in the data, and that loss can only be compensated by "imagining" the missing data.

Compression is just getting the whole information (in lossless compression) or part of the information (with lossy compression) inside the data file.

Compression is only applied to the resulting file, the number of colours is an attribute of the image.

This image is a 64 x 64 pixels image, with 8 bits per channel (red, green and blue) and a total of 2,594 colours, saved as a PNG without compression.

[atsimg]http://files.abovetopsecret.com/images/member/3308be36728b.png[/atsimg]
When I made that image in GIMP it took (at least) 64 x 64 x 3 = 12,288 bytes of memory to display the image. When I saved it as an uncompressed PNG, the resulting file size went up to 12,445 bytes, because of the information that the file needs to "present" itself to the programs opening it.

Saved as PNG with the highest compression, the file size was reduced to 7,919 bytes, but when we open the image it still takes up 12,288 bytes of memory to be displayed.

[atsimg]http://files.abovetopsecret.com/images/member/f928f1837ffc.png[/atsimg]
That's because compression is file compression, it only applies to the file, not the image itself.

Now, if I reduce the number of colours to 256, I am presented with several options, like using a dithering mode (when the program tries to create colours outside the 256 colours palette by using mixed dots of colours from the palette) or not. I didn't use dithering or a web-optimized (in which the common "web colours" are always included, even if they are not originally in my image), so I got this final image.

[atsimg]http://files.abovetopsecret.com/images/member/8cd0f0a4edb7.png[/atsimg]

That image is a 64 x 64 x 1 = 4,096 bytes image, but in as an uncompressed PNG it takes up 5,021 bytes.
The difference between the file size (5021) and amount of data (4096) is bigger than in the 8 bits per channel probably because the file needs to have the palette inside to show what colours it is using.

With the highest compression the file turns into a 4,635 bytes file, showing that the compression (as expected) could not be as efficient as before because it has less data to work with.

[atsimg]http://files.abovetopsecret.com/images/member/85136fec21dd.png[/atsimg]
We can see that there was loss of data when I reduced the number of colours from a possible maximum of 16,777,216 (although only 2,594 colours were being used) in this composite image that shows the difference between those images.

[atsimg]http://files.abovetopsecret.com/images/member/6c5802af7e8b.png[/atsimg]
As the image above was made with the images being displayed on my computer, the file compression didn't make a difference, while a file difference program (like WinDiff) will show that only the header identifying the file as a PNG is the same.

What I am trying to show is that the number of colours in an image, being an attribute of that image, is something we can see even when we do not have a file yet. We can take a photo of the computer screen and we can see (if the photo is good enough, obviously) that there are differences in the images, even when the images exist only on the computer's memory.

When we save the image in a file format that allows compression, then we can chose a compression method, and the resulting image (when read back from disk) may have loss of data if we chose a lossy compression method, when compared with the image we were seeing when we saved it.

So, while lossy compression and reducing the number of colours in an image are both ways of reducing the file size by losing data, reducing the number of colours is not compression, it's like an averaging of the information in the image, regardless of the compression we may use on the file.

Originally posted by Saint Exupery


Well, you're in luck. As of tonight (20:00 CDT Sunday, June 5, 2011), more than 70% of the dark side of the Moon is visible from Earth.

Erm...., No!

The 'dark side of the moon' NEVER faces earth. You probably mean that 70% of the side that does face earth will be in shadow.