Re: RAW vs. JPG: Fidelity vs. Convenience
NameHere
wrote:
>Here's an article that applies Kevin Maney's "Fidelity vs.
>Convenience" guide to the RAW vs. JPG question to show why and how
>each approach is successful.
>
>http://esfotoclix.com/blog1/?p=917
>
>~~~
>eNo
There's a couple glaring errors in your blog.
First off, many cameras provide the full dynamic range from the sensor's
RAW data in their JPG files. RAW only became popularized by dSLR owners who
were complaining that their cameras weren't doing the RAW > JPG conversion
properly. And many dSLR cameras sold even today still don't do it properly.
You know which cameras those are because their owners are always espousing
the benefits of RAW. Whereas, many P&S cameras with RAW capability, you'd
be hard pressed to better the JPG image that comes right from the camera by
trying to manipulate the original RAW data to equal the JPG image. For
those cameras which do it right the first time, there really is no need for
RAW. This of course also depends on the talents of the photographer too. If
they don't know how to expose an image properly in the first place they are
always looking for that RAW crutch to back up their lame photography
skills.
Secondly, only MOST editors will degrade a JPG image after editing,
resaving, reloading, reediting, resaving, et.al. But not ALL editors will
degrade JPG images during edits and resaves. Photoline does truly lossless
JPG editing. Not just lossless rotations. Which it also manages to do
better by keeping any uneven 8x8 block-counts on edges intact. Many
lossless rotations in other editors truncate images to even multiples of
8x8 pixel dimensions. I know of no other editors that can make and back-up
this lossless JPG editing claim. When using Photoline the only pixels that
get changed when resaving a JPG file are the ones you specifically choose
to change. No further JPG artifacts are introduced into the resulting
image. Unless you specifically choose a JPG compression much lower than the
original file's compression, thereby intentionally forcing Photoline to put
your image through the JPG algorithm again.
As to what I prefer, JPG or RAW? I prefer to do my homework and make sure
that I am buying a camera that will do the JPG conversion from its sensor's
RAW data correctly the first time. Then I don't have to muck about and
waste my time trying to fix what the camera maker failed to do properly in
the first place. My photography skills are also good enough that I don't
have to try to repair badly exposed images by relying on RAW data later.
Those who claim otherwise for their photography ... well, that's exactly
what they are claiming otherwise. They're your typical non-talented
snapshooter in dire need of any crutch that they can lean on to save them
from their perpetual crap-shots.
If only they could buy a dSLR with a point and shoot talent-mode built in
too, they'd be all over it in a heartbeat.
nsbm
algorithm.
The "good enough" mentality would favor a Yugo over a Mercedes.
--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---
NameHere
>I do not know of any camera ever made that has a satisfactory jpeg
>algorithm.
>The "good enough" mentality would favor a Yugo over a Mercedes.
>
>
That's what comes from people who don't know how to do their homework, nor
even know how to begin to do their own homework.
Thanks for proving that your kind exists--everywhere.
DanP
> On Wed, 23 Dec 2009 16:20:31 -0800, "nsbm" <fac_...@hotmail.com> wrote:
> >I do not know of any camera ever made that has a satisfactory jpeg
> >algorithm.
> >The "good enough" mentality would favor a Yugo over a Mercedes.
>
> That's what comes from people who don't know how to do their homework, nor
> even know how to begin to do their own homework.
>
> Thanks for proving that your kind exists--everywhere.
You are an idiot. Ever heard it before?
DanP
David J. Littleboy
"John A." <jo...@nowhere.invalid> wrote:
> because he wants to.
He's quite convincing, though. I'm quite sure he really is one.
--
David J. Littleboy
Tokyo, Japan
BD
> On Wed, 23 Dec 2009 16:20:31 -0800, "nsbm" <fac_...@hotmail.com> wrote:
> >I do not know of any camera ever made that has a satisfactory jpeg
> >algorithm.
> >The "good enough" mentality would favor a Yugo over a Mercedes.
>
> That's what comes from people who don't know how to do their homework, nor
> even know how to begin to do their own homework.
>
> Thanks for proving that your kind exists--everywhere.
So? Gonna put your mouth where your mouth is? Care to name a camera
that does such conversion correctly, just to edjumificate us poor ol'
dumfolk?
I've seen several people on forums like this one who demean others
with claims that they don't know what they're talking about - and when
they themselves are called to the task of providing some constructive
content rather than just slagging others, they just slink away. Or
keep slagging...
You've shown no knowledge here except that of insulting others. Not a
difficult skill to master.
LOL!
wrote:
And this is all that you useless and lousy DSLR-Trolls have, to try to
refute everything he said?
LOL!!!!!!!!!!
LOL!
>On Dec 23, 4:25�pm, NameHere <w...@address.info> wrote:
>> On Wed, 23 Dec 2009 16:20:31 -0800, "nsbm" <fac_...@hotmail.com> wrote:
>> >I do not know of any camera ever made that has a satisfactory jpeg
>> >algorithm.
>> >The "good enough" mentality would favor a Yugo over a Mercedes.
>>
>> That's what comes from people who don't know how to do their homework, nor
>> even know how to begin to do their own homework.
>>
>> Thanks for proving that your kind exists--everywhere.
>
>So? Gonna put your mouth where your mouth is?
So? What part of "do your OWN FUCKING HOMEWORK" is it that you useless and
highly annoying DSLR-Trolls fail to understand?
You couldn't afford to pay me enough to tell you what I worked so hard to
find out on my own. Be extremely grateful that I already share for free the
little bit I care to share with useless fucks like you. You're not even
worth giving the time of day to if you asked.
LOL!!!!!!!!
Martin Brown
> On Wed, 23 Dec 2009 14:18:59 -0800 (PST), eNo <grande...@gmail.com>
> wrote:
>
>> Here's an article that applies Kevin Maney's "Fidelity vs.
>> Convenience" guide to the RAW vs. JPG question to show why and how
>> each approach is successful.
>>
>> http://esfotoclix.com/blog1/?p=917
>
Another outing of the P&S troll.
>
> First off, many cameras provide the full dynamic range from the sensor's
> RAW data in their JPG files. RAW only became popularized by dSLR owners who
ISTR the early Kodak DC-120 P&S (about �1000 in 1998) was the first
nominally 1Mpixel digital camera to offer true raw sensor data as well
as encapsulated JPGs in its proprietory .KDC image file format. It gave
it a niche market in the scientific imaging community for a while at
least. Its JPEG algorithm was OK, although it did sometimes encode JPEG
files that nothing could decode (about 1:10000 shots). The quality
settings were optimistic and only the highest one was acceptable.
> were complaining that their cameras weren't doing the RAW > JPG conversion
> properly. And many dSLR cameras sold even today still don't do it properly.
This is utter bollocks. The JPEG encoding algorithm is extremely well
understood. You might haggle about problems with autowhite balance, and
gamma correction but not with the JPEG encoding. Several DSLRs use JPEG
settings that lose only tiny fractions of detail mostly inside the high
frequency sensor noise envelope. P&S cameras tend to be slightly more
aggressive in their choice of compression settings.
> You know which cameras those are because their owners are always espousing
> the benefits of RAW. Whereas, many P&S cameras with RAW capability, you'd
> be hard pressed to better the JPG image that comes right from the camera by
> trying to manipulate the original RAW data to equal the JPG image. For
> those cameras which do it right the first time, there really is no need for
> RAW. This of course also depends on the talents of the photographer too. If
> they don't know how to expose an image properly in the first place they are
> always looking for that RAW crutch to back up their lame photography
> skills.
RAW is useful when you need to have the option of handling 12 or 14bit
linear dynamic range. Scientific imaging wants that, and bridal
photography needs it since the cameras internal algorithms struggle in
wedding photography to get the brides white dress and the grooms black
suit both correctly exposed at once. And if the JPEG has burned out
highlights or lost shadow detail you are completely stuffed. RAW is more
flexible for difficult subject material.
>
> Secondly, only MOST editors will degrade a JPG image after editing,
> resaving, reloading, reediting, resaving, et.al. But not ALL editors will
> degrade JPG images during edits and resaves. Photoline does truly lossless
THIS IS COMPLETE AND UTTER BOLLOCKS.
> JPG editing. Not just lossless rotations. Which it also manages to do
> better by keeping any uneven 8x8 block-counts on edges intact. Many
> lossless rotations in other editors truncate images to even multiples of
> 8x8 pixel dimensions. I know of no other editors that can make and back-up
> this lossless JPG editing claim. When using Photoline the only pixels that
> get changed when resaving a JPG file are the ones you specifically choose
> to change. No further JPG artifacts are introduced into the resulting
> image. Unless you specifically choose a JPG compression much lower than the
> original file's compression, thereby intentionally forcing Photoline to put
> your image through the JPG algorithm again.
Any global change like contrast or luminance adjustment forces a
re-encoding of the data and some second generation losses. Fear of this
tiny additional loss is greatly overplayed in the amateur field.
There is no way to losslessly rotate an image which is not a horizontal
multiple of 8 pixels. The defect is in the JPEG standard itself. If an
application appears to do this it either cannot be lossless or it is
displaying some extra "image" which isn't part of the original.
>
> As to what I prefer, JPG or RAW? I prefer to do my homework and make sure
> that I am buying a camera that will do the JPG conversion from its sensor's
> RAW data correctly the first time. Then I don't have to muck about and
> waste my time trying to fix what the camera maker failed to do properly in
> the first place. My photography skills are also good enough that I don't
> have to try to repair badly exposed images by relying on RAW data later.
There are high dynamic range scenes where RAW will win. But FWIW I
normally shoot in JPEG for convenience unless I can see that the subject
material will cause problems because of intrinsic high contrast, or if I
need to do quantitative measurements on the image data later.
> Those who claim otherwise for their photography ... well, that's exactly
> what they are claiming otherwise. They're your typical non-talented
> snapshooter in dire need of any crutch that they can lean on to save them
> from their perpetual crap-shots.
>
> If only they could buy a dSLR with a point and shoot talent-mode built in
> too, they'd be all over it in a heartbeat.
The main advantage of a dSLR is that you can change the lens. Or attache
the camera to a telescope or microscope. And if you already have a
collection of specialist lenses and adapters this is an important
factor. The advent of 10x superzoom has made it a lot easier for would
be nature photographers to choose a more compact P&S camera.
Regards,
Martin Brown
LOL!
<|||newspam|||@nezumi.demon.co.uk> wrote:
>
>> Secondly, only MOST editors will degrade a JPG image after editing,
>> resaving, reloading, reediting, resaving, et.al. But not ALL editors will
>> degrade JPG images during edits and resaves. Photoline does truly lossless
>
>THIS IS COMPLETE AND UTTER BOLLOCKS.
LOL!!!!!!! Holy FUCK are you ever a FUCKING IDIOT!
LOL
>
>> JPG editing. Not just lossless rotations. Which it also manages to do
>> better by keeping any uneven 8x8 block-counts on edges intact. Many
>> lossless rotations in other editors truncate images to even multiples of
>> 8x8 pixel dimensions. I know of no other editors that can make and back-up
>> this lossless JPG editing claim. When using Photoline the only pixels that
>> get changed when resaving a JPG file are the ones you specifically choose
>> to change. No further JPG artifacts are introduced into the resulting
>> image. Unless you specifically choose a JPG compression much lower than the
>> original file's compression, thereby intentionally forcing Photoline to put
>> your image through the JPG algorithm again.
>
>Any global change like contrast or luminance adjustment forces a
>re-encoding of the data and some second generation losses. Fear of this
>tiny additional loss is greatly overplayed in the amateur field.
>
>There is no way to losslessly rotate an image which is not a horizontal
>multiple of 8 pixels. The defect is in the JPEG standard itself. If an
>application appears to do this it either cannot be lossless or it is
>displaying some extra "image" which isn't part of the original.
Proving JUST WHAT A FUCKING IDIOT YOU TRULY ARE!
Thanks!!!
The rest of your complete bullshit goes without comment, there's no reason
to make an even bigger fool of yourself than you already have!
LOL!!!!!!!
DanP
wrote:
> NameHere wrote:
> > On Wed, 23 Dec 2009 14:18:59 -0800 (PST), eNo <grandepat...@gmail.com>
You will never win if you play his game.
He feeds on the long replies he gets.
DanP
NameHere
wrote:
>On Dec 24, 9:18�am, Martin Brown <|||newspam...@nezumi.demon.co.uk>
No, Martin Brown never win simply because he's DEAD FUCKING WRONG.
ANYONE can download the free demo version of Photoline that will prove
through their OWN TESTS, that this Martin Brown is a complete and utter
FUCKING IDIOT AND MORON, who should have never been born and only wastes
the valuable time of people far more intelligent than he'll ever be.
Wasting their valuable time in having to constantly correct his stupidity.
MARTIN BROWN IS A FUCKING USELESS PIECE OF SHIT WASTE OF HUMAN FLESH.
NameHere
wrote:
>On Dec 24, 9:18�am, Martin Brown <|||newspam...@nezumi.demon.co.uk>
No, Martin Brown will never win simply because he's DEAD FUCKING
WRONG--AGAIN! On ALL COUNTS.
bugbear
>
> No, Martin Brown never win simply because he's DEAD FUCKING WRONG.
>
> ANYONE can download the free demo version of Photoline that will prove
> through their OWN TESTS, that this Martin Brown is a complete and utter
> FUCKING IDIOT AND MORON, who should have never been born and only wastes
> the valuable time of people far more intelligent than he'll ever be.
> Wasting their valuable time in having to constantly correct his stupidity.
>
> MARTIN BROWN IS A FUCKING USELESS PIECE OF SHIT WASTE OF HUMAN FLESH.
Touched a nerve, did he?
All that knowledge, detail and analysus, compared to your repetition
of "do your own homework" making you look bad?
Go on - offer something other than assertions, and we'll take you seriously.
BugBear
BD
> And this is all that you useless and lousy DSLR-Trolls have, to try to
> refute everything he said?
That's just it - He hasn't *said* anything! Except that he knows more
than everyone else.!
LOL yerself...
BD
Mmmmmm..... You're my hero..... (really - true story)
Rich
news:hha5j55og59p25fli...@4ax.com:
> On Wed, 23 Dec 2009 14:18:59 -0800 (PST), eNo <grande...@gmail.com>
> wrote:
>
>>Here's an article that applies Kevin Maney's "Fidelity vs.
>>Convenience" guide to the RAW vs. JPG question to show why and how
>>each approach is successful.
>>
>>http://esfotoclix.com/blog1/?p=917
>>
>>~~~
>>eNo
>
> There's a couple glaring errors in your blog.
>
> First off, many cameras provide the full dynamic range from the
> sensor's RAW data in their JPG files. RAW only became popularized by
> dSLR owners who were complaining that their cameras weren't doing the
> RAW > JPG conversion properly. And many dSLR cameras sold even today
> still don't do it properly. You know which cameras those are because
> their owners are always espousing the benefits of RAW. Whereas, many
> P&S cameras with RAW capability, you'd be hard pressed to better the
> JPG image that comes right from the camera by trying to manipulate the
> original RAW data to equal the JPG image.
I'd agree with that. P&S camera images generally have major problems, no
matter what format is utilized.
NameHere
<bugbear@trim_papermule.co.uk_trim> wrote:
>
>Go on - offer something other than assertions, and we'll take you seriously.
Nothing more than "assertions" are needed, you fucking moron. NOTHING that
I will post here will ever convince anyone of anything. Especially all of
you useless resident pretend-photographer trolls who aren't even educated
enough to know who is and is not telling the truth. That is why they HAVE
TO test it for themselves. Only then will they find out what an utter idiot
and lying moron and fool that Martin Brown truly is. What's the matter? You
don't want to find out that the one you call "the troll" is correct and
that some idiot who posts things that look like "facts" is in total error?
Fine by me! Join his ranks too of being an utterly ignorant idiot.
You're ALL FUCKING MORON TROLLS.
C J Campbell
>>
>
> You will never win if you play his game.
> He feeds on the long replies he gets.
>
> DanP
I put him on ignore whenever I see one of his posts. Keeps my blood
pressure a lot lower. I wish everybody else would do it, too.
--
Waddling Eagle
World Famous Flight Instructor
John McWilliams
> You're ALL FUCKING MORON TROLLS.
>
Yeah, yeah, yeah.
Why not take a few minutes and tell us why you're so pissed off. It'll
be empowering for you. Won't break your anonymity, but will start to get
you less pissed off.
But it will take a bit of cajones to start the process.
--
john mcwilliams
John McWilliams
> On 2009-12-24 02:04:55 -0800, DanP <dan....@hotmail.com> said:
>>
>> You will never win if you play his game.
>> He feeds on the long replies he gets.
Make that any reply, or discussion about.
> I put him on ignore whenever I see one of his posts. Keeps my blood
> pressure a lot lower. I wish everybody else would do it, too.
Especially those who ought to know better. Doesn't do anything for my
bp, but it takes an extra couple of minutes per day to killfile threads
he enters.
--
john mcwilliams
Wolfgang Weisselberg
[the slime is pissed]
> All that knowledge, detail and analysus, compared to your repetition
> of "do your own homework" making you look bad?
The slime cannot but hide it's sources and proof: it hasn't
got any.
> Go on - offer something other than assertions, and we'll take you seriously.
No chance --- not in this life or the next. The slime is
truly discredited.
-Wolfgang
David J Taylor
>
> Why not take a few minutes and tell us why you're so pissed off. It'll
> be empowering for you. Won't break your anonymity, but will start to get
> you less pissed off.
>
> But it will take a bit of cajones to start the process.
>
> --
> john mcwilliams
Far better simply not to reply, John.
Ofnuts
> NOTHING that I will post here will ever convince anyone of anything.
Bzzzt. Wrong. You've already convinced us you are a psycho.
For the rest, well, imagine Louis Pasteur going around and saying "Hey
folks, there is no spontaneous generation... You don't believe me? Do
your own homework!" or Einstein: "Hey, mass and energy are equivalent!
YDBM?DYOH!" or Turing: "I've got this nice little machine that can
emulate any computing machinery, provided you have infinite amounts of
time and tape. YDBM?DYOH!". Nobody would have ever heard about them...
--
Bertrand
NameHere
wrote:
Oh, I see. So if I post some examples of rotations and edits done in
Photoline, PROVING that the only pixels that get changed when resaved as a
JPG file are the ones that I intentionally changed, then you'll believe
those images, right? When you idiots can't even accept a whole photo as
evidence of anything? You won't run around yelling, "He edited that to make
it look that way!"
I'm not going to do some very very simple homework for you, that only YOU
alone can do to prove it to yourself. Go download Photoline for free,
www.pl32.net Use it to make a small 21x13 raster-graphic image (non-8x8
pixel blocks). Rotate by 90-degree increments as much as you want. No edge
pixels will get truncated nor changed. Edit one pixel, save it, load it,
resave it, load it again, as many times as you want. Watch that pixel never
change. You have 30 days on the demo to carry out this "complex" task to
prove to yourself what I cannot prove for you by posting my own examples.
Because you lame-assed trolls will just cry "foul" no matter what is
posted. Just as you useless troll fucks always do.
Go shove your useless head back up your useless ass.
Ofnuts
> I'm not going to do some very very simple homework for you, that only YOU
> alone can do to prove it to yourself. Go download Photoline for free,
> www.pl32.net Use it to make a small 21x13 raster-graphic image (non-8x8
> pixel blocks). Rotate by 90-degree increments as much as you want. No edge
> pixels will get truncated nor changed. Edit one pixel, save it, load it,
> resave it, load it again, as many times as you want. Watch that pixel never
> change. You have 30 days on the demo to carry out this "complex" task to
> prove to yourself what I cannot prove for you by posting my own examples.
Ok, so
- installed Photoline (version 15.54, freshly downloaded).
- using another program (Gimp), created a 257x149 (both primes) picture
with a diagonal pattern on it, and saved it as a low quality JPEG
- loaded it in Photoline. Did 4 times:
- rotate 90 degrees clockwise
- save
- close
- load again
So I normally should end up with an image identical to my original.
Well, the image from Photoline is now 256x144. It's missing quite a few
pixels... So, if my homework is wrong, where did I err?
--
Bertrand
NameHere
wrote:
Saving it from GIMP, you stupid gimp.
NameHere
>On Sat, 26 Dec 2009 20:35:24 -0600, NameHere <wh...@address.info>
>wrote:
>LOL!!! So it only works if the original image is *created* in
>Photoline??? So much for using it with photos from any camera.
>
No, you amazingly stupid and pathetically fucking morons. GIMP is what
truncated that image upon saving it through its JPEG compression algorithm.
Are you all so lame that you can't draw a simple raster graphic image right
in Photoline and save it from there? Or you can't even use the cropping or
lasso tools to crop any JPEG image down to a smaller test size and save
that as your test file? The resulting file adheres to all JPEG requirements
and can be viewed in any application that can open JPEG files. Or perhaps
the plethora of raster and vector graphics and conversion options that are
in Photoline are overwhelming your 1+1=2 grade-school level of mentality?
What's the matter? Is it too complex for you to operate the program
properly because all you're used to that beginner's Photoshop crap? Do you
know how to turn on Lanczos-8 for all rotations for data retention? Do you
even know what that's for?
I really have to wonder, why any decent person on earth would EVER want to
help useless fucks like you ever again, once they've had the displeasure
the first time of ever trying to communicate with something as low on the
evolutionary ladder as you people prove yourselves to be--time and time
again.
BD
> I really have to wonder, why any decent person on earth would EVER want to
> help useless fucks like you ever again, once they've had the displeasure
> the first time of ever trying to communicate with something as low on the
> evolutionary ladder as you people prove yourselves to be--time and time
> again.
You sound so cool when you talk like that. What's next... your mom can
beat up everybody else's mom?
Ofnuts
Do your own homework... when I load the original image in Photoline,
Photoline sees it as 257x149... so Gimp encodes it properly for
Photoline (and every picture viewer I tried)... so the pixels are lost
by Photoline (when the file is saved to disk, it seems). Not believing
my eyes, I tried again... same result (and very same MD5 hash...).
Have a go at it, the files are here (when I say something I take the
risk of showing proof): http://dl.free.fr/picxAqaiG
I also can't explain why these two files in the package aren't identical
(they normally contain the very same image, if PL does lossless rotation).
Load GimpOriginal+(Rotate 90CW x 4)+Save.jpg
Load GimpOriginal+(Rotate 90CW+Save Modified+Close+Load Modified)x4.jpg
> Are you all so lame that you can't draw a simple raster graphic image right
> in Photoline and save it from there?
I sure can, and that's where things start to get funny... I create a
257x149 file in Photoline with a diagonal checkers pattern and save it.
Load it back in Photoline: it's still 257x149. Rotate it CW four times
and save a copy. That new file is now 256x144 (for Photoline as well as
for some oiher image readers) (see the PL* files in the package).
> Or you can't even use the cropping or
> lasso tools to crop any JPEG image down to a smaller test size and save
> that as your test file? The resulting file adheres to all JPEG requirements
> and can be viewed in any application that can open JPEG files.
But that doesn't mean it's a "plain" jpeg. There are ways to add data
outside the standard. There would be a doubt. And we don't want to have
any doubts left, do we? You want me to shut the fuck up, overwhelmed by
the evidence, so I put myself in a situation where I would, if things
worked the way you said. However, as mentioned above, I tried also with
a Jpeg created by Photoline, and it gives the same results, so, I
haven't got much doubts left, unless you have a much better explanation
up your sleeve.
> Or perhaps
> the plethora of raster and vector graphics and conversion options that are
> in Photoline are overwhelming your 1+1=2 grade-school level of mentality?
> What's the matter? Is it too complex for you to operate the program
> properly because all you're used to that beginner's Photoshop crap? Do you
> know how to turn on Lanczos-8 for all rotations for data retention? Do you
> even know what that's for?
Yes, but it's of not mundane to 90� rotations.
> I really have to wonder, why any decent person on earth would EVER want to
> help useless fucks like you ever again, once they've had the displeasure
> the first time of ever trying to communicate with something as low on the
> evolutionary ladder as you people prove yourselves to be--time and time
> again.
I would have expected from a great mind like you to know that there is
no such thing as an evolutionary "ladder".
--
Bertrand
NameHere
wrote:
>
>Do your own homework... when I load the original image in Photoline,
>Photoline sees it as 257x149... so Gimp encodes it properly for
>Photoline (and every picture viewer I tried)... so the pixels are lost
>by Photoline (when the file is saved to disk, it seems). Not believing
>my eyes, I tried again... same result (and very same MD5 hash...).
>
>Have a go at it, the files are here (when I say something I take the
>risk of showing proof): http://dl.free.fr/picxAqaiG
I just did. And I'll admit, it does lose a pixel width on 2 sides after
just one 90-degree rotate. I have never seen this behavior before in any
JPG file rotated in Photoline. So I cropped your test image to 135x77 (by
random selection) comprising a dimension of uneven multiples of 8x8. It
remains 135x77 no matter how many times you rotate, save, reload, rotate,
save, reload. Those dimensions are not even a multiple of 4x4, nor 2x2.
By chance alone, you have stumbled on the very first occurrence I've ever
seen of Photoline truncating anything on any JPG rotation of any
proportions. It might have something do to with your selecting two prime
numbers for dimensions. Though I'd hardly call a border of 1 pixel on only
2 sides worthy of claiming much foul, especially on image dimensions that
few if ever would be using or stumble upon. All other editors would
truncate up to 7x7 pixels on all borders.
Try it with any other image dimensions that are not multiples of the 8
pixel block JPG requirement for lossless rotations. I still contend that
Photoline is the only lossless JPG editor on the planet of its advanced
editing capabilities.
Your tests and mine also completely disprove troll Martin Brown's limited
concept of JPG manipulation possibilities. The original reason for starting
this. As well as disproving all the ignorant resident trolls that supported
and agreed with him.
You have yet to edit a pixel or set of pixels and watch them survive
through as many resaves and reloads as you desire. The true strength of
Photoline's lossless JPG editing. For that is what people worry about and
complain about the most when using JPG images for editing purposes. And is
precisely why I let the OP know that he was in error on his blog about how
resaving and reloading any JPG file automatically causes its deterioration.
I'm still correct in that it does not. Not if you use an advanced editor
like Photoline.
I'm still correct on all points, except for your one unique test image of
prime-number dimensions that lost 1 pixel width on two sides. I for one
won't lose any sleep over that.
Ofnuts
> On Sun, 27 Dec 2009 15:11:21 +0100, Ofnuts<o.f.n...@la.poste.net>
> wrote:
>
>>
>> Do your own homework... when I load the original image in Photoline,
>> Photoline sees it as 257x149... so Gimp encodes it properly for
>> Photoline (and every picture viewer I tried)... so the pixels are lost
>> by Photoline (when the file is saved to disk, it seems). Not believing
>> my eyes, I tried again... same result (and very same MD5 hash...).
>>
>> Have a go at it, the files are here (when I say something I take the
>> risk of showing proof): http://dl.free.fr/picxAqaiG
>
> I just did. And I'll admit, it does lose a pixel width on 2 sides after
> just one 90-degree rotate. I have never seen this behavior before in any
> JPG file rotated in Photoline. So I cropped your test image to 135x77 (by
> random selection) comprising a dimension of uneven multiples of 8x8. It
> remains 135x77 no matter how many times you rotate, save, reload, rotate,
> save, reload. Those dimensions are not even a multiple of 4x4, nor 2x2.
>
> By chance alone, you have stumbled on the very first occurrence I've ever
> seen of Photoline truncating anything on any JPG rotation of any
> proportions. It might have something do to with your selecting two prime
> numbers for dimensions.
Indeed... also "works" for 199x151 pixels. And using primes numbers
isn't an excuse. There are good reasons to use primes numbers for sides,
this for instance is more likely to avoid "resonances" or moire effect
with the foreground when used as a tiled background.
> Though I'd hardly call a border of 1 pixel on only
> 2 sides worthy of claiming much foul, especially on image dimensions that
> few if ever would be using or stumble upon. All other editors would
> truncate up to 7x7 pixels on all borders.
Well, first, 144 from 149 isn't exactly one pixel, it's 5. So we go from
257*149=38293 pixels to 256*144=36864 which is more than a 3% pixel
loss. A bit much form a piece of software that is allegedly the most
pixel-respectful picture editor in Known Space. And second, I don't know
of any picture editor in wide use that would shave unexpectedly 7 pixels
off the borders of a picture and still keep the trust of its user
community after such a blatant bug. So if you know of such software in
general use, please tell me which, so I can check that up.
> Try it with any other image dimensions that are not multiples of the 8
> pixel block JPG requirement for lossless rotations. I still contend that
> Photoline is the only lossless JPG editor on the planet of its advanced
> editing capabilities.
Well, I tried, see above.
> You have yet to edit a pixel or set of pixels and watch them survive
> through as many resaves and reloads as you desire. The true strength of
> Photoline's lossless JPG editing. For that is what people worry about and
> complain about the most when using JPG images for editing purposes. And is
> precisely why I let the OP know that he was in error on his blog about how
> resaving and reloading any JPG file automatically causes its deterioration.
> I'm still correct in that it does not. Not if you use an advanced editor
> like Photoline.
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.
> I'm still correct on all points, except for your one unique test image of
> prime-number dimensions that lost 1 pixel width on two sides.
You've still got the math wrong...
> I for one won't lose any sleep over that.
If I were the developer, I would.
--
Bertrand
NameHere
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. 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. 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.
Ofnuts
> On Mon, 28 Dec 2009 13:30:26 +0100, Ofnuts<o.f.n...@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
NameHere
wrote:
>On 28/12/2009 15:07, NameHere wrote:
>> On Mon, 28 Dec 2009 13:30:26 +0100, Ofnuts<o.f.n...@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.
Ofnuts
>
> 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.
Martin Brown
> 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
NameHere
Not at all, you fucking nutter. Do your own tests. You'll find out that
both you and nutter Ofnuts have both misinterpreted the explanations.
No sense trying to educate fools that insist on remaining fools.
Ofnuts
>> Thank you for doing the experiment.
>> It is therefore working exactly as I originally described at the outset.
>>>
>
> Not at all, you fucking nutter. Do your own tests. You'll find out that
> both you and nutter Ofnuts have both misinterpreted the explanations.
So you know better than the developers:
"when you load a JPEG or have an image with appended JPEG data (you can
see this in the attributes dialog on tab layer), PhotoLine rotates 90
degree wise lossless. Lossless rotation has the advantage that image
data don't have to be compressed several times and get worse every time.
It has the disadvantage that only JPEG block wise images can be rotatet"
...and it does work that way. Check this out: create a 100x100 JPG (I
love the diagonal checker texture for these tests). To make things
easier to check, set the JPEG save quality to something not too good,
like 50%. Save and close it.
Test 1: Load the 100x100 into Photoline, rotate it, save it, and lo and
behold, it's now 96x96. 96 happens to be the biggest multiple of 8
smaller than 100.
Test 2: Close the file, load again the original 100x100, in the
attribute dialog, delete the JPEG data, rotate it, save it, and this
rotated version is now an unclipped 100x100.
Test 3: Close the file, load the original 100x100 file, load the
non-clipped, rotated one in an additional layer, delete its JPEG data
(to prevent clipping), rotate it backwards (so it now looks again like
the original one), put it in "difference mode", and you'll see you don't
get a full black image, there are minute differences due to the new
compression artifacts, so the rotated version wasn't the original one
pixel-for-pixel.
Developers: 1, NameHere: 0
--
Bertrand, experimental nutter
NameHere
wrote:
>On 29/12/2009 17:35, NameHere wrote:
>
>>> Thank you for doing the experiment.
>>> It is therefore working exactly as I originally described at the outset.
>>>>
>>
>> Not at all, you fucking nutter. Do your own tests. You'll find out that
>> both you and nutter Ofnuts have both misinterpreted the explanations.
>
>So you know better than the developers:
>
>"when you load a JPEG or have an image with appended JPEG data (you can
>see this in the attributes dialog on tab layer), PhotoLine rotates 90
>degree wise lossless. Lossless rotation has the advantage that image
>data don't have to be compressed several times and get worse every time.
>It has the disadvantage that only JPEG block wise images can be rotatet"
>
>...and it does work that way. Check this out: create a 100x100 JPG (I
>love the diagonal checker texture for these tests). To make things
>easier to check, set the JPEG save quality to something not too good,
>like 50%. Save and close it.
>
>Test 1: Load the 100x100 into Photoline, rotate it, save it, and lo and
>behold, it's now 96x96. 96 happens to be the biggest multiple of 8
>smaller than 100.
Are you using "Save As" or "Save"? Photoline uses its lossless method in
one but not the other. It also will not work if you use a compression
setting more than was used on the original. You did manage to RTFM, didn't
you? Of course not, or you'd know what you are doing wrong.
>
>Test 2: Close the file, load again the original 100x100, in the
>attribute dialog, delete the JPEG data, rotate it, save it, and this
>rotated version is now an unclipped 100x100.
>
>Test 3: Close the file, load the original 100x100 file, load the
>non-clipped, rotated one in an additional layer, delete its JPEG data
>(to prevent clipping), rotate it backwards (so it now looks again like
>the original one), put it in "difference mode", and you'll see you don't
>get a full black image, there are minute differences due to the new
>compression artifacts, so the rotated version wasn't the original one
>pixel-for-pixel.
>
>Developers: 1, NameHere: 0
Then you get to explain why a 135x77 pixel image can be rotated and resaved
as much as you like with no size loss whatsoever, without deleting the JPG
data from the attributes dialog.
Ofnuts: Incompetent Troll 0
NameHere: 1
Ofnuts
Did you read it yourself?
"The function Save As saves the existing JPEG-data as long as they are
smaller than the JPEG-data, that will be created by compressing using
the current JPEG-options. So don�t be surprised, if changing the
JPEG-compression only shows an effect when lowered under a certain value."
Test 1bis:
- Do a file copy of the 100x100 original file, load in PL, rotate, save
- Load original 100x100 file, load in PL, rotate, save as.
- check that the two files are identical (same MD5)
> Then you get to explain why a 135x77 pixel image can be rotated and resaved
> as much as you like with no size loss whatsoever, without deleting the JPG
> data from the attributes dialog.
Is it one you loaded from a JPEG file, or one you created in PL? Has it
got JPEG data displayed in the attributes (which is the condition
triggering the truncation, according to the authors)?
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).
--
Bertrand, amused incompetent reader & homeworker
NameHere
wrote:
>the current JPEG-options. So don�t be surprised, if changing the
>JPEG-compression only shows an effect when lowered under a certain value."
>
>Test 1bis:
>
>- Do a file copy of the 100x100 original file, load in PL, rotate, save
>- Load original 100x100 file, load in PL, rotate, save as.
>- check that the two files are identical (same MD5)
>
>> Then you get to explain why a 135x77 pixel image can be rotated and resaved
>> as much as you like with no size loss whatsoever, without deleting the JPG
>> data from the attributes dialog.
>
>Is it one you loaded from a JPEG file, or one you created in PL? Has it
>got JPEG data displayed in the attributes (which is the condition
>triggering the truncation, according to the authors)?
>
>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.
Enjoy your life of misleading misinformation.
Ofnuts
>>> 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
NameHere
wrote:
Troll troll troll your goat, bandwidth of the stream,
Merrily merrily merrily merrily, you're less than daddy's cream.
I don't have to play your troll's game. I KNOW you are wrong. Anyone else
who tests this for themselves will ALSO know you are 100% wrong.
Go fucking troll someone else for your desperate need for attention. I'm
not going to jump through hoops posting simple examples that ANYONE can do
for themselves to prove you to be nothing but a fuckingly useless waste of
time TROLL.
Chris H
<o.f.n...@la.poste.net> writes
Not going to happen... Seen it many times before you get challenged by a
poster with a fake name/email and they have thousands of reasons which
are all as fake as their email address as to why they can't post.
As some one who has used his real name and email address on line for the
last 20 years I can tell you there is no reason to hide, unless you post
complete crap that would cause you embarrassment if you got identified.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
NameHere
Another troll's manipulation tactic. ANYONE can prove to themselves that
Ofnuts is a TROLL and posting misinformation just for attention, just as
YOU are. You all fuckin' deserve to die. You're a waste of time to the
world.
Ofnuts
So I win the argument by default...
Season's greetings
--
Bertrand
NameHere
wrote:
Yes, you win at being a fuckingly useless TROLL.
Ofnuts
Ooohh... you are still there? I thought I was waste of your time? So,
wasting time for wasting time, where are your files?
--
Bertrand