There are so many things that can result in lossy "recompression" of the jpg image that you are better served "storing" your files in either TIF or PSD, and only using JPG as an "end result" format, for email or web use.
I suspect that all of your examples are "lossy" . The issue becomes critical when multiple edit and save cycles compound the problem , hence the recommendation to stay in a "non lossy" format on images that may require editting.
🙂
Brent
Brent
TIFF it is. Thanks.
Gordon
Of your list, the only one which may be possible without any loss is (1). This is only possible if the software doesn’t do a re-save. PSE Organizer can do this, for example. The only constraint is the pixel dimensions that must conform with certain criteria – most digital camera images are fine.
Otherwise, as Brent said, once you make changes to an image, keeping it in a non-lossy format is sensible – TIFF or PSD. Whenever you resave to JPEG, you lose data. So, the best this is to only save a copy when you specifically need JPEG – for email, Web etc.
Brent and Colin
I just want to make sure that I have it right for a given image:
1) OK to leave image in JPEG if no changes required.
2) If it needs rotation use PSE Organizer.
3) If change is needed make it in TIFF or PSD.
4) Leave (store) changed image in TIFF or PSD.
5) Only save the changed image into JPEG if necessary for transmission.
6) In #5 step (TIFF to JPEG) there is a loss and there is nothing to do about it.
One further question: I can make uploadable, saved crops within my camera. Do these crops also result in loss?
Gordon
One comment on your step 5
Only save the changed image into JPEG if necessary for transmission.
If you take photos to a local store or lab to be printed, they may require jpeg format for printing. It is best to check with them.
Barb O
Happy with 1-6. For (5) this should be a copy.
One further question: I can make uploadable, saved crops within my camera. Do these crops also result in loss?
Guess that depends upon the camera, but if you make the cops after th eimage is stored, I guess it could be lossy. However, I think it would be possible to do high constrained cropping in a non-lossy way.
I am using 3.0. I downloaded a picture from a CF Card, worked on the photo, and then sent the file to another card so that I could take it to be printed. However when I tried to preview the photo on the camera (Canon), I got the following message: "Incompatible JPEG Format." Also when I went to the photo place to get a print, the computer did not find any images. Any suggestions on how to overcome this problem?
Thanks.
johnmh47:
This is really a new topic …
How exactly did you save the image to the card?
The fact that the camera cannot view it is unsurprising. The software in cameras is often very specific to the subset of the JPEG standrad that they use. Such a problem should not occur with a computer at the printers.
Colin or Any Mac User
Aparently Organizer is for Windows only. In 3.0 Mac version is it safe (no loss) to use the Rotate in the Image pull down menu?
Gordon
Gordon
In 3.0 Mac version is it safe (no loss) to use the Rotate in the Image pull down menu?
No. That would load and then resave the image.
However, I would think that the rotate button in the File Browser might be OK. Maybe you want to research this. If you can’t find a definitive answer, come back here and I will take some time to experiment.
Colin
File Browser is great. To the untrained eye there was no loss during rotation. And, rotation takes place quickly in one stage. But, I do not know how to test it scientifically.
Gordon
I wonder if the FB just sets the rotate bit, which means that it actually rotates on load into Editor. The only prob is other software that doesn’t understand this bit.
The test that I would do is to take an image and rotate it using Org [which is lossless for sure] and compare the resulting file. My guess is that if the size [in bytes] is exactly the same, there’s a good bet that it’s lossless.
However, someone must know exactly what the FB does and could advise us.
Folks….
I’ve posted this before……I’ve done tests with my images whereby I’ve done multiple rotates and saves in the editor and seen no difference when comparing the file with the original….as longs as you stick to 90deg turns and have image sizes which are multiples of 8 pixels.
I’ve also performed tests saving the same unaltered image upto 10 times and seen no difference.
Most of the changes will occur after some adjustment has been made, e.g Levels (which FWIW is also destructive) but in a lot of cases this is minimal.
By far the worst affect is using high levels of jpeg compression.
If you want to compare results, place the rotated/saved image on a layer above the original and set the blend mode to difference. Zoom in and look for non black pixels.
Colin #2
I guess this is a matter of comparing theoretical degradation [every compression] with real degradation [much less].
Colin….
I believe it’s not exactly true that there is degradation with every compression. I’ve read that after a few saves ( I think it was maybe 3 or 4) that the curve flattens out and no further compression is acheived. Of course there must be no alteration in between saves.
Colin #2
There is loss with every compression. However, if that loss is identical on 2 saves, it is not making matters any worse. Think about this sequence:
You have an image with X pixels [in memory].
You save it compressed – data effectively represents Y pixels [Y<X]. You open the saved image again and have X pixels [extrapolated from the Y]. You save, after no change and the compressed file is [the same] Y pixels.
But if you did make a change, you would have a file with Z pixels worth of data, where: Z<X and Z<>Y.
The question is whether a rotate is a "material change".
I think the previous msg from Colin Walls is not quite correct. If you have an image with X pixels in memory, and you save it, even with high compression, it still has X pixels in the stored file. What compression does is make nearby pixels the same color or a close color, done in blocks, so color differences can be used to represent colors and those differences take fewer bits in the file than an independent color for each pixel. Thus when you open a compressed file, you do not (ever) get back the original file. Thats what is meant by a "lossy" compression.
Another point I haven’t seen mentioned in this thread is that it looks to me like PE keeps the uncompressed file in memory after you do a (compressed) save, so a second save doesn’t accumulate losses, like an open of that first saved file and a second save of it would.
–Milton Barber–
Milton
What you say is strictly accurate, but I would contend that the losses through compression are analagous to storing lkess pixels. As the differentiation between pixels is what’s being lost.
Another point I haven’t seen mentioned in this thread is that it looks to me like PE keeps the uncompressed file in memory after you do a (compressed) save, so a second save doesn’t accumulate losses, like an open of that first saved file and a second save of it would.
This is useful clarification. PSE’s in-memory data does not have a file format and is uncompressed.
I disagree with the statement about not (ever) getting back the original because it’s a lossy format.
In the tests I’ve performed I’ve been aware of the fact that after saving the image it’s still in memory. That’s why I closed the image every time after saving and then re-opened. I have seen no differences between the original and the image saved upto ten times. The importance being that no editing was done in between saves. Even with localised editing much of the remaining image has remained unchanged.
This cannot always be guaranteed but is proof to me that JPEG compression, at least that implemented by Elements and some cameras, is a lot smarter than often believed.
FWIW: The image size was 3072 x 2048 (multiple of 8 pixels) and I used Baseline Level 12 compression with Elements 3.
Colin #2
I have seen no differences between the original and the image saved upto ten times. The importance being that no editing was done in between saves.
Is that an obvious conclusion. Do exactly the same compression on the same data 10 times and you get the same result?
Even with localised editing much of the remaining image has remained unchanged.
Since JPEG compression works on blocks of pixels, that makes sense.
IMHO, the whole discussion is unnecessary. There are 2 reasons to use compression:
1) Storage space. A memory card has limited space, but this is becoming less of a problem by the day, as costs fall. The cost of hard drives is now below the $2/Gb level and they are fast, so what’s th epoint of messing with compression.
2) Communications bandwidth. Image son a Web page have no need to be big and everything’s set up for JPEGs. Making a copy of an image using SfW is entirely sensible. The only remaining situation is when you want to send a highest-quality image to someone electronically. One option is to use TIFF with LZW compression, which can help a lot.
Colin….
Your right that in most cases the discussion is unnecessary. I guess what irks me at times (and even I’m guilty of this) is that too often people focus on the theory i.e JPEG is lossy, I must have more pixels, RAW is better, Canon is better than Nikon( true…:-) ) without considering the true affect….can I see the difference, is the quality to my liking.
Colin #2
RAW vs JPEG is another matter entirely. That’s all about control – have the camera make the adjustments or do them yourself.
Your bottom line is, of course, what really matters.
