Re^5: Testing image output

Isn't the whole point of the tests to check that the module does what it is supposed to in real situations?

To some extent, the "large image" tests that you are suggesting have nothing to do with the behavior of the specifics of your module, because all the logic of your module can be tested with a 3x1 and a 1x3 image. Whether GD::Image::copyResampled works under every situation is outside of your control -- but it is to be expected that libgd and/or the GD::Image wrapper around that library together have sufficient tests on copyResampled to ensure that it works in any situation they claim it will work.

The copyResampled docs say, "using a weighted average of the pixels of the source area rather than selecting one representative pixel" -- what happens if they decided to slightly tweak the weights used between one version of the library and another, because it gives similar but slightly better results from the visual perspective on certain images? Your test would be looking for the specific results based on factors outside of your control, so two different machines with different versions of libgd might give a different signature, even though the image is still reasonably resized and resampled.

Because the underlying libgd library can be changed without changing the GD wrapper distribution, or the GD wrapper distribution could be changed without changing libgd, you cannot (even if it is possible) just restrict your module to require an exact version of GD -- because the version of GD doesn't guarantee a specific version of the library. So you have no way of restricting to a specific libgd version, and thus no way to guarantee that the underlying behavior of that function will always deterministically give a single known output for a given input, across all versions of the library that might be on a user's machine now or in the future.

The two three-pixel images that I suggested in my github comment seem to me to be immune to such differences, because if you specify the squares so they land on exact pixel boundaries (which is what I did), there should never be a need for averaging/interpolating, and so as far as I can tell, they would not be affected by any reasonable changes to the copyResampled algorithm -- though I might be proven wrong at some point if they got really "creative" with their implementation.

If you are really worried about large images behaving weirdly, I can think of a few options:

Just have one or more large images on your development PC, that you use to test, but don't have them in the repo and don't distribute them when you release (so neither GH Actions nor cpantesters would get them); that way, you can see that they, in general, work, but rely on the test suite of libgd/GD to provide confidence that if it works locally, it will work with reasonable results (though possibly not exactly-equivalent results) on other platforms and/or other versions
Have the two large images in your github repo, and with a variable similar to RELEASE_TESTING, but have it be CONFIDENCE_TESTING or some such to turn on/off that big-image testing. That env-var could be true on your PC or in GH Actions, but not true for smoketesters or the average user; and using MANIFEST.SKIP, you could prevent the large images from being in the distro's tarball, so that it doesn't send huge files to smoketesters or actual users.
If even GH Actions coverage isn't enough to make you confident, you could use GD::Image to generate two large-dimension images -- and since your library even includes the ability to run Image::Square->new($gd) , you don't even need the ability to write to a temporary file like I was originally thinking (plus it gives you coverage for new-from-GD instead of only new-from-file, which is a free bonus from doing it that way). For example, if you made a grid of 144 different-colored 120x120 squares in a 16x9 or 9x16 pattern (to get your vertical and horizontal aspect ratios), you could then pick a few different squares that could still be deterministic: by picking the correct ->square(1080/$n,$pos) , you could pick downscaling-factor $n and offset-factor $pos in such a way that the down-sampled squares have a portion in their middle that should be consistently the right color. It might take some experimentation, but I think you could craft one that would be enough to verify it's working with a large image, hopefully without running into problems with variations in the algorithm.

(I was originally leaning towards #1 or at most #2, but as I started writing the description #3, I realized that if it were my project, that's the direction I'd go.)

edit: finished a dangling sentence, and rephrased slightly.

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

Replies are listed 'Best First'.
Re^6: Testing image output by Bod (Parson) on Sep 15, 2023 at 23:05 UTC
it is to be expected that libgd and/or the GD::Image wrapper around that library together have sufficient tests on `copyResampled` to ensure that it works in any situation they claim it will work I think that's the key... I have been getting too focussed on testing everything but I don't need to test the things that are out of the control of my module! Following on from your 3 points I have tried this approach... use strict; use warnings; use Test::More; use GD::Simple; use Image::Square; plan tests => 3; my $horizontal = GD::Simple->new(160, 90, 1); $horizontal->bgcolor('red'); $horizontal->rectangle(10,10,150,80); my $left = GD::Simple->new(90, 90, 1); $left->bgcolor('red'); $left->rectangle(10,10,90,80); my $center = GD::Simple->new(90, 90, 1); $center->bgcolor('red'); $center->rectangle(0,10,90,80); my $right = GD::Simple->new(90, 90, 1); $right->bgcolor('red'); $right->rectangle(0,10,80,80); my $square = Image::Square->new($horizontal->gd); my $im_left = $square->square(0, 0); cmp_ok($im_left->png, 'eq', $left->png, 'left image'); my $im_center = $square->square(0, 0.5); cmp_ok($im_center->png(5), 'eq', $center->png(5), 'center image'); my $im_right = $square->square(0, 1); cmp_ok($im_right->png(5), 'eq', $right->png(5), 'right image'); [download] Drawing a rectangle with a smaller, red rectangle inside it. Then drawing the three parts of this simple shape and comparing them to the output from Image::Square. This works for the left image but not centre or right. Examining the image files, the output from Image::Square is one byte less. Not doubt from `copyResampled`. Given your excellent point about libgd and GD::Image being tested, I don't think it is worth me testing the images other than to ensure they are the expected dimensions.	[reply] [d/l] [select]
Re^7: Testing image output by Anonymous Monk on Sep 16, 2023 at 11:02 UTC
Not doubt from copyResampled. No. It's from you :-) -- not providing a line of code for stroke not being drawn. The `copyResampled` deficiencies discussed previously are not applicable if there's no scaling. It works as simple copy then, all tests are passed. I think the intention to test for correct image content was commendable, it's sad if you give up, though it's your module of course. With no scaling, tests must pass, if just one fails then GD is paperweight, sorry. Somewhat tangential, in code above you overshoot by 1 px i.e. address coordinate outside canvas, drawing rectangle for e.g. `$center`. Similarly, for `$horizontal`, rectangle clearly intended to be centered being NOT centered hurts my eyes badly :-). "5" in `png(5)` is a bit sore in the eye also Further off topic and pure speculation: I doubt that vague description of `copyResampled` is there to perpetually tweak/improve. It simply stems from long time ago when no solid and well understood (and correct) interpolation methods were implemented in GD. Anything better that nearest neighbour to avoid jagged lines was welcome. Then something close to bilinear scaling was quickly added. Though even then this method was not state-of-the-art, implemented elsewhere, described in papers, etc. Now completely off topic: checking your test failures, I was unfortunate to investigate how rectangle is stroked in GD. Looks like for lines thicker than 1 px, vertical fragments are drawn 1 px wider than horizontal fragments. It doesn't happen for stand-alone lines (left side in picture below), only for rectangles. Am I missing something? Or is it a bug? All the time being present there, for 30 or so years, then? Thing as simple as stroked frame... So much about expecting that libgd and/or the GD::Image wrapper around that library together have sufficient tests ... to ensure that it works in any situation they claim it will work use strict; use warnings; use GD; sub dump_red { my $gd = shift; my ( $w, $h ) = $gd-> getBounds; for my $y ( 0 .. $h - 1 ) { for my $x ( 0 .. $w - 1 ) { my ( $r ) = $gd-> rgb( $gd-> getPixel( $x, $y )); printf $r ? ( '%02x ', $r ) : '.. '; } print "\n"; } } my $i = GD::Image-> new( 23, 15, 1 ); my $r = $i-> colorAllocate( 255, 0, 0 ); $i-> line( 1, 2, 5, 2, $r ); $i-> line( 1, 9, 1, 13, $r ); $i-> rectangle( 7, 2, 10, 11, $r ); $i-> setThickness( 3 ); $i-> line( 1, 5, 5, 5, $r ); $i-> line( 4, 9, 4, 13, $r ); $i-> rectangle( 13, 2, 20, 11, $r ); dump_red( $i ); __END__ .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ff ff ff ff ff ff ff ff ff ff .. .. ff ff ff ff ff .. ff ff ff ff .. ff ff ff ff ff ff ff ff ff ff .. .. .. .. .. .. .. .. ff .. .. ff .. ff ff ff ff ff ff ff ff ff ff .. .. ff ff ff ff ff .. ff .. .. ff .. ff ff ff ff .. .. ff ff ff ff .. .. ff ff ff ff ff .. ff .. .. ff .. ff ff ff ff .. .. ff ff ff ff .. .. ff ff ff ff ff .. ff .. .. ff .. ff ff ff ff .. .. ff ff ff ff .. .. .. .. .. .. .. .. ff .. .. ff .. ff ff ff ff .. .. ff ff ff ff .. .. .. .. .. .. .. .. ff .. .. ff .. ff ff ff ff .. .. ff ff ff ff .. .. ff .. ff ff ff .. ff .. .. ff .. ff ff ff ff .. .. ff ff ff ff .. .. ff .. ff ff ff .. ff .. .. ff .. ff ff ff ff ff ff ff ff ff ff .. .. ff .. ff ff ff .. ff ff ff ff .. ff ff ff ff ff ff ff ff ff ff .. .. ff .. ff ff ff .. .. .. .. .. .. ff ff ff ff ff ff ff ff ff ff .. .. ff .. ff ff ff .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. [download]	[reply] [d/l] [select]