RAW vs. JPG: Fidelity vs. Convenience
in [Digital Cameras]
|
From: Ofnuts on 28 Dec 2009 13:37 On 28/12/2009 15:07, NameHere wrote: > On Mon, 28 Dec 2009 13:30:26 +0100, Ofnuts<o.f.n.u.t.s(a)la.poste.net> > wrote: > >> >> IMHO the problem isn't the loss of pixels, it's the addition of >> artifacts. And PL doesn't seem to fare any better than others, because >> this is inherent to JPEG encoding. > > You're wrong. Because the compression isn't additive with Photoline, It > won't create further artifacts on saved JPG files. It doesn't send the > re-saved image through the JGP compression algorithm again. It only > compresses any edits that you have made. Checked and granted... on the other hand this is useful only when you load a JPEG for just a quick local edit (wart removal, etc...) and resave. The way I work this doesn't happen often. Furthermore when one worries that much about artifacts added when the file is saved, one should also worry about some equally disruptive side effects of rounding and truncation errors happening when working with the 8-bit color levels that the JPG format affords ("comb" histogram, etc...)(*). Pixel-wise but image-foolish, to recycle an old saying. > If they are global (levelings, hue > changes, etc.) then it doesn't apply a compression any worse than what it > already had, unless you force it to. Same as others here. > While editing it saves a backup of the > original image in memory, then it only compresses those portions that were > intentionally changed. Any unchanged data is not put through the > compression routine again. > You are wrong in that you think this program is less-than all others. All > others are far less-than when it comes to handling JPG data properly. Did I emit anywhere an opinion on Photoline? From what I've seen, I don't think it's any worse than many others. But I don't see it vastly better than Gimp which is free, has many good plugins, and keeps my border pixels. (*) I notice PL is supposed to work in 16-bit color levels. But if the source is 8-bit it doesn't seem to make much difference. -- Bertrand
From: NameHere on 28 Dec 2009 20:56 On Mon, 28 Dec 2009 19:37:44 +0100, Ofnuts <o.f.n.u.t.s(a)la.poste.net> wrote: >On 28/12/2009 15:07, NameHere wrote: >> On Mon, 28 Dec 2009 13:30:26 +0100, Ofnuts<o.f.n.u.t.s(a)la.poste.net> >> wrote: >> >>> >>> IMHO the problem isn't the loss of pixels, it's the addition of >>> artifacts. And PL doesn't seem to fare any better than others, because >>> this is inherent to JPEG encoding. >> >> You're wrong. Because the compression isn't additive with Photoline, It >> won't create further artifacts on saved JPG files. It doesn't send the >> re-saved image through the JGP compression algorithm again. It only >> compresses any edits that you have made. > >Checked and granted... on the other hand this is useful only when you >load a JPEG for just a quick local edit (wart removal, etc...) and >resave. The way I work this doesn't happen often. Furthermore when one >worries that much about artifacts added when the file is saved, one >should also worry about some equally disruptive side effects of rounding >and truncation errors happening when working with the 8-bit color levels >that the JPG format affords ("comb" histogram, etc...)(*). Pixel-wise >but image-foolish, to recycle an old saying. I see. You're one of those "photographers" that has to always try to fix everything you did wrong in the first place. I get it now. Like all those who worship their access to RAW sensor data. > >(*) I notice PL is supposed to work in 16-bit color levels. But if the >source is 8-bit it doesn't seem to make much difference. If you know how to take your images properly in the first place there's never any need for 16-bit images. Every last one of your concerns belies your talent as a photographer. But since this seems to be a huge concern for you, keep in mind that PL will even handle 64-bit CMYK files. Should you ever buy a camera with that much latitude one day to help save you from your own mistakes. BTW: Let me know the next time someone hands you a JPG image with dimensions in prime-numbers that needs to be rotated in 90-degree increments. I usually rotate the full-size JPG before cropping my images to the dimensions I need. I'd like to hear about how dreadful this prime-number JPG rotation problem is for you in your real-life everyday editing needs and why. This sounds just like any of those fictional problems that the trolls invent because they've never actually used any of these things for real purposes in real life. But thanks for taking the time to find this prime-number rotation "bug" in Photoline. I'll be sure to keep a chart of prime-numbers laying around to make certain that my crop dimensions never fall on one of them. Should I ever find need to rotate my cropped and almost finished photo 90-degrees again because I don't have access to the original that's not in prime-number dimensions. Oh, I know when this would come in handy. When laying down and editing images while watching from a pillow. I'm starting to see why this editor requirement must be so important to you. You edit all your images side-ways first and then rotate them before using them in real-world situations. It's starting to make sense. I'd notify the Photoline authors of this prime-number rotation "bug" but I'm almost certain I'd get laughed at by everyone in their company. Just like tech-support people for computer companies will put the phone-calls from the biggest air-heads on the company's intercom system so everyone can laugh along. (A best-friend who is head of tech-support for a company does this and encourages his employees to do this, as a stress reliever.) The authors of Photoline would probably post my "bug report" publicly somewhere for the same effect.
From: Ofnuts on 29 Dec 2009 09:05 On 29/12/2009 02:56, NameHere wrote: > > I see. You're one of those "photographers" that has to always try to fix > everything you did wrong in the first place. I get it now. Like all those > who worship their access to RAW sensor data. > > If you know how to take your images properly in the first place there's > never any need for 16-bit images. Every last one of your concerns belies > your talent as a photographer. Since you seem to think that the only use of Photoline is to fix flaws in photographs, how come you know it so well? You shouldn't have any use for it since your own pictures are so perfect? And note that at this point we were not talking about photos... > I'd notify the Photoline authors of this prime-number rotation "bug" but > I'm almost certain I'd get laughed at by everyone in their company. Just > like tech-support people for computer companies will put the phone-calls > from the biggest air-heads on the company's intercom system so everyone can > laugh along. (A best-friend who is head of tech-support for a company does > this and encourages his employees to do this, as a stress reliever.) The > authors of Photoline would probably post my "bug report" publicly somewhere > for the same effect. I'm not really surprised that you fear being taken as a nutter by hotline people. But it doesn't require that much balls to file a bug report under an assumed id, does it? Anyway, a software developer worth his salt always welcomes bug reports because: - all bugs should be fixed eventually (professional pride and all that) - the "funny" bug could be the tip of the iceberg of a more important problem - even user errors may be the symptom of flaws in the UI. So I filed a bug report to the Photoline developers, and their answers are: - the truncation to multiples of 8 is always done (so it's not even a problem of prime numbers). It can be avoided if the JPG data is deleted using the "Attributes" dialog (but then you get lossy rotation of course). - in light of this, version 16 will likely keep the original size, but drop the lossless rotate on images with dimensions not multiple of 8. -- Bertrand, awaiting the post of his bug report of the PL site with baited breath.
From: Martin Brown on 29 Dec 2009 10:52 Ofnuts wrote: > On 29/12/2009 02:56, NameHere wrote: > >> I'd notify the Photoline authors of this prime-number rotation "bug" but >> I'm almost certain I'd get laughed at by everyone in their company. Just >> like tech-support people for computer companies will put the phone-calls >> from the biggest air-heads on the company's intercom system so >> everyone can >> laugh along. (A best-friend who is head of tech-support for a company >> does >> this and encourages his employees to do this, as a stress reliever.) The >> authors of Photoline would probably post my "bug report" publicly >> somewhere >> for the same effect. > > I'm not really surprised that you fear being taken as a nutter by > hotline people. But it doesn't require that much balls to file a bug It isn't just hotline people that think he is a raving nutter. > report under an assumed id, does it? Anyway, a software developer worth > his salt always welcomes bug reports because: > > - all bugs should be fixed eventually (professional pride and all that) > - the "funny" bug could be the tip of the iceberg of a more important > problem > - even user errors may be the symptom of flaws in the UI. > > So I filed a bug report to the Photoline developers, and their answers are: > > - the truncation to multiples of 8 is always done (so it's not even a > problem of prime numbers). It can be avoided if the JPG data is deleted > using the "Attributes" dialog (but then you get lossy rotation of course). Thank you for doing the experiment. It is therefore working exactly as I originally described at the outset. > > - in light of this, version 16 will likely keep the original size, but > drop the lossless rotate on images with dimensions not multiple of 8. It is a shame that proper lossless rotation and cropping cannot be fully supported within the published JPEG standard. The modification required is small but it would have side effects on all existing decoders. Regards, Martin Brown
From: Ofnuts on 31 Dec 2009 04:33
On 31/12/2009 06:51, NameHere wrote: >>> Test4: >> >> - Create 135x77 with checkered pattern, save to disk, close >> - Load 137x77 file, open attribute dialog, check size. >> - Rotate once >> - Check in attrubute dialog that the size is 137x77 (this is also the >> default size if doing a "scale layer", so there ois some coherency there�. >> - Save to disk (save and save as produce identical results) >> - Close >> - Reopen saved file. Now 64x128 (yes, 64, not 72). > > If those are the results you are getting, you don't know the first thing > about how to use Photoline properly. Thereby proving to the world that you > are nothing but a useless misinformation troll and that everything you've > said up to this point is in total error. Show me you results, then... I published mine(*), now that's your turn. (*) which you agreed with, remember? -- Bertrand |