Hi,
I plan to add imagecompare to the gd extension. No problem so far however a little discussion of the returned value
https://github.com/php/php-src/pull/14877#issuecomment-2217686123
I personally see a value of a bitmask rather than just boolean which is not harder to handle than imagetypes.
Let me know your thoughts.
Cheers.
Boolean is a much more confusing value here. A bit mask is ok, but I would prefer a better solution. Maybe a simple value object?
Hi,
On Tue, 9 Jul 2024 at 17:59, Kamil Tekiela <tekiela246@gmail.com> wrote:
Boolean is a much more confusing value here. A bit mask is ok, but I would prefer a better solution. Maybe a simple value object?
That could be an option too sure.
Hi David,
Hi,
I plan to add imagecompare to the gd extension. No problem so far however a little discussion of the returned value
ext/gd adding imagecompare. by devnexen · Pull Request #14877 · php/php-src · GitHub
I personally see a value of a bitmask rather than just boolean which is not harder to handle than imagetypes.
Let me know your thoughts.
Cheers.
If the return value is bool, does this mean that it will be true if the comparison targets are exactly the same, and false if there is even one difference? In other words, will we no longer be able to see where the differences were?
Regards,
Saki
Hi Saki.
On Tue, 9 Jul 2024 at 17:49, Saki Takamachi <saki@sakiot.com> wrote:
Hi David,
Hi,
I plan to add imagecompare to the gd extension. No problem so far however a little discussion of the returned value
https://github.com/php/php-src/pull/14877#issuecomment-2217686123
I personally see a value of a bitmask rather than just boolean which is not harder to handle than imagetypes.
Let me know your thoughts.
Cheers.
If the return value is bool, does this mean that it will be true if the comparison targets are exactly the same, and false if there is even one difference? In other words, will we no longer be able to see where the differences were?
It seems to be the opposite regarding his proposition gdImageCompare(im1, im2) & GD_CMP_IMAGE. Then yes you are right, we are losing the specifics. If you want to figure out how the image 1 and image 2 differ, you need to use the rest of the api e.g. imagecolortransparent and all that jazz … A bit too complex I feel.
Regards,
Saki
Hi David,
It seems to be the opposite regarding his proposition gdImageCompare(im1, im2) & GD_CMP_IMAGE. Then yes you are right, we are losing the specifics. If you want to figure out how the image 1 and image 2 differ, you need to use the rest of the api e.g. imagecolortransparent and all that jazz … A bit too complex I feel.
Thanks for the explanation.
What I think is important to note here is that there are two types of users who will use this feature:
- Users who simply want to know if there is a match (i.e. a bool return value is sufficient)
- Users who want to know the details of the differences
The object return type that Kamil mentioned was something I was considering as well, but I was concerned that it would be a bit verbose for type 1 users and would necessarily incur the overhead of object creation. (This is probably an unnecessary concern, as image analysis takes much longer.)
Regards,
Saki
On Tue, 9 Jul 2024 at 18:31, Saki Takamachi <saki@sakiot.com> wrote:
Hi David,
It seems to be the opposite regarding his proposition gdImageCompare(im1, im2) & GD_CMP_IMAGE. Then yes you are right, we are losing the specifics. If you want to figure out how the image 1 and image 2 differ, you need to use the rest of the api e.g. imagecolortransparent and all that jazz … A bit too complex I feel.
Thanks for the explanation.
What I think is important to note here is that there are two types of users who will use this feature:
- Users who simply want to know if there is a match (i.e. a bool return value is sufficient)
True. Anyhow, such users can always do imagecompare($im1, $im2) & IMG_CMP_IMAGE themselves eventually.
- Users who want to know the details of the differences
The object return type that Kamil mentioned was something I was considering as well, but I was concerned that it would be a bit verbose for type 1 users and would necessarily incur the overhead of object creation. (This is probably an unnecessary concern, as image analysis takes much longer.)
Agreed, I ll likely just commit as is sometime this week.
Cheers.
Regards,
Saki
Hi
Yes, please no more global constants with names that are shortened beyond all recognition.
On 7/9/24 18:59, Kamil Tekiela wrote:
Boolean is a much more confusing value here. A bit mask is ok, but I would
prefer a better solution. Maybe a simple value object?
If it's "simple" then it would also be unwieldy to use. To me the obvious modern alternative would be a list of enum cases that represent the differences, with an empty array meaning no differences. The function should probably be renamed 'imagediff()' or similar then.
namespace Gd;
enum ImageDifference {
case Height;
case Width;
case AlphaChannel; // or: case Transparency
case Interlacing;
// ...
}
Best regards
Tim Düsterhus