Re^4: Testing image output

Neither coders nor decoders are stable

Do you mean the hashing coder/decoder or the image format?

Does your module (can't find it on CPAN) inherit from GD (judging by width/height/jpeg methods)?

Yes, it does use GD. It doesn't inherit from it.

You can't find it on CPAN because it is still in development release. Although the module works under all visual testing, I wanted to get it working with a complete test suite before releasing it publicly.

Yes, the module does use GD::Image-> trueColor( 1 ); and the tests specify $new->jpeg(50) rather than leaving GD to choose the best compression (whatever that means) as the docs say it does. I stayed away from PNG as I know that the exact behaviour of that depends on how GD was built, something that will vary on target machines.

I hadn't thought of using a GD object to perform the comparison...obvious really...thanks...

Comment on Re^4: Testing image output Select or Download Code

Replies are listed 'Best First'.
Re^5: Testing image output by Anonymous Monk on Sep 09, 2023 at 11:23 UTC
GD image file format`[1]` is not an "object", just dumb data stored externally, same as PNG, JPG, TIF, etc. I now see the module on CPAN. Not sure if it's worth re-iterating, what I suggested was no JPGs in `t` folder, because same image file can't be expected to decode to same data. Neither `$new->jpeg(50)` is reliable: `v5.32.1 2.76 d0116830c00ed65dbebfd53afec1dcd0 v5.16.3 2.49 a26bc180a0f0067e00788dee47975324` [download] for `CoventryCathedral.jpg` source, because (1) comment segments are `CREATOR: gd-jpeg v1.0 (using IJG JPEG v90), quality = 50 CREATOR: gd-jpeg v1.0 (using IJG JPEG v80), quality = 50` [download] respectively, and (2) APP0 segment stores aspect ratio for the former, vs. dots-per-inch resolution for the latter, for no obvious reason. +Of course I meant image coders/decoders. `1: https://libgd.github.io/manuals/2.3.3/files/gd_gd-c.html` [download]	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^5: Testing image output
by Anonymous Monk on Sep 09, 2023 at 11:23 UTC

GD image file format[1] is not an "object", just dumb data stored externally, same as PNG, JPG, TIF, etc. I now see the module on CPAN. Not sure if it's worth re-iterating, what I suggested was no JPGs in t folder, because same image file can't be expected to decode to same data. Neither $new->jpeg(50) is reliable:

v5.32.1
2.76
d0116830c00ed65dbebfd53afec1dcd0

v5.16.3
2.49
a26bc180a0f0067e00788dee47975324
[download]

for CoventryCathedral.jpg source, because (1) comment segments are

CREATOR: gd-jpeg v1.0 (using IJG JPEG v90), quality = 50
CREATOR: gd-jpeg v1.0 (using IJG JPEG v80), quality = 50
[download]

respectively, and (2) APP0 segment stores aspect ratio for the former, vs. dots-per-inch resolution for the latter, for no obvious reason. +Of course I meant image coders/decoders.

1: https://libgd.github.io/manuals/2.3.3/files/gd_gd-c.html
[download]

[reply]
[d/l]
[select]