Prev: genuine fractals
Next: CC photos (flickr) -- CC foto's (flickr)
From: NameHere on 26 Dec 2009 21:35
On Sun, 27 Dec 2009 02:51:12 +0100, Ofnuts <o.f.n.u.t.s(a)la.poste.net>
wrote:

>On 26/12/2009 19:52, NameHere wrote:
>
>> 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?

Saving it from GIMP, you stupid gimp.

From: BD on 27 Dec 2009 05:54

> 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?

From: NameHere on 27 Dec 2009 20:38
On Sun, 27 Dec 2009 15:11:21 +0100, Ofnuts <o.f.n.u.t.s(a)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. 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.


From: Ofnuts on 28 Dec 2009 07:30
On 28/12/2009 02:38, NameHere wrote:
> On Sun, 27 Dec 2009 15:11:21 +0100, Ofnuts<o.f.n.u.t.s(a)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
From: NameHere on 28 Dec 2009 09:07
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. 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.

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: genuine fractals
Next: CC photos (flickr) -- CC foto's (flickr)