Thu, Nov 14, 9:49 AM CST

Renderosity Forums / Poser - OFFICIAL



Welcome to the Poser - OFFICIAL Forum

Forum Coordinators: RedPhantom

Poser - OFFICIAL F.A.Q (Last Updated: 2024 Nov 14 9:14 am)



Subject: Sorta OT, but pertaining to Poser: jpegs vs. png's vs. tiff


  • 1
  • 2
jartz ( ) posted Wed, 24 November 2010 at 3:54 AM · edited Wed, 13 November 2024 at 9:06 PM

I been hearing lately (and venturing into the forums) about how .jpegs can loose some detail or cause pixilation.  So what's the best source, .png or .tiff format?

Can anyone chime in?

Happy early Thanksgiving to everyone here.

____________________________________________________________________________________________________________________________

Asus N50-600 - Intel Core i5-8400 CPU @ 2.80GHz · Windows 10 Home/11 upgrade 64-bit · 16GB DDR4 RAM · 1TB SSD and 1TB HDD; Graphics: NVIDIA Geforce GTX 1060 - 6GB GDDR5 VRAM; Software: Poser Pro 11x


ShaaraMuse3D ( ) posted Wed, 24 November 2010 at 4:08 AM

.jpegs are compressed in a way that you lose some data (Especially at higher compression rates) 

.png are good because they offer lossless compression.

However, if you have very large source files, they will still be huge, so sometimes very high quality (100%) jpgs may still be the best way to go.


RobynsVeil ( ) posted Wed, 24 November 2010 at 4:31 AM

I guess it's all about investment vs dividends... is using a tiff or png going to yield a dramatically better render? Depends on the scene, the machine (RAM) and the requirements of the artist.

I've actually taken 4000 x 4000 skin images down to 2000 x 2000 with no appreciable difference. But then, I'm not doing a Ultra-Super-Close-Up where you could count nose hairs. :biggrin:

Monterey/Mint21.x/Win10 - Blender3.x - PP11.3(cm) - Musescore3.6.2

Wir sind gewohnt, daß die Menschen verhöhnen was sie nicht verstehen
[it is clear that humans have contempt for that which they do not understand] 

Metaphor of Chooks


ghonma ( ) posted Wed, 24 November 2010 at 5:49 AM

Note that even 100% JPGs lose a lot of color info so if you're going for quality, you do not want to use JPGs ever. PNGs for 8 bit files and TIFFs or OpenEXR for float should be your preferred formats.

Also there is no difference between JPGs, PNGs, TIFFs etc in terms of RAM usage. They all get converted to uncompressed formats on rendering and all take the same amount.


ice-boy ( ) posted Wed, 24 November 2010 at 5:54 AM

i watching gnomon and other dvd tutorials. and they always use .tiff.

 

why?


Acadia ( ) posted Wed, 24 November 2010 at 6:43 AM

I always use png files when saving in Poser to take into my graphic program. 

I do alot of single renders that require no background, so .png is ideal because it opens into any graphic program backgroundless (unless of course you saved it with a background in place).  With a .tiff format, you have to apply a mask of the image to itself to remove the background.

And as others have said, .jpg images always have quality loss because the file is compressed, even at 100%. And the more often you save a .jpg file the more loss you experience because the compression is cumulative.

"It is good to see ourselves as others see us. Try as we may, we are never
able to know ourselves fully as we are, especially the evil side of us.
This we can do only if we are not angry with our critics but will take in good
heart whatever they might have to say." - Ghandi



ghonma ( ) posted Wed, 24 November 2010 at 6:53 AM

Quote - i watching gnomon and other dvd tutorials. and they always use .tiff

Cause .tiff is an old and widely supported format and it allows things like layers, thumbnails etc. But since poser doesn't render layered tiffs (i think) you're better off with png. If you have ppro2010 though, PSD is also a good choice as it lets you use render passes.


bagginsbill ( ) posted Wed, 24 November 2010 at 7:04 AM · edited Wed, 24 November 2010 at 7:08 AM

file_462056.jpg

Why do members of this forum have to spout the equivalent of old wives tales over and over and over. Is it just impossible for any of you to try proving anything?

Sigh.

According to what I keep reading, if I open a JPEG and re-save it I lose something, right?

I screen grabbed Acadia's post. I then saved it as PNG and as JPEG (100%).

Then I opened the JPEG and saved it again - until I had gone through 15 JPEG compression steps.

I will now post the two grabs. You tell me which is the JPEG that was modified 15 times. No fair peaking at the file names until you do the comparison fairly with your own eyes.

I understand something is missing in the JPEG, but I defy you to see what. And whatever is missing is missing in all 15 copies, including the first.

JPEG removes stuff you don't need or notice. Once removed, no more is removed. Essential data remains.

It's like sweeping the floor. Just because you sweep it 15 times doesn't mean the floor got removed.


Renderosity forum reply notifications are wonky. If I read a follow-up in a thread, but I don't myself reply, then notifications no longer happen AT ALL on that thread. So if I seem to be ignoring a question, that's why. (Updated September 23, 2019)


bagginsbill ( ) posted Wed, 24 November 2010 at 7:04 AM · edited Wed, 24 November 2010 at 7:05 AM

file_462057.png

You probably have to click these and compare at full size.


Renderosity forum reply notifications are wonky. If I read a follow-up in a thread, but I don't myself reply, then notifications no longer happen AT ALL on that thread. So if I seem to be ignoring a question, that's why. (Updated September 23, 2019)


bagginsbill ( ) posted Wed, 24 November 2010 at 7:07 AM

Note - some browsers will show you these two images with different color profiles and so one may appear lighter than the other. Be aware that they are identical in color.


Renderosity forum reply notifications are wonky. If I read a follow-up in a thread, but I don't myself reply, then notifications no longer happen AT ALL on that thread. So if I seem to be ignoring a question, that's why. (Updated September 23, 2019)


Teyon ( ) posted Wed, 24 November 2010 at 7:54 AM

I think the first is a Jpeg - that's without enlarging them. Did I win a prize? :)


bagginsbill ( ) posted Wed, 24 November 2010 at 8:42 AM

Only if this coin I flip comes up heads - nope you lost. grin


Renderosity forum reply notifications are wonky. If I read a follow-up in a thread, but I don't myself reply, then notifications no longer happen AT ALL on that thread. So if I seem to be ignoring a question, that's why. (Updated September 23, 2019)


WandW ( ) posted Wed, 24 November 2010 at 8:59 AM

Great experiment, BB.  Thanx for setting it straight.  😄

----------------------------------------------------------------------------------------

The Wisdom of bagginsbill:

"Oh - the manual says that? I have never read the manual - this must be why."
“I could buy better software, but then I'd have to be an artist and what's the point of that?"
"The [R'osity Forum Search] 'Default' label should actually say 'Don't Find What I'm Looking For'".
bagginsbill's Free Stuff... https://web.archive.org/web/20201010171535/https://sites.google.com/site/bagginsbill/Home


Haarspalter ( ) posted Wed, 24 November 2010 at 9:00 AM

Quote - Why do members of this forum have to spout the equivalent of old wives tales over and over and over. Is it just impossible for any of you to try proving anything?

Sigh.

According to what I keep reading, if I open a JPEG and re-save it I lose something, right?

I screen grabbed Acadia's post. I then saved it as PNG and as JPEG (100%).

Then I opened the JPEG and saved it again - until I had gone through 15 JPEG compression steps.

I will now post the two grabs. You tell me which is the JPEG that was modified 15 times. No fair peaking at the file names until you do the comparison fairly with your own eyes.

I understand something is missing in the JPEG, but I defy you to see what. And whatever is missing is missing in all 15 copies, including the first.

JPEG removes stuff you don't need or notice. Once removed, no more is removed. Essential data remains.

It's like sweeping the floor. Just because you sweep it 15 times doesn't mean the floor got removed.

 

I maintain this is nonsense. See more:

http://en.wikipedia.org/wiki/JPEG

 


jerr3d ( ) posted Wed, 24 November 2010 at 9:28 AM

I seem to recall the quality of jpg files being not as good as they are today, back about 10 years ago, say Photoshop 3.

Maybe the Joint Photographic Experts Group (I had to look that up on Wikipedia) got together and improved the quality of jpg files, and perhaps that is where the idea that jpgs mess up the quality of a image came from.


markschum ( ) posted Wed, 24 November 2010 at 9:33 AM

png files for initial render , then psd for layered photoshop images, and finally png for printing or jpg for the web.

jprg compression removes colors. So if you have say a forest scene with 50 shades of green jpeg compression will reduce the number of different greens. 


cspear ( ) posted Wed, 24 November 2010 at 10:48 AM

I won't add to the confusion other than to say that using a lossy compression scheme (e.g. JPEG) requires some common sense: if you compress the hell out of an image, of course it will lose detail and worse, introduce compression artefacts. Also, the TIFF format accommodates all sorts of compression including LZW, ZIP and JPEG so is not in itself a guarantee of quality. These days I'm using PNG as my preferred format.

What would be great is if some future version of Poser could address Photoshop files, and specifically layers, properly: that way all the variations (make-up, tattoos, body hair etc.) would be in a single file and could be turned on or off as required.


Windows 10 x64 Pro - Intel Xeon E5450 @ 3.00GHz (x2)

PoserPro 11 - Units: Metres

Adobe CC 2017


pjz99 ( ) posted Wed, 24 November 2010 at 1:50 PM

Quote - JPEG removes stuff you don't need or notice. Once removed, no more is removed. Essential data remains.

Bagginsbill yes, that is nonsense.  Only in the very specific and impractical set of circumstances you tested with is that statement true, otherwise it is horrible, horrible advice.

My Freebies


Cyberwoman ( ) posted Wed, 24 November 2010 at 2:56 PM

Great experiment, bagginsbill, and great analogy to sweeping floors. That backs up exactly what I've found in my own graphics-manipulation projects--that I can save an image three or four times as high-quality-setting JPEG images, with no noticable loss in quality. If I am doing a large project that I will be backing up many times, I save it as PSDs while I'm working on it (although that is mostly because PSDs save layers, the lack of image quality worries is just a nice side effect 😉). Then at the end I save it as a JPEG, normally with a high quality level. The only times I have generated bad-quality photos were when I had the quality level set too low (and even then the photos were usually fine for web use). Renders from Poser get exported as JPEGs or PSDs, depending on what I'm going to do with them.

~*I've made it my mission to build Cyberworld, one polygon at a time*~

Watch it happen at my technology blog, Building Cyberworld.


FightingWolf ( ) posted Wed, 24 November 2010 at 4:22 PM

I don't use tiff simply because I never had a reason or need to use it.  As to which one is best to use then it would all depend on what you are trying to accomplish.  The file format that you should use should be based on your need.  So think of it as which file format is best for what you want to accomplish.

For me the JPEG and the PNGs are a matter of file size and background transparency. I often save my rendered files as a .png file because it allows me to do things like piece together a large scene or when I want the flexibility to postwork individual elements in my scene by moving them around within a graphics editor like Photoshop or Paintshop Pro. With a .png file I can work in multiple layers but with a .jpg file everything will be as one image.  .png file formats are also good if you plan on using your renders as clip art.
After I finish post working my image in the .png file format then I save the completed version just in case I want to change things around in the scene.  If I'm planning on posting the image online then I'll save my finished scene as a .jpg file.  This way the image meets the size requirements for many online galleries also the .jpg file format is much smaller in file size than the .png version of my completed scene so it will load faster as well.

If you ask a general question about which is best without defining what you are trying to accomplish then all you are going to get are posts like you have seen above. The best image file to save as for quality is all relative to what you are going to use the image for.



bagginsbill ( ) posted Wed, 24 November 2010 at 4:27 PM

Quote - > Quote - JPEG removes stuff you don't need or notice. Once removed, no more is removed. Essential data remains.

Bagginsbill yes, that is nonsense.  Only in the very specific and impractical set of circumstances you tested with is that statement true, otherwise it is horrible, horrible advice.

I backed up what I claimed with evidence, and if you can understand it I could also explain the math - how the discrete cosine transform works and how information density is reduced using the JPEG techniques.

Nobody has contradicted anything I've said or in fact shown. You're contradicting things I didn't say - things that are indeed nonsense.

I find this sort of baseless argumentative attitude offensive. Do you have a math point to make? Then make it. Because I already demonstrated my point with a picture. All that's left is the math.


Renderosity forum reply notifications are wonky. If I read a follow-up in a thread, but I don't myself reply, then notifications no longer happen AT ALL on that thread. So if I seem to be ignoring a question, that's why. (Updated September 23, 2019)


MagnusGreel ( ) posted Wed, 24 November 2010 at 4:42 PM

ah hello.

 

can someone point me to the calm and reasoned discussion on the pro's and con's of file formats for the storage of graphics?

 

I thought this was it, but obivously it's not.

Airport security is a burden we must all shoulder. Do your part, and please grope yourself in advance.


pjz99 ( ) posted Wed, 24 November 2010 at 4:58 PM

file_462069.jpg

> Quote - I find this sort of baseless argumentative attitude offensive.

Please be a big boy and don't react like that.  I think we can agree that there are significant differences between this pic...

My Freebies


pjz99 ( ) posted Wed, 24 November 2010 at 5:00 PM

file_462070.jpg

and this pic (saved at min quality).  Also, opening and saving with no changes is not the same as "modifying".  Taking your words at literal value has real problems, notwithstanding what you might have meant.

My Freebies


FightingWolf ( ) posted Wed, 24 November 2010 at 5:33 PM

Quote - ah hello.

 

can someone point me to the calm and reasoned discussion on the pro's and con's of file formats for the storage of graphics?

 

I thought this was it, but obivously it's not.

The pros and con's of file formats for the storage of graphics.

.jpg good but will not have a transparent background. Smaller file size than .png and is commonly used on the Internet. Benefit is that it doesn't take up space and the image can still look high quality.

.png good file that is great for working in layers because it can give you a transparent background. It's larger than a .jpg of the same size. Meaning if you save your render in .png and then convert it into a .jpg then the .jpg will be smaller file size than the original .png file.  This file format is often used for production pieces like clipart, tubes, and post working in Photoshop or Paintshop Pro.  Use this file if you want to move separately renderd objects around in the scene during the postwork phase.

.psd files gives you the same benefits as a .png file with the exception that is a Photoshop file format that is HUGE. It is the largest out of the .jpg, .png, .psd. file formats.

The pros and cons of the files depend on what you are trying to do.  If you want a transparent background image to use as clip art or to add on a 2D background then you'll need to use a .png file. In this case the .jpg file format is not the best to use.

If you want to put your an image on the Internet for people to view then use the .jpg file because you will get a quality image without the massive file size. If you have a decent monitor then the image will look great.  If you don't have a decent monitor then even a high quality image would look bad.

The file that you save the image as all depends on what you are planning to use the image for.  If you are going to use it for printing posters then some printers are going to ask you for a .png file but not a .jpg file. If you are going to use it print on paper then either one will do.

Here is my guide line for saving Poser Renders.

  1. Save as a .png always because it gives me the best of two worlds. Transparency at a lower file size than .psd.

  2. If I need to covert the file later then it's easy to do but I always keep a .png version because it gives me the most flexibility at a smaller file size.



bagginsbill ( ) posted Wed, 24 November 2010 at 5:45 PM · edited Wed, 24 November 2010 at 5:48 PM

pjz,

Where was I ever talking about saving at min quality?

I was responding to

Quote - Note that even 100% JPGs lose a lot of color info

No they don't.

Quote - as others have said, .jpg images always have quality loss because the file is compressed, even at 100%.

Yes but the loss is so small most people cannot detect it by normal observation.

Quote - And the more often you save a .jpg file the more loss you experience because the compression is cumulative.

And I demonstrated that this is simply not the case.

I was responding to two fallacies. Never was I responding to the idea that saving at low quality is undetectable, which is what you seem to be arguing.

The two fallacies, commonly repeated, are:

  1. JPEG cannot come close enough to the original to be satisfactory, even at 100% quality.

  2. JPEG artifacts accumulate from repeated open/save cycles, even at high quality.

These are both incorrect statements. My responses are not nonsense. If you're going to say I'm wrong, then explain how I'm wrong. Talking about minimum quality has not got anything to do with what I was talking about or showing.

Quote - this pic (saved at min quality). 

That's a wonderfully unresponsive statement. I stated 100% quality and was showing that it is not a certainty that visible artifacts appear with cumulative compression at high quality. Artifacts are there but they remain small regardless of how many times you re-compress the image.

What is the problem with my demonstration?


Renderosity forum reply notifications are wonky. If I read a follow-up in a thread, but I don't myself reply, then notifications no longer happen AT ALL on that thread. So if I seem to be ignoring a question, that's why. (Updated September 23, 2019)


Haarspalter ( ) posted Wed, 24 November 2010 at 6:14 PM

Quote - What is the problem with my demonstration?

 

The problem is which is it still nonsense.

http://en.wikipedia.org/wiki/JPEG


pjz99 ( ) posted Wed, 24 November 2010 at 6:38 PM

Quote - Never was I responding to the idea that saving at low quality is undetectable, which is what you seem to be arguing.

Actually you didn't address quality at all, but rather made a blanket statement, which is only correct in the circumstances you tested with (as I said).

Quote - I stated 100% quality and was showing that it is not a certainty that visible artifacts appear with cumulative compression at high quality.

The "at high quality" was absent from your blanket statement.  You're also confusing "open and re-save with no changes" with "modify and save".  I'm not going to play this game with you of dissecting each and every word of what you said and previous posters said.  You can repeat the same blanket statement, and it will be the same blanket statement, only true in the specific impractical circumstances you demonstrated. 

My Freebies


nruddock ( ) posted Wed, 24 November 2010 at 6:47 PM

Quote - > Quote - What is the problem with my demonstration?

The problem is which is it still nonsense.

http://en.wikipedia.org/wiki/JPEG

Referring people to a wikipedia article which confirms the BB's argument == Priceless :woot: The key phrase is "JPEG is also not well suited to files that will undergo multiple edits", note the word "edits", meaning you only get quality loss if the image changes in ways that don't meet the criteria given later on in the section titled "Lossless editing".


johnpf ( ) posted Wed, 24 November 2010 at 6:50 PM · edited Wed, 24 November 2010 at 6:58 PM

I've got no horse in this race, but I carried out a little experiment and... well... it was rather interesting what I found. Okay, interesting to me.

 

Successive JPEG Compressions - A short experiment

John Flynn, 24 Nov 2010**
**

Aim

To investigate the claim that serial JPEG compressions at a fixed compression rate will have a cumulative effect on each generation of saved (i.e., compressed via JPEG algorithms) images.

 

Hypothesis

I will begin with the hypothesis that the quality of a compressed image saved via JPG compression at a fixed compression rate will decrease, evident from a visual examination for JPEG artifacts and supported by the expected decrease in file-size of each successive compression.

 

Method

  1. I took an image at random from a collection of scanned photographs that I had already on my computer's hard drive. My only criterion for selecting an image that it be a JPEG file that had already undergone compression. This I designated the source image, and it can be found here:

http://www.mannyslife.co.uk/img/DialysisUnit01.jpg

  1. I opened the software application "Paint Shop Pro 7" and opened the source image.

  2. Without altering the picture in any way, I opened the "Save As..." dialog and ensured that the file-save format was set to "JPEG - JFIF Compliant (*.jpg, *.jif, *.jpeg)", thus enabling the file to be compressed via the JPEG compression method.

  3. I opened the "Options" dialog and chose "Run Optimizer" to open a more detailed window in which the compression ratio and the resulting file-size would be displayed.

  4. I entered "15" into the "Set compression value to" field. On previous uses of this option, I had noted that the allowed values are from 0 to 100, and as this value increases the expected file-size decreases, thus leading me to deduce that the value entered in this field results in the JPEG compression rate being "100 - value". This gave me a JPEG compression rate of 85% using this (unconfirmed) calculation. The actual figure is not of importance to the final results but I have documented it for reference. If the calculation proves to be incorrect, then the figure of 85 should be amended to the new value but the results and conclusion will remain unaffected.

  5. I saved the image but first incrementing the number contained in the filename by 1, creating a file named DialysisUnit02.jpg.

  6. I closed my source file and opened the most recently saved DialysisUnit02.jpg image.

  7. I repeated steps 3 to 7 with each successive filename being incremented by 1 and stopping when I had created DialysisUnit15.jpg.

  8. I opened my source image and DialysisUnit15.jpg for a visual comparison.

 

Results

All 15 images in the series can be found here:

http://www.mannyslife.co.uk/img/DialysisUnit01.jpg 68125
http://www.mannyslife.co.uk/img/DialysisUnit02.jpg 68090
http://www.mannyslife.co.uk/img/DialysisUnit03.jpg 68108
http://www.mannyslife.co.uk/img/DialysisUnit04.jpg 68085
http://www.mannyslife.co.uk/img/DialysisUnit05.jpg 68093
http://www.mannyslife.co.uk/img/DialysisUnit06.jpg 68091
http://www.mannyslife.co.uk/img/DialysisUnit07.jpg 68091
http://www.mannyslife.co.uk/img/DialysisUnit08.jpg 68093
http://www.mannyslife.co.uk/img/DialysisUnit09.jpg 68082
http://www.mannyslife.co.uk/img/DialysisUnit10.jpg 68100
http://www.mannyslife.co.uk/img/DialysisUnit11.jpg 68089
http://www.mannyslife.co.uk/img/DialysisUnit12.jpg 68089
http://www.mannyslife.co.uk/img/DialysisUnit13.jpg 68089
http://www.mannyslife.co.uk/img/DialysisUnit14.jpg 68089
http://www.mannyslife.co.uk/img/DialysisUnit15.jpg 68089

During the saving process, I noticed that the file-size was not changing as my hypothesis had predicted. I noted down the number of bytes that each image would be after compression and they are recorded in the table above in the second column.

For the visual comparison, I loaded the source image and the final iteration of the compressed images, and viewed them with unaided eyes at 1:1 magnification and then at 4:1 magnification in order to see individual pixels.

During the visual inspection with unaided eyes, at 1:1 magnification, I could detect no noticeable differences. At 4:1 magnification, I could detect no noticeable differences.

I then copied the source image to the clipboard and pasted it as a second layer on the final iteration image (DialysisUnit15.jpg). I changed the blend mode for this layer to Difference, opacity untouched at 100%. The Difference blend mode displays the result of subtracting the pasted image from the underlying image, thus removing any similarities shared by both images and leaving only the pixels that are different and their RGB components containing the magnitude of that difference.

The saved image resulting from the Difference blending can be found here:

http://www.mannyslife.co.uk/img/DialysisUnitDIFF.png

After performing the Difference blending, on a visual examination with unaided eyes at 1:1 magnification, I was presented with what I believed to be a completely black (RGB = 0, 0, 0) image. I magnified the image to 4:1 and, after chosing several random areas of the image, could find no areas that were anything but black.

Using the colour picker tool, I swept the mouse cursor across several random areas of the image and noticed that the RGB values of the displayed image were not 0, 0, 0 as I had expected from my visual examinations, but were values ranging from 0, 0, 0 to 2, 2, 2. Please note, this was the result of a non-methodical, random sampling of the image.

 

Conclusion

On visual inspection, I could see no difference between the source image and the final iteration of the compression series. This leads me to believe that an unmagnified (1:1) image that has undergone 15 successive JPEG compressions will appear identical to most viewers looking at the image with unaided vision.

After performing the Difference blending and examining the resulting image with the colour picker tool, I can see proof that there are differences, but they are so small that they are imperceptible to anyone viewing the 15th iteration image under normal circumstances.

These conclusions are supported, I feel, by an examination of the file-sizes recorded for each generation of the compression series. There is a clear difference in file-size between the source image and the 15th iteration image, but the difference is only 36 bytes. If my starting hypothesis had been true, I would have expected a much larger difference as each successive compression generation would be reducing the quality (and thus, I would have expected, the file-size) by 15% each time a compression was performed.

From the file-sizes noted, I am led to further hypothesize that, because the series of compressions is apparently converging on one file-size, the JPEG compression algorithm is not reducing each generation's quality by 15% in a linear manner and, instead, reaches a point (as defined by the specifics of the compression algorithm) beyond which a fixed compression rate will not make any further reductions in quality or file-size.


ghonma ( ) posted Wed, 24 November 2010 at 7:05 PM

This is the article you guys should be looking at:

http://en.wikipedia.org/wiki/Generation_loss

In short, like pjz99 said, in some cases JPGs can work fine with multiple saves, in other cases they don't. The "don't" bit is usually when you edit the image, scale it or crop it etc, basically any change that causes the compression process to change increases the artifacts. Frankly it's just not worth the hassle and it's far easier to just use a lossless format instead.

As for the 100% thing, i'll just quote this bit from that JPEG article posted by Haarspalter:

"Since the quantization stage always results in a loss of information, JPEG standard is always a lossy compression codec. (Information is lost both in quantizing and rounding of the floating-point numbers.) Even if the quantization matrix is a matrix of ones, information will still be lost in the rounding step."

For the visually inclined, there are pics at both articles to see for yourself.


Miss Nancy ( ) posted Wed, 24 November 2010 at 7:58 PM

I resaved acadia's post as jpeg 4 times at 10/100 in CS4. using flip test, save 1 indistinguishable from save 4.  but maybe it gets worse when resaved on different computer each time.  like each time somebody rents DVD from netflix, more scratches appear, until they finally decide to give it up and do streaming only (ca. 2012).



bagginsbill ( ) posted Wed, 24 November 2010 at 9:46 PM · edited Wed, 24 November 2010 at 9:54 PM

Quote - This is the article you guys should be looking at:

http://en.wikipedia.org/wiki/Generation_loss

In short, like pjz99 said, in some cases JPGs can work fine with multiple saves, in other cases they don't. The "don't" bit is usually when you edit the image, scale it or crop it etc, basically any change that causes the compression process to change increases the artifacts. Frankly it's just not worth the hassle and it's far easier to just use a lossless format instead.

As for the 100% thing, i'll just quote this bit from that JPEG article posted by Haarspalter:

"Since the quantization stage always results in a loss of information, JPEG standard is always a lossy compression codec. (Information is lost both in quantizing and rounding of the floating-point numbers.) Even if the quantization matrix is a matrix of ones, information will still be lost in the rounding step."

For the visually inclined, there are pics at both articles to see for yourself.

That statement is wrong. The quantization stage does not always result in a loss of information. It depends on whether the information already has experienced reduction or not.

You guys know I studied information theory at MIT and I am not a noob at math, right?

You also know that Wikipedia is a great resource but not everything written there is accurate, particularly scientific and math stuff, right?

Let me give you an analogy that perhaps will help you understand.

Suppose I decide to simplify the description of all the coins in all our pockets. Instead of recording how many quarters, dimes, nickels, and pennies each of us has, I replace all pennies with nickels (in groups of 5). Any odd pennies left over (0 to 4) we just ignore.

Now everybody empties their pockets and we rebuild everybody.

Who experiences coin "loss"?

Some have exchanged units of 5 pennies for nickels, and while they have fewer coins, they have the same amount of money as they started with.

Some have lost 1 to 4 cents. 

But some pockets did not change at all! If they had no pennies to begin with, then the loss of data about how many pennies they had is irrelevent!

But in describing everybody's pockets without counting pennies, I have now reduced the coin counts per person from 4 counters to 3. That's a pretty good compression for a very small loss of information. In fact, we lost a lot of data but we did not lose information in all cases. This is an important distinction. Information loss does not always happen when data is reduced.

Now, let's suppose we record our pocket contents again and empty them. There are no pennies at all now, so no information is lost, by definition. We don't need to count pennies if we're starting with the premise that none of us have any pennies.

Rebuilding our pockets, we find that nobody has experienced any change at all.

We can do this an infinite number of times, ignoring pennies, and we'll experience no change because there are no pennies - forgetting things that don't exist anymore is not important.

In JPEG, the pennies are the high frequency components.

Losing them does not change the colors very much.

And once they've been removed, re-saving cannot remove them again - they don't exist anymore.

If you still don't understand the point, then I'll have to use the math and I doubt that will matter either, so just move on.


Renderosity forum reply notifications are wonky. If I read a follow-up in a thread, but I don't myself reply, then notifications no longer happen AT ALL on that thread. So if I seem to be ignoring a question, that's why. (Updated September 23, 2019)


pjz99 ( ) posted Wed, 24 November 2010 at 10:10 PM

Quote - ...move on.

Excellent advice!

My Freebies


kawecki ( ) posted Thu, 25 November 2010 at 1:24 AM · edited Thu, 25 November 2010 at 1:38 AM

It is like the story of MP3 vs CD music, it depend on the ears that people have. For most people MP3 is the same, but some perceive the better quality of CD.

Not only the ears are important, the quality of the source is also important. If the music is a crap it will not make any difference between CD and MP3, even with 8 bit PCM it will be the same, crap is always a crap.

With jpeg compression is the same story, something is lost in the compression process. What is lost and how important is the loss will depend on the eyes and the quality of the source.

Many people don't see any difference between a 256 color gif and a 24 bit color image, I suppose that here everyone knows the difference. The same is jpeg vs bmp/png/tiff/psd/tga/etc. With training your eyes perceive more, more and more and something that once look the same now is not and the differences can make an image horrible that once it was good.

The question is what is lost in jpeg compression? Jpeg compression works in the wavelet or frequency domain where the high frecuency information is removed, the amount depend on the compression level that always exist some. Also the color information is reduced as the eye is less sensitive to color than to luminance, the same story as for color TV.

Here comes again the importance of the quality of the source, if the source has no or little high frecuency information nothing is lost with jpeg compression. A poor quality image has little high frecuency information, so nothing is lost. If the image has excellent quality and has a lot of high frecuency information the image can suffer a notable degradation in the compression.

Not all good quality images has high frecuency spectrum, an image that is a green plane has no frecuency information, well you also cannot define its quality. Repeated compression of the same image will reduce even more the high frecuencies, but as almost all was removed in the first compression very little remain to be removed in the second and almost nothing in the third. Compressing 100 times more will change nothing.

Now, what does mean high frecuency components, how you see them in the image. You see in how much detailed is the image, how much definition it has. A blurred image has only low frecuency components. A sunlight landscape full of trees, plants, blue sky, clouds can have a lot of of high frecuencies. The differences are much greater with digital cameras. A human face has little high frecuencies.

Jpeg compression has other big problem. The compression process divides the image in 8x8 pixel blocks, tranform each block to the feecuency domain, remove the high frecuencies and transform back to the image domain. The problem is with the 8x8 block, that is too small, a 16x16 pixels would be much better, but it would take a lot more time to transform. This 8x8 block has little problem with normal images, but with small images it becomes very important. A 640x640 image has 80x80 = 6400 blocks, but a 64x64 image has only 8x8 = 64 blocks. The result is that for very small images as thumbs jpeg cpmpression is horrible, any 256 color gif looks much better. And if you put some text in the thumb the result is even worst.

Conclussion. It all will depend on what you do. If you compress an image and see no difference or the difference has no importance then use jpeg because it will produce smaller files, even you can increase the compression level. If you are able to see the difference and it is important then save the image with a lossless format.

Another important point, even your eyes don't see any difference today, tomorrow maybe will see it, but tomorrow probably the cameras will be much better than today and so the stored images will have worst quality than the newer one, so it will not make any difference if are png or jpeg.

For professional use, never save images in jpeg format, something always is lost and you have to process and manipulate the images several times, you must preserve the quality n all the process even the final destiny is to be printed in a toillet paper with four colors.

Stupidity also evolves!


aRtBee ( ) posted Thu, 25 November 2010 at 4:30 AM

hi folks,

fun thread, like to jump in. Lots of info, lots of horror, lost of tech detail and still some unanswered questions (like Why is gnomon using tiff (ice-boy)).

JPG is meant to be a publishing format for photograph-like images. When saving the basic image info to JPG you will loose some info on the color hue (which the human eye is not that sensitive for) in favor of gaining info on luminoscity (which the eye is more sensitive for). It's a bit like having floating point numbers first and rounding them to integers when saving. Eg 123.45 becomes 123. When you save at lower quality, the 123.45 becomes 120 or even 100, the rounding just gets more rude.

Indeed, reopening and resaving will load the 123 as 123.0 and save it as 123 again, so after the first loss, no more losses occur (and 100 is loaded as 100.0 and resaved as 100 again).

This changes however when you start working on them. I took the testfile (PNG) as presented by bagginsbill, saved as JPG at high quality (60%), reopend, rotated 90*, saved at 60% again, repeated it a few times and the differences became appearent. Especially the text color was taking the color of the surrounding blue/gray background, and taking Difference blending in Photoshop revealed serious changes overall (after pumping up brightness and contrast to make them visible).

This is why all photographers manuals tell you to use JPG for final publishing only, and not for preliminary and intermediate results in your workflow. On the other hand, when your postwork is limited and you use high quality settings (100%), differences will be minimal, and definitely smaller than the variations between peoples monitor characteristics. And as the chain is as strong as the weakest link, why bother?

A second issue with JPG is that you loose fine detail, sharpness. No real issue for photographic results, but not that good for textures driving displacement, bump, or lace transparency. Still no real issue for images published on the net, but less nice for 7000x5000 images for large scale fine print, or results for the big movie screens. 

A third issue with JPG is that the file format embeds information that compensates for default monitor characteristics. For a long time, Poser failed to take this compensation out of the textures before rendering, but the recent PP2010 has some features to deal with it correctly. Just read the Gamma Correction and P8/PP2010-difference threads about the details. 

A related fourth issue with JPG was that this embedded info was different for Apple and PC. But that one is resolved since OSX / Snow Leopard or so. 

PNG is considered a 'next generation GIF', meant for sharp vector/line drawings. It does not have the limitations of colorhandling as in GIF and does support an alpha channel, but does not support animation. Compared to JPG, the PNG24 does its colortone-handling as good as JPG or even better, but JPG wins on luminosity. Photographers tend to prefer JPG for images with variation and prefer PNG for images with fine color nuances, like monotones, cloudy skies and jungle greens (as far as they prefer JPG or PNG at all).

As PNG keeps the fine details it's preferred over JPG for driving displacements and lace transparency, and everthing else is about the same. It's not the best file format for intermediate results in your workflow, and it embeds monitor compensation. No differences between Apple and PC, but older PNG versions showed different implementations simply causing RGB=(255,0,0) to produce different shades of red between JPG and various PNGs. Thats sort of fixed now. Again, P8 and before did not take out this compensation from the textures before rendering giving you the Poser-look in your images, PP2010 does a better job in this.

Again, all differences are small but for publishing in a Rendo gallery I would prefer JPG over PNG for outdoor Vue / Poser renders and PNG over JPG for sharp fractal images. In all cases, keep in mind that JPG and PNG are meant to produce decent looking results in home, office and other non-graphics-pro environments, like internet galleries and home print.

TIFF is different. It can do 16-bits per channel (so the 123456.789 is rounded to say  123456 instead of 123000), it supports layers and alpha channels, and it does not contain monitor-compensation, and therefore has no difference between Apple and PC. 

This makes it the format of choice for high end print and big screen movie textures (which require 16 bit color anyway), and for high end intermediate results in a professional workflow. mental ray, V-ray and similar renderers assume that any monitor compensation info is taken out of (or absent from) any textures beforehand. Effectively, software like Max and Maya assumes to run in a professional environment anyway, with proper color management implemented at least.

So, have a peek at www.thegnomonworkshop.com. Professional training for artists, it says. Check the software/tools button. No Poser. Gnomon is not into JPG or PNG, unless its for internet publishing or concept print. They're into TIFF instead.

Happy Posing.

- - - - - 

Usually I'm wrong. But to be effective and efficient, I don't need to be correct or accurate.

visit www.aRtBeeWeb.nl (works) or Missing Manuals (tutorials & reviews) - both need an update though


kawecki ( ) posted Thu, 25 November 2010 at 5:48 AM

PNG can have 16 bit per color too and TIFF can use floating point colors.

TIFF can be and is used for georeferrenced data (DEMs, terrains). PNG also can be used. Forget JPEG, its compression will produce random hills and wrong slopes.

Stupidity also evolves!


Haarspalter ( ) posted Thu, 25 November 2010 at 5:57 AM · edited Thu, 25 November 2010 at 6:03 AM

 

 

 

An easy experiment:
 
 

  1. With photoshop create a image with 800x400 ppi store away with max. JPEG-Quality(12)
  1. Open this file 15 Time over and over again and under another name store away.
     
  2. The 15-th file has serious high-class losses.

 

This is the start-image, 800x400 ppi store with max jpeg-quality

This is image number 15. 800x400 ppi store with max jpeg-quality:

 

Sorry for my bad english.


kawecki ( ) posted Thu, 25 November 2010 at 6:20 AM

This is the effect of the 8x8 blocks into which the image is divided for compression added to quantization noise The color at each side of the boundary of two blocks is not the same, it is almost the same producing vertical bands. You don't see horizontal bands because in this image there is no color variation in the vertical direction.

Another problem with jpeg is for selecting or extracting a part of an image by color boundary. An image of an object on a black or other color background, once saved the image as jpg, the black is not more RGB 0,0,0. It is black with random pixels with a dark color. Using black for selection you pick the objects with noise pixels and many times with not clear defined borders and then you have to clean the mess. If you saved the image as png, bmp, tiff, you never have this problem.

Stupidity also evolves!


Haarspalter ( ) posted Thu, 25 November 2010 at 6:25 AM

Quote - If you saved the image as png, bmp, tiff, you never have this problem.

Yes certainly, this was the sense of this example to indicate one has the JPEG qualitative losses whom it several times stores.
 
In this Thread it was maintained JPEG would not have these losses.


bagginsbill ( ) posted Thu, 25 November 2010 at 6:51 AM

Haarspalter you don't know what you're using. JPEG quality = 12? You're using an old buggy version of JPEG compression that expresses quality on a scale of 1 to 12.

I said 100% many times and I posted the 15th result.

Just because you can do the experiment incorrectly proves nothing.

My dog can also fail to produce good results with my Nikon D90, but that only proves he is a poor photographer who doesn't understand the tool.


Renderosity forum reply notifications are wonky. If I read a follow-up in a thread, but I don't myself reply, then notifications no longer happen AT ALL on that thread. So if I seem to be ignoring a question, that's why. (Updated September 23, 2019)


Haarspalter ( ) posted Thu, 25 November 2010 at 7:04 AM

 

 

Quote - Haarspalter you don't know what you're using. JPEG quality = 12? You're using an old buggy version of JPEG compression that expresses quality on a scale of 1 to 12.

 

I said 100% many times and I posted the 15th result.

Just because you can do the experiment incorrectly proves nothing.

My dog can also fail to produce good results with my Nikon D90, but that only proves he is a poor photographer who doesn't understand the tool.

 

What a nonsense !

I have used photo shop CS5 for the example.
 
Nevertheless, they do not want to state seriously Adobe uses in this version "on old buggy version"?
 

Does scratch thus in her ego once to be wrong to admit?


aRtBee ( ) posted Thu, 25 November 2010 at 7:12 AM · edited Thu, 25 November 2010 at 7:20 AM

@kawecki

although the file format specs might support whatever comes around, the question at hand is: does the rendering or painting software support it. I welcome more info on this.

TIFF and PNG for geo (heightmaps): of course, we're talking displacement here. Thanks for the addition, it completes the picture.

@haarspalter

I agree with the experiment, and with kaweckis analysis. Sort of.

I'd like to add - as can be seen when switching to Lab mode - that the color hues keep intact all over the file versions while only the luminosity gets dimples at regular intervals. That aside, nothing changes as the pixels at say (50,50), (400,200) and (750,350) keep their exact values over the experiment.

This banding is a well know JPG artifact (at least to me), and the reason why sky-and-clouds shots are better published in PNG or even GIF, than JPG. But I did not know it got worse over time. Thanks for the tip.

So I repeated the experiment, in Paintshop Pro instead. Surprise! No banding. No dimples. Well, it's there though, after a very close investigation (take difference, and increase brightness to +100 and contrast to +60 in an additional adjustment layer). But the dimples are less deep, and about 4 times wider spaced.

So, I hold the theoretical position that - at the pixel level - repeatedly loading and saving JPG will not damage the file, like repeatedly reloading a CD will not change the music or the sound quality. Changing the image and saving however, does.

But the experiments second the practical note that - at the image handling software level - repeatly loading and saving increasingly creates banding artifacts in the luminosity. This is a software flaw, not a JPG feature, and differs per tool used. Like repeatedly loading a CD will cause scratches in real life. Actually, having an end-user photo-oriented tool like PaintshopPro winning over a professionals oriented Photoshop on this, isn't even a surprise, at second thought. It's having JPG as its home market. I guess Photoshop is better in tiff handling. Or might have been improved and options added in the meantime, as BB seems to point out. Doesn't matter. The artifact is in the software, not in the JPG format.

Thats another lesson learned. Thanks for the input.

- - - - - 

Usually I'm wrong. But to be effective and efficient, I don't need to be correct or accurate.

visit www.aRtBeeWeb.nl (works) or Missing Manuals (tutorials & reviews) - both need an update though


Haarspalter ( ) posted Thu, 25 November 2010 at 7:24 AM

 

Unfathomably!
 
If one here criticism of an icon expresses one is exiled without comment from the forum.

 

After the last Posting I can log in no more in the Poser forum.

 

 


MagnusGreel ( ) posted Thu, 25 November 2010 at 7:26 AM

no, thats technical problems and you are not exiled at all. plus you did actually post that in the forum.

Airport security is a burden we must all shoulder. Do your part, and please grope yourself in advance.


bagginsbill ( ) posted Thu, 25 November 2010 at 7:38 AM · edited Thu, 25 November 2010 at 7:41 AM

Quote - What a nonsense !

I have used photo shop CS5 for the example.
 
Nevertheless, they do not want to state seriously Adobe uses in this version "on old buggy version"?
 

Does scratch thus in her ego once to be wrong to admit?

Yes the File Save in Photoshop is intentionally buggy - intentionally identical to the very first JPEG exporter ever included in Photoshop, more than 10 years ago. This is my point  about knowing your tools. If you have never read about this, then you do not know your tool. I have written about it before.

The JPEG exporter reached in Photohshop via "Save for Web" is completely different.

Instead of making wild claims and further demonstrating that you're arguing not from knowledge but from emotion, you should do some experiments properly, or read more.

Please stop responding with claims of nonsense. If there is an ego involved here it is your own. You decided to not only challenge a technical matter but you claimed it is nonsense, multiple times. Not once did you present any honest refutation of anything I've said, but you're obviously spitting mad about what I've said. You're not to be taken seriously after such a display. Now you have so boxed yourself in a corner that you cannot acknowledge facts - you've lost all sense of self control and have resorted to attacks upon me as a person. That's generally not a good idea. Don't connect your personal sense of self-worth to the ideas you hold to be true.

You'd look far less foolish if you appeared to be seeking knowledge instead of trying to show that you refuted me.

Why not ask, for example, "I saved from Photoshop CS 5 here and it degraded a lot. Why is that?"

Then I'd tell you and you would look like a smart person instead of ...


Renderosity forum reply notifications are wonky. If I read a follow-up in a thread, but I don't myself reply, then notifications no longer happen AT ALL on that thread. So if I seem to be ignoring a question, that's why. (Updated September 23, 2019)


aRtBee ( ) posted Thu, 25 November 2010 at 7:44 AM · edited Thu, 25 November 2010 at 7:56 AM

Haarspalter, criticism is good, we can learn from it. If it's not on the subject itself, it's on the clarity of our understanding or explanation instead.

And if the Photoshop results even differ by the way we create them (as I read in BB's posting), things even get more interesting. IMHO there was nothing wrong in your experiment, but BB might like to tell us his way to get the better results out.

Oh, he just did. Well, when I performed the experiment via Save as (q=12) as well as Save for Web (q=100), I got exactly the same results both ways while using Photoshop-7. So, over time, one route got improved while the other one didn't. Great thinking. How about "know your users" instead of "know your tools" (not for BB but for Adobe). Most of the people around are photographers and artists, usage oriented instead of equipment oriented. They don't speak tech. We can help each other.

BTW: my dog prefers smell-o-graphs over phot-o-graphs :-) and tend to eat camera manuals.

- - - - - 

Usually I'm wrong. But to be effective and efficient, I don't need to be correct or accurate.

visit www.aRtBeeWeb.nl (works) or Missing Manuals (tutorials & reviews) - both need an update though


MagnusGreel ( ) posted Thu, 25 November 2010 at 7:48 AM

"Yes the File Save in Photoshop is intentionally buggy -"

 

Citation please.

 

Airport security is a burden we must all shoulder. Do your part, and please grope yourself in advance.


Haarspalter ( ) posted Thu, 25 November 2010 at 8:05 AM · edited Thu, 25 November 2010 at 8:08 AM

Quote - Yes the File Save in Photoshop is intentionally buggy - intentionally identical to the very first JPEG exporter ever included in Photoshop, more than 10 years ago. This is my point  about knowing your tools. If you have never read about this, then you do not know your tool. I have written about it before.

 

I have just contacted by telephone Adobe in Germany (http: // www.adobe.com/de/).
 
Nothing is there known by a bug in the JPEG storage in a photo shop-version.


bagginsbill ( ) posted Thu, 25 November 2010 at 8:06 AM

Interesting. Haarspalter, your red-green gradient comes out messed up when saving multiple times using either Photoshop method. It seems to be a particular case for which JPEG is very weak.

 


Renderosity forum reply notifications are wonky. If I read a follow-up in a thread, but I don't myself reply, then notifications no longer happen AT ALL on that thread. So if I seem to be ignoring a question, that's why. (Updated September 23, 2019)


aRtBee ( ) posted Thu, 25 November 2010 at 8:44 AM

Quoting BB: It seems to be a particular case for which JPEG is very weak.

You mean... for which Photoshop is weak. Not JPG as such. I guess/hope the Photoshop way of saving JPGs has strong points too, but for smooth color gradients it creates apparent limunosity banding which increases with repeated load/save cycles. It might have similar issues in other kinds of images, but I guess these are far less visible.

Photoshop does not have a problem in the color-part, and other programs like PaintshopPro don't have the luminosity-issue either (or at least far less).

But please note: Photoshop is intended for professional use, and this use advices to turn an image into JPG when it's required as the last step in (internet) publishing. A one-off thing. So in fact we're debating on a flaw in a solution for which we shouldn't have the problem in the first place.

- - - - - 

Usually I'm wrong. But to be effective and efficient, I don't need to be correct or accurate.

visit www.aRtBeeWeb.nl (works) or Missing Manuals (tutorials & reviews) - both need an update though


  • 1
  • 2

Privacy Notice

This site uses cookies to deliver the best experience. Our own cookies make user accounts and other features possible. Third-party cookies are used to display relevant ads and to analyze how Renderosity is used. By using our site, you acknowledge that you have read and understood our Terms of Service, including our Cookie Policy and our Privacy Policy.