From: Ofnuts on
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
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
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
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
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